ERP procurement starts with an operating problem, not a product name
An ERP tender should explain which decisions, records and controls need to improve. “Finance, HR and inventory” is not enough: bidders need to understand the organizations, locations, users, approval levels, currencies, reports, integrations, data sources and operating constraints inside the intended scope.
The issuing organization remains responsible for its procurement method, applicable law or donor rules, evaluation authority and final contract. This guide is a planning aid, not a substitute for those requirements.
1. Establish governance before drafting the solicitation
- Name the procurement owner, business sponsor, process owners, technical reviewers and authorized approver.
- Record the procurement objective, budget authority, target decision and material dependencies.
- Define how clarification, addenda, conflicts of interest, confidentiality and bidder communication will be handled.
- Separate people who prepare requirements, evaluate responses and authorize the award where the applicable rules require it.
A small decision group with written authority is more useful than a long participant list without ownership.
2. Describe outcomes and representative workflows
Translate broad module names into end-to-end scenarios. A procurement workflow might run from request through approval, quotation, purchase order, receipt, invoice, payment and accounting. A payroll workflow might include attendance inputs, approved adjustments, calculation, review, payment and posting.
For each scenario, identify roles, required data, approval boundaries, exceptions, outputs and acceptance evidence. This gives evaluators something concrete to compare during written review and demonstration.
3. Build a traceable requirements matrix
Give every material requirement an identifier and classify it using the organization’s approved method. Ask bidders to answer with one controlled status such as standard capability, configuration, custom development, third-party dependency, future roadmap or exception.
- Functional workflows, validations, approvals and reports
- Roles, segregation of duties and activity history
- Languages, RTL behavior, branches, units and currencies
- Data migration, integrations and external dependencies
- Availability, performance, accessibility and supported devices
- Security, privacy, retention, backup and recovery
- Training, documentation, deployment, support and exit requirements
A “yes” without explanation or evidence should not be treated as equivalent to a demonstrated, contractually included capability.
4. State the implementation responsibility matrix
The solicitation should distinguish supplier work, client work and shared work. Typical responsibilities include process confirmation, source-data ownership, cleaning, configuration decisions, integration access, test scenarios, UAT, training attendance, infrastructure, cutover approval and support contacts.
Dates become credible only when the dependencies and decision deadlines on both sides are visible. A bidder cannot responsibly guarantee migration quality when the source data, owner and validation method are unknown.
5. Request security evidence proportionate to risk
Describe data sensitivity, privileged actions, user populations, locations, internet exposure, uptime and recovery needs. Ask how the proposed team controls source access, changes, dependencies, secrets, environments, testing, releases, logging, incidents and vulnerability handling.
Do not turn a framework name into an automatic certification claim. The evidence, scope and responsible party must be clear. Security obligations should continue through implementation, hosting, maintenance and exit—not end with the proposal.
6. Compare total evaluated responsibility, not only licence price
Request a price structure that makes comparison possible. Depending on the procurement, this can include licences or subscriptions, implementation, configuration, custom work, migration, integrations, infrastructure, travel, training, taxes, support, renewals and optional items.
Record commercial assumptions: user counts, environments, data volumes, service hours, currencies, payment milestones, price validity and change-control rules. Lowest initial price and lowest evaluated cost are not automatically the same.
7. Use demonstrations as controlled evidence
Give shortlisted bidders the same representative scenarios, sample roles and evaluation time. Require them to distinguish existing capability from configuration, proposed development and third-party services. Record unanswered questions and written clarifications through the authorized procurement channel.
A polished generic presentation is not evidence that the proposed scope can perform the organization’s transactions, controls and reports.
8. Define acceptance and contract boundaries before award
- Deliverables and reviewable stages
- Requirements baseline and change procedure
- Migration scope and reconciliation evidence
- Test environments, defect classification and UAT authority
- Cutover, rollback, handover and documentation
- Data ownership, export, licences and intellectual-property terms
- Warranty, support, SLA measurement, renewal and termination
Evaluation promises that matter should be reflected in the signed scope or contract. Marketing language that never becomes a deliverable cannot be accepted objectively.
A practical tender pack
A complete pack commonly contains instructions, background, scope, workflow scenarios, requirements matrix, data and integration overview, security expectations, implementation responsibilities, deliverables, evaluation method, response format, commercial schedule, contract conditions and an authorized clarification process.
Primary guidance used for this article
The structure was cross-checked against the World Bank Procurement Regulations for IPF Borrowers, sixth edition and its current guidance on evaluating bids and proposals. Those documents apply only where their governing framework says they apply; every organization must follow its own current legal, donor and internal procurement rules.