The observation that kept coming back
Over the past three articles in this series:
- Why Document AI Isn't Enough for Regulated Engineering Workflows
- When Engineering Data Becomes an Execution Risk
- Intelligent document processing for Utilities and Infrastructure Operators
I've been writing about engineering documentation: how unstructured drawings create execution risk, why revision control and audit trails matter more than most AI vendors acknowledge, and why regulated environments have already figured out what the rest of the market is still learning.
Those conversations were about documents. But somewhere around the same period, a different set of conversations started overlapping with them.
Procurement managers frustrated that their materials master is full of duplicates and poorly described items they can't confidently order from. Operations teams who know they have too much of the wrong stock and not enough of the right parts, but can't prove it well enough to act on it. Maintenance planners who get the inventory report and the engineering register and notice that the two don't quite describe the same plant.
At first these felt like separate conversations. Different functions, different pain, different language. They're not separate. The closer I look, the more clearly I can see that they're the same problem, operating in two different rooms.
Why your ERP and P&ID register are strangers: the root cause of MRO data problems
Here is a simple description of a situation I've encountered in one form or another across petrochemicals, oil and gas, utilities, and port operations.
A pump sits inside a facility. It has a tag. That tag appears on a P&ID, linked to a process line, documented in a datasheet, referenced in a maintenance procedure. It also exists in an ERP system as a line item in the materials master: a record with a description, a classification, a stock quantity, and a reorder level.
Those two records were almost certainly created by different teams, in different systems, at different times. In most organisations I talk to, nobody has ever formally linked them.
| Parameter | Engineering record (P&ID / DMS) | Inventory record (ERP / materials master) |
|---|---|---|
| Created by | Project team / EPC contractor | Procurement / operations team |
| When created | Design & build phase | Commissioning, migration, or later |
| System | Document Management System | ERP (SAP, Oracle, etc.) |
| Language | Tags, P&IDs, revisions, datasheets, asset hierarchy | SKUs, min/max levels, reorder points |
| Owner | Engineering manager / document controller | Procurement / maintenance planner |
What happens when the data layer is broken
When engineering documentation is fragmented and unstructured, the consequences are real: validation delays, rework, commissioning backlogs, compliance exposure. A single unresolved discrepancy between contractor-submitted and model-generated documentation can hold up handover for weeks.
But the same broken data layer has a second set of consequences that tend to stay invisible longer, until they don't.
When materials data is poorly structured, descriptions are inconsistent, duplicates accumulate. The same bearing appears in the system under three different names because three different people entered it at three different times. One record gets ordered when the plant needs it. Two others sit on shelves in warehouses that didn't know the part already existed somewhere else in the network.
When inventory records are not linked to engineering documentation, spare parts can't be traced to the assets they support. Min/max provisioning decisions are made on historical order patterns rather than actual criticality. A part genuinely critical for a safety system gets treated the same as a generic consumable, because nobody connected it to the engineering register where its criticality was defined.
When engineering data changes, and it always changes, those changes don't propagate to the inventory layer. A component gets redesigned, the tag gets updated on the P&ID, and the materials master record for the old part continues to exist unchanged, because nobody was watching both systems at once.
Evidence from the field: document side
Let me add some numbers that come from actual project work rather than industry surveys.
At the PETRONAS RAPID project, one of the largest integrated refinery and petrochemical complexes in Asia, commissioning isometrics had been submitted across more than ten EPC contractor packages in inconsistent formats. The gap between what was submitted and what was expected was large enough that manual checking within the commissioning timeline was assessed as not feasible.
The AI-driven consolidation processed 539,263 isometric sheets across 14 process assets and produced a complete, validated flange register. That register was a safety-critical dataset, required for plant operational readiness. The project was completed on time and in full, with a 70 percent reduction in schedule time and a 50 percent reduction in manhours compared to conventional processing methods.
The number that stays with me is not the volume. It's the phrase "not feasible within the commissioning timeline." That's the language organisations use when they've looked at the problem straight and accepted that the manual approach isn't an option. The data problem had grown past the point where human effort alone could solve it in time.
MRO inventory optimization in practice: real numbers from asset-intensive operations
The same logic applies to inventory, and the numbers are larger.
A petrochemical operator in Southeast Asia with 20 plants and 12 warehouses had 730,000 SKUs under managemen. The stock value was USD 315 million. The operator knew the number was wrong: too much of some items, not enough of others, a significant portion of the catalogue duplicated or miscategorised. The target was to reduce stock exposure by 10 percent, which on those numbers represents USD 31 million in working capital.
The blockers were not commercial. They were data quality. Before any optimisation decision could be made with confidence, the materials master had to be cleaned: duplicates eliminated, descriptions normalised, items linked back to the engineering records that defined what they were and where they belonged in the plant.
That last step, connecting inventory records to engineering documentation, is the one most AI-powered spare parts management programmes miss. Structuring the materials master in isolation helps. But the real reduction in risk, the ability to say with confidence that the critically rated item is stocked correctly and the obsolete item can be released, requires the two datasets to talk to each other.
In a separate engagement spanning operations in the UK and Australia, a cross-operator inventory sharing programme handled 690,000 SKUs and 2.3 million total items. The outcome included 19 weeks of engineering time saved. That figure deserves unpacking: nineteen weeks is not a productivity improvement. It is the time that was previously spent manually reconciling what different operators held, where it was, and whether it matched the engineering specifications of the assets it was supposed to support. Time that was consumed entirely by the data layer problem.
The hidden cost of separating engineering data from inventory management
There are obvious organisational reasons why engineering document management and inventory optimisation are handled as separate initiatives.
| Dimension | Engineering / document teams | Procurement / inventory teams |
|---|---|---|
| Function | Design, HSE, commissioning | Procurement, supply chain, maintenance |
| Problem trigger | Project execution, regulatory review | Outages, stock counts, shortages |
| Language | Tags, revisions, asset hierarchy, P&IDs | SKUs, lead times, reorder points, min/max |
| Data owner | Engineering manager / doc controller | Procurement / maintenance planner |
| Reporting line | Engineering or projects | Operations, supply chain, or finance |
But the cost of treating them separately is real, and it compounds over time. Every year the materials master is managed in isolation from the engineering register, the gap widens. New items are added to inventory without being linked to the drawings that define their context. Engineering changes happen without triggering materials updates. Duplicate records accumulate because there's no single source of truth to check against.
The underlying structure is the same
Across the conversations I described above, and across the project evidence I've been accumulating over several years of working in this space, one pattern repeats consistently.
The document problem and the inventory problem share a root cause: unstructured, fragmented, unlinked engineering data.
On the document side, that manifests as drawings that can't be validated against each other, tag registers that don't match contractor submissions, revision histories that nobody can reconstruct quickly enough for a regulatory review.
On the inventory side, it manifests as materials records that can't be traced to the assets they support, duplicate items that can't be safely consolidated, criticality classifications that don't reflect what the engineering documentation actually says.
The fix is not two separate projects. It's one shared data foundation.
What a Unified Approach Actually Looks Like
In practice, the work tends to follow a sequence.
Engineering documentation is ingested, classified, and processed first. Tags are extracted. Asset hierarchies are built. Relationships between documents are mapped. The output is a structured, searchable engineering dataset in which each element can be traced to its source.
Materials data is then structured against that engineering foundation. Duplicates are identified and resolved. Descriptions are normalised against engineering classification standards. Items are linked to the tags and equipment records in the engineering dataset. Where an item's criticality is defined in a maintenance procedure or a safety document, that definition is connected to the materials record.
Optimisation analysis runs against the combined dataset. Minimum and maximum stock levels are calculated with reference to actual asset criticality, lead times, and maintenance schedules. Parts which are no longer relevant to the current plant configuration can be identified confidently. Sharing opportunities across sites or across operators can be evaluated because the descriptions are now consistent enough to compare.
This is not a single product installation. It is a data programme, and it requires both technical capability and domain knowledge to execute well. But the starting point is always the same: you cannot optimise what you cannot describe, and you cannot describe it accurately without structured engineering data as the foundation.
Where the Conversation Is Heading
The three articles that preceded this one traced a line from document processing efficiency through execution risk to governance requirements in regulated environments. The common thread was always the same: the quality of engineering data determines the quality of every decision that depends on it.
Inventory is not an exception to that principle. It is one of the most expensive places where poor engineering data shows up in the financial statements.
The organisations I'm watching move fastest on this are the ones which have stopped treating documentation and inventory as parallel problems. They've recognised that the data layer underneath both of them is singular, and that cleaning it once, properly, with the right linkages in place, produces returns across both functions at the same time.
That recognition is still not widespread. Most organisations are managing two separate programmes with two separate teams, each solving half of a problem that has one root cause.
The question worth asking is not which of the two to address first. It is whether the data foundation you're building for one is already designed to support the other.
If it isn't, you're creating the conditions for the same reconciliation effort ten years from now.
Azati's DIGATEX platform is designed to work across both layers: engineering document intelligence and inventory optimisation, built on a shared data foundation. If either of these problems is on your agenda, we're interested in the conversation.
