RFP ERP (Request for Proposal) là tài liệu chuẩn hóa cách doanh nghiệp mô tả nhu cầu và yêu cầu các vendor/đối tác phản hồi trên cùng một cấu trúc. Mục tiêu không phải tạo một file thật dài, mà là giảm tình trạng mỗi vendor hiểu scope theo một cách khác khiến báo giá, demo và proposal không thể so sánh công bằng.
RFP nên được xây sau khi doanh nghiệp đã có problem statement, scope và requirement ưu tiên. Nếu chưa đến bước đó, xem cách lựa chọn phần mềm ERP để đi từ need → requirement → shortlist trước khi gửi RFP.
RFP ERP nên giúp doanh nghiệp trả lời điều gì?
- Vendor hiểu đúng business context và phạm vi hay chưa?
- Requirement nào được đáp ứng standard, configuration, extension/custom hay không đáp ứng?
- Data migration và integration nằm trong hay ngoài proposal?
- Ai thực sự tham gia delivery và support sau go-live?
- Giá được tính trên assumption nào?
- Những phần nào có thể phát sinh change request?
- Rủi ro, dependency, quyền sở hữu dữ liệu/code và exit plan ra sao?
Cấu trúc RFP ERP đề xuất
| Section | Nội dung chính | Output mong muốn từ vendor |
|---|---|---|
| 1. Business Context | Mô hình kinh doanh, pain point, mục tiêu | Hiểu bối cảnh và assumption |
| 2. Scope | Company, location, user, process, module | In-scope/out-of-scope rõ |
| 3. Functional Requirements | Requirement theo process/module | Standard/config/custom/not available + evidence |
| 4. Data Migration | Source, volume, history, cleansing, reconciliation | Method, responsibility, deliverable |
| 5. Integration | System, flow, direction, latency, security | Architecture, ownership, monitoring |
| 6. Technical & Security | Deployment, identity, access, backup, DR | Architecture và control response |
| 7. Implementation | Method, team, governance, UAT, training, cutover | Named roles, plan, dependency |
| 8. Support & Operations | SLA, escalation, release, upgrade | Operating/support model |
| 9. Commercial | License, service, recurring, assumption | Pricing theo cùng format |
| 10. Vendor Response | Reference, team, risk, deviation | Proposal có thể chấm và audit |
1. Business Context: cho vendor đủ thông tin để không đoán
Không cần tiết lộ mọi chi tiết nội bộ, nhưng vendor cần hiểu business model, số pháp nhân/địa điểm, chuỗi giá trị, hệ thống hiện tại, pain point và outcome chính. Nếu context mơ hồ, vendor có xu hướng tự đặt assumption và proposal sẽ khó so.
- Mô hình kinh doanh và thị trường.
- Pháp nhân, location, warehouse/site.
- Nhóm user và role chính.
- Hệ thống hiện tại và dependency.
- Pain point có evidence.
- Business outcome cần cải thiện.
- Constraint: timeline, compliance, deployment, budget envelope nếu doanh nghiệp muốn chia sẻ.
2. Scope: khóa in-scope và out-of-scope
Scope nên mô tả theo process và location, không chỉ bằng tên module. “Inventory in-scope” chưa đủ; cần biết kho nào, process nhập/xuất/transfer/stocktake nào và integration nào liên quan. Có thể dùng các module ERP làm inventory ban đầu nhưng RFP phải xuống tới process.
3. Functional requirement matrix
Mỗi requirement nên có ID, priority, process owner, mô tả, acceptance hoặc scenario. Yêu cầu vendor phản hồi theo cùng taxonomy để tránh câu trả lời marketing dài nhưng không xác định mức fit.
| ID | Requirement | Priority | Vendor Response | Evidence/Note |
|---|---|---|---|---|
| INV-01 | Điều chuyển tồn kho giữa nhiều location có approval | Must | Standard / Config / Extension / Custom / N/A | Demo scenario hoặc tài liệu |
| FIN-01 | Kiểm soát posting theo role và approval | Must | … | … |
| REP-01 | Báo cáo theo dimension đã định nghĩa | Should | … | … |
Không mặc định “custom” là xấu hoặc “standard” là tốt. Quan trọng là hiểu chi phí, regression, upgrade và ownership của mỗi gap.
4. Data Migration trong RFP ERP
RFP cần mô tả source system, domain, volume ước tính, lịch sử cần giữ, data quality issue đã biết và trách nhiệm của hai bên. Yêu cầu vendor nói rõ profiling, mapping, cleansing support, mock migration, reject handling, reconciliation và cutover.
Chi tiết workstream nằm tại Data Migration ERP. Không nên ghi một dòng “vendor migrate data” rồi để toàn bộ assumption sang sau khi ký.
5. Integration requirement trong RFP
Liệt kê từng hệ thống cần kết nối, business flow, direction, dữ liệu, latency, authentication và owner. Vendor cần nêu architecture, connector/API dependency, middleware nếu có, error handling, monitoring và reconciliation.
Xem tích hợp ERP để xây interface inventory trước khi đưa vào RFP.
6. Technical, deployment và security
- Cloud/on-premise/private/managed model và responsibility.
- Environment: dev/test/UAT/prod.
- Identity, SSO/MFA nếu yêu cầu.
- Role/permission và segregation of duties.
- Audit logging.
- Encryption và secret handling.
- Backup/restore, RPO/RTO requirement.
- Data residency/compliance requirement nếu có.
- Upgrade/release model và regression responsibility.
Nếu deployment chưa được khóa, xem Cloud ERP vs On-premise trước khi đưa constraint cứng vào RFP.
7. Implementation approach và named team
Đừng chỉ hỏi “phương pháp triển khai của vendor”. Hãy yêu cầu vai trò cụ thể, phần nào do vendor làm, phần nào doanh nghiệp phải làm và deliverable của từng phase.
- Named project manager và solution lead.
- Functional/technical consultant theo workstream.
- Governance và escalation.
- Fit-gap/blueprint method.
- Configuration/custom development control.
- Migration/integration ownership.
- Testing/UAT support.
- Training và knowledge transfer.
- Cutover/hypercare/support handover.
Phần people-side cũng cần rõ trách nhiệm. Xem Change Management ERP để xác định stakeholder, training, readiness và adoption deliverables.
8. Pricing: chuẩn hóa để so TCO
Yêu cầu mọi vendor tách cùng nhóm chi phí: license/subscription, implementation, migration, integration, custom, training, environment, support, recurring services và assumption. Nếu một hạng mục chưa rõ, đánh dấu TBD/Excluded thay vì tự coi bằng 0.
Đưa proposal về cùng horizon bằng khung TCO ERP trước khi xếp hạng.
9. Scorecard: tách fit, delivery, technical và commercial
Không nên gom mọi thứ thành một điểm “vendor score” duy nhất ngay từ đầu. Hãy chấm theo nhóm để nhìn thấy trade-off và hard gate.
| Nhóm | Ví dụ tiêu chí | Hard gate có thể có |
|---|---|---|
| Functional Fit | Must requirement, exception, usability | Critical process không có safe workaround |
| Data & Integration | Migration, API, monitoring, reconciliation | Không đáp ứng critical integration/control |
| Technical & Security | Deployment, identity, audit, recovery | Không đáp ứng compliance/security bắt buộc |
| Delivery | Named team, method, governance, references | Không có resource/ownership phù hợp |
| Commercial/TCO | One-time, recurring, assumption, change model | Vượt constraint ngân sách đã khóa |
Trọng số phải do steering team xác định theo business risk. Không nên dùng một bộ trọng số cố định cho mọi doanh nghiệp.
10. Scripted demo sau RFP
RFP response không thay demo. Những requirement critical nên được đưa vào cùng một scripted scenario để các vendor chứng minh trên cùng dữ liệu và exception. Không cho mỗi vendor chỉ demo phần mạnh nhất của họ.
- Scenario ID và business context.
- Input data.
- Expected process/output.
- Exception cần xử lý.
- Người chấm và evidence.
- Gap phát hiện sau demo.
RFP response matrix có thể copy dùng ngay
| Req ID | Priority | Requirement | Response | Module | Config/Custom | Evidence | Assumption | Cost impact |
|---|---|---|---|---|---|---|---|---|
| Must/Should/Could | Std/Config/Ext/Custom/N/A | Demo/Doc |
Checklist trước khi phát hành RFP ERP
- Problem statement và outcome đã được sponsor duyệt.
- Scope/out-of-scope đủ rõ.
- Requirement có priority và process owner.
- Migration scope/source/history đã mô tả.
- Integration inventory đã có.
- Security/deployment constraint đã xác minh.
- Vendor response format được chuẩn hóa.
- Pricing template dùng cùng nhóm chi phí.
- Scorecard và hard gate được thống nhất trước khi nhận proposal.
- Scripted demo được chuẩn bị cho critical scenario.
- Assumption/deviation phải được vendor ghi rõ.
Kết luận
RFP ERP tốt không phải tài liệu dài nhất mà là tài liệu khiến nhiều vendor trả lời cùng một bài toán theo cùng cấu trúc. Hãy khóa context, scope, requirement, migration, integration, security, delivery và pricing trước; sau đó dùng scorecard và scripted demo để biến proposal thành evidence có thể so sánh. Khi vendor đã được chọn, chuyển toàn bộ assumption và commitment quan trọng vào SOW/contract và quản trị tiếp bằng quy trình triển khai ERP.
Nối RFP với business case và partner decision
Dùng Business Case ERP để kiểm tra requirement và proposal có còn phục vụ đúng baseline, value driver và TCO đã được duyệt; sau đó dùng chọn đối tác triển khai ERP để đánh giá named team, methodology, reference, commercial assumption và knowledge transfer trước khi khóa SOW.
Khi cần khóa scope trước khi phát hành RFP
Bài này tiếp tục sở hữu intent RFP ERP. Nếu requirement còn phân tán hoặc doanh nghiệp muốn đưa Odoo vào shortlist nhưng chưa khóa readiness, scope, critical scenario, data/integration inventory và TCO assumptions, xem tư vấn scope và RFP 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ả.
