Đọc một bản proposal / SOW ERP như thế nào cho đúng

Đọc một bản proposal / SOW ERP như thế nào cho đúng

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

Bản SOW (Statement of Work) là tài liệu quan trọng nhất trong cả dự án ERP, nhưng cũng là tài liệu bị đọc lướt nhiều nhất. Khách hàng thường tập trung vào tổng giá và thời gian, trong khi hai con số đó lại là thứ dễ thương lượng nhất. Cái thực sự quyết định số phận dự án nằm ở những phần mà ít ai đọc kỹ.

Dưới đây là cách đọc một bản SOW theo thứ tự ưu tiên của người đã từng ngồi viết ra nó.

1. Đọc phần "Scope" và "Out of Scope" trước tiên

Đừng đọc từ đầu xuống. Nhảy thẳng vào phần định nghĩa scope. Câu hỏi cần trả lời: ranh giới ở đâu? Một bản SOW tốt luôn có mục "Out of Scope" (những gì không bao gồm) rõ ràng và cụ thể. Nếu mục này mỏng hoặc mơ hồ, đó là dấu hiệu cảnh báo: mọi thứ không được liệt kê rõ về sau đều có thể trở thành Change Request tính phí thêm.

Mẹo: với mỗi nghiệp vụ quan trọng của bạn, tự hỏi "cái này nằm trong scope hay ngoài scope?" — và tìm câu trả lời bằng chữ trong tài liệu, chứ không phải bằng lời hứa miệng của sales.

2. Assumptions — phần "cài bẫy" tinh vi nhất

Mục Assumptions (Giả định) thường bị bỏ qua vì trông vô hại. Thực ra đây là nơi partner tự bảo vệ mình. Ví dụ: "Giả định khách hàng cung cấp dữ liệu sạch, đúng định dạng, đúng hạn" — nghe hợp lý, nhưng nếu dữ liệu của bạn thực tế là bừa bộn (mà dữ liệu doanh nghiệp thì gần như luôn bừa bộn), giả định này vừa bị vi phạm, và mọi phát sinh sẽ là lỗi của bạn.

Hãy đọc từng assumption và tự hỏi: "Nếu điều này không đúng thì sao? Ai chịu chi phí?"

3. Deliverables phải đếm được

Một deliverable tốt là thứ có thể kiểm tra đúng/sai một cách khách quan: "Tài liệu thiết kế được khách ký duyệt", "20 báo cáo theo danh sách đính kèm", "Migration thành công X bản ghi với tỷ lệ lỗi dưới Y%". Hãy cảnh giác với những deliverable mơ hồ như "hỗ trợ go-live" hay "tư vấn tối ưu quy trình" — chúng nghe hay nhưng không đo được, nên cũng không thể bắt lỗi khi thiếu.

4. Điều khoản nghiệm thu (Acceptance Criteria)

Đây là câu hỏi sống còn: làm sao để biết một hạng mục đã "xong"? Nếu SOW không định nghĩa rõ tiêu chí nghiệm thu, bạn sẽ rơi vào cảnh partner nói "xong rồi" còn bạn thấy "chưa dùng được" — và không có căn cứ nào để phân xử. Đặc biệt chú ý cơ chế nghiệm thu tự động: nhiều SOW ghi "nếu khách không phản hồi trong X ngày thì coi như đã nghiệm thu". Điều khoản này có thể khiến bạn vô tình chấp nhận một deliverable lỗi chỉ vì đội bạn bận.

5. Cơ chế Change Request

Change Request là chuyện bình thường — không dự án nào không có. Vấn đề là quy trình. SOW tốt mô tả rõ: ai được đề xuất CR, được đánh giá tác động (thời gian/chi phí) thế nào, ai duyệt, và đơn giá tính ra sao. Nếu phần này thiếu, bạn đang trao cho partner một cây bút mở để viết hóa đơn.

6. Vai trò và trách nhiệm (RACI)

Rất nhiều dự án chậm không phải vì partner làm chậm, mà vì khách hàng không biết mình phải làm gì và khi nào. Một bảng phân vai rõ ràng — ai chịu trách nhiệm, ai duyệt, ai được tham vấn, ai chỉ cần biết — giúp cả hai bên khỏi đổ lỗi lẫn nhau về sau.

Danh sách kiểm tra nhanh

• Phần "Out of Scope" có cụ thể không?
• Các assumption có điều nào phi thực tế với tình hình của tôi không?
• Deliverable có đếm được và nghiệm thu được không?
• Có điều khoản "tự động nghiệm thu" gài trong đó không?
• Quy trình và đơn giá Change Request có rõ không?
• Trách nhiệm của phía tôi đã được ghi rõ chưa?

Nếu đọc qua danh sách này mà bạn thấy quá nửa còn mơ hồ, đừng vội ký. Đó chính là lúc một con mắt độc lập tiết kiệm được nhiều tiền nhất.

---

Về songnghia.com

Bạn đang cầm một bản proposal / SOW và không chắc mình đang ký gì? songnghia.com cung cấp dịch vụ soát xét độc lập — đọc kỹ scope, assumptions, điều khoản nghiệm thu và cơ chế Change Request, rồi chỉ ra những chỗ đáng thương lượng lại trước khi bạn đặt bút. Ghé songnghia.com để tìm hiểu thêm.