Walk into almost any manufacturing operation – regardless of revenue size, industry, or the sophistication of the ERP they run – and you will find the same thing. The ERP is open on one screen. A spreadsheet is open on another. And somewhere in the background, a WhatsApp group is carrying the decisions that neither system was built to handle.
This is not a technology failure. It is not a training problem. It is not evidence that the organisation bought the wrong ERP or implemented it badly. It is the entirely predictable consequence of asking a transaction management system to do something it was never designed to do.
ERPs were built to record what happens. They were not built to decide what should happen next. That distinction – between a system of record and a system of decision – is the planning gap that most manufacturers have learned to work around without ever naming it.
ERPs Were Designed for Transactions, Not Decisions
The architecture of an ERP reflects its design intent. Tables store transactions. Workflows route approvals. Audit trails record what changed and when. The system is optimised for accuracy, compliance, and record integrity – all of which matter enormously for finance, procurement, and operations reporting.
What the architecture was not optimised for is the question a supply chain planner faces every morning: given everything that has changed since yesterday – the supplier delay, the customer who moved their delivery date, the machine that went down for four hours – what should we do today?
That question requires the system to hold multiple scenarios simultaneously, weigh competing constraints, surface what needs attention, and produce a recommendation that reflects the operational reality of the moment. ERP architecture was not built for this. The tables, the transaction logic, the approval workflows – none of it is designed around the decision, only around the record of it.
The ERP records that the order was late. It does not tell you which orders will be late tomorrow, or what to do about them today.
This is not a criticism of ERPs. SAP, Oracle, and every well-implemented local ERP system do exactly what they were designed to do, and they do it well. The problem is the expectation gap – the belief that a transaction management system, if configured correctly enough, will eventually become a decision-making system. It won’t. The architecture doesn’t support it. The design intent never intended it.
The Excel and WhatsApp Supply Chain
Every supply chain operation has a formal system and an actual system. The formal system is the ERP – the system of record that leadership sees in reports, that auditors review, that the IT team maintains. The actual system is the collection of spreadsheets, shared drives, and messaging groups where the real planning happens.
The Excel sheet exists because someone needed to model a scenario the ERP couldn’t run. It stayed because the model worked, and because rebuilding it inside the ERP would take months. Eventually it became the planning tool. The ERP became the place where decisions, once made, were recorded.
The WhatsApp group exists because a decision needed to be made faster than any formal system could support. A supplier called with a delay. A customer needed a confirmation. The production team needed to know if they should set up for the next job or wait for materials. The ERP had no mechanism to surface that question to the right person and get an answer in time. WhatsApp did.
The ERP is the system of record. Excel is the system of planning. WhatsApp is the system of execution. Most manufacturing operations run on all three simultaneously.
This is not dysfunction. It is adaptation. The people running these operations are not choosing to circumvent the ERP out of stubbornness. They are using the tools that let them make decisions fast enough to keep the operation running. The ERP records the outcome. Everything that led to that outcome happened somewhere else.
The cost of this adaptation is significant and largely invisible. Decisions made on spreadsheets are not traceable. Commitments made on WhatsApp are not in the system. When something goes wrong – an OTIF failure, an inventory write-off, a missed customer commitment – the trail of decisions that led there is distributed across screens and chat histories that no audit can reconstruct.
The Gap Is Structural, Not Configurational
Organisations that recognise this pattern often respond by trying to close the gap through ERP configuration. More custom reports. More planning modules. More consultants spending more months trying to make the transaction system behave like a decision system.
The gap does not close, because the gap is structural. No amount of configuration changes what an ERP was designed to do. The architecture optimised for transaction integrity cannot be reconfigured into an architecture optimised for decision support. These are different design problems with different solutions.
The planning gap requires a different layer – one built specifically for the questions that arise between transactions. What capacity is available against the commitments already made? Which supplier delays will impact which customer orders? What does the inventory position look like across the network against the demand plan for the next four weeks? These questions require a system designed around decisions, not around records.
Closing the planning gap does not mean replacing the ERP. It means building the decision layer that sits above it – the layer the ERP was never designed to be.
What the Decision Layer Does
A decision intelligence layer does not replace the ERP. It reads from it, processes the planning logic the ERP cannot run, and surfaces decisions back to the operation – while transactional data stays where it belongs, inside the ERP.
The demand planner still works in the same operation. The procurement team still raises purchase orders in the ERP. The production scheduler still confirms jobs through the same system. What changes is what happens before those transactions are raised – the decisions about what to commit, what to schedule, what to prioritise, and what to flag as a risk before it becomes a crisis.
The spreadsheets get replaced not because someone mandated it, but because the decision layer does what the spreadsheets were doing – faster, with live data, with traceability, and with the constraints of the actual operation built in. The WhatsApp group quiets down because exceptions are surfaced in the system before they need to be escalated in a chat.
The ERP keeps doing what it was built to do. The decisions that used to happen outside it now happen inside a system designed for exactly that purpose. The gap closes – not because the ERP changed, but because the layer above it was finally built.
The Question to Ask
The right question for any manufacturing organisation running an ERP is not whether the ERP is configured correctly. It is whether the planning decisions that drive operational outcomes are being made in a system built for decisions, or in a system built for records – with the real work happening on spreadsheets and in chat groups that no one can audit.
If the answer is the latter, the ERP is not the problem. The missing decision layer is.
About Oritiq
Oritiq is the decision intelligence layer above your ERP – connecting planning, procurement, production, and distribution into a single system of decisions. It does not replace your ERP. It closes the gap between what your ERP records and what your operation needs to decide.