The drawing knows something the warehouse doesn't.
The warehouse holds something the drawing has never referenced.
This is not a technology problem. It is a conversation that never happened.
This is the fifth and final article in a series on engineering data in asset-intensive industries.
I am not an engineer. I am not building the technology. But I have spent enough time in conversations with operators across oil and gas, petrochemicals, and infrastructure to recognise a pattern that keeps repeating, and that almost nobody seems to be connecting end to end.
The previous four articles covered:
- P&ID validation and intelligent document processing
- Revision control and execution risk
- Why document AI alone is insufficient for regulated workflows
- How data quality problems upstream become inventory capital problems downstream
Each time, the conversation came back to the same structural gap: the people responsible for engineering documentation and the people responsible for inventory rarely share data, systems, or even the same floor.
This final article is about what happens when they do.
One Story That Makes the Case
A UK-based oil and gas operator needed a critical spare part for a planned gas turbine turnaround. It wasn't on their shelves. The standard outcome in that situation is a delay: unplanned shutdown, production loss, and costs of millions per day while the part is sourced and shipped.
Instead, they found it at another operator's facility in Darwin, Australia.
Most organisations cannot satisfy the first condition reliably on their own assets. The second condition is almost never in place at all. What made the Darwin outcome possible wasn't luck. It was data structure. The part was findable because it had been described correctly, classified consistently, and made visible across a shared platform.
That is an engineering data problem before it is a logistics problem.
Why the Two Layers Never Meet
Engineering documentation and inventory management are built, maintained, and owned by different teams. In most large operators, they run in different systems, P&IDs and technical drawings in one environment, materials master data and ERP in another. Updated on different cycles, by people who don't share vocabulary, let alone data standards.
The drawing is updated when engineering changes something. The warehouse record is updated when procurement moves stock. The tag on the drawing and the line item in the ERP may refer to the same physical asset, but nobody is responsible for keeping them in sync.
When the engineering layer and the inventory layer are built on the same tags, the same classification schema, and the same attribute structure, something changes. Inventory optimisation logic, min/max levels, criticality rankings, demand forecasting, can finally run against assets that are actually described. Not guessed at. Not approximated from stale ERP records that haven't been reconciled with the current engineering state.
What the Numbers Say About the Cost of Keeping Them Separate
Two cases illustrate the scale of what is at stake when these layers remain disconnected.
| Case | Scale | Target | Blocker |
|---|---|---|---|
| Petrochemical operator, Southeast Asia | 730,000 SKUs across 20 plants and 12 warehouses; USD 315M of stock | 10% stock reduction (USD 31M target) | Materials master not structured against a consistent class library; attributes missing, duplicated, or inconsistently described across sites |
| O&G operator network, UK and Australia | 2.3 million total items across facilities | Inventory optimisation | 19 weeks of engineering time spent on reconciliation, before optimisation could begin |
In both cases, the sequence was identical: data quality problem first, optimisation problem second. Organisations that had tried to reverse that sequence, applying optimisation logic before data was clean and connected, generated recommendations they couldn't trust and couldn't act on.
According to Gartner research, poor data quality costs organisations an average of $12.9 million per year, a figure that scales dramatically in capital-intensive industries where inventory decisions carry direct operational consequences.
What Connecting the Layers Actually Looks Like
The technical path is more tractable than most operators expect. The data that comes out of P&ID processing: equipment tags, functional attributes, line classifications, equipment hierarchies, is precisely the data that should be structuring inventory decisions downstream.
A pump tag extracted from a drawing carries attributes: type, specification, installed count, system membership. Those attributes, mapped to a shared class library, become the anchor for a materials master record in the inventory layer. When these two layers sit on the same platform, running against the same tag register and attribute schema, the downstream effects are concrete.
Connected engineering and inventory data enables:
- Criticality analysis at scale: derived from engineering data itself: what system does this asset support, what is the consequence of failure, what is the installed count. One O&G operator in Saudi Arabia processed 50,000 documents and 200,000 SKUs this way. Criticality review completed digitally, consistently, at a scale no manual process could match.
- Trustworthy optimisation models: min/max recommendations, reorder point calculations, and demand forecasts all tied to what the plant actually contains and how it is configured today, not to a materials master last reconciled three projects ago.
- Cross-facility spare parts sharing: when both operators' inventory is described in a common language, a spare part sitting unused in one facility becomes visible and usable by another. The Darwin story only works because of this.
Where Most Organisations Are Today, and What the First Step Looks Like
In the majority of asset-intensive operators encountered across these conversations, the engineering documentation function and the inventory/MRO function run as separate workstreams. Different teams, different budgets, different technology vendors, and no shared data standard connecting them.
The practical first step is not a platform decision. It is a data audit: understand what tag register you have, whether it is current, whether it is connected to your materials master, and what the attribute coverage looks like on both sides. That diagnostic surfaces the problem in terms that both functions can act on, and defines the scope of what a connected approach would actually require.
A data audit should answer four questions:
- What tag register do you have, and is it current?
- Is your tag register connected to your materials master?
- What is the attribute coverage on the engineering side?
- What is the attribute coverage on the inventory side, and where do the two diverge?
The technology to connect these layers exists. The organisational will to put the two teams in the same conversation is the harder part, and the more consequential one.
The Gap Still Hasn't Closed
The drawing knows something the warehouse doesn't. The warehouse holds something the drawing has never referenced. Five articles in, that gap still hasn't closed for most operators. But the path to closing it is clearer than it has ever been.
Is your engineering team and your inventory team working from the same data right now? If you're looking at that question and not sure of the answer, that's usually where the conversation starts.
About This Series
This article is the final part of a five-part series on engineering data in asset-intensive industries:
- Intelligent Document Processing for Utilities and Infrastructure Operators — February 2026
- When Engineering Data Becomes an Execution Risk — March 2026
- Why Document AI Isn't Enough for Regulated Engineering Workflows — May 2026
- MRO Inventory Optimization Starts with Engineering Data — May 2026
- The Drawing Knows. The Warehouse Holds. Nobody Connected Them. — June 2026
