# Khách đã thuê Accenture hay Deloitte: FDE giữ chữ "xong"

> Nhà tích hợp hệ thống lo phần xây. Bạn giữ ba thứ họ thường không giữ: tiêu chí "xong", hiểu biết về sản phẩm và việc bàn giao vận hành.

Bản gốc: https://fdetimes.net/vi/bach-khoa/nha-thau-tich-hop-accenture-deloitte-fde-lam-viec-cung/

Bạn đến buổi kickoff đầu tiên ở một khách hàng doanh nghiệp và thấy mình không phải người kỹ thuật duy nhất trong phòng. Ngồi bên kia bàn là đội của Accenture hoặc Deloitte, đã có SOW ký sẵn, có timeline và project manager riêng. Câu hỏi đầu tiên bật ra trong đầu: vậy mình đến đây làm gì?

Tình huống này ngày càng phổ biến. Khi OpenAI ra mắt nền tảng Frontier ngày 23/2/2026, các hãng tư vấn như Accenture và Capgemini tham gia với tư cách đối tác, làm việc cùng đội FDE của OpenAI. Trước đó, tháng 12/2025, Accenture và Palantir lập một nhóm kinh doanh chung, dựa trên hơn 2.000 nhân sự của Accenture thạo Palantir.

Vì thế, làm việc cạnh một nhà tích hợp hệ thống (SI) đã thành một kỹ năng của nghề FDE, không còn là chuyện riêng của bên sales. Làm tốt, bạn dẫn dắt phần kỹ thuật mà không phải tự làm hết.

Làm dở thì một trong hai chuyện sẽ xảy ra: bạn thành người trả lời ticket cho SI, hoặc thành đối thủ của họ ngay trong văn phòng khách.

## Hai đội, hai cách hiểu chữ "xong"

Thoạt nhìn, việc chia vai khá rõ: SI xây và tích hợp, còn người hiểu nền tảng sâu nhất là bạn. Nhưng hai bên được chấm điểm theo hai thước đo khác nhau.

Theo Webfuse, phạm vi và cách làm của một dự án tư vấn do SOW định sẵn, người tư vấn được đánh giá theo mức hoàn thành so với phạm vi, và công ty tư vấn theo dõi utilization.

FDE thì được đánh giá bằng mức độ dùng thật trong production và tác động đo được lên quy trình. Entrans, một công ty đang chào bán dịch vụ FDE nên cần đọc như một quan điểm, nói việc chỉ xong khi hệ thống thực sự vận hành ra kết quả kinh doanh đã định. Thành công cũng không đo bằng SLA thông thường như uptime hay độ trễ API.

Khoảng giữa hai mốc đó thường chẳng ai ký nhận.

Forgepoint Capital giải thích vì sao khoảng ấy khó lấp bằng hợp đồng: chất lượng trong các dự án AI rất khó ghi thành điều khoản. Họ đặt câu hỏi, nếu hai bên còn không thống nhất được thế nào là tốt, làm sao thống nhất được sản phẩm bàn giao trong SOW?

Đó là quan điểm, không phải kết quả đo. Nhưng nó giải thích vì sao phần khó định nghĩa nhất, gồm eval, hành vi của agent và xử lý lỗi của model, hay rơi về tay bạn dù hợp đồng không ghi. Nick Johnston của Salesforce nói thẳng rằng kỷ nguyên agent được quyết định bằng kết quả kinh doanh, không phải bằng các dự án thí điểm.

Đừng vì thế mà coi SI là bên chậm hơn: tháng 8/2026, Deloitte công bố đưa FDE vào thẳng các đội triển khai giải pháp trong một dự án Salesforce. SD Times cũng cho rằng FDE bổ sung chứ không thay thế người tư vấn truyền thống, lấp vào những chỗ họ không mạnh. Chức danh không quan trọng bằng câu hỏi ai chịu trách nhiệm phần nào.

## Thử hình dung: agent xử lý hồ sơ bồi thường

Giả sử khách là một công ty bảo hiểm muốn có agent đọc hồ sơ bồi thường rồi đề xuất duyệt hoặc chuyển cho người xem.

SOW của SI ghi "xong" là khi agent tích hợp được với hệ thống quản lý hồ sơ và qua UAT gồm 20 kịch bản. Phía khách thì muốn tự động hoá các hồ sơ đơn giản, với điều kiện agent đúng ít nhất 95%.

Giờ thử tính. Agent qua cả 20/20 kịch bản UAT, vì đó toàn là trường hợp đi đúng luồng. Nhưng khi bạn chạy nó trên bộ eval 200 hồ sơ thật đã ẩn danh, agent chỉ đúng 170 hồ sơ, tức 85%. Theo hợp đồng thì dự án đã xong, còn kết quả khách cần thì chưa đạt.

Không ai trong chuyện này làm sai. SI làm đúng những gì đã ký, chỉ là hợp đồng đo nhầm thứ cần đo. Việc của bạn là phát hiện khoảng chênh đó từ tuần đầu, đừng để đến ngày go-live mới thấy.

Công cụ đầu tiên là một bảng phân vai, làm xong trước khi ai bắt tay vào viết code:

| Hạng mục | SI | FDE của hãng | Khách |
|---|---|---|---|
| Tích hợp với hệ thống quản lý hồ sơ, xác thực, dữ liệu nội bộ | Chịu trách nhiệm chính | Tư vấn giới hạn API | Cấp quyền truy cập |
| Bộ eval và ngưỡng 95% | Chạy trong CI | Thiết kế, giữ chất lượng | Gán nhãn, duyệt ngưỡng |
| Thiết kế agent, xử lý lỗi model | Cài đặt | Chịu trách nhiệm chính | Xác nhận quy tắc nghiệp vụ |
| Giới hạn và thay đổi sắp tới của nền tảng | Được thông báo | Chịu trách nhiệm chính | Được thông báo |
| Runbook vận hành sau go-live | Chịu trách nhiệm chính | Cùng viết, cùng diễn tập | Phê duyệt |

Mỗi dòng chỉ có một bên chịu trách nhiệm chính. Dòng thứ hai là chỗ bạn dẫn dắt: bộ eval trở thành tài liệu nghiệm thu chung và đội SI chạy nó mỗi lần có thay đổi. Nhờ vậy, "xong" theo hợp đồng và "xong" theo kết quả kinh doanh cuối cùng trùng nhau.

## Nêu khoảng trống mà không lấn sân

Cách bạn nói ra con số 85% cũng quan trọng không kém chính con số đó. Một kịch bản cho cuộc họp tuần có thể như sau.

Bạn: "UAT đã qua hết, đội anh chị làm phần tích hợp rất chắc. Bên em vừa chạy thêm 200 hồ sơ thật thì được 85%, còn mục tiêu nghiệp vụ là 95%. Phần thiếu chủ yếu nằm ở hành vi của agent, đó là phần bên em chịu trách nhiệm."

Lead của SI: "Vậy có ảnh hưởng timeline của bọn tôi không?"

Bạn: "Phần tích hợp thì không. Em chỉ đề xuất đưa bộ 200 hồ sơ này vào CI của anh chị để bản build nào cũng báo điểm. Bên em sửa agent, bên anh chị thấy kết quả ngay."

Đoạn hội thoại này làm đúng ba việc, theo thứ tự: ghi nhận phần việc SI đã làm tốt, nhận phần thiếu về phía mình, rồi đưa ra một cơ chế chung là chạy eval trong CI thay vì đổ lỗi cho ai.

**Điểm mấu chốt:** Dẫn dắt kỹ thuật không phải là làm hết việc, mà là giữ định nghĩa thế nào là xong.

## Các bước làm từ tuần đầu

Việc đầu tiên là xin đọc SOW của SI, hoặc ít nhất phần phạm vi và điều khoản nghiệm thu. Viết lại trong một câu xem theo đó "xong" là gì, rồi so với kết quả khách thực sự cần. Khoảng chênh giữa hai câu ấy chính là kế hoạch làm việc của bạn.

Sau đó lập bảng phân vai và nhờ tech lead phía khách xác nhận. Khi chính khách đã đồng ý, SI sẽ không thấy bạn tự gán vai cho mình.

Tiếp theo, dựng bộ eval từ dữ liệu thật và đề xuất dùng nó làm tiêu chí nghiệm thu chung. Một playbook FDE đăng trên dev.to khuyên định nghĩa "chạy được" bằng con số đo được trước khi viết code production. Nếu chất lượng khó ghi vào hợp đồng như Forgepoint nhận định, một bộ eval chạy được là thứ gần nhất với điều khoản chất lượng.

Rồi hẹn một buổi chia sẻ ngắn mỗi tuần với kỹ sư SI về nền tảng: giới hạn, hành vi lúc lỗi và những thay đổi sắp tới. Đây là phần kiến thức chỉ bạn có, và chia sẻ sớm thường giúp cả hai bên đỡ được nhiều ngày debug.

Cuối cùng, chuẩn bị bàn giao ngay từ đầu. Cũng playbook đó mô tả thứ FDE để lại là một hệ thống đang chạy, cộng với năng lực của tổ chức để tự vận hành nó.

Khi SI sẽ là bên tiếp quản vận hành, hãy viết runbook cùng họ và diễn tập một sự cố: kỹ sư SI xử lý, còn bạn chỉ đứng quan sát.

## Ba cái bẫy khiến FDE mất vai

Cái bẫy phổ biến nhất là coi SI như đối thủ. Trong văn phòng khách, hai đội cùng thắng hoặc cùng thua, và cách nhìn FDE bổ sung cho người tư vấn mới là cách nên mang vào phòng họp.

Một cái bẫy khác là âm thầm làm hộ phần việc của SI cho nhanh. Khi thấy tiến độ chậm, bạn rất dễ sốt ruột. Nhưng code bạn viết hộ là code không ai biết vận hành vào ngày bạn rời dự án.

Cái bẫy khó thấy nhất là giữ kiến thức về nền tảng cho riêng mình để được coi là không thể thiếu. Bạn được trả lương để khách và SI tự chạy được hệ thống, không phải để họ cần bạn mãi.

Nếu đang phỏng vấn cho một vị trí FDE ở hãng công nghệ, hãy hỏi thẳng bạn sẽ làm cùng nhà tích hợp hay đối tác tư vấn thường xuyên đến đâu. Câu trả lời cho bạn biết kỹ năng nào sẽ được dùng mỗi ngày.

Trong CV, hãy kể cụ thể: bạn đã biến bộ eval nào thành tiêu chí nghiệm thu chung, và từ khi nào đội SI tự vận hành được hệ thống.

Lần tới có SI ngồi cạnh trong buổi kickoff, đừng hỏi mình đến đây làm gì. Hãy hỏi xem trong hợp đồng, chữ "xong" đang được định nghĩa thế nào.

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

- Mở SOW hoặc tài liệu phạm vi của dự án gần nhất, tìm điều khoản nghiệm thu và viết ra một câu: theo điều khoản này thì "xong" là gì, và nó khác kết quả khách cần ở đâu.
- Lập bảng phân vai cho dự án đó, mỗi hạng mục chỉ có một bên chịu trách nhiệm chính, rồi gửi cho tech lead phía khách xem.
- Viết một trang tóm tắt giới hạn của nền tảng (rate limit, hành vi lúc lỗi, những gì sắp thay đổi) để gửi cho đội SI.

## Nguồn

- [Margin of Safety #55: Why OpenAI and Anthropic are building the new Accenture](https://forgepointcap.com/perspectives/margin-of-safety-55-why-openai-and-anthropic-are-building-the-new-accenture/)

- [Forward Deployed Engineering: How the Delivery Model Works](https://www.entrans.ai/blog/forward-deployed-engineering)

- [Deloitte Becomes First Global System Integrator to Deliver a Salesforce Forward Deployed Engineering Engagement](https://pr.taosnews.com/article/Deloitte-Becomes-First-Global-System-Integrator-to-Deliver-a-Salesforce-Forward-Deployed-Engineering-Engagement/6a7c79b5e2557832e110e212)

- [Accenture and Palantir Technologies (PLTR) Form Accenture Palantir Business Group](https://finance.yahoo.com/news/accenture-palantir-technologies-pltr-form-165648703.html)

- [OpenAI teams up with Accenture, Capgemini and other consulting giants to deploy enterprise AI agents](https://www.businesstoday.in/technology/news/story/openai-teams-up-accenture-capgemini-and-other-consulting-giants-to-deploy-enterprise-ai-agents-517668-2026-02-24)

- [Forward-Deployed Engineers vs. Implementation Consultants: The Crucial Distinctions](https://sdtimes.com/software-engineering/forward-deployed-engineers-vs-implementation-consultants-the-crucial-distinctions/)

- [Forward Deployed Engineer vs Technical Consultant](https://www.webfuse.com/blog/forward-deployed-engineer-vs-technical-consultant)

- [The Forward Deployed Engineer Playbook](https://dev.to/truongpx396/the-forward-deployed-engineer-playbook-23d9)