Operational context: the thing your ERP does not have

An ERP is a record of what is true. It holds the order, the purchase order, the works order, the stock position and the delivery date, and it holds them accurately.

What it does not hold, in a form anything can use, is how those things depend on one another right now. That dependency graph exists, but it is distributed across experienced people, and it is reassembled by hand every time something goes wrong.

What operational context means

Operational context is the connective layer: which customer order this works order serves, which purchase order lines that works order waits on, which asset the routing requires, which inspection gates the release, which consignment carries it out of the door, and how much slack exists at each hop.

Pieces of this are implicit in the data. A bill of materials and a routing contain much of the structure. What is missing is the live state of each link and, crucially, the resolution across systems that call the same physical thing different names.

The resolution problem is the hard part

This is where these projects actually spend their time, and it is consistently underestimated.

• The same supplier appears three times in purchasing with different spellings, from different buyers, over different years.
• A part has a legacy code and a current code, and both are still in active use in different places.
• The warehouse uses an internal location reference that does not appear in the ERP at all.
• A customer is one account commercially and four delivery points operationally.
• A works order was split on the floor and only one half was recorded.

None of this is a sign of a badly run business. It is what a decade of real operation looks like in any system. But a connected view has to resolve it, because a dependency that cannot be matched is a dependency the system cannot see, and a blind spot in an early warning system is worse than no system at all.

Every unmatched record is a chain the system will fail to trace, silently.

Why not build it inside the ERP

It is a fair question, and occasionally the answer is that you should. More often there are three reasons not to.

1. The data is not all thereMaintenance history, warehouse movements, quality records and supplier correspondence frequently live outside the ERP. A view built inside it is already missing part of the chain.
2. The write riskOperational intelligence needs to read widely and write almost nothing. Building it inside the transactional system puts analytical logic next to the records that run the business, which is a larger risk than it needs to be.
3. The paceThis layer changes as you learn what matters. Iterating weekly inside a validated ERP is not realistic in most organisations, and the ones where it is tend to regret it.

The alternative is not replacing anything. It is reading from the systems you already run and holding the connective layer separately, where it can change quickly and cannot damage anything.

What having it makes possible

Once the graph exists, a set of questions that were previously expensive become straightforward.

• Which customer orders does this one supplier actually sit behind.
• If this asset is down for a shift, which committed dates move, and which have enough slack to absorb it.
• This part is short in three weeks. Which orders need it, and which of those are already at risk for other reasons.
• This inspection is holding four batches. Which of them is standing between a priority order and its dispatch.

Each of those is answerable today by a capable person with an afternoon and several systems open. The difference is that the graph answers them continuously, for everything, which is what makes early warning possible rather than occasional.

It is also where the solutions stop being separate

This is the reason we treat order risk, production disruption, inventory shortage, supplier performance and the rest as applications on one layer rather than separate products.

A supplier slipping, a machine stopping and a batch being held are three events in three functions. Against a shared dependency graph they are three inputs to the same question: which commitments are now at risk, and what can still be done. Built separately, they become three systems that each know part of the answer and none of which know the chain.

Where to begin

Not with the whole graph. Take one commitment type, usually the customer delivery date, and resolve only the entities that commitment depends on. That is a much smaller set than the full master data problem, and it produces something useful while it is still incomplete.

The graph grows as the questions do. Trying to build all of it first is how this becomes a two-year data programme that never ships a decision.