The Engineering Digital Data Thread challenge: No Product Data, no thread, no traceability
Most high-tech and semiconductor companies are running product development on a foundation that was never designed to hold it. The high tech products large engineering companies build today: lithography systems, microscopes, industrial robots, advanced packaging equipment, radar and defense systems, medical imaging equipment, high-precision systems, are among the most complex engineered objects ever existed. An unimaginable complexity, number of parts, and supply chains crossing multiple continents are part of these engineering marvels. But underneath these machines sit a digital data layer that was assembled incrementally. Bit by bit, system by system, over several decades. Never designed as a whole.
Let’s break down several of the most important engineering data layers
- Product data (PDM), ECAD and MCAD | Design intent, geometry, tolerances, revisions, release states. Details on what engineering created and why. This is where the product lives as an engineered object. Most organizations think this is well managed. It is better than the rest, but the reasoning behind the data, the tradeoffs, the rejected options, still lives outside the system. The deeper problem with product data is that products has become the default storage of engineering data. Not because it was designed for that role. Now it sits in the middle of a data architecture it was never designed to store, govern or scale.
- Commercial and manufacturing data and ERP | BOM sequencing, procurement, cost roll-ups, supplier contracts, specific variants. ERP is not strong in understanding and keeping design intent. It cares about delivery and cost. The moment engineering releases a change, ERP needs to interpret it, and that interpretation step is where errors enter and where one product starts multiple journeys.
- Process and operational data, MES (or mess) | Process parameters, machine settings, production sequences, yield data, operator instructions. This is where the product becomes physical. In well run organizations MES owns this. In most organizations a significant portion live in spreadsheets, local drives, or the heads of process engineers who built the line several years ago and have since then moved on. Field performance data sits even further in service systems that engineering never touches and rarely has access to.
- Configuration and variant data | Which exact configuration is running in which field unit. Hardware revision, software version, installed options, customer specific modifications. In low volume, high complexity equipment like semiconductor tools is a nightmare. No two machines (hardware/mechanical/electrical/software) are identical. Most organizations cannot tell you with confidence what is installed at a customer site versus what the engineering record says should be there.
- Requirements and verification data | What does the product need to do, how should it be configured what are the characteristics, how that was verified, and whether the verification is still valid after a change. This is the domain of requirements management tools and Model-Based Systems Engineering (MBSE). In most organizations it is the least mature of all the buckets. Requirements live in Word documents or disconnected tools. Verification records are in test management systems that have no live link back to the requirement or the design. When a change happens nobody can tell you with confidence what needs to be re-verified.
Default response | When engineering organizations feel the pain of fragmented tooling the next action is predictable. System integration hurts the most, CAD to PLM, PLM to ERP. Each integration feels like progress, but it is not architecture. Architecture starts with a clear information model: what data exists, who owns it, and how it transforms as it crosses domain boundaries.
The real problem is context | Nobody wrote down why. Back to the engineer drive, or their head. Trade-offs on size, tolerance, material choice, those decisions made sense to the engineer who made them. But they are not in any system. Organizations do not lose their data, but they do lose the context and reasoning behind it. The part number survives. The tradeoff that produced it does not. This matters more than it used to.
The integration and governance problem | Every technical integration (e.g., software link) moves data, but not the reasoning and context. There is also a discipline gap that tooling cannot close. Product data mgt governs the output, the CAD file, the drawing, etc. What it does not govern is the engineering reasoning that produced it: the assumptions, the rejected options, the “we decided this because”. That reasoning currently lives in email threads, meeting notes, and the heads of engineers who have since moved to other programs or are retired (or getting there)
to think about | When was the last time a change in engineering caused a surprise downstream, and how long did it take you to find out why?
Observations to improve from a siloed and legacy environments to a more connected engineering digital data thread:
- Assess before you redesign | Where does “it” actually break? Map the manual handoffs, the systems that have drifted apart, the data nobody owns. In most organizations that map does not exist. That is the first problem.
- Use toolchain transitions as transformation moments | Product data, migrations, ERP upgrades, MBSE rollouts. These are the natural re-entry points where information model decisions can be made by choice instead of inherited. Most organizations waste them by lifting and shifting the old model into the new tool. Every major toolchain change is an opportunity to close one gap.
- Fix BOM transformation before adding more systems | The eBook (Engineering BOM) to mBOM (Manufacturing BOM) gap is where most digital thread ambitions collapse. It has been papered over by people for years. Therefore, it is also a political problem before it is a technical one. Define the transformation process explicitly, assign a senior leader as owner, and govern it as a process and transformation program. You can think downstream, but that will be hard without this is stable.
- Introduce MBSE (Model-Based Systems Engineering) into a governed data environment | MBSE without connected data governance creates a bigger silo and does not increase data interconnects and quality. Before rolling out MBSE tooling, define how model artifacts connect to product data, requirements management, and verification.
- Assign data ownership across silos and put a leader behind it | Data that crosses domain boundaries have no owner. Every interface between product data and ERP, between engineering and manufacturing, between design and field, needs a named owner with the authority to enforce data quality gates and resolve conflicts. Without visible leadership sponsorship, domain boundaries become grey areas.
Until engineering organizations treat the data layer with the same discipline they apply to product architecture, defined ownership, quality gates, explicit domain boundaries, the thread stays broken.