Plant Engineering Document and Asset Information Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does the legacy scan backlog swallow the project?

Scanning is the easiest part of this problem to describe and to fund, which is why it becomes the whole project. A steering committee understands a drawing count and a price per drawing. It does not, at first, understand that scanning produces files and the problem was never files.

The pattern is consistent. The archive is loaded first because it feels like the foundation. Indexing forty years of microfiche takes far longer than estimated, because quality varies by decade and nobody agreed what a drawing without a legible title block should be called. Twelve months in, the system holds correctly filed history that nobody has used to plan a job, so the next budget cycle asks what it was for.

This is specific to owner operators because the value in plant information is operational, not archival. An engineer needs everything known about transmitter PT-2041 this afternoon: the datasheet, the loop drawing, the piping and instrumentation diagram it appears on, the hazardous area certificate, the vendor manual and the spare part number. That question is answered by the tag to document relationship, not by the number of files in the store.

The fix is sequencing. Pick one operating unit, load its current documents and its tags, build the relationships, and prove the tie-in scenario end to end before touching the archive. Then run the legacy backlog as a parallel track with its own budget and its own schedule. The system earns its next phase from a working search, not from a completed scan.

What goes wrong with the tag register and the CMMS hierarchy?

The data problem that decides whether this system survives is not the drawings. It is the tag register, and specifically whether it agrees with your computerised maintenance management system.

Your functional location hierarchy in the maintenance system is where work happens: notifications, work orders, history and spares all hang off it. Your engineering tags come from project deliverables and vendor documentation. They were built by different people for different purposes and they do not match. There are tags with no functional location, functional locations with no tag, the same instrument under two identifiers, and decades of organic growth in a hierarchy nobody has pruned.

Teams discover the extent of this when they try to match the two lists, which is usually after the data model is fixed. At that point the project acquires a permanent reconciliation job that somebody will staff forever, and that cost quietly exceeds the software.

The fix is to decide which system is master before the model is drawn, and to run the match as a discovery exercise in the first four weeks rather than a data load later. Extract both lists, match them, and produce a written exception report with a named owner per class. Expect duplicates that only become visible when matched, and expect engineering and maintenance to disagree about which identifier is correct in a way that needs a decision from someone senior enough to end it. Avoiding that conversation is what creates the permanent reconciliation job.

Why do handover and maintenance system integrations break after launch?

Two connections matter here and both degrade in ways that are hard to see.

Project handover is the first. A contractor delivers tens of thousands of documents near practical completion, at the exact moment your engineering team is busiest. Your specification said document numbers shall follow the owner convention and required attributes shall be populated. Verifying that by hand across forty thousand files is not possible, so it gets accepted and the debt becomes yours. Even where a validation gate exists it decays: a new contractor arrives with a different numbering scheme, an exception is granted under schedule pressure, and it becomes the precedent for the next project.

Maintenance system synchronisation is the second. It works on the day it is tested and drifts afterwards. A plant reorganisation renames a functional location branch. A new area is commissioned and the tags are created in one system only. A bulk update from a maintenance improvement project changes descriptions across thousands of records, and your matching rules were keyed to descriptions.

What to require: handover validation as a mechanical gate tied to a commercial consequence, so failures return as a report the contractor clears before retention is released. Monthly reconciliation reports listing tags present in one system and absent from the other, sent to a named owner rather than a distribution list. Matching keyed to stable identifiers rather than descriptions. And every contractor exception recorded with a reason and an approver, because undocumented exceptions are how a good specification becomes decoration in three projects.

What happens when the redline and as-built loop is not covered?

This is the failure that turns an information system into a liability, because it produces documents that look current and are not.

Modifications happen. A change is approved, the work is executed, and someone marks up a drawing on site with a red pen because that has always worked. It goes back to the engineering office when somebody gets around to it. In practice the loop closes on the big jobs and quietly fails on the small ones, which is why drift always sits in the details: a small bore branch, a relocated instrument, a deleted drain.

A document control system that does not bind the as-built obligation to the change record makes this worse, not better, because a well presented current revision carries more authority than a dog eared print. An engineer plans an isolation off a drawing the system says is current, and the disagreement between the line list, the diagram and reality eventually finds a person with a spanner.

The fix is a hard dependency. A change cannot close while any affected document remains in a redline pending state, and the affected documents are known because the change references the tags. Capture field redlines as annotations on a tablet against the current revision, so nothing depends on paper surviving the trip back. The drafting queue still exists, because updating a diagram is real work by a real person. What changes is that the queue is visible and ageing, and the plant manager can see eleven changes closed on paper and open in the drawing set.

Should you build custom or configure what you already own?

A good number of facilities should configure rather than build, and the honest test is scale and the state of your project pipeline.

If you are one plant with an orderly file share, a stable process and no active project handing you new documents, ProArc or a well configured document management system on the stack you already own will serve, and your money is better spent on a scanning and indexing programme. ProArc is pragmatic at the document level and reasonable to run without a dedicated team.

If you are a large operator willing to fund an information management function and adopt a vendor class library, Hexagon SmartPlant Foundation and AVEVA Asset Information Management have real depth and rebuilding it would be irrational. Bentley eB is solid document control with mature transmittal handling. The limitation for all three is cost of ownership rather than capability: they assume an owner who will staff administration and reshape internal processes around the tool.

Build when two or more of these are true. You carry more than roughly twenty thousand tags and no register lists them. Your maintenance functional locations and engineering tags disagree and someone reconciles them by hand. You receive project handovers you cannot validate. Your redline loop closes on big jobs and fails on small ones. Or the incumbent products have been quoted and the licence plus the administration headcount exceeds what the information is worth at your size, which is a legitimate and common finding.

How do hidden costs get into the quote?

The items below are where plant information quotes lose contact with the work.

• Condition of the scan estate. A hundred thousand clean vector documents and a hundred thousand poor microfiche scans are different projects at similar volumes. Sample before pricing.
• Manual indexing assumptions. If a proposal says users will index legacy drawings themselves, price that labour. It is frequently larger than the software budget.
• Maintenance system reconciliation, which is discovery with two departments rather than a data mapping task.
• Conformance obligations. If a joint venture partner or regulator requires CFIHOS or ISO 15926 aligned deliverables, that is an organisational commitment with a cost, not a configuration setting.
• Three dimensional model integration, if you want to click a valve in a laser scan or design model and get its documents.
• Field access, which means devices and connectivity meeting hazardous area requirements, not a responsive layout.

In Digital Heroes delivery experience, a first release with a tag register aligned to your functional locations, a document register with real revision states, tag to document relationships and search that reads inside drawings runs $70,000 to $150,000 over 12 to 18 weeks. A full platform adding handover validation, the change driven redline loop, bulk legacy extraction with a review workflow, field access and maintenance system synchronisation runs $200,000 to $500,000 over 9 to 15 months.

What separates a build that works from one that fails here?

Four things, and the first is the data model.

Tag and document are two registers with a many to many relationship, plus revision, transmittal, change record and discipline as distinct objects. Ask any developer to draw it before you sign. A folder tree with metadata attached is a file manager, and you already own one. Revision must be a state on the object, not a substring in a filename, because a filename cannot answer which version is approved for construction.

Second, low confidence extraction goes to a review queue rather than being rejected or trusted. Optical recognition tuned to engineering drawings pulls tag numbers, drawing numbers and title block attributes out of raster scans, and it will not be perfect on poor microfiche. It does not need to be. A technician confirming a proposed value in seconds beats typing it from scratch, and the comparison is against a data capture contract priced per drawing, not against perfection.

Third, corrections and history are preserved. Superseded revisions stay accessible because you need them legally and practically, marked unambiguously and never offered as the default.

And fourth, the exit is agreed before kickoff. You should own the repository, the hosting accounts and an export in an open format including the tag to document relationships, which are the part that took the effort to build. Plant information outlives any development relationship, which makes portability a basic requirement rather than a negotiating position.