A– Hm… Sure, what revision do you plan to transfer?
Q– We just need to transfer the quantities to allow procurement to run the purchase
A– Is it related to the released product or to the product you develop?
Q– Just transfer the data, ERP people say they need updated information.
As much as such a dialog can be shocking, I can hear the same questions again and again. The reason for that is the very low data management culture in many companies. For many years, companies created a silo-based culture of “throwing things over the wall” and hope these things will work. In such a way, the typical thinking of engineers is how to send the data (CAD designs) to manufacturing (MRP/ERP) systems and forget about it. The manufacturing guys will figure this out. When it comes to problems, these companies struggle to figure out where to find a correct revision of part, Bill of Materials, Drawings, and how to trace changes that were made in a specific product that is currently needed to be maintained on the customer side.
Silo Thinking Is The Main Problem
The biggest problem of companies asking these questions is a very low level of understanding of how to manage the data in the companies. For these companies, the tools are the only things they can see. So, here is how it comes. Obviously, nobody is making drawings on paper these days, so engineers are using CAD systems to design and make drawings. The financial department needs their systems to manage to purchase and usually, the procurement and finance department is using ERP and/or finance systems. Production is where things are starting to break because you cannot do it without information coming from other places.
Holistic Data Management Culture
The outcome of silo thinking is that a company doesn’t have a person or organization, which is taking a holistic look at information flows between the department and how data should be managed to make this flow efficient to feed all other systems and departments with the information they need. The questions like how to manage Part Numbers, revisions, changes, how to differentiate between different product configurations, production orders, baselines. How to find documents belonging to a specific revision or customers and many others. Once a company decides that they need to think about data first, things can go better. Until that moment, a company lives in data chaos.
Can PLM a system to solve the problem?
PLM is a technology, product, and also business strategy. Very often people are confused about each of these elements and making wrong expectations. Many old and mature PLM systems are not more than CAD file data managers with no ability to manage data, with no flexible data models, and with no capabilities easy to integrate with other systems. These systems were developed 20+ years ago and they have been refurbished with a modern digital facade. Other PLM systems ignore the engineering aspect of product development, are not integrated with CAD systems, and require data to be entered manually or imported in a batch process. Out of the box was the mantra of many PLM companies for the last decade. So, this is why some systems can only manage specific data and tasks, and extending or adapting data models is beyond their capabilities. Companies need to come with the right data management culture, understand their data and then apply appropriate technologies and systems to manage the data.
What is my conclusion?
Many manufacturing companies live in a data mess and use “over the wall data strategy” to solve their data management problems. Here is the thing… If you have a data mess, don’t bring computers to this mess. You will end up with a computerized mess. First focus on how to understand the data you need to manage, how your company, product, and process data must be organized to serve your business, and then think about how to bring computers, technologies, and other systems including PLM. Product development and manufacturing is a complex discipline. Thinking you can organize it by sending data from CAD to ERP systems standing in isolation is a wrong approach that will cost you a lot of money and won’t solve the problem. Just my thoughts…