Product Data Backbone

Content of Product Data Backbone

Many companies still lack the ability to seamlessly support the continued digital use of their information. Their Bills of Materials need to be copied by hand and entered manually into their ERP systems. This changes when a Product Data Backbone comes into play and consolidates data and documents from across all departments and systems (CAD, PDM/PLM, ERP) into a common data foundation. It 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 companies to fully embrace Digitalization, e.g. in plant engineering and mechanical engineering, and implement seamless digital processes for their production operations.

3.1 Unified Platform

PRO.FILE is a PDM/PLM software for “Collaborative Product Lifecycle Management” that allows for the creation of such a Product Data Backbone. In it, CAD (e.g. AutoCAD, Autodesk Inventor, Creo, Solid Edge, or Solidworks) and Product Data Management (PDM system) combine with a technical document management system (DMStec) to form a unified platform that is designed from the ground up to deliver cross-company Collaboration and integrate effortlessly with the ERP system as a PDM/PLM system.

Engineering companies are often unsure as to what their expectations for a PDM/PLM system will look like over time. But experience shows that they are likely to go up. This leaves companies with the following options: They can start out with a basic solution provided by their CAD vendor or with a simple CAD/ERP interface solution. This, however, means that they will quickly hit a brick wall once their functional requirements get more sophisticated.

Another option would be to go with a PLM suite, which, however, often means functional overkill. What’s more, their implementation takes a lot of time and effort and so does any subsequent effort to adapt them to the requirements at hand. Companies end up using only a fraction of the available features and foregoing necessary modifications because they would be too costly. The result: They spend 80% of their budget on implementing the software, leaving them with only 20% to ensure the intended outcome of the project when in fact it should be the other way around.

As a scalable PLM solution, PRO.FILE presents a way out of this dilemma. It ensures an easy way in and allows for a gradual progression towards a fully-fledged collaborative PLM solution. Users no longer have to make the hard choice between a large PLM suite and a simple interface solution, but can rather start from their current requirements and gradually move on to expand the PDM/PLM system.

Konfiguration statt Customizing mit ISI.CON

The idea here is to choose “configuration over customization”. Any required changes can be implemented by the project manager (or the customer) directly in the PDM/PLM system with no programming skills required. This way, users get to work right away with a PDM/PLM system that is tailored to SMB budgets and can later be scaled up to a more sophisticated implementation.

3.2 Digital Thread

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.

But 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, however, prevent the creation of digital products.

No context means no insights into dependencies. 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 its works as intended. There is hardly any feedback, and when there is, it never makes it to the design or product management departments. Rather, incidents are resolved by the service teams on a case-by-case and as-needed basis.

However, there is no such dialogue if everyone is limited to working in “their” respective system and making such changes there. They don’t report 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). But 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, during which it is eventually decided which part is to be used. Subsequent enquiries and 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, 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 hard to do. What’s more, it is not possible to update outdated software to the latest version.

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 must 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.

The 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 ongoing operations with development, allowing companies to easily analyze their items/parts. PDM/PLM software provides the appropriate means 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 collecting customer complaints so they can incorporate this knowledge into their work 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 purchased. Consequently, the PDM/PLM system needs a bidirectional 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. 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. Companies can elevate service levels, maintain them more easily, and increase the quality of their products by reducing the number of defective parts.

Product Data Backbone

The solution: the Product Data Backbone

A central Product Data Backbone that integrates and logically connects product data and product-relevant information from across all disciplines (MCAD, ECAD, software development) gives mechanics, electronics, and software development a common language.  This means companies need to integrate their CAD systems, such as AutoCAD, Autodesk Inventor, Creo, Solid Edge, or Solidworks, with their PDM/PLM system. The result is the creation of a digital thread. When everything is connected, it is easy to put every single component – whether mechanical, electronic, or software-based – into its context, eliminating 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.

Previously siloed data is connected. The next necessary step is the integration of the PDM/PLM system with the ERP system as this will also add any related business information to the Product Data Backbone (PDB). This means that information on preferred parts (in stock, cheaper, faster lead times) is already available during the design stage. Information is exchanged bidirectionally 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, 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.