Đo AI bằng việc đổi workflow

Đo AI bằng việc đổi workflow

Đừng đo AI bằng số tool đã mua. Hãy đo bằng đoạn workflow thật sự đổi hành vi, giảm ma sát, và sống được qua vận hành hằng ngày.

“Team mình đã dùng AI chưa?” là câu hỏi nghe rất oách trong phòng họp, nhưng nhiều khi câu trả lời thật chỉ là: có, tụi mình đã bật thêm vài nút lấp lánh trong Google Docs, mua thêm một gói chatbot, rồi vẫn copy-paste như cũ.

Niềm tin phổ biến là: AI càng mới, càng nhiều tính năng, càng dễ chứng minh giá trị. Mình muốn phản biện nhẹ mà đau: giá trị của AI không nằm ở chỗ bạn đã mua gì, mà nằm ở workflow nào đã đổi được cách người trong team làm việc.

Nếu không đo ở tầng workflow, bạn rất dễ rơi vào cảnh nấu một nồi rất thơm mùi công nghệ, nhưng đến bữa thì không ai biết món chính là gì.

Sơ đồ minh họa cho bài Đo AI bằng việc đổi workflow

Sơ đồ tóm tắt ý chính của bài viết.

Mục tiêu: đừng hỏi “ROI bao nhiêu”, hãy hỏi “đổi việc nào?”

ROI — return on investment, tức lợi tức trên khoản đầu tư — vẫn quan trọng. CFO không sống bằng cảm hứng. Nhưng với generative AI, nếu bạn lao vào đo ROI quá sớm, bạn sẽ đo nhầm.

Vấn đề là đường từ “AI giúp viết nhanh hơn” đến “doanh nghiệp kiếm thêm tiền hoặc tiết kiệm chi phí” hiếm khi thẳng tắp. Google Cloud nhấn mạnh một ý đáng giữ: AI có thể khuếch đại năng lực kỹ thuật, nhưng giá trị dài hạn phụ thuộc vào hệ thống tổ chức và văn hóa làm việc xung quanh nó, không chỉ model hay license.

Nói thẳng ra thì: AI không tự tạo business value; nó tạo cơ hội để team thiết kế lại cách làm việc.

Vậy playbook hôm nay không phải là “chọn tool nào”. Mục tiêu là giúp bạn chọn một workflow đáng đo, thử trong một buổi chiều, rồi quyết định có nên mở rộng hay dừng lại.

Checklist 15 phút: workflow nào đáng đưa AI vào?

Trước khi mở thêm tab demo, hãy lấy một workflow thật trong team và chấm nhanh theo 5 câu hỏi này:

| Câu hỏi | Nếu câu trả lời là “có” |
|---|---|
| Việc này lặp lại hằng tuần không? | Có cơ hội tiết kiệm thời gian thật |
| Đầu vào có tài liệu, ticket, email, dashboard rõ không? | AI có nguyên liệu để xử lý |
| Đầu ra có tiêu chuẩn đánh giá không? | Dễ biết kết quả dùng được hay không |
| Có người chịu trách nhiệm duyệt không? | Giảm rủi ro AI trả lời tự tin nhưng sai |
| Nếu lỗi xảy ra, hậu quả có kiểm soát được không? | Phù hợp để thử nghiệm sớm |

Nếu workflow không qua nổi 3/5 câu, khoan đưa AI vào. Không phải vì AI yếu, mà vì bạn đang thiếu công thức. Đổ model xịn vào một quy trình mơ hồ giống như nêm gia vị khi chưa biết đang nấu canh hay kho cá.

Ví dụ cụ thể: team sales muốn “dùng AI để tăng doanh thu”. Câu đó rộng quá. Đổi thành: “AI đọc transcript cuộc gọi, tóm tắt pain point của khách, gợi ý follow-up email để sales duyệt trước khi gửi”. Bây giờ bạn có đầu vào, đầu ra, người duyệt, và điểm đo.

Playbook 4 bước cho một buổi chiều

Bước 1: Chọn một lát workflow nhỏ

Đừng bắt đầu bằng “triển khai AI cho toàn bộ phòng marketing”. Hãy chọn một lát đủ hẹp:

Ý từ Cohere về AI trong business intelligence rất đáng chú ý: AI hữu ích khi nó giúp người dùng hỏi dữ liệu bằng ngôn ngữ tự nhiên và tìm insight nhanh hơn. Nhưng “hỏi dữ liệu” chỉ có giá trị nếu dữ liệu đã có ngữ cảnh và người dùng biết sẽ ra quyết định gì sau câu trả lời.

Hình dung thế này: nếu trưởng nhóm kinh doanh hỏi “tháng này kênh nào tụt?”, AI không nên chỉ trả lời một câu đẹp. Nó cần kéo đúng dashboard, chỉ ra biến động, và nếu được thì gợi ý câu hỏi tiếp theo. Workflow đổi ở đây là từ “chờ analyst xuất report” sang “người quản lý tự truy vấn bước đầu, analyst tập trung kiểm tra và đào sâu”.

Bước 2: Viết định nghĩa “xong” trước khi prompt

Trước khi viết prompt, hãy viết Definition of Done — tiêu chí thế nào là hoàn thành.

Ví dụ:

Workflow: Tóm tắt ticket hỗ trợ khách hàng
Đầu vào: Nội dung ticket + lịch sử trao đổi
Đầu ra: 5 dòng tóm tắt + mức độ ưu tiên + bước xử lý đề xuất
Người duyệt: Support lead
Không được làm: Tự hứa hoàn tiền, tự xác nhận lỗi sản phẩm
Đo thử: Lead mất ít thời gian hơn để phân loại ticket; số ticket phải đọc lại giảm rõ rệt

Điểm quan trọng: đừng chỉ đo “AI trả lời có hay không”. Hãy đo người duyệt làm việc khác đi như thế nào.

Bước 3: Gắn đo lường vào nơi người dùng đang làm việc

Một lỗi rất Việt Nam: thử AI ở một file riêng, một chatbot riêng, một tab riêng. Kết quả demo nhìn ổn, nhưng sau hai tuần không ai dùng vì phải đổi ngữ cảnh quá nhiều.

Nếu team đang sống trong Google Docs, Slack, Jira, Notion, CRM, hay dashboard BI, hãy đặt thử nghiệm càng gần nơi đó càng tốt. Nguồn TechCrunch về việc tắt AI trong Google Docs là một lời nhắc vui mà thật: AI xuất hiện sai chỗ có thể biến thành nhiễu, không phải năng suất.

Vì vậy, hãy đo cả adoption friction — ma sát khi sử dụng. Thuật ngữ này đơn giản là: người dùng phải tốn bao nhiêu công để đưa AI vào việc đang làm. Nếu phải copy qua lại 5 lần, đăng nhập thêm 2 nơi, rồi tự format lại, giá trị sẽ bay hơi nhanh.

Bước 4: Thêm vận hành trước khi mở rộng

Khi một workflow AI bắt đầu có người dùng thật, câu hỏi tiếp theo không phải “nhân rộng ngay không?”, mà là “nó hỏng kiểu gì?”.

AWS nói nhiều về vận hành AI ở quy mô lớn: monitoring nhiều lớp, cảnh báo theo ngữ cảnh, tránh tạo case trùng, và giúp đội SRE xử lý nhanh hơn. Với team nhỏ, bạn không cần bê nguyên kiến trúc enterprise về. Nhưng tinh thần thì nên giữ.

Tối thiểu, bạn cần một bảng theo dõi:

Tên workflow:
Người dùng chính:
Lỗi thường gặp:
Ai duyệt đầu ra:
Khi nào phải escalate:
Chi phí ước tính:
Dấu hiệu nên dừng:
Dấu hiệu nên mở rộng:

Monitoring — theo dõi vận hành — không chỉ là log kỹ thuật. Trong bối cảnh AI cho công việc, nó còn là việc ghi nhận: AI có giúp người làm ra quyết định nhanh hơn không, hay chỉ tạo thêm một lớp văn bản để đọc?

Bẫy hay gặp: đo phần dễ nhìn, bỏ phần tạo giá trị

Có ba kiểu đo rất dễ làm nhưng dễ lạc:

1. Đếm số prompt đã chạy. Ồn ào nhưng ít ý nghĩa. Prompt nhiều không có nghĩa workflow tốt.

2. Đo cảm giác hài lòng ngay sau demo. Demo thường là lúc món vừa ra khỏi bếp, còn nóng và thơm. Production là lúc phải phục vụ đều mỗi ngày, có lúc thiếu nguyên liệu, có lúc khách đổi yêu cầu.

3. Chỉ đo tiết kiệm thời gian cá nhân. Nếu một người tiết kiệm 10 phút nhưng ba người khác phải kiểm tra lại thêm 30 phút, hệ thống đang lỗ.

Thay vào đó, hãy dùng khung 3 lớp:

Giả sử team bạn 5 người làm customer support. AI giúp tạo nháp phản hồi nhanh hơn, nhưng nếu lead vẫn phải đọc từng câu vì sợ sai chính sách, giá trị chưa nằm ở “viết nhanh”. Giá trị thật có thể nằm ở bước trước đó: phân loại ticket, gom ngữ cảnh, đánh dấu trường hợp cần người có kinh nghiệm xử lý.

Nếu là mình, mình sẽ chọn bài test này trước

Nếu bạn đang ở một team Việt Nam cỡ nhỏ hoặc vừa, mình sẽ không bắt đầu bằng agent tự động làm hết. Mình sẽ chọn một workflow có người duyệt rõ:

“AI tạo bản tóm tắt có cấu trúc từ tài liệu dài để người phụ trách ra quyết định nhanh hơn.”

Áp dụng được cho:

Trong một buổi chiều, bạn có thể làm như sau:

  1. Chọn 10 mẫu đầu vào thật đã xử lý xong.
  2. Viết tiêu chí đầu ra mong muốn.
  3. Chạy AI tạo bản nháp.
  4. Cho người phụ trách chấm: dùng được, cần sửa, hay bỏ.
  5. Ghi lại lỗi lặp lại và quyết định: sửa prompt, thêm dữ liệu, đổi workflow, hoặc dừng.

Điểm đổi cách nghĩ sau bài này: đừng xem AI project là cuộc thi chọn tool; hãy xem nó là bài kiểm tra xem workflow nào đủ chín để nêm AI vào mà không làm hỏng món chính.

AI có thể làm nhanh hơn, nhưng nhanh hơn thứ sai thì vẫn là sai — chỉ là sai khi còn nóng.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo