Engineering information management is the foundation that determines whether your organisation owns the unexpected or gets owned by it.
By Tjidde Boers, Global Industry Principal, Assai
The challenge facing most industrial organisations is no longer whether engineering information exists. After decades of operation, most possess vast amounts of it. The challenge is confidence. When an incident occurs, an audit begins, a project hands over, or an AI system is introduced, organisations need to know whether the information they are relying on is complete, current, and trustworthy. Confidence in engineering information is increasingly an operational capability in its own right, and the organisations that have built it are the ones that stay in control when things go wrong.
When something goes wrong, your data is either ready or it isn’t
I met someone recently who described what happened when a transformer failed on an offshore production platform. No injuries, thankfully. But before anyone could begin diagnosing what happened, the safety authority arrived and needed the complete documentation package for that asset. Manuals. Certificates. P&IDs. Historical work orders. Operating parameters at the time of failure.
In the case he described, it took the team nearly three weeks to assemble that documentation. Not three weeks to fix the transformer. Three weeks just to find the paperwork.
In those three weeks, production was halted, the investigation could not begin, and exposure with the regulator grew by the day. The data existed. It was scattered across different systems, maintained by different people, under different naming conventions. Nobody could see the complete picture of a single asset.
I have heard variations of this story more times than I can count. An audit that becomes a scramble. A permit-to-work process that stalls because nobody can find the current drawing revision. A handover that takes months because documentation is incomplete. The organisations that handle these moments well are not the ones with the biggest budgets. They are the ones whose engineering information is connected, findable, and trusted.
The challenge is not only finding information. The biggest challenge is knowing whether the information you find can be trusted.
Why engineering data becomes fragmented and why it stays that way
Most organisations I speak with don’t have a shortage of data. They have an integration problem. Over decades of operation, information accumulates across systems that were never designed to talk to each other. Over time, the as-built view of the plant no longe reflects operational reality.
Consider a single cooler on a plant. Its functional location and maintenance history live in SAP. Its alarm and trip settings live in a spreadsheet. Its data sheet and manual are PDFs in a document management system. Its live readings come from a process historian. And the tag name is slightly different in each system: CL-203 in one place, 30.CL.203 in another, and NL34/67/30/30/CL-203 in a third. Same physical asset. Multiple systems. No single connected view.
Nobody designed it this way. It happened gradually. And the reason it stays this way is that fixing it feels impossibly large. The conventional answer is familiar: consolidate everything into a single master data platform. This requires a migration that takes years, costs millions, and frequently gets abandoned before it delivers value.
Meanwhile the business cost compounds quietly. Rework due to poor document control consumes 5 to 15 percent of CAPEX budgets. More than 65 percent of major industrial projects run late, with information gaps among the most persistent causes. Experienced engineers are retiring faster than organisations can replace them, and new operators cannot afford to spend two years becoming subject matter experts. Audit and regulatory burdens are increasing. And organisations embarking on AI initiatives are discovering that their data is not clean or controlled enough to trust.
Four pressures are converging: workforce change, compliance burden, project performance, and AI readiness. The organisations that address them share a common foundation.
What it looks like when engineering information works
One of the clearest examples I can point to is a nuclear power plant we work with. Every morning, their maintenance and operations teams gathered for work planning. A large P&ID on the table. Work orders on one screen. Live process data on another. Teams would manually plan work on the physical P&ID and cross-reference information from all three sources to identify conflicts before sending anyone into the field. The process typically took between one and two hours every day for a team of a hundred people.
After connecting their P&IDs, work order system, and real-time process data into a single view, where conflicts flagged were automatically, the morning planning was transformed. The organisation has reported significant reductions in time spent on work preparation and coordination, and the approach has been recognised by their safety authority as a significant contribution to the safe operation of the nuclear facility. What changed was not the engineers or the process. What changed was that approved, controlled information was in the right place at the right moment.
Critically, this was not a new platform that replaced existing systems. The P&IDs, work orders, and historian data all stayed where they were. What changed was that they became connected, and people could access that connected context directly inside the tools they already used, without switching systems or hunting across screens.
The organisations that handle unexpected events well are the ones whose engineering information is connected, findable, and trusted. Advanced technology alone is rarely the differentiator.
The data fabric approach: connect what you have, don’t replace it
The insight that changes the economics of this problem is straightforward: you don’t need to move your data. You need to connect it.
A data fabric approach leaves information in its master systems, such as SAP, the historian, the document management system, and file shares, then builds a knowledge graph on top of them. Think of it as a continuously updated map of how assets, tags, documents, systems, and operational data relate to one another. That map understands that CL-203, 30.CL.203, and NL34/67/30/30/CL-203 all refer to the same physical cooler, and surfaces everything associated with it, including specifications, work orders, drawings, manuals, and live readings, in one connected view, assembled automatically.
Because nothing is migrated, organisations can often begin using connected asset context within weeks rather than waiting years for a full migration programme. Because data stays in its source systems, lock-in risk is significantly reduced. If an organisation changes its DMS or CMMS, the knowledge graph adapts rather than requiring a new migration. And because the knowledge graph continuously cross-references what is in each system, data quality gaps become visible and actionable rather than hiding in silos where nobody can see them.
I often describe it this way: we are not a system of record. We provide a reality capture layer across your existing systems, continuously creating a knowledge graph that shows where information lives, how it connects, and where quality issues exist.
From connected assets to operational confidence
Connected information is the foundation, but it is only the first step. Once engineering information is structured around assets and their relationships, something important shifts: people can access the context they need without manually searching across systems. A maintenance engineer working in Maximo can see the relevant P&IDs, certificates, and work history for an asset without leaving their workflow. An operator in the field can check live process data against engineering specifications in a single view.
From that human-centric layer, AI agents can begin to assist by answering questions such as why a valve is sticking, what steps are needed to safely replace a pump, or what conflicts exist around planned maintenance activities. Because they are reasoning over connected, approved, controlled, and verified asset information rather than isolated documents, their answers are traceable and auditable.
And beyond day-to-day operations, connected information enables something that fragmented data cannot: genuine control over change. When a modification is made to a plant, every affected document, tag, and system record needs to be updated. With a knowledge graph, those dependencies are visible. Progress can be tracked. Completion can be verified before changes are closed out. That is what it means to own change, not just document it.
Why this matters more than ever right now
Every conversation I have these days turns to AI at some point. And the question I hear most is some variation of: we want to deploy AI across our operations, but we are not sure our data is good enough to trust it.
That concern is well founded. In industrial environments, AI that reasons over fragmented, inconsistent, uncontrolled engineering data does not just underperform. It creates liability. In environments where safe operations depend on accurate information, a confident wrong answer is worse than no answer at all.
The organisations making real progress on industrial AI are not chasing the most advanced models. They are building the foundation that makes any model trustworthy: connected, approved, controlled, and verified engineering information structured around assets and relationships. That foundation is what turns AI from a liability into an operational advantage.
Where to start
The good news, in my experience, is that you do not need to start over. The data you need already exists. The systems your teams rely on can stay in place. What changes is how they are connected, and what becomes possible when they are.
Engineering information management is not a glamorous discipline. It does not generate the headlines that AI and digital twins do. But it is the foundation on which operational readiness, regulatory confidence, and AI capability are all built. And when the unexpected happens, as it always does, it is the difference between weeks of paralysis and hours of clarity.
See how Assai Next in this series: How people access engineering context in the flow of work.connects your engineering informationBook a 20-minute discovery call at assai-software.com
About the author
Tjidde Boers is Global Industry Principal at Assai, working with asset-intensive industries across energy, chemicals, and nuclear to connect engineering information to operational reality.
He has spent more than 3 decades in the field with customers across Europe, the Middle East and Asia, and writes from direct experience of what works and what doesn’t. He can be reached at [email protected] or found on LinkedIn.