The failure mode of ERP projects is remarkably consistent. It is almost never "the software did not work". It is "the software worked, and the finance team kept using the spreadsheet".
That happens because the system was built against how the organisation says it works, not how it actually works. The gap between those two things is where the project dies — and you can find that gap for free, before you spend anything, by writing down six workflows.
Do this before you talk to any vendor. It will make every quote you receive more accurate, and it will tell you more about your own organisation than the ERP will.
1. A purchase request, end to end
Start with one real request that completed recently. Not a typical one — an actual one, with names.
Write down:
- Who raised it, and what triggered it
- Every person who approved it, in order
- What each approver was actually checking
- How long each step took, honestly
- What happens when someone is on leave
- Where it stalled, and who chased it
The last three are the valuable ones. Approval hierarchies on paper are always tidy. Real ones have delegation, informal escalation, and one person everyone calls when it is urgent. A system that models only the tidy version gets bypassed within a month.
The question that exposes the gap: who is allowed to approve on someone else's behalf, and is that written down anywhere?
2. Goods receipt and what happens when it does not match
The purchase order said 100 units. 94 arrived, two are damaged, and one is the wrong specification. Write down exactly what your organisation does next.
This single scenario determines a surprising amount of your data model: partial receipts, quality holds, returns to supplier, invoice matching tolerance, and whether the purchase order can be amended after the fact.
Most organisations discover during this exercise that there are two different answers depending on who you ask.
3. A stock movement, including the informal ones
Follow one item from arrival to consumption:
- Receipt into which warehouse
- Transfers between locations, and who authorises them
- Issue to a department or job, and against what
- Returns, and whether they go back to the same location
- What happens to damaged or expired stock
Then write down the movements that happen without paperwork. Every warehouse has some. Pretending they do not exist does not remove them from the system — it just means the system's stock figure and the shelf disagree, which is how people stop trusting the system.
4. The month-end close
List every report produced at month end, and for each one: who produces it, from which sources, how long it takes, and who reads it.
You will usually find at least one report that takes a full day to assemble and is read by nobody, and at least one number that two departments calculate differently. Both are findings worth having before you build.
The question that exposes the gap: if a manager asked for this number on the 14th instead of the 30th, could anyone produce it?
5. Contracts and obligations
If you procure under contracts, document: where contracts live today, who knows when they expire, what obligations they carry, and what happens when one lapses unnoticed.
This is the workflow most often left out of ERP scope and most often requested six months after go-live, at which point it is an expensive addition rather than a cheap module.
6. Who is allowed to see what
Write down, per role: what they can view, what they can create, what they can approve, and what they must never see. Include the exceptions — the person who is technically a clerk but everyone treats as a manager.
Permissions are the single hardest thing to change after launch, because by then people have habits built around what they could see. Getting this on paper first is worth more than any feature list.
On the Ministry of Interior supply platform I worked on as part of the delivery team (case study), the approval hierarchy and permission model were among the most consequential parts of the system — because they are what makes procurement records defensible under audit, which was the entire point of the project.
What to do with the document
Three things, in this order.
First, fix the process problems that are not software problems. If two departments calculate the same number differently, no ERP resolves that — it just automates the disagreement. Resolve it first.
Second, decide build versus configure. With the workflows written down, this becomes a factual question rather than a preference. Standard finance, stock and purchasing are cheaper on a mature product like ERPNext/Frappe. Genuinely unusual workflows — multi-vendor negotiation, sector-specific approval chains, an operating model no product ships — earn the cost of custom work. Anyone who answers this question before reading your workflows is guessing.
Third, sequence the rollout. One department goes live, gets supported until it is genuinely used, then the next. Big-bang rollouts are how systems get rejected, because the first week of friction hits everyone at once and there is no one left with capacity to help.
The uncomfortable part
Doing this properly usually surfaces something nobody wanted to write down: a step that exists only because one person prefers it, a control that everybody routes around, or an approval that has never once been refused.
That is not a reason to stop. It is the most valuable output of the exercise, and it is far cheaper to confront now than after you have encoded it into software.
Next step
If you want a second pair of eyes on the workflows you have written, the ERP for procurement and operations page covers the scope, the build-versus-ERPNext decision, and how rollout works.
Or book a free 15-minute call and bring exactly one workflow — the one that hurts most. We will map it together, and you will get a straight answer on whether it needs custom software or a better spreadsheet.