1. Bối Cảnh
Scope creep (phình phạm vi) là kẻ thù số 1 của dự án ERP. Đây là hiện tượng phạm vi dự án liên tục mở rộng ngoài những gì đã thỏa thuận, dẫn đến: dự án kéo dài, vượt ngân sách, đội ngũ kiệt sức, khách hàng không hài lòng dù đã làm thêm rất nhiều.
Thực trạng phổ biến:
- Khách hàng liên tục "tiện thể": "Tiện thể anh làm thêm cái báo cáo này nhé", "Tiện thể tích hợp thêm phần mềm kế toán cũ vào nhé" — mỗi "tiện thể" tốn 2-5 ngày công
- Không có quy trình change request: Mọi thay đổi được chấp nhận qua miệng, không qua văn bản, không báo giá bổ sung
- Thiếu baseline: Không có tài liệu phạm vi gốc để đối chiếu khi khách yêu cầu thêm
- PM không dám nói "không": Sợ mất lòng khách, PM nhận hết yêu cầu — đội triển khai "chết chìm"
Một checklist kiểm soát phạm vi dự án ERP sẽ giúp:
- Có baseline rõ ràng để đối chiếu mọi yêu cầu thay đổi
- Quy trình change request chặt chẽ — mọi thay đổi phải qua đánh giá và phê duyệt
- Bảo vệ đội triển khai khỏi làm không công
- Dự án đúng hạn, đúng ngân sách
2. Checklist kiểm soát phạm vi dự án ERP
GIAI ĐOẠN 1: XÁC ĐỊNH BASELINE
- [ ] Phạm vi dự án được mô tả CHI TIẾT trong tài liệu (không chỉ trong hợp đồng)
- [ ] Mỗi module có danh sách chức năng cụ thể: bao gồm những gì, KHÔNG bao gồm những gì
- [ ] Tài liệu phạm vi được khách hàng ký xác nhận (đây là baseline)
- [ ] Mọi thứ không có trong baseline = ngoài phạm vi = change request
GIAI ĐOẠN 2: QUY TRÌNH CHANGE REQUEST
- [ ] Khi khách yêu cầu thêm: ghi nhận vào form Change Request (CR)
- [ ] CR bao gồm: mô tả yêu cầu, lý do, mức độ ưu tiên, impact (nếu không làm)
- [ ] BA/PM đánh giá: effort (ngày công), impact đến timeline, impact đến các module khác
- [ ] Báo giá bổ sung (nếu có chi phí phát sinh)
- [ ] Khách hàng duyệt CR (ký hoặc email xác nhận) → mới bắt đầu làm
- [ ] Cập nhật baseline sau khi CR được duyệt
GIAI ĐOẠN 3: GIAO TIẾP VỀ PHẠM VI
- [ ] Họp hàng tuần: review danh sách CR đang chờ, đã duyệt, đã hoàn thành
- [ ] Báo cáo tiến độ luôn kèm theo cập nhật về phạm vi (có thay đổi gì không?)
- [ ] Khi phát hiện yêu cầu ngoài scope: thông báo ngay, không "làm trước báo sau"
GIAI ĐOẠN 4: BẢO VỆ BASELINE
- [ ] PM phải là "người gác cổng" — mọi yêu cầu thêm đều phải qua PM
- [ ] Tuyệt đối không nhận yêu cầu trực tiếp từ key user mà không qua quy trình CR
- [ ] Khi khách nói "tiện thể": trả lời "Chúng tôi sẽ ghi nhận vào CR và báo giá bổ sung"
- [ ] Định kỳ review baseline với sponsor để tránh "scope creep ngầm"
3. Form Change Request mẫu
| Trường | Nội dung |
|---|---|
| Mã CR | CR-2026-001 |
| Ngày yêu cầu | 15/08/2026 |
| Người yêu cầu | Ông Nguyễn Văn A (Sponsor) |
| Mô tả | Bổ sung báo cáo tổng hợp doanh thu theo từng chi nhánh |
| Lý do | Ban Giám đốc cần báo cáo này hàng tuần |
| Mức độ ưu tiên | Cao |
| Effort ước tính | 3 ngày công |
| Impact timeline | Dời go-live 3 ngày |
| Chi phí phát sinh | 3 × 5,000,000 = 15,000,000 VNĐ |
| Phê duyệt | ☐ Chưa duyệt / ☑ Đã duyệt (ngày 16/08/2026) |
4. Ứng dụng ERP vào kiểm soát phạm vi
| Module | Chức năng | Lợi ích |
|---|---|---|
| Dự án (Project) | Task, WBS, baseline | So sánh thực tế với baseline, phát hiện scope creep |
| Helpdesk | Ticket CR | Quy trình CR tự động: yêu cầu → đánh giá → phê duyệt |
| Timesheet | Chấm công theo task | Phát hiện task ngoài scope (effort không có trong kế hoạch) |
5. Kết luận
Kiểm soát phạm vi không phải là "từ chối khách hàng" — mà là quản lý kỳ vọng và bảo vệ lợi ích cả hai bên. Một quy trình CR chuẩn giúp:
- Khách hàng hiểu rõ mỗi yêu cầu thêm đều có chi phí và ảnh hưởng đến timeline
- Đội triển khai không bị "chết chìm" trong yêu cầu ngoài scope
- Dự án đúng hạn, đúng ngân sách
Nguyên tắc vàng: "Mọi thứ không có trong baseline là ngoài phạm vi. Mọi thứ ngoài phạm vi phải qua CR. Mọi CR phải được duyệt trước khi làm. Không có ngoại lệ."