# Hiểu kinh doanh cho FDE: lần theo dòng tiền trước khi viết dòng code đầu tiên

> Một pilot chạy tốt về kỹ thuật vẫn có thể chết trong cuộc họp ngân sách, nếu FDE không trả lời được khách kiếm tiền ở đâu, tiền dự án lấy từ quỹ nào và ai là người ký.

Bản gốc: https://fdetimes.net/vi/bach-khoa/business-acumen-hieu-khach-kiem-tien-the-nao/

Thử hình dung tuần thứ sáu của một pilot. Agent chạy ổn, độ chính xác đẹp, trưởng phòng vận hành gật gù. Rồi một người bên tài chính hỏi đúng một câu: "Cái này giúp công ty kiếm thêm hay tiết kiệm được bao nhiêu tiền?" Cả phòng im lặng, còn FDE thì chỉ có biểu đồ latency trong tay.

Kịch bản đó không hiếm. IBM dẫn một báo cáo của MIT mùa hè 2025, theo đó 95% pilot generative AI đang thất bại. Khảo sát CEO của chính IBM cho thấy chỉ khoảng 25% sáng kiến AI đạt ROI kỳ vọng, 16% được mở rộng ra toàn doanh nghiệp, và chỉ khoảng 29% lãnh đạo tự tin rằng họ đo được ROI.

IBM rút ra rằng thách thức chính không nằm ở công nghệ mà ở tổ chức. Với bạn, một developer muốn làm FDE, đây là tin tốt: kỹ năng còn thiếu không phải là thêm một framework, mà là đọc được dòng tiền của khách. Kỹ năng này học được.

## Thời gian tiết kiệm có phải là tiền không?

IBM chia ROI làm hai loại. Hard ROI là tác động hữu hình, gắn trực tiếp với lợi nhuận. Soft ROI là những lợi ích chưa gắn ngay với lợi nhuận nhưng vẫn có ích cho tổ chức, chẳng hạn nhân viên đỡ mệt hơn hay quyết định nhanh hơn.

Cái bẫy với kỹ sư nằm ở chỗ hầu hết những gì ta đo được (số phút tiết kiệm, tỷ lệ tự động hoá, độ chính xác) mới chỉ là soft ROI. Chúng chỉ thành hard ROI khi khiến một dòng cụ thể trên báo cáo lãi lỗ (P&L) thay đổi. Doanh thu tăng, chi phí giảm, hoặc một khoản chi đáng lẽ phát sinh nay không cần nữa.

Khách hàng kiếm tiền theo ba cách cơ bản: bán thêm, giữ khách lâu hơn, và làm cùng việc đó với chi phí thấp hơn. Trước khi viết code, bạn cần biết dự án của mình tác động vào cách nào. Nếu câu trả lời là "không cách nào cả", dự án đó chỉ đang chờ đến lượt bị cắt.

## Làm thử một phép tính: call center 200 người

Lấy một ví dụ giả định. Một công ty tài chính tiêu dùng có call center 200 nhân viên, mỗi người xử lý 60 cuộc gọi một ngày. Sau mỗi cuộc gọi, nhân viên mất 3 phút ghi chú vào CRM. Bạn triển khai một agent tóm tắt cuộc gọi, hạ thời gian đó xuống còn 1 phút.

Phép tính kỹ thuật rất đẹp: 200 người × 60 cuộc × 2 phút = 24.000 phút, tức 400 giờ mỗi ngày. Nhưng hãy đặt câu hỏi của người bên tài chính: 400 giờ đó đi đâu? Nếu nhân viên vẫn ngồi đủ ca, vẫn nhận đủ lương, số cuộc gọi không tăng, thì P&L không đổi một đồng. Đó là soft ROI.

Có ba cách biến nó thành hard ROI, và mỗi cách cần một người khác nhau đồng ý. Thứ nhất, call center nhận thêm cuộc gọi bán hàng với cùng đội ngũ: giám đốc kinh doanh phải cam kết có đủ lead. Thứ hai, công ty không phải tuyển thêm người trong đợt cao điểm sắp tới: trưởng nhân sự phải xác nhận kế hoạch tuyển.

Thứ ba, giảm chi phí thuê ngoài: người quản lý hợp đồng outsourcing phải đồng ý giảm quy mô.

**Điểm mấu chốt:** Số phút tiết kiệm chỉ trở thành tiền khi có một người cụ thể bên phía khách cam kết dùng số phút đó vào việc gì.

Từ đó, câu trả lời cho người bên tài chính không còn là "tiết kiệm 400 giờ" nữa. Nó trở thành: "400 giờ mỗi ngày tương đương với số nhân sự mùa cao điểm mà phòng nhân sự đang định tuyển, và phòng nhân sự đã xác nhận con số đó." Đây là một câu tài chính có thể kiểm chứng.

## Tiền nằm ở đâu, ai ký?

Nhiều kỹ sư mặc định CIO là người có tiền, vì CIO là người họ gặp đầu tiên. Futurum Group ghi nhận điều ngược lại: chi tiêu cho AI ngày càng nằm trong ngân sách của các đơn vị kinh doanh, khiến quyền quyết định ngân sách lan ra ngoài CIO.

Lời khuyên của họ dành cho nhà cung cấp là xác nhận ai thực sự nắm ngân sách trước khi coi CIO là economic buyer chính.

Một bài quan điểm trên DEV Community mô tả cách phân chia hay gặp: IT chọn công nghệ, đơn vị kinh doanh áp dụng, tài chính duyệt ngân sách. Vấn đề, theo tác giả, là không ai sở hữu kết quả tài chính, tức chênh lệch giữa con số dự phóng và con số thực tế.

Đây là góc nhìn của một người viết chứ không phải khảo sát, nhưng nó cho FDE một bản đồ dùng được.

| Bên | Họ quan tâm | FDE cần mang đến |
|---|---|---|
| IT | Bảo mật, tích hợp, chi phí vận hành | Kiến trúc, cách xử lý dữ liệu, kế hoạch bảo trì |
| Đơn vị kinh doanh | Chỉ tiêu của phòng mình có đạt không | Chỉ số nghiệp vụ trước và sau, workflow mới |
| Tài chính | Tiền bỏ ra so với tiền thu về | Baseline, giả định, cách đo hard ROI |

Phòng tài chính càng đáng để ý khi chi phí bắt đầu vượt kế hoạch. Futurum cho biết 46,9% doanh nghiệp báo cáo chi tiêu AI vượt ngân sách, trong khi chỉ 5,6% chi thấp hơn kế hoạch. Theo Futurum, tài chính cũng là bộ phận nhiều khả năng nhất sẽ buộc chuyện này phải được nói thẳng.

Nếu bạn chưa gặp ai bên tài chính, họ sẽ tìm đến bạn, thường là vào lúc tệ nhất.

## Bốn câu hỏi cho buổi discovery

Bạn không cần xem báo cáo tài chính của khách. Bạn cần bốn câu hỏi, hỏi một cách tự nhiên trong buổi customer discovery, tốt nhất với người phụ trách nghiệp vụ.

"Nếu dự án thành công, con số nào trong báo cáo hằng tháng của anh/chị sẽ thay đổi?" Câu này tìm ra dòng P&L. "Hiện tại con số đó là bao nhiêu, và ai đang đo nó?" Câu này cho bạn baseline. "Chi phí dự án được trả từ ngân sách của phòng nào?" Câu này tìm ra economic buyer.

"Nếu muốn mở rộng ra toàn công ty, ai sẽ phải ký?" Câu này cho bạn biết người cần gặp tiếp theo.

Ghi câu trả lời vào một trang tài liệu ngắn: dòng P&L, baseline, người nắm ngân sách, người ký mở rộng, người sẽ so sánh dự phóng với thực tế. Ô nào còn trống thì đó là rủi ro của dự án, quan trọng ngang với một API chưa có tài liệu.

## Ba sai lầm hay gặp

Sai lầm đầu tiên là báo cáo chỉ số kỹ thuật cho người cần chỉ số tài chính. Độ chính xác 92% không có nghĩa gì với người duyệt ngân sách nếu bạn không nói được 8% còn lại tốn bao nhiêu tiền xử lý tay.

Sai lầm thứ hai là không đo baseline trước khi triển khai. Khi agent đã chạy, bạn không còn cách nào chứng minh "trước đây mất 3 phút". Hãy đo ngay tuần đầu, kể cả đo thủ công bằng đồng hồ bấm giờ trên 30 cuộc gọi.

Sai lầm thứ ba là coi người dùng thân thiện nhất là người ra quyết định. Trưởng nhóm khen hết lời không có nghĩa là họ nắm ngân sách. Nếu bạn chỉ có một mối quan hệ ở phía khách, dự án sống hay chết phụ thuộc vào việc người đó có ở lại cuộc họp ngân sách hay không.

## Đưa kỹ năng này vào CV

Khi đọc JD của một vị trí FDE, hãy để ý những đoạn nói về kết quả kinh doanh của khách hay việc làm cùng nhiều bên liên quan. Nếu có, đó là chỗ bạn nên đặt ví dụ kiểu call center ở trên, kể cả trong buổi phỏng vấn. Trong CV, đừng viết "xây dựng pipeline tóm tắt cuộc gọi".

Hãy viết rằng bạn giảm thời gian xử lý sau cuộc gọi từ một con số cụ thể xuống một con số cụ thể, được phòng nào xác nhận, và điều đó thay đổi gì trong kế hoạch của họ.

Một FDE giỏi không chỉ triển khai được agent. Họ là người đứng giữa phòng họp và trả lời được câu hỏi của người bên tài chính trước khi câu hỏi đó được nêu ra.

**Thử ngay tuần này:**

- Chọn một dự án bạn đang làm, viết đúng một câu: 'Nếu dự án thành công, dòng ___ trên P&L của khách sẽ thay đổi ___'. Nếu không điền được, đó là việc cần làm đầu tiên.
- Vẽ bảng ba cột IT, đơn vị kinh doanh, tài chính cho khách hiện tại, ghi tên người cụ thể ở từng cột và đánh dấu ô nào bạn chưa biết.
- Trong buổi họp tới với khách, hỏi câu: 'Ngân sách cho dự án này nằm trong khoản chi của phòng nào?'

## Nguồn

- [How to maximize AI ROI in 2026 (IBM Think)](https://www.ibm.com/think/insights/ai-roi)

- [Enterprise AI Overruns Hit 46.9%: Is the Reckoning in FY2027? (Futurum)](https://futurumgroup.com/insights/enterprise-ai-overruns-hit-46-9-is-the-reckoning-in-fy2027/)

- [The CFO's Missing Role: Why AI Investments Without Finance Ownership Almost Always Disappoint (DEV Community)](https://dev.to/arthicksdev/the-cfos-missing-role-why-ai-investments-without-finance-ownership-almost-always-disappoint-1pnk)