THÊM MỘT ĐÊM MẤT NGỦ VÌ AI

Chiều qua, tôi bắt tay vào cùng xây dựng 1 Web app Google Apps Script cho khách hàng doanh nghiệp đang tham gia chương trình AI Transformation. Đây vừa là để giải quyết vấn đề trước mắt cũng vừa để nâng cao năng lực quản trị AI Agents như 1 nhân sự số. Mục tiêu ban đầu là tạo một hệ thống giúp doanh nghiệp quản lý hoạt động của nhiều chi nhánh thống nhất hơn, giảm bớt việc báo cáo thủ công và giúp lãnh đạo có đủ dữ liệu để ra quyết định.

Ứng dụng dự kiến giải quyết ba nhóm nhu cầu chính.

Đầu tiên là chuẩn hóa báo cáo chi nhánh. Thay vì mỗi nơi gửi một kiểu, người nhập Excel, người nhắn Zalo, người chụp ảnh sổ tay, ứng dụng sẽ cung cấp các biểu mẫu thống nhất cho doanh thu hằng ngày, tồn kho, tình hình nhân sự, sự cố vận hành và những chỉ số quan trọng khác. Dữ liệu đi vào cùng một cấu trúc thì người quản lý mới có thể tổng hợp, đối chiếu và phát hiện vấn đề mà không phải mất thêm vài giờ dọn dẹp những bảng báo cáo vốn được tạo ra với một niềm tin rất lạc quan rằng người nhận sẽ tự hiểu.

Nhóm nhu cầu thứ hai là phổ biến quy trình. Ứng dụng sẽ trở thành một dạng “sổ tay vận hành số”, nơi nhân viên có thể tra cứu quy trình làm việc, biểu mẫu, hướng dẫn và checklist ngay khi cần. Nhân viên mới không phải hỏi lại từng việc nhỏ. Các chi nhánh cũng không phải giữ những bản quy trình cũ đã in từ nhiều tháng trước. Khi có thay đổi, doanh nghiệp chỉ cần cập nhật một phiên bản trên hệ thống.

Nhóm thứ ba là quản lý KPI, thưởng, phạt và các điểm vi phạm một cách minh bạch hơn. Nhân viên hoặc quản lý chi nhánh có thể thấy doanh số hiện tại, mức thưởng dự kiến, các lỗi phát sinh và số điểm bị trừ trong tháng. Khi số liệu được cập nhật rõ ràng, phòng nhân sự bớt phải giải thích đi giải thích lại, người lao động cũng có căn cứ để kiểm tra thay vì chỉ nhận một kết quả cuối cùng mà không biết nó được tính như thế nào.

Tôi đặc biệt quan tâm đến việc giảm gánh nặng báo cáo cho nhân sự. Trước đây, mỗi lần đi làm ở một tổ chức nào đó, báo cáo luôn là phần tôi cực kỳ không thích. Không hẳn vì báo cáo không cần thiết, mà vì rất nhiều hệ thống báo cáo buộc người làm phải nhập lại những dữ liệu đã tồn tại ở nơi khác, trình bày cùng một nội dung theo nhiều định dạng hoặc dành quá nhiều thời gian phục vụ việc tổng hợp hơn là công việc thực tế.

Vì vậy, yêu cầu quan trọng của ứng dụng là mỗi cấp nhân sự chỉ nhìn thấy đúng phần dữ liệu thuộc phạm vi trách nhiệm của mình. Nhân viên thấy công việc và kết quả của cá nhân. Quản lý chi nhánh thấy toàn bộ hoạt động của chi nhánh. Bộ phận chức năng xem được dữ liệu liên quan đến chuyên môn của họ. Lãnh đạo có cái nhìn tổng thể về toàn hệ thống để ra quyết định dựa trên dữ liệu thay vì dựa vào báo cáo rời rạc, ký ức hoặc cảm nhận chủ quan.

Mục tiêu nghe khá ổn. Logic vận hành ban đầu cũng đã được phác thảo. Tôi bắt đầu giao việc cho AI agent triển khai từng phần.

Đến khuya, hạn mức sử dụng của agent gần như đã hết. Tôi định dừng lại và đi ngủ. Nhưng nằm trên giường một lúc vẫn không ngủ được vì đầu óc còn mắc ở những phần chưa hoàn thành. Cuối cùng, tôi lại dậy, mở máy và nâng cấp gói thuê bao để tiếp tục làm.

Một quyết định rất con người: trả thêm tiền để được tiếp tục mất ngủ hiệu quả hơn.

Sau khi làm thêm một hồi, tôi bắt đầu nhận ra vấn đề. Agent vẫn làm việc chăm chỉ, thậm chí quá chăm chỉ. Nó tiếp tục tạo bảng, sửa cấu trúc, kiểm tra công thức, đề xuất cách phân quyền và thử nhiều phương án kết nối. Tuy nhiên, tốc độ tiêu hao hạn mức lại cao hơn nhiều so với tiến độ thực tế.

Nguyên nhân nằm ở cách tôi khởi động dự án.

Từ đầu, tôi đã xác định mục tiêu và mô tả khá kỹ logic vận hành, nhưng chưa thiết lập đầy đủ các ranh giới của hệ thống. Quyền quyết định chưa được chốt rõ. Tài khoản nào sẽ sở hữu ứng dụng chưa được thống nhất. Phạm vi dữ liệu từng vai trò được truy cập vẫn còn một số điểm mơ hồ. Những giới hạn của AppSheet, API và các lớp kết nối cũng chưa được khảo sát đủ sớm.

Một số giới hạn tưởng như chỉ là chi tiết kỹ thuật, như cách tổ chức dữ liệu, cơ chế phân quyền, tài khoản sở hữu ứng dụng hay khả năng kết nối với hệ thống bên ngoài, lại có thể làm thay đổi toàn bộ kiến trúc dự án.

Khi những điểm này chưa rõ, agent vẫn có thể làm. Nó chỉ phải liên tục giả định, thử nghiệm, quay lại sửa và tạo thêm các nhánh giải pháp. Kết quả là dự án tiêu tốn nhiều thời gian, nhiều token và nhiều công sức hơn mức cần thiết.

Tôi dừng việc triển khai trực tiếp và quay lại hệ thống hóa toàn bộ dự án từ đầu.

May mắn là trong suốt quá trình trước đó, tôi luôn yêu cầu các agent ghi nhật ký làm việc khá kỹ: đã tạo gì, sửa gì, thử phương án nào, lỗi xuất hiện ở đâu, quyết định nào đã được thông qua và phần nào còn bỏ ngỏ. Nhờ vậy, việc làm lại không đồng nghĩa với việc xóa sạch và bắt đầu từ con số không. Những phần có giá trị được giữ lại, các giả định sai được loại bỏ, còn các điểm chưa rõ được đưa thành những cổng quyết định cụ thể.

Sau khi chuyển sang workflow mới, tiến độ thay đổi rõ rệt. Agent không còn lao ngay vào xây dựng. Nó kiểm tra điều kiện trước, chỉ ra thông tin còn thiếu, cảnh báo những quyết định có thể ảnh hưởng đến kiến trúc và chỉ triển khai khi đã đi qua từng cổng cần thiết.

Từ trải nghiệm này, tôi chốt lại một workflow gồm tám cổng cho các dự án sử dụng AI agent.

Cổng 1. Chốt bài toán và kết quả cần đạt

Trước khi nói đến công cụ, phải trả lời được ai sẽ sử dụng hệ thống, vấn đề vận hành nào đang cần giải quyết và kết quả nào chứng minh dự án đã thành công.

Với ứng dụng này, thành công không thể chỉ được mô tả là “xây xong một app”. Kết quả cần đo được bằng những thay đổi cụ thể hơn: báo cáo chi nhánh được chuẩn hóa, thời gian tổng hợp số liệu giảm, nhân viên tra cứu được quy trình, dữ liệu KPI minh bạch và người quản lý có đủ thông tin để ra quyết định.

Bên cạnh mục tiêu, cần chốt cả phạm vi chủ động loại ra. Phiên bản đầu tiên chưa nhất thiết phải giải quyết mọi nghiệp vụ, tích hợp mọi hệ thống hoặc tự động hóa toàn bộ công việc. Một dự án không có ranh giới rất dễ biến thành một danh sách mong muốn kéo dài vô hạn.

Cổng 2. Chốt người có quyền quyết định

Một hệ thống có thể có nhiều người sử dụng, nhiều người góp ý và nhiều bộ phận bị ảnh hưởng, nhưng cần có một người hoặc một vai trò chịu trách nhiệm quyết định cuối cùng.

Ai là chủ sở hữu ứng dụng? Ai duyệt cấu trúc quy trình? Ai phê duyệt quyền truy cập dữ liệu? Khi yêu cầu của phòng nhân sự xung đột với yêu cầu của quản lý chi nhánh, ai có quyền chốt phương án?

Trong dự án vừa rồi, vấn đề tài khoản email nào sẽ sở hữu AppSheet tưởng như chỉ là một chi tiết kỹ thuật. Thực tế, nó ảnh hưởng trực tiếp đến khả năng quản trị, chuyển giao, thanh toán, bảo mật và quyền kiểm soát hệ thống về sau.

Nếu quyền quyết định chưa rõ, agent sẽ nhận được nhiều chỉ dẫn khác nhau và vẫn cố gắng làm hài lòng tất cả. Đây là một cách rất hiệu quả để tạo ra một hệ thống phức tạp mà không ai thực sự chịu trách nhiệm.

Cổng 3. Kiểm tra điều kiện tiên quyết

Trước khi xây dựng, cần kiểm tra tài khoản, giấy phép, dữ liệu, quyền truy cập, yêu cầu bảo mật và những đầu vào còn thiếu.

Mỗi điều kiện quan trọng nên gắn với một điểm dừng rõ ràng. Nếu chưa có tài khoản sở hữu chính thức, dự án có thể thiết kế nhưng chưa nên triển khai trên hệ thống thật. Nếu chưa có quy định phân quyền, chưa nên kết nối dữ liệu nhân sự. Nếu dữ liệu mẫu chưa đủ gần thực tế, chưa nên đánh giá hiệu quả của báo cáo.

Điểm dừng không làm dự án chậm hơn. Nó ngăn đội ngũ dành ba ngày xây một thứ phải sửa lại vì một điều kiện lẽ ra cần được phát hiện trong ba mươi phút đầu tiên.

Cổng 4. Vẽ quy trình nghiệp vụ và mô hình dữ liệu

Khi điều kiện cơ bản đã đủ, cần mô tả rõ người nào làm gì, dữ liệu được tạo ra ở đâu, ai được xem, ai được sửa, ai có quyền duyệt và trạng thái của một bản ghi sẽ thay đổi như thế nào.

Ví dụ, một báo cáo sự cố có thể bắt đầu từ nhân viên, chuyển sang quản lý chi nhánh xác nhận, sau đó phòng nhân sự hoặc ban điều hành xử lý. Mỗi trạng thái cần có người chịu trách nhiệm, thời hạn và hành động tiếp theo.

Đây cũng là lúc xác định mối quan hệ giữa các bảng dữ liệu: nhân viên thuộc chi nhánh nào, KPI được tính theo cá nhân hay đơn vị, một lỗi vi phạm liên quan đến ai, dữ liệu doanh thu được tổng hợp theo ngày, ca làm việc hay người thực hiện.

Một giao diện đẹp không cứu được một mô hình dữ liệu lộn xộn. Đến khi doanh nghiệp muốn mở rộng, mọi lỗi cấu trúc ban đầu sẽ quay lại, thường vào lúc ít ai còn nhớ vì sao hệ thống được thiết kế như vậy.

Cổng 5. Khảo sát khả năng của công cụ

Chỉ sau khi hiểu quy trình và dữ liệu, chúng ta mới nên đánh giá công cụ nào làm được phần nào, giới hạn nằm ở đâu và giả định kỹ thuật nào cần được kiểm tra.

AppSheet có thể phù hợp với nhiều quy trình nội bộ, nhưng vẫn có giới hạn về phân quyền, cấu trúc dữ liệu, tích hợp và khả năng mở rộng. API có thể mở thêm khả năng tự động hóa, nhưng cũng tạo ra yêu cầu mới về bảo mật và vận hành. MCP, tức lớp kết nối giúp AI truy cập công cụ và dữ liệu, có thể hỗ trợ agent hành động, nhưng bản thân nó chỉ là đường ống. Đường ống rất tốt vẫn không giúp ích nhiều nếu chưa biết dữ liệu nào cần chảy qua và chảy về đâu.

Ở bước này, nên thực hiện những thử nghiệm kỹ thuật nhỏ trước khi cam kết kiến trúc. Một lát cắt thử nghiệm mười lăm phút đôi khi có giá trị hơn một bản kế hoạch triển khai dài hai mươi trang được xây trên một giả định chưa từng kiểm chứng.

Cổng 6. Chọn kiến trúc và chỉ kết nối công cụ cần thiết

Sau khi biết công cụ làm được gì, mới quyết định hệ thống sẽ gồm những thành phần nào, dữ liệu nằm ở đâu và các công cụ kết nối với nhau bằng cách nào.

Nguyên tắc tôi chọn là vừa đủ và đúng lúc. Chỉ kết nối những công cụ thực sự cần cho phiên bản hiện tại. Không mở hàng loạt quyền truy cập chỉ vì có thể. Không đưa toàn bộ dữ liệu doanh nghiệp vào phạm vi hoạt động của agent khi agent chỉ cần xử lý một bảng cụ thể.

Kết nối sớm thường tạo cảm giác dự án đang tiến triển nhanh. Thực tế, nó làm tăng bề mặt rủi ro, số lượng điểm lỗi và độ khó khi cần truy nguyên vấn đề. Con người rất thích cắm mọi thứ vào nhau rồi gọi đó là hệ sinh thái. Đến lúc một phần ngừng hoạt động, không ai biết nên rút sợi dây nào trước.

Cổng 7. Phân rã thành sản phẩm bàn giao

Khi kiến trúc đã rõ, dự án mới được phân rã thành những hạng mục cụ thể. Mỗi hạng mục cần có người phụ trách, tiêu chí nghiệm thu, phần phụ thuộc, thứ tự thực hiện và phiên bản bàn giao.

Thay vì giao một nhiệm vụ mơ hồ như “xây hệ thống quản lý chi nhánh”, có thể chia thành các sản phẩm rõ hơn: biểu mẫu báo cáo doanh thu, biểu mẫu tồn kho, cơ chế phân quyền theo vai trò, bảng điều khiển dành cho lãnh đạo, thư viện quy trình, màn hình KPI cá nhân, nhật ký thay đổi và hướng dẫn sử dụng.

Mỗi sản phẩm phải trả lời được thế nào là hoàn thành. Biểu mẫu chạy được chưa đủ. Dữ liệu phải lưu đúng, người dùng đúng quyền mới nhìn thấy, lỗi nhập liệu được kiểm soát và người sử dụng thực tế có thể hoàn thành công việc mà không cần người xây hệ thống đứng bên cạnh giải thích.

Nhật ký quyết định cũng cần được duy trì liên tục. Khi có thay đổi, phải biết điều gì đã thay đổi, vì sao thay đổi và phần nào bị ảnh hưởng. Chính các bản ghi này đã giúp tôi quay lại cấu trúc dự án mà không phải làm lại toàn bộ.

Cổng 8. Thử nghiệm trọn quy trình trước khi mở rộng

Phiên bản thử nghiệm cần đủ nhỏ để sửa nhanh, nhưng phải chứa trọn một chu trình vận hành thực tế.

Có thể chọn một chi nhánh, một nhóm nhân sự và một số loại báo cáo quan trọng. Dữ liệu thử nghiệm cần gần với dữ liệu thật. Người dùng thật phải trực tiếp nhập, tra cứu, xác nhận và phản hồi.

Quá trình kiểm thử cần ghi lại cả lỗi kỹ thuật lẫn những điểm gây bất tiện: người dùng không hiểu tên trường dữ liệu, phải bấm quá nhiều bước, không biết báo cáo đã gửi thành công hay chưa, hoặc nhìn thấy thông tin không cần thiết.

Chỉ khi quy trình nhỏ này vận hành ổn định, hệ thống mới nên được mở rộng sang các chi nhánh và nhóm nghiệp vụ khác.

Điều quan trọng nhất tôi rút ra sau một đêm mất ngủ là kế hoạch đầu tiên chỉ nên được xem như một giả thuyết. AI agent có thể triển khai rất nhanh, nhưng tốc độ đó chỉ tạo ra giá trị khi con người thiết kế được các cổng kiểm soát phù hợp.

Agent càng mạnh, hậu quả của một giả định sai càng được khuếch đại nhanh. Nó có thể tạo thêm bảng, thêm công thức, thêm kết nối và thêm hàng nghìn dòng nhật ký trong lúc bài toán gốc vẫn chưa được chốt.

Sau khi hoàn thiện workflow này, tôi đóng gói nó thành một kỹ năng hướng dẫn riêng cho các agent. Từ nay, trước khi bắt đầu một dự án tương tự, agent phải tự kiểm tra tám cổng, nhắc lại những phần còn thiếu và cảnh báo nếu tôi đang cố nhảy qua một bước quan trọng.

Workflow đầy đủ không cần được áp dụng như một nghi lễ hành chính. Với dự án nhỏ, tám cổng có thể được rà soát trong ba mươi phút. Dự án lớn, liên quan đến nhiều phòng ban, dữ liệu nhạy cảm và nhiều hệ thống thì cần làm kỹ hơn. Mục đích của workflow là giảm việc làm lại và giúp quyết định tốt hơn, chứ không tạo thêm một tầng thủ tục để mọi người điền biểu mẫu về việc họ đang điền biểu mẫu.

Công thức cuối cùng của tôi là:

Bài toán rõ → quyền quyết định rõ → điều kiện đủ → quy trình và dữ liệu rõ → công cụ khả thi → kiến trúc phù hợp → sản phẩm bàn giao rõ → thử nghiệm trọn quy trình → triển khai rộng.

Sau khi hệ thống lại theo trình tự này, phần việc còn lại diễn ra nhanh hơn nhiều. Tôi dùng ít token hơn, agent ít phải quay lại sửa và những quyết định kỹ thuật cũng trở nên nhất quán hơn.

Một đêm mất ngủ vẫn là một đêm mất ngủ. Ít nhất lần này, ngoài một ứng dụng đang dần hoàn thiện, tôi có thêm một workflow đủ tốt để những dự án sau không phải trả lại cùng một loại học phí.

Bài gốc trên Substack của Lê Đình Lực.