OpenText Extended ECM for engineering: who owns the asset tag before AI reads it
OpenText's 9 October post on engineering content opens with a list every plant engineer will recognise: P&IDs, CAD drawings, data sheets, maintenance records, vendor documentation, inspection reports, operating procedures. Then it names the problem. Asset tags inside those files "may not match the organization's master asset database."
Picture a pump whose tag on the drawing is written one way and whose equipment number in SAP PM is written another: a missing hyphen, a suffix in a different place. A person usually works out that they're the same pump. An AI assistant asked for that pump's last inspection may not.
What the tooling does. The post describes Cad-Capture's Asset Data Intelligence working with OpenText Content Management (Extended ECM) for Engineering and Documentum Content Management for Engineering. AssetXtractor pulls asset tags out of native CAD files and PDFs and checks them against authoritative enterprise sources, flagging inconsistencies, missing records, duplicate assets and naming conflicts. CaptureFlow extracts title-block information and engineering metadata. Once tags are validated, "HotSpots" turn a drawing into a way into related records and maintenance history. When engineers find a discrepancy, content management processes "route, review, update, approve, and govern the necessary changes."
The software finds the mismatch. It doesn't pick the winner. If the drawing and the equipment record disagree, someone has to decide whether the drawing changes, the master record changes, or both stay as they are with a cross-reference. In most SAP plant landscapes that's two people: the document controller for the drawing, and the maintenance master data owner for the functional location or equipment record. That's our read, not OpenText's.
Before the first extraction run, settle three things:
Which source wins by default. Usually the SAP master record, because work orders and costs hang off it. Write down the exceptions.
Who clears the discrepancy queue, and how fast. Thousands of unreviewed flags look like progress. Nothing has been cleared.
When AI may read the content. Our view: not until a plant area's tag discrepancies are cleared or accepted. The post puts it plainly: "AI is only as trustworthy as the information behind it."
Cleanup ends in deletion. Read one alert first. A tag review nearly always turns up duplicate drawings, superseded revisions and folders that need reorganizing. People want the leftovers gone. If that content sits in Extended ECM, read KB0801652 on OpenText My Support before anyone runs a purge. OpenText describes a data-loss risk: inconsistent ancestor data in the database can flag documents for deletion, for example after concurrent folder moves, and purging can then lose data. The issue is fixed in 22.4, but systems upgraded from CE 20.4 through 22.3 may still be affected. The article tells customers to disable auto-purge and stop manual purging, and points to the Recycle Bin settings.
That fits the ownership point above. A cleanup run should have a named owner for the delete step too, usually the platform administrator, who confirms the system's upgrade history against KB0801652 before the first purge. Folder reorganization done by several people at once is exactly the pattern the article mentions, so schedule it rather than letting it happen in parallel.
None of this needs a big program. Start with one plant area, name its two owners, agree the default winner, check the purge settings, then run the extraction.
Setting those rules before the AI work starts is where we'd begin with you.
