Khi doanh nghiệp đi thuê partner triển khai ERP: Ai đứng về phía bạn?

Khi doanh nghiệp đi thuê partner triển khai ERP: Ai đứng về phía bạn?

Hầu hết các dự án ERP thất bại không phải vì phần mềm dở, cũng không phải vì partner triển khai kém. Chúng thất bại vì một sự mất cân bằng rất đơn giản: partner hiểu về dự án gấp mười lần khách hàng.

Khi một doanh nghiệp quyết định triển khai Dynamics 365, SAP, hay bất kỳ hệ ERP nào, họ bước vào một cuộc chơi mà đối phương đã chơi hàng trăm lần còn mình thì chơi lần đầu. Họ nhận được một bản proposal dày cộm, một bảng estimate với những con số man-day mà không cách nào kiểm chứng, và một hợp đồng SOW đầy thuật ngữ. Rồi họ ký. Và thường thì rắc rối bắt đầu từ đúng chữ ký đó.

Vấn đề thật sự: bất đối xứng thông tin

Tôi đã dành nhiều năm ngồi ở phía triển khai — viết tài liệu, làm customization trên Business Central và Finance & Operations, xây integration, chạy UAT, xử lý go-live. Tôi biết chính xác một dự án hay chết ở đâu, và tôi biết partner thường "cắt góc" chỗ nào.

Đây là vài điều khách hàng gần như không bao giờ nhìn ra khi cầm bản proposal:

• Scope viết mập mờ có chủ đích. Càng mơ hồ thì càng dễ phát sinh Change Request (CR) về sau — và mỗi CR là một hóa đơn mới.
• Estimate phi thực tế ở những khâu vô hình. Data migration, integration, và UAT gần như luôn bị ước lượng thiếu. Đây là ba chỗ làm dự án đội giá và trễ hạn nhiều nhất.
• Lock-in. Một khi đã đi được nửa đường, khách gần như không thể đổi partner. Đòn bẩy đàm phán mất sạch đúng lúc cần nó nhất.
• Ký cái mình không hiểu. Ranh giới giữa "trong scope" và "phát sinh" nằm ở vài dòng trong SOW mà khách đọc lướt qua.

Không phải partner xấu. Đơn giản là họ đại diện cho quyền lợi của họ. Vấn đề là: trong phòng họp đó, không ai đại diện cho quyền lợi của khách hàng bằng đúng ngôn ngữ kỹ thuật của partner.

Vai trò còn thiếu: một cố vấn độc lập đứng về phía khách

Ở các thị trường trưởng thành hơn, vai trò này có tên gọi hẳn hoi: independent ERP advisor, client-side advisor, hoặc IV&V — Independent Verification & Validation. Có những công ty sống hoàn toàn bằng nghề này. Ở Việt Nam và khu vực, khoảng trống này gần như còn bỏ ngỏ — trong khi nhu cầu thì rất thật.

Ý tưởng cốt lõi rất giản dị: một người vừa hiểu nghiệp vụ vừa hiểu kỹ thuật triển khai, nhưng không bán phần mềm, không bán man-day triển khai — chỉ đại diện cho quyền lợi của doanh nghiệp. Người đó biết partner đang nói gì, biết đâu là hợp lý, đâu là thổi phồng, và dịch tất cả sang thứ ngôn ngữ mà người ký tiền hiểu được.

Cố vấn độc lập làm gì, theo từng giai đoạn dự án

1. Giai đoạn chọn partner (trước khi ký). Đây là nơi tiết kiệm được nhiều tiền nhất mà lại ít người để ý nhất.

• Xây RFP đúng trọng tâm để partner báo giá trên cùng một mặt bằng — thay vì mỗi bên hiểu một kiểu.
• Thiết kế bộ scorecard chấm thầu khách quan.
• Viết demo script để "test" tay nghề thật của partner, thay vì xem một bản demo được dàn dựng sẵn.
• Review proposal, SOW và pricing — đối chiếu với mặt bằng thực tế của thị trường.

2. Trong lúc triển khai (giám sát chất lượng).

• Thiết lập governance và các "quality gate" theo từng milestone.
• Review deliverable một cách độc lập trước khi khách ký nghiệm thu.
• Giám sát UAT — khâu mà khách hàng gần như luôn làm hời hợt và trả giá về sau.
• Đánh giá Change Request: cái nào chính đáng, cái nào là "scope creep" trá hình.

3. Go-live và sau đó.

• Đánh giá mức độ sẵn sàng trước khi bấm nút go-live (readiness assessment).
• Giám sát giai đoạn hypercare.
• Đánh giá xem dự án có thực sự mang lại lợi ích đã hứa hay không (benefits realization).

Vì sao một người từng làm delivery lại là lựa chọn đáng tin

Một cố vấn chưa từng "xắn tay" làm triển khai thì nói gì partner cũng đối đáp lại được, và khách cũng khó tin. Điểm khác biệt nằm ở đây: khi bạn đã từng tự mình viết estimate, tự mình chạy migration lúc 2 giờ sáng trước go-live, tự mình cãi nhau về ranh giới scope — bạn biết chính xác đâu là chỗ hay bị giấu.

Nói cách khác, giá trị của người cố vấn độc lập không đến từ việc "đọc hợp đồng giùm", mà đến từ việc đã đứng ở cả hai phía của chiếc bàn.

Nếu bạn đang chuẩn bị triển khai ERP

Bạn không cần thuê một đội tư vấn khổng lồ ngay từ đầu. Điểm khởi đầu hợp lý và rẻ nhất thường là một việc rất cụ thể: lấy ý kiến thứ hai (second opinion) cho bản proposal và SOW mà bạn đang cầm trên tay.

Vài câu hỏi đáng để tự hỏi trước khi ký:

• Estimate cho data migration và integration đã thực tế chưa, hay chỉ là con số cho đẹp hợp đồng?
• Ranh giới giữa "trong scope" và "phát sinh" có được viết rõ ràng không?
• Nếu muốn đổi partner giữa chừng, bạn có còn đường lui không?
• Ai sẽ chịu trách nhiệm nếu UAT thất bại — và "thất bại" được định nghĩa thế nào?

Một khoản chi nhỏ cho việc soát xét ở đầu dự án thường rẻ hơn rất nhiều so với những Change Request và tháng trễ hạn ở cuối dự án.

---

Bài viết chia sẻ góc nhìn từ kinh nghiệm triển khai Dynamics 365 (Business Central & Finance and Operations) và tích hợp hệ thống. Nếu doanh nghiệp của bạn đang trong quá trình chọn partner hoặc đang triển khai và cần một góc nhìn độc lập, hãy để lại bình luận bên dưới.