Biến quy trình thành công cụ

Có những bảng tính chỉ một người trong nhóm thực sự hiểu. Công thức nhìn thấy được, nhưng lý do đằng sau chúng nằm trong trí nhớ: cột này được sửa sau giờ chốt đơn, dòng kia giữ lại vì khách có thể đổi ý, con số cuối cùng phải kiểm tra thêm trong một cuộc trò chuyện.

Nhờ agent biến bảng ấy thành ứng dụng có vẻ là một bước tiến rõ ràng. Tuy nhiên, nếu những quy ước ngầm chưa được làm sáng tỏ, phần mềm mới chỉ giúp thực hiện sự mơ hồ nhanh hơn. Việc đầu tiên đáng làm thường là tìm ra quy trình thật đang vận hành bên dưới các ô dữ liệu.

Công cụ bắt đầu từ hiểu biết về công việc

Trong “Vibe Coding Hardware”, đăng ngày 28/05/2026 trên nav.al, Blake Scholl kể về việc đưa những luồng kỹ thuật vốn nằm trong bảng tính vào phần mềm có thể lặp lại. Ông mô tả vai trò phối hợp giữa người xây kiến trúc phần mềm và chuyên gia lĩnh vực. Bài này lấy quan sát ấy làm điểm khởi hành để phân tích một quy trình nhỏ trong bối cảnh Việt Nam, với tình huống hoàn toàn giả định.

Phần có thể mang theo không nằm ở quy mô của công ty trong câu chuyện. Nó nằm ở câu hỏi: người hiểu nghiệp vụ đang biết điều gì mà công cụ hiện tại chưa thể hiện được? Một quy tắc được diễn đạt rõ có thể trở thành điều kiện kiểm tra. Một ngoại lệ được nhận diện có thể trở thành bước dừng đúng lúc.

Hiểu biết ấy khác với khả năng sử dụng một phần mềm thành thạo. Bạn có thể rất nhanh trong việc sửa bảng tính nhưng chưa từng phải giải thích vì sao một trường hợp được xử lý khác đi. Quá trình tạo công cụ sẽ buộc những phân biệt đó xuất hiện.

Vẽ một đơn hàng đi qua hệ thống

Giả sử một cửa hàng nhỏ nhận đơn từ tin nhắn, ghi sản phẩm vào bảng tính và đối chiếu khoản chuyển bằng tệp tải về. Mỗi tối, một người ghép ba nguồn ấy để biết đơn nào có thể giao. Mục tiêu ban đầu có thể chỉ là tạo danh sách những đơn đủ thông tin để kiểm tra lần cuối.

Hãy đi theo một đơn từ lúc xuất hiện đến lúc hoàn tất. Ai tạo mã đơn? Khi nào số tiền được coi là đúng? Một khách chuyển cho hai đơn thì ghi nhận thế nào? Nếu tiền đã đến nhưng khách đổi sản phẩm, trạng thái nào cần được giữ lại? Những câu hỏi này giúp phân biệt dữ liệu, quyết định và hành động.

Dữ liệu là điều đã ghi nhận: nội dung đơn, số tiền, thời điểm. Quyết định là cách diễn giải dữ liệu: khoản này có thuộc về đơn kia không? Hành động là việc tiếp theo: đưa đơn vào danh sách chuẩn bị hàng. Tách ba lớp giúp công cụ hỗ trợ kiểm tra mà chưa phải tự thực hiện mọi hành động sau đó.

Một sơ đồ chỉ có “nhận đơn → thu tiền → giao hàng” thường chưa đủ. Các bước chờ và các đường quay lại mới cho thấy công việc thực sự khó ở đâu.

Đặt tên cho trạng thái thay vì sửa tay kết quả

Trong bảng tính, người dùng có thể đổi một ô từ chưa xử lý sang xong. Trong công cụ, chữ xong cần có nghĩa cụ thể. Đã tìm thấy khoản chuyển? Đã được một người xác nhận? Hay đã giao hàng? Nếu cả ba cùng dùng một nhãn, người tiếp quản sẽ khó biết cần làm gì.

Có thể bắt đầu với những trạng thái ít nhưng rõ: thiếu thông tin, chờ đối chiếu, có đề xuất khớp và đã được xác nhận. Đây chỉ là ví dụ cho tình huống giả định, không phải bộ trạng thái áp dụng cho mọi cửa hàng. Điều quan trọng là mỗi lần chuyển trạng thái có một căn cứ và một người hoặc quy trình chịu trách nhiệm.

Một khoản tiền khớp về số lượng chưa chắc đã khớp về danh tính. Hai đơn cùng giá trị có thể xuất hiện trong một ngày. Khi thiếu căn cứ, kết quả hữu ích là đưa cả hai vào danh sách cần xem lại, kèm lý do chưa thể chọn. Tự tin sai dễ gây nhiều việc sửa hơn một lời báo chưa đủ thông tin.

Viết ngoại lệ trước khi yêu cầu agent triển khai

Người làm nghiệp vụ thường nhớ những ca khó đã từng gặp. Đó là một tài sản tốt để thiết kế công cụ. Thay vì chỉ mô tả trường hợp thuận lợi, hãy tạo dữ liệu mẫu cho từng ngoại lệ: mã đơn bị thiếu, cùng một dòng xuất hiện hai lần, khoản tiền bị tách thành hai lần chuyển, khách đổi yêu cầu sau khi đã xác nhận.

Với mỗi ca, viết đầu ra mong đợi và giải thích ngắn vì sao. Chẳng hạn, hai dòng trùng mã giao dịch phải được đánh dấu để kiểm tra, không được cộng thành hai khoản riêng. Nếu công cụ chạy lại cùng một tệp, nó cần cho kết quả nhất quán thay vì tạo thêm những bản ghi tương đương.

Bộ ví dụ này có hai chức năng. Nó giúp agent hiểu quy tắc và giúp người dùng kiểm tra phiên bản mới. Khi thay một điều kiện, bạn sẽ biết những trường hợp trước đây làm đúng còn được giữ lại hay không.

Chọn một đoạn nhỏ có thể quay lại cách cũ

Một bản thử đầu tiên có thể chỉ nhận hai tệp dữ liệu giả và xuất ra tệp đối chiếu mới. Nó chưa cần gửi tin nhắn cho khách, ghi đè dữ liệu gốc hoặc thay toàn bộ hệ thống bán hàng. Phạm vi nhỏ giúp thấy rõ phần nào đúng và giảm số nơi phải tìm khi có lỗi.

Người vận hành vẫn làm theo quy trình cũ trong giai đoạn so sánh. Mỗi chênh lệch giữa hai cách là một câu hỏi cần giải thích. Công cụ sai quy tắc, dữ liệu đầu vào bị thiếu, hay chính cách làm cũ đang dựa vào một thông tin chưa được ghi lại?

Chỉ khi hiểu được các chênh lệch ấy mới có cơ sở để mở rộng. Một lần đối chiếu trùng khớp chưa cho biết công cụ có xử lý được ngày có hoàn tiền, đổi đơn hoặc nhập trùng dữ liệu hay không.

Chi phí nằm cả ở tháng sau

Một công cụ nhỏ vẫn cần người giữ gìn. Tệp đầu vào có thể đổi tên cột. Người trong nhóm có thể sử dụng một ký hiệu mới. Máy chạy công cụ có thể được thay. Nếu không ai biết cách nhận diện và xử lý những thay đổi ấy, thời gian tiết kiệm hôm nay có thể trở thành sự phụ thuộc khó chịu sau này.

Vì thế, bản bàn giao nên nói được công cụ nhận dữ liệu gì, tạo ra gì, báo lỗi ở đâu và cách quay lại quy trình thủ công. Quy tắc cần được ghi cạnh ví dụ, thay vì chỉ nằm trong một đoạn trao đổi với agent mà người tiếp quản không tìm thấy.

Cũng có lúc một biểu mẫu thống nhất hoặc vài quy ước đặt mã đã giải quyết đủ vấn đề. Làm rõ công việc rồi nhận ra chưa cần viết phần mềm vẫn là một kết quả có ích. Quy trình tốt phục vụ người vận hành; họ không có nghĩa vụ duy trì thêm một ứng dụng chỉ vì đã xây được nó.

Một cách bắt đầu vào sáng mai

Chọn một thao tác phải lặp lại trong tuần. Quan sát một lần làm thật và ghi các quyết định mà người thực hiện phải đưa ra. Lấy dữ liệu giả, viết một trường hợp bình thường và vài ngoại lệ có ý nghĩa, rồi nhờ agent tạo đúng một bước hỗ trợ.

Khi dùng thử, hãy giữ câu hỏi này ở trước mặt: một người khác có thể giải thích vì sao công cụ tạo ra kết quả ấy không? Nếu câu trả lời chưa rõ, việc cần làm tiếp theo có thể là viết lại quy tắc. Phần mềm trở nên đáng tin hơn khi hiểu biết về công việc đã có một nơi rõ ràng để tồn tại.