The digital thread is often described as a continuous flow of product information across the entire lifecycle.
In practice, though, many OEM threads are only continuous until the product leaves production.
Engineering has the CAD model. Manufacturing has the build structure. Quality has the inspection records. Procurement has the supplier information. And the ERP contains commercial part numbers and stock data.
But then the product enters service and the thread begins to fray. The aftermarket team gets handed a spreadsheet, exported parts lists, static PDFs, a classroom training session, and knowledge passed between experienced employees.
The result is a technician looking at a machine in the field 6 months later with no simple way to establish its exact configuration. For example, a dealer may need to call the OEM before ordering a replacement part, or a technical author may have to recreate illustrations and procedures from engineering information that was never structured for reuse.
In almost every example, the data exists, but the useful relationships between it have been lost, which is one of the biggest missed opportunities in the OEM digital thread.
It is also a commercial one. Research from McKinsey suggests aftermarket and service margins can be up to four times those achieved on new equipment, yet the aftermarket remains substantially underdeveloped across many industrial businesses. McKinsey describes aftermarket and service as both 'highly valuable' and 'frequently untapped'.
To take advantage of that opportunity, OEMs need to stop treating aftermarket product knowledge as something to be reconstructed after launch. Instead, the digital thread has to be designed to reach the people identifying parts, maintaining products and carrying out repairs.
Product development is sometimes presented as a straight line:
The real process is more complicated.
A product begins with customer, commercial, technical, safety and regulatory requirements. These ultimately inform concepts, system architecture and detailed design.
Engineering teams create CAD models, drawings, specifications, software and an engineering Bill of Materials, or eBOM.
Designs are analysed, prototyped, tested and verified.
Components change. Assemblies are reorganised. Materials are substituted. Suppliers change. Problems discovered during testing are fed back into engineering.
Manufacturing engineering then has to determine how the product will actually be made. The engineering view of the product is transformed into a manufacturing structure, commonly represented through the mBOM. This may organise components differently, introduce production consumables, define assembly sequences and connect the product to tooling, workstations, quality checks and manufacturing instructions.
The product may then continue to change during industrialisation and production too:
Controlled engineering change processes are supposed to assess the impact, approve the change and propagate it into the relevant product records - this is where the digital thread earns its name.
It is not simply a collection of digital files. The Digital Thread is the traceable relationship between requirements, designs, parts, configurations, tests, manufacturing processes and subsequent changes.
NIST describes the manufacturing digital thread in terms of communicating structured product designs into manufacturing and quality activities, while also returning manufacturing and inspection information to engineering. Its work highlights the role of standards such as STEP in maintaining usable product definitions across different systems. NIST’s Digital Thread for Manufacturing programme also acknowledges that significant gaps remain between tools, standards and engineering silos.
The trouble is that many OEMs still stop this process too early.
They manage the information required to design and build the product, but do not prepare it for what happens during the following ten, twenty or thirty years - leading to a common 'Break and Fix' support model.
Watch DRVEN's CEO Sam Burgess talk about the difference between a 'Break & Fix' strategy and 'predictive maintenance.
The break usually appears at the handover between the teams that create the product and those expected to support it.
Engineering releases a product that can be manufactured, production builds it, sales delivers it - but then aftermarket teams begin asking a totally different set of questions:
The eBOM alone cannot answer all these questions as it only defines the product from an engineering perspective, but the mBOM describes how the product is actually manufactured. However, neither necessarily represents how a technician needs to inspect, understand, disassemble, service or repair it.
This distinction is recognised within established product lifecycle management thinking. PTC, for example, describes the eBOM, mBOM and sBOM (AKA service BOM) as different but connected views of the same product. It argues that changes must propagate between them if parts lists, maintenance instructions and other downstream information are to remain aligned with the product definition. PTC's explanation of connected BOM structures also highlights the importance of retaining the position and occurrence of individual parts within the 3D product structure.
Where those connections do not exist, aftermarket teams have to rebuild the product in their own systems creating product knowledge issues everywhere: a parts specialist exports a spreadsheet from the ERP, a technical author manages to hunt down a set of drawings, and they are provided with a simplified CAD model. Equally, service procedures are commonly written in Word and published as PDFs, product photographs are annotated with arrows, and an experienced engineer explains in a message which parts are interchangeable.
Now, the first version may be broadly correct, but maintaining it and all the revisions and changes over time becomes extremely difficult: a design change is approved, yet the parts catalogue remains untouched. A replacement component enters the ERP, but the relevant work instruction still shows the old one. A service bulletin covers the difference, although only some dealers receive it. The latest information exists somewhere, but there is no dependable route from the change to everyone affected by it.
The thread has not disappeared! It's just split into smaller strands owned by different departments, people and systems - creating headaches for OEM support and maintenance teams and leading to high non-active repair times and a lack of accessible and up-to-date product knowledge for product support to be effective.
Extending the digital thread does not mean exposing an engineering system directly to every technician or customer.
Engineering data is detailed because it serves engineering, but may contain internal structures, non-serviceable components, intellectual property and manufacturing information that would confuse an aftermarket user.
The aim is to create an appropriate aftermarket view of the product while retaining traceability to the source.
That view may bring together:
This is the product knowledge required to support an installed base, rather than simply manufacture a new unit.
A digital twin can make that knowledge easier to understand and use, but the term needs some care. A 3D model on its own is not a digital twin. The model becomes more useful when it is connected to the identity, configuration, condition and history of a real product.
The digital thread provides the connections, while the digital twin represents the product, product type or individual asset using information carried through those connections.
For aftermarket use, a digital twin could allow a technician to open the record for a specific machine, explore its assemblies in 3D, identify the fitted part, check whether it has been replaced previously and access the correct procedure for the current configuration.
That is much more useful than giving them another generic PDF.
The best time to prepare product knowledge for aftermarket use is while the product is still being designed.
Designing for supportability means treating inspection, maintenance, repair and lifecycle support as product requirements. The design team considers how the product will be supported alongside how it will perform, how much it will cost and how it will be manufactured.
This can influence the physical design:
NASA’s design-for-maintainability guidance describes maintainability as something that must be included early in the design process, covering considerations such as accessibility, modularity, standardisation, fault detection and the resources required to perform maintenance. NASA’s Design for Maintainability technical brief reinforces a simple point: supportability cannot be inspected into a finished design at the end.
However, supportability is not only about physical access.
The OEM also has to design the information needed to support the product. For every serviceable item, it should therefore be possible to understand what it is, where it is fitted, which configurations use it, how it can be inspected or replaced, and what else is needed to complete the task.
This means involving aftermarket, service, technical publications and spare parts teams during product development. They can help define which product relationships and attributes need to survive beyond engineering.
Without that input, an OEM can create a product that is technically maintainable but digitally difficult to support.
A modern electronic parts catalogue should be a usable expression of the digital thread.
Instead of manually redrawing a product after launch, the OEM can use structured product data and 3D geometry to create an interactive view of the relevant assemblies. Engineering changes can then be assessed for their effect on the catalogue rather than waiting for someone in aftermarket to discover the difference.
The underlying thread should help the catalogue answer three questions:
The catalogue needs product structure, visual context, applicability and commercial information. It must distinguish between parts that were used during manufacture and parts that can be ordered in the aftermarket. It must account for replacement kits, superseded numbers and products that have been modified since leaving the factory.
When those relationships are retained, a user can move from a physical component on a machine to the correct orderable item with far less interpretation.
The effect reaches beyond convenience. Easier part identification can reduce support calls, incorrect orders, returns and delays. It also makes the genuine OEM channel easier to use, which matters when customers and dealers can search elsewhere within seconds.
Watch this demo of DRVEN showing how to turn CAD and sales data into a 3D parts catalogue in minutes for a pump assembly.
The same product foundation can also improve the creation and maintenance of procedures.
An SOP and a work instruction serve related but different purposes.
An SOP generally defines the controlled process: what needs to happen, who is responsible, which standards apply and what evidence should be captured.
A work instruction operates closer to the task. It explains how to complete a particular inspection, assembly, maintenance or repair activity.
A generic procedure may tell a technician to remove a cover, but a contextual work instruction can show which cover is fitted, where its fixings are located, which sequence to follow, what warning applies and which replacement items will be needed.
If the instruction is connected to the same structured product data as the parts catalogue, the technician can move naturally between understanding the task and identifying its parts.
They might:
This is where the digital thread stops being an IT or engineering concept and becomes something useful in the flow of work.
A digital thread is really only valuable if it survives change. Imagine that a bracket is strengthened after early units experience cracking. The new bracket has a different part number and requires a revised fitting sequence.
That single engineering change may affect:
A weak internal OEM process would update the systems needed to build tomorrow’s products, but leaves the installed base to be dealt with manually.
A stronger process uses the relationships in the digital thread to identify every downstream artefact and audience affected by the change. However, this does not mean automatically publishing every engineering update to customers - reviews and checks are still required, but the main improvement is that the aftermarket impact becomes visible and manageable.
The OEM can ask:
That is how product knowledge stays accurate as the installed base grows.
A complete aftermarket digital thread cannot operate only from engineering to service. Remember that field activity creates product knowledge too!
Technicians discover recurring failure modes, dealers identify confusing part descriptions, warranty claims expose weak components, repair records reveal which tasks take longer than expected, parts orders show unexpected demand, and support calls expose procedures that users cannot understand.
This is happening right now across the majority of OEMs and yet the flow of that knowledge back to engineering is often as weak as the data landing with the aftermarket teams.
If that information remains in service systems, inboxes or individual memories, then engineering never receives a clear picture of how the product behaves in use.
Connecting it back into the thread creates a feedback loop:
The product used by the customer is rarely identical to the original engineering release forever because it will likely be repaired, upgraded, modified and updated many times. So the digital representation must be capable of following that history.
For many mid-sized OEMs, this does not require a huge digital transformation programme before any value can be realised.
A practical starting point is to choose a product family with meaningful aftermarket demand and trace the information needed to support it.
Identify where the CAD models, eBOM, mBOM, commercial parts data, technical documentation, service knowledge and asset records are held.
Pay particular attention to manual handovers and duplicate records.
Start with the decisions people need to make.
Can a dealer identify a part?
Can a technician confirm the applicable procedure?
Can support determine a machine’s configuration?
Can a change be traced to affected assets?
The use case should determine which connections need to be built first.
Decide which assemblies and components need to be represented for inspection, maintenance and repair.
Separate the engineering view from the user-facing view without losing the relationship between them.
Record model, option, serial-number and date applicability. Establish how replacements, supersessions and engineering changes will be reflected downstream.
Prepare engineering geometry so it can support visual parts identification and interactive procedures without exposing unnecessary detail or creating a completely separate model to maintain.
Connect serviceable components to the relevant inspections, SOPs and work instructions. Allow users to move from the part to the process, and from the process back to the parts required.
Define ownership for reviewing and releasing aftermarket information when product data changes. Automation can reduce the effort, but accuracy still needs governance.
Return service findings, asset changes, parts demand and procedure feedback to the teams responsible for improving the product and its support information.
OEMs already invest heavily in creating product knowledge.
Every requirement, CAD model, test result, Bill of Materials and engineering change contributes to an increasingly valuable understanding of the product. Yet too much of that value becomes difficult to reach once the machine enters service.
The aftermarket is then expected to support decades of inspections, parts orders, upgrades and repairs using flattened, duplicated and ageing versions of the original information.
However, by designing for supportability and extending the digital thread beyond production, OEMs can turn existing engineering knowledge into accurate parts catalogues, contextual SOPs, interactive work instructions and better product understanding.
The goal is not simply to connect more systems, but instead make sure the product knowledge created upstream remains understandable and actionable for the people responsible for keeping that product working.
Because the digital thread only delivers its full value when it reaches the end of the spanner!