Product Data Backbone

The Product Data Backbone provides a foundation for the consolidation of product related data and documents from across all departments and systems. That is why the overarching PLM approach is to integrate all IT systems (ERP, CAD, and PDM/PLM) relevant to the product lifecycle and to create a single information platform. With it, companies have a foundation that enables them to seamlessly and digitally leverage their information in any subsequent processes. The PLM system aggregates and connects all product data and documents in digital form. All disciplines are looked at as a whole across the entire product lifecycle. Dependencies can be controlled when changes occur and everyone is aware of any direct or functional relationships, turning the Product Data Backbone into a central repository for all product related digital information. It enables product-centric companies to fully embrace Digitalization and establish seamless digital processes in their product engineering and product management.

5.1 Digital PlatformInformation Source for the Entire Product Lifecycle

Much like a human backbone, the Product Data Backbone constantly and seamlessly provides a company’s different departments and locations with information generated from across the product lifecycle through a digital platform. The important part here is to digitally establish relationships that connect the information relevant to product engineering and product management and to model their dependencies, as this is the only way to digitally initiate workflows. Two examples would be to inform designers of a failed test of an assembly they created or to have technical editors modify the documentation to reflect changes to a part.

The people involved in the workflow do not have to piece together their documents from various sources but are automatically provided with complete and valid information through the relationship information provided by the Product Data Backbone.



A PDM/PLM solution for Product Lifecycle Management provides the foundation from which to build such a Product Data Backbone. In it, CAD (e.g. AutoCAD, Autodesk Inventor, Creo, Solid Edge, NX or Solidworks) and product data management system (PDM system), combined with a technical document management system (DMStec), form a unified digital platform that is designed from the ground up to deliver cross company collaboration and used as a PDM/PLM system across the enterprise.

5.2 Product Engineering and Product ManagementThe step towards ‘Digital Product Engineering’

The lifecycle of a product starts with its creation – regardless of whether you are dealing with pumps, motors, components of a special-purpose machine, or a large technical facility in its entirety. Adapting and enhancing their existing and proven basic components to meet the specific requirements of their customers is the bread and butter of many product-centric companies. The key here is to leverage all those templates that were already created elsewhere. The improvement of product engineering processes, among other things, requires streamlined coordination between the different disciplines involved, that is, between the fields of mechanics, electrical engineering, electronics, and software development. This in turn means that product-centric companies need end-to-end visibility into the dependencies and relationships of the available information that are represented by the wealth of information surrounding their products and the adjacent administrative areas. This is a first step towards ‘Digital Product Engineering’


Produktentstehung_Produktmanagement-1

The many documents that are created alongside the workflows of product-centric companies are usually managed separately. The CAD data generated during product development is stored in PDM systems. The ERP/SCM solutions that support a company’s manufacturing and logistics processes have their own document management, as do CRM applications that facilitate communication with the customer. On top of that, conventional DMS solutions are often used to control parts of the document flow. The lack of a single integrated system is a sure fire recipe for conflicts and disruptions.  The most sensible way to address this is to create a common context for all product related information/documents. The best approach is to establish a single  Product Data Backbone.

Ongoing service delivery is increasingly becoming a part of the product itself. The more customized the product, the more important it is for the manufacturer to have instant access to the information and documents that relate to it. To describe this, the terms digital product management and digital information twin have been coined. PDM/PLM and DMStec solutions consolidate this information, structure it, and represent it based on technical structures such as the structure of a plant and the assemblies and parts installed throughout it. If multiple instances of the same motor have been installed in one or multiple plants, the service specifications linked to that motor will also be linked to the motors installed throughout the plants.

5.3 Digital Information RelationshipsCommunication between mechanics, electronics, and software development is key

Employees working on the business side of the manufacturing industry are usually one step ahead, at least when it comes to the integrated experience delivered by the software solutions at their disposal. Their ERP system provides a single pane of glass that allows them to navigate information on all components, be they mechanical, electronic or software based. They can put these components into their context at any time.

This is exactly the kind of context that designers and developers lack, at least in cases where no PDM/PLM system is in place. The reason: The information is siloed and scattered across multiple systems. MCAD and ECAD designers and software developers maintain most of their information themselves. Communication barriers between mechanics, electronics, and software development prevent the creation of digital products. Digital information relationships are the remedy.

If, for example, an electronics designer decides to make a PCB five centimeters wider, the mechanical designer should be automatically notified of the need to adapt the housing accordingly. Design departments design complex products but are hardly ever kept in the loop on what the customer actually thinks of the product and whether it works as intended. There is hardly any feedback, and when there is, it never makes it to the design or product management departments. Incidents are usually resolved by the service teams on a case-by-case and as-needed basis.


5-3-Digital-Information-Relationships

Lack of context prevents this information from flowing back

However, there is no such dialogue if everyone is limited to working in “their” respective system and making such changes there. No one reports back and there is no plan detailing how complaints can be matched to the parts that are affected by them and put into context (in order to ensure an accurate analysis of the complaint). Having this type of feedback is exactly what is needed to ensure that potential design flaws can be eliminated as quickly as possible. For example, when there is too little room between installed components that regularly causes the capacitor to overheat or a part that keeps breaking down and should be redesigned from the ground up.

Duplicate developments are another unwanted consequence of this failure of communication. They are often due to poorly defined responsibilities, typically in the case of parts whose function is not confined to any one discipline. This results in problems in production planning and eventually they have to decide which part to use. Subsequent enquiries and lack of coordination delay the manufacturing process and if the error goes unnoticed, the worst outcome is that a part is manufactured twice or to the wrong specifications.

In addition to the versioning of the parts found in a piece of machinery, it is becoming increasingly important to connect them to the different versions of the machine software. This, however, is seldom the case at present- which is due to the fact that until recently, software accounted for a relatively small share of design work. In the wake of Digitalization in product-centric companies, this share is already growing quickly; a product’s value proposition is increasingly shifting towards the software that powers it. A machine that is delivered today is run on completely different software than the model that was built ten years ago and you will be hard pressed to find any similarities. Consequently, it is crucial for the manufacturer to know which machine was delivered when and with which software – otherwise maintenance will be challenging.

Manufacturing companies should be aware which components in their products are more prone to defects than others. They should be able to assess how components can be easily repaired and replaced and what their development and product management teams can do to proactively prevent defects. Companies that communicate this type of information to the relevant departments are able to prepare accurate service plans, which in itself gives them a competitive edge. The objective should be to adopt a strategic maintenance management process that allows them to replace the part in question ahead of time and to do so for every machine in service before it is too late. This enables manufacturers to meet their service level agreements and minimize warranty claims.

5.4 Digital ThreadThe digital thread connects ongoing operations with development

Companies can avoid complaints and raise the quality of their products by establishing a relationship between the parts they design and the complaints they receive. A digital thread connects information from ongoing operations with development, allowing companies to easily analyze their items/parts. A Product Data Backbone is an absolute must to put complaints into context with the corresponding parts. So this goes beyond merely establishing customer context (which is done in the CRM system), as this will only benefit the support teams. Designers, too, need to be immediately made aware of any parts that keep generating customer complaints so they can incorporate this knowledge into their development and production documents right away. If they are kept out of the loop, they will use the same part over and over again for lack of better information and on the service side this means that the same repairs keep coming up.

The PDM/PLM software should also reflect the relationship between the parts that a company designs itself and the purchased parts maintained in the ERP system, in case that purchased parts are prone to breaking down and need to be replaced frequently. Naturally, these do not come up in the design process, but designers should be aware of any quality issues nonetheless. This will allow them to design a replacement part themselves or suggest that a different part be procured. Consequently, the PDM/PLM system needs a bi-directional interface with the ERP system to ensure that information can flow both ways and that it is put into the desired context.



Companies that want to be able to analyze the services provided for each item should also consider establishing a controlled change and improvement process. By doing so and by putting design parts, purchased parts, and complaints into a common context, they can build a digital thread across the enterprise. This digital thread connects information from ongoing operations with development and strict observance of this digital path will quickly lead to significant reductions in the frequency of service calls. Ad-hoc services are replaced with preventive measures that can be planned ahead of time (maintenance). Companies can elevate service levels, maintain them more easily, and increase the quality of their products by reducing the number of defective parts.

The use of a Product Data Backbone gives mechanics, electronics, and software development a common language. Companies that connect product relevant data and documents create digital information relationships, putting every single component – whether mechanical, electronic, or software-based – into context. This eliminates any guesswork as to when which version of which part was installed and reused in which project. Companies that have this clarity of information and clearly defined responsibilities between their different disciplines minimize the risk of duplicate effort in the design and manufacturing of their parts.

By including commercial data from the ERP system in the Product Data Backbone, information on preferred parts (in stock, cheaper, faster lead times) is already available during the design stage. Information is exchanged bi-directionally between the PDM/PLM and ERP systems, establishing a connection both between the individual components and with the projects they were used in.

Unambiguous information throughout the development process is the key to enabling successful collaboration across all disciplines. Likewise, unambiguous labels ensure that everyone know what they need to do. They show which parts are already present in the mechatronic structure, who created them, and what effects changes would have. Teams spend less time coordinating their work, achieve effortless collaboration, and can move faster from design to manufacturing to delivery, while eliminating any errors in the process.



Given the relentless pace of Digitalization in midsized enterprises and product-centric companies in particular, the need to establish a digital thread will only become more pressing. This makes it all the more important to leverage a PDM/PLM system as a Product Data Backbone that overcomes the communication barriers between mechanics, electronics, and software development and paves the way for the creation of digital products.