Bài 3 — Ưu tiên use case: khung Impact–Feasibility & tính ROI

Backlog 20–30 cơ hội không thể làm cùng lúc. Bài này cho bạn cách ép ra thứ tự bằng dữ liệu, không cảm tính.

Ma trận Impact – Feasibility

Chấm mỗi use case trên 2 trục, thang 1–5.

Impact (tác động) = tổng của:

• Giá trị tiền/năm (giờ tiết kiệm × chi phí giờ, hoặc doanh thu tăng).
• Tính chiến lược (khách hàng cảm nhận, lợi thế cạnh tranh).

Feasibility (khả thi) = tổng của:

• Chất lượng & sẵn có dữ liệu.
• Độ rõ của quy tắc/quy trình.
• Sẵn có API/tool để agent hành động.
• Chi phí sai thấp (dễ giám sát, dễ hoàn tác).

Bốn góc phần tư:

         Impact cao
            |
  [Nền tảng]| [Quick win / Flagship]
  (làm sau, | (LÀM TRƯỚC)
   cần đầu tư)|
------------+------------ Feasibility cao
  [Bỏ qua]  | [Điền chỗ trống]
  (loại)    | (làm khi rảnh)
            |

• Impact cao + Feasibility cao = Quick win/Flagship → ưu tiên số 1.
• Impact cao + Feasibility thấp = Nền tảng, cần đầu tư dữ liệu/hạ tầng trước.
• Impact thấp + Feasibility cao = điền chỗ trống, làm khi có băng thông.
• Impact thấp + Feasibility thấp = bỏ.

Ví dụ tính ROI cụ thể

Use case "agent phân loại & trả ticket cấp 1":

• Giờ tiết kiệm: 320 giờ/tháng × 60% tự động = 192 giờ.
• Chi phí giờ support: 150.000đ → tiết kiệm 28,8 triệu/tháng ≈ 345 triệu/năm.
• Chi phí xây + vận hành năm 1: ~180 triệu (API LLM, tích hợp, giám sát).
• ROI năm 1 ≈ (345 − 180) / 180 ≈ 92%, hoàn vốn ~6,3 tháng.

Quy tắc ngón tay cái: use case đầu tiên nên hoàn vốn dưới 9 tháng để tạo niềm tin nội bộ.

Lưu ý phần chi phí vận hành hay bị bỏ quên: token LLM (mỗi lượt agent chạy nhiều bước nên tốn nhiều token hơn một câu hỏi đơn), chi phí giám sát của người trực escalate, và bảo trì khi hệ thống nguồn thay đổi. Một dự án tính "chỉ tốn 80 triệu để xây" mà quên 100 triệu vận hành/năm sẽ ra ROI ảo và vỡ trận sau vài tháng.

Bảng chấm điểm (dùng trực tiếp)

Use case: __________
Impact:
  Giá trị tiền/năm (1-5):        __
  Tính chiến lược (1-5):         __
Feasibility:
  Dữ liệu sẵn sàng (1-5):        __
  Quy trình rõ (1-5):            __
  API/tool sẵn có (1-5):         __
  Chi phí sai thấp (1-5):        __
Điểm Impact = TB 2 dòng đầu
Điểm Feasibility = TB 4 dòng sau

Các bước làm

• Đưa cả backlog vào bảng chấm điểm.
• Cho điểm cùng một nhóm 3–5 người để giảm thiên lệch, lấy trung bình.
• Vẽ scatter Impact (trục dọc) × Feasibility (trục ngang).
• Tính ROI thô cho top 5 use case ở góc Quick win.
• Chọn 1 use case đầu tiên: Impact khá + Feasibility cao + ROI < 9 tháng + chi phí sai thấp.
• Ghi rõ lý do chọn để trình lãnh đạo.

Sai lầm thường gặp

• Chọn use case Impact cao nhưng Feasibility thấp làm đầu tiên: dự án sa lầy vì thiếu dữ liệu, mất niềm tin nội bộ.
• Chấm điểm một mình: thiên lệch theo phòng ban của người chấm.
• Quên chi phí vận hành: chỉ tính chi phí xây, bỏ token LLM + giám sát + bảo trì.
• Chọn quá nhiều use case cùng lúc: dàn trải, không cái nào tới đích.
• Coi điểm số là chân lý tuyệt đối: ma trận là công cụ hỗ trợ tranh luận, không thay thế phán đoán. Nếu một use case điểm thấp nhưng gỡ được nút thắt chiến lược, hãy ghi rõ ngoại lệ và lý do.

Tóm tắt

Ưu tiên hóa là nơi biến danh sách mong muốn thành một quyết định có thể bảo vệ trước lãnh đạo. Hai trục Impact và Feasibility, cộng với ROI hoàn vốn dưới 9 tháng và chi phí sai thấp, cho bạn một use case số 1 rõ ràng cùng lý do bằng số. Đừng để "Impact cao" một mình dẫn dắt — chính Feasibility mới quyết định bạn có về đích được hay không.

Đã có use case số 1. Bài 4 sẽ dựng roadmap nhiều đợt và cân giữa quick win với đầu tư nền tảng để chương trình đi được đường dài.