We are regularly handed a spreadsheet with 300 rows, each a feature with a Yes/No column. Every vendor ticks nearly every box, the quotes come back within 10% of each other, and the company chooses on price. Eighteen months later it turns out the system cannot do the one thing that mattered.
An ERP requirements document that works looks nothing like that. It describes what your business does, not what software might have.
Why feature checklists fail
A checklist asks "does it support multi-warehouse?" Every product says yes. What it cannot ask is whether it supports your multi-warehouse — the one where stock moves between three locations on a consignment basis and is only invoiced when sold.
Features are binary. Processes have shape. Vendors can only price shape.
What an ERP requirements document should contain
1. Describe your processes as narratives
Write each core process as a short story, in the order it actually happens, naming who does what. A purchase might read: "The branch manager raises a request. Anything over 5,000 JOD needs the GM. Procurement issues a PO. Goods arrive at the central warehouse and are checked against the PO. Discrepancies over 2% are escalated."
Six to ten of these narratives will tell a vendor more than 300 checkboxes.
2. State your volumes honestly
Numbers change the architecture and the price. Include:
- Transactions per month — invoices, purchase orders, stock movements.
- Number of SKUs, and how often the catalogue changes.
- Concurrent users at peak, not total headcount.
- Years of history you need migrated and years you merely need archived.
3. Name your constraints
These narrow the field faster than anything else, so put them early:
- JoFotara e-invoicing compliance.
- Arabic documents for customers, and whether the interface must also be Arabic.
- Systems that must keep working and exchange data with the ERP.
- Whether data must remain in Jordan.
- The date something must be live by, and why that date exists.
4. Separate what you need from what you want
Mark each requirement Must, Should or Could. Be ruthless about Must — if everything is essential, nothing is, and vendors will price for the whole list. In our experience a genuine Must list is fifteen to twenty items.
The section most people omit
Describe what is broken today, plainly. Not "we need better reporting" but "the month-end close takes eleven working days because inventory and finance are reconciled by hand."
This does two things. It lets a good vendor propose something you had not thought of, and it gives you a measurable definition of success — which is what you will hold them to later.
How this changes the quotes
A vendor reading a narrative-based ERP requirements document has to think. Some will decline, which is useful information. The ones who bid will bid differently from each other, because they are proposing approaches rather than confirming a list.
Those differences are exactly what you want to see. Comparable quotes from a checklist tell you nothing except who priced most aggressively.
A practical structure
- Context — what the company does, size, locations, current systems.
- Problems — what is broken now, with numbers.
- Process narratives — six to ten, written as they happen.
- Volumes — the figures above.
- Constraints — compliance, language, integrations, dates.
- Must/Should/Could — the honest priority list.
- What success looks like — measurable, twelve months out.
An ERP requirements document in this shape runs eight to twelve pages. It takes about two weeks of internal work, most of it interviewing your own people. It is the cheapest fortnight you will spend on the project.
