Who needs single source of truth for BoM?

One of my best blogging buddies in product lifecycle management and President of Lifecycle Insight Chad Jackson open 2016 with a very provocative statement – A Single Source of the Truth for the BOM Still Doesn’t Exist. The article speaks about complexity of BoM management between different engineering disciplines – mechanical, electronic, software. Chad brings awareness to the need of having integrated product development tools. The topic also known as system system development. Here is my favorite passage in the article:

When planning and modifying designs, mechanical engineers, electrical engineers and embedded software developers must work together and collaboratively to come up with holistic design solutions. That means that satisfying a system level requirement will often be broken down and assigned to hardware and software components. It means that if a new material in that mechanical component can’t satisfy that requirement, there might need to be a change to the requirement on the software component, which might flow down to an API or function library. These types of trade-offs and coordination plays out in hundreds of different scenarios, like change orders, modified requirements, failed prototypes and so many more, in engineering organizations on a daily basis.

The most interesting part of this passage is related to collaborative work between engineers working on different aspects of product development. Collaboration is such a vague word. PLM vendors were preaching to the need of collaboration between engineers for many years. However, as Chad noticed, the integrated development across engineering disciplines matters more today than ever.

The roots of integration development are going to multidisciplinary data, which is one dimension of BoM management complexity. Few months, I shared some of my thoughts about why PLM is failing to manage multi-disciplinary BoM?

In my view,technical difficulties and disagreement between people often can lead to problems in establishment of cohesive BoM management solutions. PLM fails to provide a way to manage multi-disciplinary BoM and changes. Manufacturing companies are using high diversity of design tools these days – mechanical, electronic, software. While specific data management tools are well equipment to manage a particular discipline of data, there is certain lack of versatile tool that can be adapted to all requirements and integrated with design tools. It leads to limitation of BoM management tools and complexity of integration and UX.

However, the key question, in my view, is who needs the tool capable to manage multiple disciplines of design information? The best tool will be dead without people that want to use it. The collaboration is fancy word, but very often engineers are working in silos (mechanical, electronics, software) with not much interesting to interconnect. Chad Jackson article gives us a hint – requirements. Requirements (or maybe system definitions) can intertwine data and bring engineers to collaborate together.

What is my conclusion? The complexity of products and development processes is creating a demand for tools capable to handle multi-disciplinary product data and supporting better collaboration and data tracking between engineers. The challenge is that CAD and PLM vendors are already providing tools to manage design data, BoM and requirements. Is there a place for another layer of tools for System Development? Maybe… What is clear to me that to manage product information across multiple disciplines, product lifecycle and product development processes is challenge manufacturing companies are facing every day. PLM vendors need to think how to solve it more efficiently. Just my thoughts…

Best, Oleg

Disclaimer: I’m co-founder and CEO of OpenBOM developing a digital network-based platform that manages product data and connects manufacturers and their supply chain networks. My opinion can be unintentionally biased.