5 chỗ estimate ERP hay bị thổi phồng (và cách kiểm chứng)

5 chỗ estimate ERP hay bị thổi phồng (và cách kiểm chứng)

Bài 3 trong series: "Thuê partner triển khai D365 / ERP mà không bị hớ".

Estimate của một dự án ERP thường là con số mà khách hàng ít khả năng phản biện nhất. Bạn nhìn thấy "Data Migration: 40 man-days" và… làm sao biết nó đúng hay sai? Con số ấy có thể quá cao (bạn trả thừa) hoặc quá thấp (dự án sẽ đội giá về sau). Cả hai đều hại cho bạn.

Dưới đây là 5 hạng mục hay lệch nhất trong các dự án Dynamics 365 / ERP, cùng cách để bạn tự đặt câu hỏi kiểm chứng.

1. Data Migration — thường bị ước lượng THIẾU

Migration là hố đen kinh điển. Estimate ban đầu thường chỉ tính công "chuyển dữ liệu", trong khi phần tốn sức thật lại là làm sạch (cleansing), ánh xạ (mapping), và đối soát (reconciliation). Dữ liệu doanh nghiệp thực tế luôn bẩn hơn ai cũng tưởng: mã trùng, thiếu trường, định dạng lộn xộn, lịch sử mâu thuẫn.

Câu hỏi kiểm chứng: Estimate này đã bao gồm bao nhiêu vòng migration thử (mock migration)? Việc làm sạch dữ liệu do bên nào chịu — và tính vào công của ai? Có ngân sách cho đối soát sau migration không?

2. Integration — điểm bị đánh giá thấp một cách hệ thống

Mỗi tích hợp với hệ thống bên ngoài (cổng thanh toán, ngân hàng, CRM, kho, hệ thống cũ) là một dự án nhỏ trong dự án lớn. Estimate hay chỉ tính công "dựng interface" mà quên phần xử lý lỗi, cơ chế retry, đối soát hai chiều, và test các tình huống ngoại lệ — vốn chiếm phần lớn thời gian thật.

Câu hỏi kiểm chứng: Với mỗi integration, estimate có tách riêng phần xử lý lỗi và test các case ngoại lệ không? Ai chịu trách nhiệm khi hệ thống đầu kia thay đổi?

3. UAT — bị coi nhẹ ở cả hai phía

User Acceptance Testing thường bị nhét vào một khung thời gian ngắn ở cuối dự án, như thể nó sẽ trôi chảy. Thực tế UAT là lúc mọi hiểu lầm về nghiệp vụ lộ ra, và nó luôn sinh ra một loạt điều chỉnh. Estimate quá mỏng cho UAT gần như đảm bảo dự án sẽ trễ ở phút chót.

Câu hỏi kiểm chứng: Có bao nhiêu vòng UAT được dự trù? Có ngân sách cho việc sửa lỗi phát hiện trong UAT không, hay mỗi lỗi lại thành một Change Request?

4. Báo cáo & tùy chỉnh — "tảng băng chìm"

"Xây 20 báo cáo" nghe đơn giản, nhưng độ phức tạp giữa các báo cáo chênh nhau rất xa. Một estimate gộp chung tất cả vào một con số trung bình thường sai lệch nặng. Tương tự, mỗi customization đều kéo theo chi phí ẩn: nó phải được test, được bảo trì, và có thể vỡ khi hệ thống nâng cấp phiên bản.

Câu hỏi kiểm chứng: Danh sách báo cáo/tùy chỉnh có được phân loại theo độ phức tạp không? Ai chịu chi phí khi customization vỡ sau một bản cập nhật của nhà cung cấp phần mềm?

5. Quản lý dự án & hypercare — thường bị ước lượng THỪA hoặc mờ ám

Ngược với bốn hạng mục trên, phần "project management" và "post go-live support" đôi khi bị thổi phồng vì khó kiểm chứng. Một dòng "hypercare: 20 man-days" mà không nói rõ làm gì trong 20 ngày đó thì rất khó đánh giá.

Câu hỏi kiểm chứng: Hypercare bao gồm chính xác những gì, đo bằng chỉ số nào (thời gian phản hồi, số vấn đề tồn đọng)? Tỷ lệ công quản lý dự án so với công triển khai có hợp lý không?

Nguyên tắc chung khi đọc estimate

Đừng hỏi "tổng bao nhiêu tiền". Hãy hỏi "con số này được tạo ra từ giả định nào". Một estimate đáng tin luôn đi kèm giả định rõ ràng — và chính những giả định đó mới là thứ bạn cần soi. Khi giả định lệch thực tế, không có con số nào cứu được dự án.

---

Về songnghia.com

Không chắc estimate của partner là thực tế hay đang lệch? songnghia.com đối chiếu từng hạng mục — migration, integration, UAT, báo cáo, hypercare — với mặt bằng thực tế và với chính tình trạng dữ liệu của bạn, để bạn biết mình đang trả đúng hay trả hớ. Tìm hiểu tại songnghia.com.