Agent của bạn đang chạy, nhưng metric cũ đang nói dối: Chuyển sang mô hình vận hành dựa trên kết quả

Bạn đang lead một team finance shared services. Trong nhiều năm, bạn đo lường mọi thứ bằng số lượng hóa đơn mỗi analyst xử lý, tốc độ đóng ticket, và lịch làm việc kín mít của team. Những metric đó có ý nghĩa khi con người làm gần như toàn bộ công việc.

Giờ đây, team bạn dùng agent để điều phối month-end close, chuẩn bị đối chiếu, và phân loại các ngoại lệ hóa đơn. Phần lớn công việc hành chính biến mất. Nếu bạn vẫn nhìn vào dashboard cũ, tất cả những gì bạn thấy là "hoạt động của con người giảm". Điều đó có nghĩa là performance tệ hơn?

Câu hỏi thực sự: hóa đơn được xử lý chính xác hơn không? Ngoại lệ được giải quyết nhanh hơn không? Backlog có giảm không? Tỷ lệ giải quyết ngay lần đầu có cải thiện không? Team người của bạn cuối cùng có tập trung vào những case thực sự cần phán đoán không?

Đây là vấn đề cốt lõi mà mọi tổ chức engineering đang đối mặt khi agent đi vào workflow. Các metric như giờ làm việc, nỗ lực bỏ ra, hay headcount trên mỗi quy trình trở nên kém ý nghĩa. Điều quan trọng không còn là bao nhiêu hoạt động đã diễn ra, mà là kết quả nào đã đạt được.

Ba lớp của mô hình vận hành dựa trên kết quả: ai quyết định, công việc chảy thế nào, và danh mục nào bạn xây dựng.

Mô hình cũ đang âm thầm vỡ

Khi agent bắt đầu đọc context, định tuyến case, chuẩn bị hành động, gọi tool, và hoàn tất giao dịch, cấu trúc công việc thay đổi căn bản. Trong finance, agent điều phối close. Trong procurement, chúng phân loại intake và kiểm tra policy. Trong IT operations, chúng phân loại incident. Trong customer operations, chúng giải quyết các case đơn giản mà không cần con người.

Nếu management vẫn tập trung vào activity, tổ chức sẽ đọc sai giá trị. Activity trở thành một biến trung gian, không phải mục tiêu. Điều quan trọng là outcome tác động đến business.

Một mô hình vận hành dựa trên outcome (outcome-based operating model) ra đời từ nhu cầu này: quản lý doanh nghiệp bằng kết quả dịch vụ và tác động kinh doanh, không chủ yếu bằng activity và năng lực lao động. Đây không chỉ là thay đổi KPI. Đó là thay đổi cách bạn thiết kế dịch vụ, phân bổ trách nhiệm, cấu trúc hợp đồng, và quyết định use case nào xứng đáng được scale.

"Outcome" thực sự trông như thế nào

Cụ thể, mỗi function cần định nghĩa kết quả nào thực sự quan trọng. Dưới đây là các ví dụ dựa trên workflow thực tế:

• Finance: close nhanh hơn, kiểm soát tốt hơn; hóa đơn được xử lý đúng; ít ngoại lệ đối chiếu hơn
• Procurement: yêu cầu được định tuyến đúng ngay từ đầu; cycle time được cải thiện; tuân thủ policy cao hơn
• Customer operations: giải quyết ngay lần đầu; giảm số lần liên hệ lại; cải thiện sự hài lòng
• IT operations: phục hồi incident nhanh hơn; ít escalation sai; sẵn sàng thay đổi tốt hơn

Những outcome này hữu ích hơn nhiều so với việc đếm xem bao nhiêu tác vụ đã được tự động hóa. Quan trọng hơn, tư duy dựa trên outcome buộc một câu hỏi khó hơn: tác vụ này có cần tồn tại không?

Nhiều quy trình doanh nghiệp đầy rẫy các hoạt động legacy. Các kiểm tra trùng lặp có thể loại bỏ nếu dữ liệu tốt hơn. Các bàn giao chỉ tồn tại vì cấu trúc tổ chức cũ. Các phê duyệt không còn tương xứng với rủi ro. Các báo cáo thủ công không ai dùng để ra quyết định thực sự. Nếu công ty chỉ chạy theo tự động hóa activity, họ sẽ tăng tốc chất thải. Agentic AI làm rủi ro này lớn hơn, vì công nghệ giờ có thể tự động hóa nhiều hơn. Nếu không có kỷ luật về outcome, tổ chức có thể trở nên rất hiệu quả trong việc chạy các quy trình sai.

Vì vậy, trước khi xây dựng một agent, câu hỏi đầu tiên không nên là "tôi có thể tự động hóa tác vụ nào?" Mà là "tôi muốn cải thiện outcome nào, và hoạt động nào thực sự đóng góp vào outcome đó?"

Từ headcount đến kết quả dịch vụ

Sự thay đổi tiếp theo xảy ra trong cách công ty nhìn nhận dịch vụ nội bộ và bên ngoài. Nhiều shared services, GCC, và tech services vẫn được quản lý bằng logic dựa trên nỗ lực: bao nhiêu người được phân bổ, bao nhiêu giờ sử dụng, bao nhiêu ticket xử lý, bao nhiêu năng lực cần thiết.

Mô hình này không biến mất hoàn toàn, nhưng nó ngày càng không phù hợp khi lao động số là một phần của việc cung cấp dịch vụ. Trong mô hình agentic, throughput có thể tăng mà không cần tăng headcount tuyến tính. Cấu trúc chi phí cũng thay đổi: có chi phí nền tảng, chi phí model và inference, chi phí tích hợp, chi phí observability và governance — nhưng có sự giảm trong nỗ lực thủ công cho một số khối lượng nhất định.

Kết quả là, định giá dựa trên FTE hoặc theo giờ mất đi sự phù hợp. Nếu một dịch vụ giờ được cung cấp bởi sự kết hợp của agent, workflow engine, và người giám sát, việc tính phí hoặc phân bổ chi phí chỉ dựa trên nỗ lực của con người trở nên sai lệch.

Ví dụ thực tế: một team procurement shared services từng tính phí dựa trên số nhân viên hỗ trợ trên mỗi business unit, giờ đây có ý nghĩa hơn khi đo bằng outcome như số yêu cầu được giải quyết, cycle time, hay tỷ lệ tuân thủ. IT services từng đo bằng ticket xử lý ở level one có thể chuyển sang metric như incident được giải quyết trong thời gian mục tiêu, thời gian phục hồi dịch vụ, hay tỷ lệ thành công của thay đổi. Finance operations từng được biện minh bằng tỷ lệ FTE-trên-giao dịch, giờ cần nhìn vào chi phí trên mỗi hóa đơn được xử lý đúng hoặc chi phí trên mỗi ngoại lệ được giải quyết.

Sự thay đổi này cũng chạm đến hợp đồng vendor. Trong các dịch vụ agentic, công ty không mua "công cụ" hay "thêm nhân lực." Họ ngày càng mua kết quả dịch vụ. Hợp đồng managed services và outsourcing cần chuyển từ định giá dựa trên input, time and material, hay headcount leverage, sang các mô hình gắn với quality throughput, resolution outcomes, compliance outcomes, hay các KPI kinh doanh cụ thể.

Tất nhiên, điều này không phải lúc nào cũng dễ dàng. Không phải mọi dịch vụ đều phù hợp với hợp đồng dựa trên outcome thuần túy. Nếu quy trình bị ảnh hưởng nhiều bởi yếu tố bên ngoài hoặc dữ liệu của khách hàng kém, vendor sẽ khó chấp nhận toàn bộ rủi ro. Nhưng hướng đi rõ ràng: agentic delivery càng trưởng thành, logic định giá dựa trên nỗ lực càng yếu đi.

Khi outcome chưa thể được định nghĩa rõ ràng, baseline chất lượng chưa tồn tại, yếu tố bên ngoài chi phối, hoặc quyền kiểm soát dữ liệu và quy trình bị phân tán, hãy bắt đầu với mô hình hybrid:

• Một phần chi phí cố định (bao gồm nền tảng cơ bản, tích hợp, và giám sát con người)
• Một phần phí dựa trên outcome đã thỏa thuận (gắn với kết quả dịch vụ có thể đo lường)

Ai quyết định? Ai chịu trách nhiệm khi thất bại?

Quản lý dựa trên outcome chỉ hoạt động nếu quyền sở hữu được xác định rõ ràng. Đây là kiến trúc trách nhiệm bạn cần:

• Business owner: sở hữu kết quả dịch vụ (ví dụ: close nhanh hơn, tuân thủ cao hơn)
• Agent owner: sở hữu hành vi agent, đánh giá, và kỷ luật release
• Risk owner: sở hữu guardrails, phê duyệt, và các ràng buộc

Khi có sự cố, tổ chức phải có khả năng xác định vấn đề đến từ dữ liệu xấu, policy không rõ ràng, tích hợp yếu, hành vi model kém, hay thiết kế quy trình sai. Nếu không, mọi thất bại sẽ trở thành "vấn đề AI," và không ai sửa nguyên nhân thực sự.

Agent có thể thực thi công việc, nhưng chúng không giữ trách nhiệm. Trách nhiệm vẫn thuộc về con người và tổ chức.

Quản lý sáng kiến như một danh mục outcome

Khi một công ty có nhiều sáng kiến agentic, thách thức không còn chỉ là xây dựng use case. Đó là quản lý một danh mục các outcome. Không phải use case nào cũng xứng đáng tiếp tục, và không phải quick win nào cũng xứng đáng được scale.

Trong thực tế, một danh mục agentic thường cần cân bằng bốn loại:

• Quick wins: giá trị rõ ràng, rủi ro kiểm soát được, dữ liệu sẵn sàng. Ví dụ: phân loại intake, phân loại hóa đơn, giải quyết service desk tiêu chuẩn.
• Strategic bets: tiềm năng thay đổi mô hình vận hành đáng kể hơn, nhưng phức tạp hơn. Ví dụ: điều phối close xuyên thực thể, phối hợp ngoại lệ chuỗi cung ứng, workflow IT delivery đa agent.
• Platform investments: có thể không hiển thị giá trị trực tiếp trên một quy trình, nhưng cần thiết cho scale. Ví dụ: identity, observability, policy engine, integration layer, evaluation harness.
• Risk reduction initiatives: cải thiện dữ liệu, kiểm soát, khả năng kiểm toán, governance cho phép các use case khác chạy an toàn.

Nếu công ty chỉ chạy theo quick wins, họ sẽ có nhiều pilot nhưng ít chuyển đổi. Nếu chỉ chạy theo strategic bets, họ có nguy cơ di chuyển quá chậm và mất đà. Một danh mục lành mạnh cần sự cân bằng.

Mô hình dựa trên outcome cũng đòi hỏi kỷ luật để dừng các sáng kiến không hiệu quả. Mỗi use case nên có các stage gate rõ ràng:

• Vấn đề kinh doanh có thực không?
• Có baseline không?
• Dữ liệu và policy đã sẵn sàng đủ chưa?
• Pilot có cho thấy outcome được cải thiện không?
• Tỷ lệ sửa lỗi và hồ sơ rủi ro còn chấp nhận được không?
• Kinh tế có lành mạnh không?

Nếu câu trả lời là không, use case nên được dừng, thu hẹp, hoặc thiết kế lại. Điều này quan trọng vì agentic AI dễ tạo ra optimism bias. Một demo đẹp thường khiến tổ chức miễn cưỡng thừa nhận rằng một use case cụ thể không đủ giá trị hoặc quá rủi ro ở thời điểm hiện tại.

Đánh giá danh mục không nên chỉ là diễn đàn công nghệ. Chúng phải có sự tham gia của business owner, CIO hoặc CTO hoặc platform leader, finance, risk hoặc compliance hoặc security, và nếu liên quan, HR hoặc transformation office. Quyết định scale không chỉ là về việc agent có hoạt động hay không. Đó là về việc outcome kinh doanh có thực, governance có đầy đủ, và tổ chức có sẵn sàng hấp thụ sự thay đổi hay không.

Áp dụng vào hệ thống thật

Nếu bạn đang vận hành một nền tảng agent, đây là cách bạn có thể bắt đầu chuyển đổi ngay:

1. Audit dashboard hiện tại: Nếu dashboard của bạn chỉ hiển thị số lượng task, số giờ, hay headcount, đó là dấu hiệu đỏ. Thay vào đó, thêm các metric outcome: accuracy rate, first-pass resolution rate, backlog trend, cost-per-correct-outcome.

2. Xác định ba owner cho mỗi agent: Trong file README hoặc runbook của mỗi agent, ghi rõ business owner (ai chịu trách nhiệm về outcome), agent owner (ai chịu trách nhiệm về behavior và release), risk owner (ai phê duyệt guardrails). Nếu không có, agent đó không nên vào production.

3. Xây dựng stage gate trong CI/CD pipeline: Thêm các bước kiểm tra trước khi deploy agent mới hoặc scale: có baseline không? correction rate có dưới ngưỡng không? cost-per-transaction có trong ngân sách không? Nếu không pass, pipeline tự động chặn.

4. Thiết kế hybrid pricing cho dịch vụ nội bộ: Nếu team bạn cung cấp dịch vụ cho business unit khác, chuyển từ chargeback theo headcount sang mô hình: phí nền tảng cố định + phí biến đổi theo outcome (ví dụ: số invoice xử lý đúng, số incident giải quyết trong SLA).

5. Tổ chức portfolio review hàng tháng: Không chỉ review tech, mà review danh mục outcome. Dùng bốn category (quick wins, strategic bets, platform investments, risk reduction) để phân loại. Nếu một use case ở quick win nhưng không scale được sau 3 tháng, hãy dừng hoặc redesign.

Điều này có ý nghĩa gì trong thực tế

Ngừng coi mọi sáng kiến