Lựa chọn phần mềm ERP không nên bắt đầu bằng danh sách “top ERP”. Một hệ thống chỉ phù hợp khi đáp ứng đúng quy trình, dữ liệu, integration, compliance, năng lực vận hành và ngân sách vòng đời của doanh nghiệp.
Cách an toàn hơn là biến nhu cầu kinh doanh thành requirement có ưu tiên, dùng cùng một bộ scenario để demo nhiều giải pháp, chấm scorecard và tính TCO trên cùng phạm vi. Nếu chưa rõ ERP bao phủ những gì, xem ERP là gì; nếu doanh nghiệp chưa xác định rõ nhu cầu và readiness, nên đọc ERP cho doanh nghiệp vừa và nhỏ trước khi đi vào selection.
Bước 1: Khóa owner URL, outcome và phạm vi lựa chọn
Trước khi mời vendor, hãy viết một problem statement ngắn: vấn đề nào đang gây chi phí hoặc rủi ro, quy trình nào bị ảnh hưởng, outcome mong muốn là gì và phạm vi nào nằm ngoài dự án. “Cần ERP để chuyển đổi số” không đủ cụ thể để chấm giải pháp.
Bước 2: Chuyển nhu cầu thành requirement có ưu tiên
Requirement nên phân loại theo Must / Should / Could hoặc một mô hình tương đương. Mỗi requirement cần có process owner, lý do kinh doanh và tiêu chí acceptance. Tránh yêu cầu kiểu “phải có module X” nếu chưa xác định chức năng thực sự cần.
- Must: thiếu là không thể vận hành hoặc không đáp ứng compliance.
- Should: tạo giá trị rõ nhưng có workaround tạm thời.
- Could: hữu ích nhưng không nên làm hỏng timeline hoặc TCO.
Nếu cần map phạm vi theo chức năng, xem các module ERP.
Bước 3: Lập shortlist theo functional fit và kiến trúc
| Nhóm tiêu chí | Câu hỏi cần trả lời |
|---|---|
| Functional fit | Standard đáp ứng bao nhiêu quy trình trọng yếu? |
| Data model | Master data, multi-company, multi-warehouse có phù hợp? |
| Integration | API, webhook, middleware, monitoring và ownership thế nào? |
| Security | Role, audit trail, SSO/MFA, segregation of duties có đáp ứng? |
| Deployment | Cloud, on-premise, managed/private cloud phù hợp yêu cầu nào? |
| Localization | Thuế, kế toán, chứng từ và yêu cầu địa phương được hỗ trợ ra sao? |
| Upgrade model | Custom và integration ảnh hưởng thế nào khi nâng phiên bản? |
| Partner ecosystem | Ai triển khai, hỗ trợ và chịu trách nhiệm sau go-live? |
Bước 4: Demo bằng scenario thật, không demo theo menu
Yêu cầu vendor chạy cùng một bộ scenario end-to-end. Ví dụ: nhận đơn hàng, kiểm tra tồn, tạo nhu cầu mua/sản xuất, giao hàng một phần, trả hàng, xuất hóa đơn và đối soát công nợ. Điều này cho thấy integration giữa module tốt hơn việc xem từng màn hình riêng lẻ.
Scenario nên bao gồm ngoại lệ: thiếu tồn kho, thay đổi giá, đơn hàng hủy, lỗi interface, user không đủ quyền hoặc dữ liệu đầu vào sai.
Bước 5: Dùng scorecard thay vì tranh luận cảm tính
| Tiêu chí | Trọng số gợi ý | Cách chấm |
|---|---|---|
| Functional fit | Cao | Đạt standard / cần config / cần custom / không đạt |
| Data & integration | Cao | Khả năng làm system of record và kết nối hệ thống |
| Security & control | Cao | Role, audit, access, segregation |
| UX & adoption | Trung bình–cao | Key user tự thực hiện scenario được không? |
| TCO | Cao | So trên cùng horizon và scope |
| Delivery & support | Cao | Named team, SLA, escalation, knowledge transfer |
Trọng số phải phản ánh rủi ro của doanh nghiệp, không có bộ số chuẩn cho mọi dự án. Quan trọng là dùng cùng một hệ tiêu chí cho mọi ứng viên.
Bước 6: Tính TCO, không chỉ so license
TCO nên gồm license/subscription, triển khai, migration, integration, customization, training, hạ tầng, support, upgrade và nguồn lực nội bộ. Hai giải pháp có giá license khác nhau nhưng tổng chi phí sở hữu có thể đảo chiều khi custom và vận hành được tính đủ.
Dùng khung chi phí triển khai ERP để chuẩn hóa báo giá trước khi so.
Bước 7: Kiểm tra deployment model và trách nhiệm vận hành
Cloud và on-premise không chỉ khác vị trí máy chủ. Chúng khác cách trả chi phí, trách nhiệm backup, patching, upgrade, monitoring, khả năng kiểm soát hạ tầng và tốc độ tiếp nhận innovation. Xem Cloud ERP vs On-premise để tách riêng quyết định kiến trúc này.
Bước 8: Đánh giá đội triển khai, không chỉ sản phẩm
- Named project manager và functional/technical consultant là ai?
- Ai sở hữu fit-gap, data migration, integration và UAT?
- Custom code và tài liệu bàn giao thuộc về ai?
- Support model sau go-live thế nào?
- Escalation và exit plan nếu thay partner ra sao?
Một sản phẩm tốt vẫn có thể thất bại nếu governance và delivery yếu. Vì vậy product score và implementation-partner score nên được tách riêng.
Bước 9: PoC khi rủi ro tập trung ở một vài capability
PoC không cần mô phỏng toàn bộ ERP. Hãy chọn các capability chưa chắc chắn nhất: BOM phức tạp, costing, một integration quan trọng, volume dữ liệu lớn, quyền truy cập đặc thù hoặc một capability AI/agent có mức tự chủ đáng kể. Với AI, nên dùng AI trong ERP để khóa data boundary, permission, human approval, evaluation và fallback trước khi đưa capability vào scorecard hoặc PoC.
Checklist trước khi ký
- Scope và out-of-scope đã rõ.
- Requirement Must/Should/Could đã có owner.
- Demo chạy bằng scenario của doanh nghiệp.
- Gap đã phân loại standard/config/integration/custom.
- Data migration scope đã khóa.
- Integration ownership đã rõ.
- TCO được tính trên cùng horizon.
- Named team và support model đã xác nhận.
- Acceptance criteria và change control có trong SOW.
- Upgrade, data/code ownership và exit plan đã rõ.
Kết luận
Cách lựa chọn phần mềm ERP tốt nhất là biến quyết định thành một quy trình có bằng chứng: requirement → shortlist → scenario demo → scorecard → TCO → PoC khi cần → contract. Sau khi lựa chọn, dùng quy trình triển khai ERP để chuyển từ quyết định mua sang readiness, blueprint, UAT, cutover và go-live.
Đi tiếp từ selection sang quyết định đầu tư và đối tác
Trước khi ký, dùng Business Case ERP để nối baseline, TCO, risk và benefits owner với quyết định đầu tư; dùng chọn đối tác triển khai ERP để chấm named team, methodology và handover tách biệt với product score. Nếu business model là bán lẻ, hãy kiểm tra riêng các scenario omnichannel, POS, inventory và fulfillment trong ERP cho doanh nghiệp bán lẻ thay vì dùng demo generic.
Khi shortlist cần đi vào assessment cụ thể
Bài này tiếp tục sở hữu intent cách lựa chọn phần mềm ERP. Nếu shortlist đã hình thành và doanh nghiệp cần kiểm tra Odoo theo critical scenario, fit-gap, data/integration context, TCO assumptions và readiness, xem tư vấn lựa chọn ERP/Odoo.
Đoàn Trình Dục là Giảng viên Khoa Công nghệ Thông tin tại Đại học Công nghệ Sài Gòn (STU), với hơn 10 năm kinh nghiệm thực chiến trong các lĩnh vực Mạng máy tính, Marketing Online, SEO và Bảo mật hệ thống.
Với nền tảng sư phạm và kinh nghiệm tư vấn cho nhiều doanh nghiệp, thầy chuyên sâu vào việc xây dựng các giải pháp kỹ thuật số toàn diện và hiệu quả.
