Why your ERP does not solve procurement execution

The complaint is usually misdirected

When a procurement team says the ERP is not working, they rarely mean it is recording transactions incorrectly. They mean that getting to the transaction takes three weeks and four people.

That distinction matters, because it points at a different solution. An ERP that records well and a procurement process that runs manually are two separate facts, and only one of them is a problem.

What sits between the request and the transaction

Consider a plant asking for a replacement component. Before the ERP has anything to record, somebody has to understand the request, decide which buying route applies, chase the missing specification, identify eligible suppliers, request quotations, follow them up, compare responses, obtain approval and then enter the result.

None of that is transaction recording. All of it is coordination, and it is performed by people whose time is expensive and finite.

Why configuration does not close the gap

The instinctive response is to configure the ERP more thoroughly: more workflow, more validation, more approval routing. This improves transactional control and leaves the coordination untouched.

An ERP workflow can route a requisition to an approver. It cannot notice that the approver has not responded for five days and decide, within policy, to escalate. It cannot read an ambiguous email and work out what was actually requested.

The system-of-record and system-of-execution split

A more useful architecture separates the two roles. The ERP remains the system of record: requisitions, purchase orders, receipts, invoices and financial postings.

A governed execution layer performs the work around those records — interpreting, routing, chasing, comparing, drafting and updating — inside the policies, permissions and approvals the organisation defines. Approved outcomes are written back, and the ERP stays authoritative.

What this changes commercially

Procurement capacity stops being a straight function of headcount. The team’s attention shifts from coordination towards commercial judgement, and categories that were never worth the administrative effort become sourceable.

It also removes an entire class of error. Approved outcomes reaching the ERP without a person retyping them eliminates transcription mistakes that reconciliation currently catches, at cost, later.

The practical test

Take one workflow and count the manual touches between the trigger and the ERP record. Not the approvals — those are decisions the organisation wants — but the interpretation, chasing, consolidation and rekeying.

If that number is high, the constraint is execution, not recording, and no amount of ERP configuration will address it.

Why the ERP was built this way

It is worth being fair to the ERP. It was designed to hold a single, consistent, auditable record of what an organisation committed to and paid for. That is a genuinely hard problem, and modern ERPs solve it well.

The design assumptions that make it good at recording are the same ones that make it poor at coordination. A record system needs structure before it can accept an entry; procurement work arrives unstructured. A record system is optimised for consistency; procurement coordination is mostly exception handling. Neither is a flaw — they are the consequence of what it was built to do.

The four activities no ERP performs

Take one purchase from need to record and separate the activities that require judgement from those that require only attention. Four categories consistently fall outside what any ERP does.

• Interpretation — turning a description of a problem into a structured requirement with a category, entity, value band and date.
• Route selection — deciding which buying process applies, given value, category, entity and risk, and being able to evidence which rule decided it.
• Coordination — chasing suppliers, approvers and evidence, on a schedule, without waiting for a person to remember.
• Normalisation — converting inconsistent supplier responses into something comparable before a decision can be made at all.

Why configuration does not close the gap

The usual response is to configure the ERP harder — more workflow, more fields, more validation. This produces a familiar outcome: the process becomes more rigid without becoming more capable, and the business routes around it.

The reason is that configuration adds structure to a system whose limitation is not insufficient structure. The missing capability is the ability to act on variation, which is a different property from being able to record it.

What to measure before deciding anything

Before evaluating any solution, count manual touches in one workflow. Take a single recent purchase and list every point at which a person had to read, decide, chase, rebuild or retype something between the need arising and the record existing.

Then separate that list into judgement and coordination. The judgement items are work the organisation wants people to do. The coordination items are the addressable population, and their size usually surprises the team that counted them.