PLM and Zero BOM errors: the devil is in details

PLM and Zero BOM errors: the devil is in details

zero-bom-errors

To manage Bill of Materials (BOM) is not a simple job. Often you can hear a simple definition of bill of material as a “list of component needed to build a product”. However, in reality, BOM is much more complex and contains information about product structure, the ways product is manufactured, maintained and even disposed. The variety of requirements coming from multiple departments make BOM a complex information entity. Because of diversity of disciplines, organizations and tools BOM traditionally managed as a separate structures related to design, engineering, manufacturing, support, supply chain, etc. Mistakes in Bill of Material management are costly and painful to companies. It can lead to wrong material orders, shipment delays, regulation issues and many other problems.

My attention was caught by few examples of PLM vendors emphasizing their ability to support “zero BOM errors” in their BOM management solutions.

First example came from Dassault Systems ENOVIA. Navigate to my post  – PLM, demolished silos and closed BOM loop. You can get more information also in recent Razorleaf blog covering ENOVIA conference here. According to ENOVIA, errors are coming from synchronization or design and engineering BOM. Therefore “zero file solution” strategy developed by Dasasult System ENOVIA will lead to zero BOM problems. Here is a passage from both articles:

The zero error BOM (Bill of Materials) demands a zero file solution. 3DEXPERIENCE brings the zero file world into the engineering environment; what we do is to connect directly to product data, not to files”. 

Dassault spent significant time at the event returning to the theme of the business benefits of ENOVIA, describing a “Power of Zero” mantra across ENOVIA’s capabilities (for example, “Target Zero BOM Errors”). ENOVIA CEO Andy Kalambi offered a nice overview of how these “Power of Zero” themes connect the direction of the ENOVIA product line with the business needs of ENOVIA’s customers.

Second example came from Arena Solutions case study – How Nutanix Reduced BOM Errors to Absolute Zero. You can download case study for free by registering on the website. Interesting enough, the problem of “Zero BOM errors” is completely different here. It speaks to collaboration and access of BOM by multiple people in a team or even different organizations suppliers. Here is an interesting quote from case study that outlines that:

“Our suppliers now access the same BOM and revision, and we have had zero wrong BOMs built since the system was implemented. Configuration integrity is assured… Change management was a nightmare,” said Sangster. “With several people making changes and suggestions to uncontrolled documents there were multiple revisions of the same BOM flying around the ether. No one had any trust in the data, so many local copies abounded based on the ‘mine is right’ premise.”

The devil is in details. When you plan how to implement BOM management, you need to work on multiple use cases. Bill of Material has multiple point of failures. I mentioned two in my post today – 1/ synchronization between design and engineering/PLM tools; 2/ collaboration and  change management scenarios. I can see many other use cases. When you plan a solution, it is important to focus on a specific problem you want to handle. At the same time, when vendor speaks to you about “Zero BOM error”, don’t hesitate to ask questions. Same buzzwords mean different things sometimes.

What is my conclusion? BOM management is a complex domain. It is hard to underestimate the value of having correct BOM without error. BOM errors are costly and to manage consistency of BOM is one of the most important objectives of PLM solutions. At the same time, BOM has multiple points of failure. This is a note to PLM implementers and IT people to focus on important scenarios and not to take “Zero BOM mantra” as silver bullet that solves all problems. Just my thoughts…

Best, Oleg

Share

Share This Post

  • Nikolai Nyrkov

    Thank you Oleg. I agree that understanding of really many use cases is needed. And that’s not only about software, but more about business processes. Eg. couple of times I faced “temporary” part numbers, which were assigned by designers on the early design stages. Next designers had to change temp nums to the “real” nums, but of course sometimes temp nums were used (among real nums) on almost all the stages, incl. mfg tooling. You can imagine the troubles in the BOM mgmt. BTW let me add my humble conclusion – Guys, please don’t use temporary part numbers!

  • beyondplm

    Nikolai, thanks for sharing your thoughts and practice! However, I’m in slight disagreement with your conclusion. An appropriate usage of lifecycle state and status on Parts can prevent others from using part, which is not ready to use. Example, part that still in the development or using “not approved” vendor, etc. What do you think?

  • Nikolai Nyrkov

    I fully agree that correct using of “statuses” is a right way. But reality is reality, and in my case mfg engineers started to work on parts with temp numbers just for the faster mfg preparation. They created many their own DB records as well as docs using temp nums. And next they received a new version of the same BOM with the same parts but with new nums. Oops. Sure even in this case the issues of comparison and correction can be solved technically, but the price and risks are high.

  • beyondplm

    Nikolai, isn’t a PLM function to manage processes in order to prevent people from doing of what you explained above? For example, BOM module can “prevent” users from adding parts with “wrong status”…

  • Nikolai Nyrkov

    Agree

  • Regarding process adoption and compliance, there’s an old adage, “You can lead a horse to water but you can’t make ’em drink!” My conclusion? The problem isn’t the temporary part numbers-it is the perceived or real short leadtime available to MEng. Solve that problem and you create buffer for the process to roll out and complete correctly…

  • beyondplm

    Chris, great advise! actually confirms that in many cases people are the root of a problem