Một bản khởi động gọn để đội văn phòng biết cần cải thiện việc gì, khảo sát đến đâu và mời ai vào bàn trước khi chọn công nghệ.
Sáng thứ Hai, Lan gửi hồ sơ công tác phí. Đến chiều thứ Tư, chị vẫn phải nhắn hỏi: “Hồ sơ của em đang ở đâu?”.
Trong cuộc họp cải tiến, một ý kiến xuất hiện rất nhanh: “Làm chatbot AI đi. Nhân viên hỏi là biết ngay trạng thái”.
Đó có thể là một ý tưởng hữu ích. Nhưng biết hồ sơ đang chờ không đồng nghĩa với việc hồ sơ được xử lý nhanh hơn. Nếu nút thắt nằm ở mã chi phí bị thiếu, người duyệt đi vắng hoặc bước bàn giao sang kế toán, chatbot chỉ giúp Lan nhìn rõ hàng chờ.
Một dự án AI cần bắt đầu bằng công việc muốn cải thiện, không phải bằng công cụ muốn triển khai.
Đây cũng là điểm nối với cách tiếp cận bắt đầu kiến trúc AI bằng giá trị: trước khi chọn công nghệ, hãy làm rõ ai cần nhận được một kết quả tốt hơn.
Chương Goals–Scope–Stakeholders trong Mastering the Requirements Process, Fourth Edition đặt nền móng bằng ba yếu tố: mục tiêu, phạm vi và các bên liên quan. Áp dụng vào doanh nghiệp, chúng giúp trả lời ba câu hỏi rất đời thường:
Mục tiêu: Sau dự án, điều gì trong công việc phải tốt hơn?
Phạm vi: Muốn tạo ra thay đổi đó, chúng ta phải tìm hiểu những phần việc nào?
Các bên liên quan: Ai hiểu việc, ai có quyền quyết định và ai sẽ chịu tác động?
Ba câu trả lời không đứng riêng. Mục tiêu dẫn đường cho phạm vi; phạm vi giúp tìm đúng người; những người ấy lại giúp sửa mục tiêu cho sát thực tế. Đội dự án có thể cần trao đổi vài vòng trước khi thống nhất, thay vì cố chốt mọi thứ ngay trong lần họp đầu tiên.
Ba nhánh cùng một gốc: cải thiện công việc của doanh nghiệp. Công nghệ chỉ có ý nghĩa khi phục vụ được gốc này.
1. Đổi “triển khai AI” thành một kết quả có thể kiểm chứng
“Triển khai AI cho phòng kế toán” mô tả một hoạt động. “Có chatbot công tác phí” mô tả một sản phẩm. Cả hai chưa nói rõ nhân viên hay doanh nghiệp nhận được lợi ích gì.
Một cách làm rõ mục tiêu là tách thành mục đích – lợi ích – đo lường.
Hãy tiếp tục với tình huống của Lan. Đây là ví dụ giả định; các con số dưới đây là giả định ban đầu để minh họa cách đặt mục tiêu, không phải kết quả triển khai thực tế.
Câu cuối vẫn cần được làm rõ cùng người làm việc. Đồng hồ bắt đầu lúc nhân viên gửi hồ sơ hay lúc kế toán xác nhận đủ giấy tờ? Kết thúc khi được duyệt hay khi tiền về tài khoản?
Trong ví dụ này, đội thống nhất bắt đầu từ lần gửi đầu tiên, kết thúc khi hồ sơ đã duyệt được bàn giao cho kế toán để chi trả. Thời gian chờ nhân viên bổ sung cũng được ghi nhận, không bị loại ra để làm đẹp kết quả. Giờ làm việc được tính theo lịch thống nhất; các trường hợp chưa hoàn tất phải được báo cáo riêng.
Như vậy, mục tiêu hiện tại là cải thiện xử lý hồ sơ, chưa phải rút ngắn toàn bộ thời gian tiền về tài khoản. Nếu muốn cam kết cả khâu chi trả, đội phải xem lại phạm vi và mời thêm người phụ trách khâu đó.
Trước khi nhận mục tiêu 8 giờ, hãy kiểm tra mức nền trên dữ liệu thực tế, thời gian dành cho từng bước và khả năng thay đổi của đội. Một con số hấp dẫn không tự biến thành một mục tiêu khả thi.
Đừng để tốc độ che mất chất lượng
Một bản tóm tắt được tạo trong vài giây không có nghĩa là hồ sơ đã được xử lý đúng. Người nhận có thể mất thêm thời gian kiểm tra số tiền, tìm chứng từ hoặc sửa mã chi phí.
Vì vậy, nên đo kết quả của toàn bộ công việc được chọn, không chỉ đo tốc độ sinh câu trả lời. Với mục tiêu định tính như “dễ dùng hơn”, hãy chuyển thành câu hỏi có thể quan sát: nhân viên có tự gửi được hồ sơ không, có biết bước tiếp theo không, có bớt phải nhờ đồng nghiệp hướng dẫn không?
Một bản mẫu đơn giản, thử với người dùng đại diện, có thể giúp phát hiện vướng mắc trước khi đội xây cả hệ thống.
2. Phạm vi khảo sát rộng hơn chiếc hộp chat
Nếu chỉ khảo sát những câu hỏi nhân viên muốn hỏi chatbot, đội sẽ dễ bỏ qua phần việc tạo ra câu trả lời: ai cập nhật trạng thái, ai xác nhận giấy tờ đủ, ai nhận bàn giao, ai giải quyết ngoại lệ?
Phạm vi cần tìm hiểu không đồng nghĩa với phạm vi sẽ tự động hóa.
Trong tình huống công tác phí, đội cần tìm hiểu việc chuẩn bị hồ sơ của nhân viên, cách trưởng bộ phận duyệt, cách kế toán kiểm tra, các trường hợp trả lại và sự trao đổi với hệ thống kế toán hiện có. Điều đó không có nghĩa là AI sẽ thay tất cả những người này.
Sau khảo sát, giải pháp đầu tiên có thể chỉ hỗ trợ kiểm tra thiếu thông tin và soạn bản tóm tắt để con người xem lại. Cũng có thể nút thắt được giải quyết tốt hơn bằng mẫu biểu rõ ràng và quy định người duyệt thay thế, chưa cần AI ở bước đó.
Vẽ ranh giới công việc, chưa vẽ kiến trúc công nghệ
Một sơ đồ ngữ cảnh giúp đội thống nhất phạm vi. Ở giữa là phần công việc đang nghiên cứu; bên ngoài là những nơi cung cấp hoặc nhận thông tin. Các mũi tên chỉ dữ liệu đi vào và đi ra.
Với ví dụ của Lan, sơ đồ có thể được mô tả như sau:
Bên trong: chuẩn bị, kiểm tra, bổ sung, duyệt và bàn giao hồ sơ; gồm cả thao tác của nhân viên, người duyệt và kế toán kiểm tra.
Hệ thống kế toán hiện có ở bên ngoài: cung cấp danh mục mã chi phí và nhận hồ sơ đã duyệt. Trong đợt này, đội không được thay đổi chức năng hạch toán của hệ thống đó.
Bộ phận quản lý chính sách ở bên ngoài: cung cấp quy định hiện hành, nhận phản hồi về những điểm gây khó hiểu. Đợt thử nghiệm chưa có thẩm quyền sửa chính sách.
Khâu chi trả ở bên ngoài: nhận hồ sơ hợp lệ và gửi lại trạng thái tiếp nhận nếu cần theo dõi bàn giao.
Đừng vội đưa từng mô hình AI, cơ sở dữ liệu hay bước xử lý kỹ thuật vào sơ đồ này. Mục đích của nó là thống nhất công việc nào thuộc bài toán và thông tin nào đi qua ranh giới, chưa phải mô tả hệ thống hoạt động ra sao.
Khi thấy thiếu một luồng dữ liệu, đội có thể phát hiện thiếu cả một phần việc. Chẳng hạn, nếu hồ sơ bị trả lại mà không có thông tin về lý do, chatbot lấy gì để hướng dẫn Lan bổ sung?
Thu hẹp vào giao diện có thể bỏ sót nút thắt. Mở rộng phạm vi khảo sát giúp chọn đúng phần việc cần cải thiện, không phải tự động hóa mọi thứ.
Phân biệt quyền thay đổi với khả năng tác động
Đội dự án có thể được phép sửa mẫu gửi hồ sơ, cách chuyển người duyệt hoặc thông báo trạng thái. Nhưng đội không thể tự ý thay chức năng phần mềm kế toán, sửa chính sách chi tiêu hay yêu cầu một nhà cung cấp ngoài doanh nghiệp thay hệ thống của họ.
Có những nơi ta chỉ có thể tác động thông qua trao đổi và thỏa thuận, không thể ra lệnh. Ranh giới này cần được ghi rõ để mục tiêu không dựa vào những thay đổi ngoài quyền của đội.
Nếu giữa chừng có yêu cầu “tiện thể làm luôn tạm ứng và quản lý ngân sách”, đừng lặng lẽ đưa vào danh sách tính năng. Hãy hỏi: yêu cầu mới đóng góp cho mục tiêu nào, thêm luồng dữ liệu nào, cần người quyết định nào và làm thay đổi thời gian hay nguồn lực ra sao?
Phạm vi không phải bất biến. Nhưng mỗi lần thay đổi phải là một quyết định được nhìn thấy, không phải một việc được thêm vào vì “chắc cũng đơn giản”.
3. Mời người biết việc, không chỉ mời người có chức danh
Một buổi họp có lãnh đạo và đội công nghệ vẫn có thể bỏ sót yêu cầu quan trọng. Người trực tiếp xử lý hồ sơ thường biết những chi tiết khó thấy trong báo cáo: ảnh hóa đơn bị mờ, thiếu mã dự án, trường hợp duyệt thay, hoặc hồ sơ bị trả lại nhiều lần.
Danh sách các bên liên quan nên bao gồm cả người có thẩm quyền và người có kiến thức thực tế.
Một người có thể đảm nhiệm nhiều vai trò. Điều quan trọng là trách nhiệm được gọi tên, không nhất thiết phải có đủ từng chức danh trong một đội nhỏ.
Với mỗi hệ thống nằm ngoài ranh giới, cũng nên tìm một người đại diện hiểu nó. “Phần mềm sẽ kết nối được” không thay thế cho việc hỏi người đang vận hành phần mềm ấy.
Lắng nghe cả người không hào hứng
Nếu một kế toán không muốn dùng AI, đừng vội kết luận họ chống đổi mới. Có thể họ đã thấy một bản tóm tắt bỏ sót chứng từ và lo mình phải chịu trách nhiệm cho sai sót đó.
Hãy hỏi cụ thể: “Anh/chị cần kiểm tra được gì trước khi chấp nhận kết quả?”. Câu trả lời có thể trở thành yêu cầu về việc đối chiếu với chứng từ gốc, sửa bản nháp hoặc chuyển ngoại lệ cho người xử lý.
Nếu phần việc có đọc chứng từ bằng AI, có thể đọc tiếp góc nhìn đánh giá VLM theo bằng chứng thay vì chỉ theo câu trả lời. Đó là một chủ đề cần làm rõ sau khi biết người sử dụng phải kiểm tra điều gì.
Trong ví dụ này, đội có thể chọn giới hạn ban đầu: AI hỗ trợ kiểm tra và soạn nháp; con người vẫn xác nhận hồ sơ và thực hiện phê duyệt. Đây là quyết định cho tình huống đang xét, không phải một thiết kế mặc định cho mọi dự án AI.
4. Một cuộc họp khởi động 60 phút nên để lại gì?
Không cần biến buổi đầu thành một cuộc họp trình diễn công nghệ. Có thể thử lịch làm việc sau; đây là gợi ý thực hành cho đội văn phòng, không phải một thời lượng bắt buộc của phương pháp trong sách.
10 phút – Kể một hồ sơ thật. Theo dấu từ lúc gửi đến lúc hoàn tất. Ghi chỗ phải hỏi lại, chờ đợi hoặc sửa thông tin.
15 phút – Viết mục tiêu. Tách mục đích, lợi ích, cách đo; đánh dấu số liệu đã có và giả định cần kiểm chứng.
15 phút – Vẽ ranh giới. Liệt kê công việc cần tìm hiểu, hệ thống bên ngoài, dữ liệu vào/ra và những gì chưa được phép thay đổi.
10 phút – Tìm đúng người. Ghi ai hiểu việc, ai quyết định, ai chịu tác động và ai còn thiếu trong cuộc họp.
10 phút – Chốt việc tiếp theo. Phân công người lấy dữ liệu nền, gặp người còn thiếu và cập nhật bản khởi động.
Một lịch họp ngắn giúp tạo bản khởi động ban đầu. Những điểm chưa rõ cần được ghi lại và xác minh, không được coi là đã giải quyết chỉ vì hết giờ.
Đầu ra nên là một trang mà người làm nghiệp vụ cũng đọc được:
Công việc muốn cải thiện: …
Mục đích – lợi ích – cách đo: …
Dữ liệu nền và giả định cần kiểm chứng: …
Phạm vi khảo sát và phần chưa triển khai: …
Thông tin đi vào/đi ra; hệ thống ngoài ranh giới: …
Quyền thay đổi và nơi cần thỏa thuận: …
Người hiểu việc – người quyết định – người chịu tác động: …
Việc tiếp theo, người phụ trách và ngày xem lại: …
Nếu chưa biết ai quyết định, chưa kiểm chứng được dữ liệu nền hoặc chưa thống nhất ranh giới, hãy tiếp tục khảo sát trước khi cam kết phạm vi xây dựng và ngân sách.
Chọn công nghệ sau khi đã biết mình cần đi đâu
Sau khi làm rõ mục tiêu, phạm vi và các bên liên quan, đội mới có cơ sở để quyết định cần AI ở đâu, kết nối với hệ thống nào và giữ phần việc nào cho con người. Đội cũng có thể nhận ra thay đổi quy trình đơn giản là đủ cho bước đầu.
Khi chuyển từ ranh giới nghiệp vụ sang thiết kế kết nối công cụ, bài MCP và kiến trúc tích hợp AI doanh nghiệp là một hướng đọc tiếp. Nhưng một chuẩn kết nối không thể thay đội trả lời câu hỏi ai có quyền thay đổi phần việc nào.
Với Lan, thành công không phải là một chatbot trả lời trôi chảy. Thành công là hồ sơ ít phải làm lại, bàn giao rõ ràng và được xử lý nhanh hơn theo cách đã thống nhất.
Đừng hỏi “chúng ta sẽ xây AI gì?” trước khi trả lời “công việc nào cần tốt hơn, trong ranh giới nào và với sự đồng thuận của ai?”.
Trong dự án đang làm, đội bạn đã thống nhất ba câu trả lời này chưa? Nếu phải chọn một điểm còn mơ hồ nhất, đó là mục tiêu, phạm vi hay người quyết định?
Nền tảng tham khảo: James Robertson và Suzanne Robertson, Mastering the Requirements Process, Fourth Edition, Chương 5 “Goals–Scope–Stakeholders”. Tình huống công tác phí, chỉ tiêu thử nghiệm, giới hạn AI và lịch họp 60 phút là phần diễn giải thực hành của bài viết; không phải số liệu hoặc kết quả nghiên cứu trong sách.
Ở đội của bạn, hồ sơ thường chậm vì thiếu thông tin, chờ người duyệt hay bàn giao chưa rõ? Hãy thử chọn một quy trình nhỏ và chia sẻ ba điều: mục tiêu cần đạt, ranh giới muốn cải thiện và người có quyền quyết định. Biết hồ sơ đang chờ chưa đủ; điều quan trọng là làm cho công việc bớt phải chờ.