Manufacturing BOM is the next cool thing in PLM

Manufacturing BOM is the next cool thing in PLM

plm-manufacturing-bom-boom

I’ve been doing data management system for the last 20 years. The one thing you learn very fast – 3D and visualization are cool. Data is boring. So, if you want to impress somebody (journalist, analyst, your boss… whoever else)  you need to create realistic representation of your future product. And show how to can turn it on the screen of your computer or better on mobile device (the reality of last 3 years). I agree, to see what you mean is cool, especially if you can make it before it will be manufactured. Awesome stuff. It can sell your product before it even exists. CAD/ PLM companies made lots of money selling visualization and rendering products. These days you almost cannot differentiate the video or photo of real car from realistic visualization.

Forget about it, for the moment… Design can be cool. However, important question these days is that – can you really make this product? If yes, than how? How fast? Or even more – can you make a profit after you design, visualize, manufacture and sell your product?

Engineering.com articleThe Next Big Boom in PLM and ERP and the Battle Over mBOM Ownership announced “war alarm” between PLM and ERP companies around manufacturing BOM (MBOM). Article speaks about how important MBOM and Master data management in solving problems such as cost, quality, tooling and many others.

I made me think again about how future of manufacturing will be dependent on solving of old PLM/ERP integration problem. In my view, complicated data synchronization is really bad thing. It leads to complex behavior, user experience and, after all, to product data errors. The question of product data errors is one the disturbs manufacturing companies. Emailing spreadsheet with bill of material won’t make your product development and manufacturing process more efficient. The following passage from engineering.com article is my favorite:

Ashley Morris, a researcher at Cardiff University in the UK, has identified seven root causes of product data errors. The three most important ones are 1/ Inaccurate data entry; 2/ Incorrect data flow between applications; 3/ Duplicate data between systems. Product development teams are all-too-familiar with how these errors occur given the various systems that manage the data. Generally cBOMs (configuration BOMs) and eBOMs (engineering BOMs) are created in the PLM systems, whereas mBOMs (manufacturing BOMs) and sBOMs (service BOMs) emanate from ERP or/and MES systems. But there’s no rule here.  Several variants and combinations are “on the map”.

MBOM is tough problem. I identified 4 main reasons why MBOM is hard for PLM. Read my previous article here. In a nutshell, here are four main reasons why MBOM solution is not simple for PLM vendors and service providers:

1- Most PLM systems starts from CAD and Engineering BOM.

2- Engineering and manufacturing people live in different worlds.

3- Synchronization of BOMs is messy by default.

4- For PLM to get data about manufacturing parts is painful.

Despite all these complexities and difficulties, PLM vendors is pushing towards better integration with manufacturing. I really liked the following quote explaining the objective of Bill of Material module by Siemens PLM:

“The objective of this BOM module (TC PMM) is to provide an integrated BOM foundation spanning Engineering, Manufacturing, Prototype and Service domains.” The tight integration to design and manufacturing processes can drive virtual validation of both these process types from a BOM point of view. “With our approach the BOM is documented once and various other BOM’s like mBOM, sBOM, pBOM etc are derived from this core eBOM, without re-documentation.”

So, what it all means for PLM? Bill of Materials (BOM) was always the apple of discord between PLM and ERP. Large companies these days cannot live with PLM and ERP systems. While engineering part of product information resides in PLM system, manufacturing part is managed by ERP. Product cost and quality can often fail between chairs and this situation disturbs manufacturing companies. This is the simplest possible configuration. Sometimes, design and engineering product even more distributed (look on Airbus’ case) – design (CATIA), product configuration (Windchill), manufacturing BOM (SAP). Which brings me back to my thoughts about why companies are not ready for single BOM? Main reasons – specialized tools used by different departments, no agreement between organizations how to manage data in a consistent way, absence of ‘universal’ tools.

What is my conclusion? MBOM is going to be in focus for many manufacturing these days. Efficiency and ability of manufacturing company to execute flawlessly becomes more and more important. Manufacturing environment is highly distributed these days with lots of constraints and dependencies. To design and bring product to market in a short time is a complex task you cannot solve without tools that will help you to synchronize and connect bill of materials. Just my thoughts…

Best, Oleg

Share

Share This Post

  • Colin Bull

    The ability to be able to visualise how you will manufacture / assemble your product is in the realm of PLM and the vendors know this hence the acquisition of Tecno by Siemens and the creation of Delmia by Dassault. I agree though the world of design and the world of manufacturing and service are completely different and they have different requirements of what should be in the BOM. Even manufacturing have differing requirements take a Part and Assembly manufacturer the Part could be a welded assembly of 3 parts, with stage drawings and definitions for the manufacturing processes and heat treatment etc, but to the assembly engineer it is one part. Or for assembly it is one part, but to the service engineer there are repairable components within.
    I do believe though the ability to visualise the manufacturing is cool and is a key differentiator of why the MBOM / SBOM should be defined in PLM before the product is finalised and then passed over to ERP / MES for the management and execution on the shop floor / field.

  • beyondplm

    Colin, thanks for your comments and insight! The complexity of visualization is the ability to bring all BOMs together. While BOMs managed in PLM can be handled together, BOMs managed by ERP, MES and other systems are representing the next level of complexity. At the end… we have too many systems. What is your take on this?

  • Colin Bull

    I agree, to many BOMs in too many applications is adding to inherent complexity. 
    In essence a bom be it EBOM MBOM SBOM should only be mastered in one application however reality is that it can’t.  PLM is the creator and master of the virtual product, which in  is the EBOM and the definition of the MBOM as manufacturing process planning is done in the virtual world however it is then refined in the physical world, however i would argue that it should be changed in the virtual world, as this is knowledge to be leveraged by the next virtual product. 
    ERP and MES are very much in the physical world, do they need a BOM? In reality ERP needs to be able to order Parts and Stock Sub Assemblies to be consumed at a later date in a product, then ship the completed product.  It also handles the routings in manufacturing does this really require BOM?  Same can be said for MES?  Service requires information of the parts fitted but by part number and serial lot number this clearly has to come from the shop floor / maintenance system therefore  cannot be defined in PLM. However, it should be fed back to PLM so they information from the current products for future innovation.

  • beyondplm

    Colin, yes, this is a very complicated and messy world. However, this is a real complexity manufacturing companies are facing these days. In the past, companies tried to put a boarder between virtual and physical worlds (engineering vs. manufacturing). It allowed to reduce the complexity. However, today it is almost impossible. Another dimension is related to multiple disciplines in BOM management – mechanical, electronic, software, etc.

  • Colin Bull

    Added to that are the system engineering, test and validation, mechatronics etc. It’s great working in PLM. However, the MBOM should be defined and mastered in PLM as the product development and manufacturing planning start there.

  • beyondplm

    Yep, these disciplines are coming too. Thanks for mentioning that…

  • hadfield4

    Oleg, one of my favorite rationales for why MBOM belongs in PLM is centered on the Change Control process. This is something that IMHO should reside in PLM. And given that the part data that originates in PLM should be integrated back to design intent, so should change impact, analysis and review. I believe that the part disposition information can be done inside PLM or as a separate workflow task in ERP with results reported back. But a dominating question is “if I change the MBOM, what do I screw up?” is a good reason to consider PLM being the master.

  • beyondplm

    The interplay between ERP and PLM a very complicated. I’ve seen variety of workflows – it depends on type of manufacturing (mass production, ETO, BTO). Controlling of MBOM in PLM can give lot of additional opportunities for cost control on early stage as well as mass customization. But it requires a better connection in PLM/ERP workflows. So, the answer on “what do I screw up?” will be more predictable :). Thanks for your comments! Best, Oelg