4 Reasons Why It Is Hard to Deliver MBOM in PLM?

Manufacturing Bill of Materials or MBOM. Where it belongs and how to support it right? Does it part of your ERP system? PLM system? Is it a piece that normally fails between chairs of engineering and manufacturing? In PLM development, manufacturing BOM is usually a piece of functionality that raises lots of disputes and inconsistencies. PLM vendors usually put MBOM as part of the overall PLM solution. Few links can lead you to Windchill MPMLink product or TeamCenter BOM Management system.

The discussion around Manufacturing BOM is quite hot in blogosphere. I found few interesting articles and references on management of Bill of Materials vendors related as well as independent consulting vendors and bloggers. I found the following two publications outstanding in the whole list of BOM debates and posts. Jos Voskuil (aka Virtual Dutchman) posted analytical article asking a simple question "Where is MBOM?". This is a question customers are probably asking the most. Where do we need to plan our MBOM implementation? Is it part of PLM? Is it part of ERP? The following passage is a try to answer on the question. It sounds to me like no answer.

Ask yourself as a company ” where do I handle the MBOM ?” Some of you might say, we do not have an MBOM as our EBOM with some modifications is already good enough for manufacturing. Many companies might say, we manage the MBOM in the ERP system as this is (was) the only system we had where we could define such structures. These companies are candidate for improving their Concept to Manufacturing process, as for sure either users or working methods are compromised to work with the MBOM in the ERP system. Yes, as ERP systems are built to schedule and execute the production of well defined products in the most efficient way. ERP systems are needed for the execution, often the core activity for manufacturing systems. PLM systems are reason that ERP systems can execute, they bring the product definition and information to produce a product. And in case the company designs and manufactures excellent and innovative products the future is bright.

Another interesting publication on the same topic came last week from Arena blog. Navigate your browser to read – Manufacturing BOM: Critical for Successfully Building a Product. I like the way this article presented the importance of MBOM. Here is my favorite passage.

The manufacturing bill of materials drives manufacturing, operations, purchasing and logistics for a product. The information from the MBOM feeds the business systems used to order parts and build the product. These include enterprise resource planning (ERP), materials resource planning (MRP) and manufacturing execution system (MES) solutions.Inaccuracies in a manufacturing BOM lead to problems: If the wrong parts or wrong quantities of parts are ordered, a company will not be able to build enough product—or any product at all. This leaves the company with unusable components that need to be returned or extra parts that tie up money in inventory. For manufacturing and operations departments that are already running lean, cleaning up these mistakes is a hassle that wastes time and money. Depending on the size of the original mistake, the amount of money lost could be large enough to impact the company’s bottom line.

The assumption of Arena (at least how I understood it) is that MBOM managed by PLM system. The fact MBOM feeds business systems – ERP, MRP, MES and other system create significant dependencies on an accuracy of MBOM. I posted few times about MBOM. You can refresh your memory by navigating to PLM and ERP: Why it doesn’t fit? and the discussion about how to create a single BOM in the company – Seven rules towards single Bill of Materials.

All the above made me think about what are main reasons that prevent PLM vendors to deliver a successful MBOM in PLM and why manufacturing BOM is always an issue in most of PLM implementations.

Here are my 4 reasons:

1. Most of PLM implementations starts from CAD/EBOM. This is a typical PLM implementation route in many companies. CAD data management, Bill of Materials – document BOM, engineering BOM, change processes (ECR, ECO) and … MBOM.

2. Engineers are not taking care of MBOM. Manufacturing BOM is less related to engineering work. Usual "bad" engineering practice is to forget about manufacturing work and to come very late to implement the overall BOM management solution. The trend is to have an integrated solution, but changes happen very slow.

3. Structure synchronization is messy by definition. In order to keep multiple BOMs synchronized (inside one system or multiple systems), PLM vendors developed multiple synchronization tools. Industry didn’t invent any better option, but synchronization tools usually not good (by definition) and brings lots of complexity in the engineering to manufacturing process. MBOM is a key part of this process.

4. To get data about manufacturing parts is painful. However, any PLM implementation required to do so in order to deliver an efficient MBOM solution. Without that, PLM manufacturing implementation is very limited and can end up by serving as "yet another data silo".

What is my conclusion? Manufacturing BOM is very important to deliver a PLM value "beyond engineering". The complexity of data and systems make it complex to deliver. This is one of few solutions that has no shortcuts. You need to get data from ERP/MRP system and you need to blend it with your best engineering effort. I think, an efficient MBOM solution today is mostly service and consulting project combined with significant integration solution in place. A good place to innovate. Just my thoughts…

Best, Oleg

11 Responses to 4 Reasons Why It Is Hard to Deliver MBOM in PLM?

  1. Ketan says:

    Oleg, I partially agree to the view point here. Let me elaborate:

    Definition of MBOM from Wiki (http://en.wikipedia.org/wiki/Manufacturing_bill_of_materials) = MBOM is a type of bill of materials (BOM). Unlike Engineering bill of materials (EBOM), which is organized with regards to how the product is designed, the MBOM is focused on the parts that are needed to manufacture a product.

    It is important to understand the last part “focused on the parts that are needed to manufacture a product”

    I will take a very typical example of a Turbine – the 2 main parts are Generator and the Gearbox. So by definition of MBOM I just need a Generator and a Gearbox of any kind to fit together and it will work. If finally I do manufacture the turbine with a clock-wise generator and an anit clock-wise gearbox – think of what will happen on the first run.

    Why I bring in this point is to tell that yes Engineering controls what combination should go on the unit, Sourcing controls where it buys it from, and Manufacturing controls “How to put it together”. Where most of us fall short is to understand what we control is it “Parts and manufacturing process” or just “Manufacturing process”

    Going back to PLM systems – I believe that a PLM system plays a big role in MBOM and to tell Manufacturing what combination it should be using to manufacture a unit.

    Going to the next level – if we do not maintain the MBOM in PLM and do expect that our services will be able to know what exact parts went into a unit in the field based on the MBOM – which is a generic and parts are not traceable.

    My strong argument is to have the traceability between Generic Configuration, EBOM, MBOM and As Running BOM in a single system.

    The other big question is change – That is your point 3. We did build a custom solution that was developed as a Rapid change management process for the MBOMs. What it does is brings in the Manufacturing into PLM (Good or Bad) but the change to a BOM is driven from a part / configuration centric system and the chances of failure are less.

    My 2 cents.

  2. Jos Voskuil says:

    Oleg and Ketan thanks for making me even more focussed on my upcoming presentation at PLM Innovation 2012, where I will exactly address the issues you mention. The need for the MBOM in PLM (the ideal world) and the historical reasons not to do it :)

    For me it all comes down to how you interpret PLM either
    – consider it a platform that supports the development process towards manufacturing (and beyond) or
    – consider it as a platform that manages all product related information shared by all departments.

    The first approach is the classical one where you talk about transfering information from discipline to discipline which leads you in the discussion where to store the information.

    The second approach (my vision too) makes it clear the MBOM should be part of the PLM infrastructure

  3. Dick Bourke says:

    Enough talking about problems; let’s talk solutions. The four reasons should not be interpreted as an excuse for not pursuing a solution.

    Granted, “Structure synchronization” may be messy, however, what other choice is there when faced with legitimate differences between the EBOM and the MBOM, particularly in a multi-plant environment? Certainly, not allow ERP folks to create an MBOM without reconciliation of the structure changes.

    Moreover, the question about whether the process should be in PLM can be re-phrased for clarity. Who, organizationally speaking, should be responsible for developing the MBOM? Generally: manufacturing and process engineering with assistance of production planners familiar with the company’s ERP system. In other words, it doesn’t matter in which system the structure synchronization takes place, as long as adequate software is available to those responsible for creating and maintaining the MBOM.

    The MBOM process should be embedded in collaborative product development, i.e., no more “Throw the prints over the wall,” the approach in the old days.

  4. Dijon says:

    Depending on the company and industry there may be several other considerations beyond choosing PLM or ERP or MES or whatever as the master system for any given form of BOM.

    I don’t believe in the integrated/unified/universal BOM approach. That isn’t due to it not being technically feasible, since filters or views can theoretically be applied to the all inclusive depiction, but rather because nobody can agree to who owns it and has the right to update it over time. That concept may work if a company had an impartial and dedicated department/group that performs the creation and maintenance of item masters and BOMs behalf of other organizations.

    The dilemma of keeping BOMs appropriately synchronized between Engineering and Manufacturing is one example of many. Marketing, Sales, Finance, Purchasing, Aftermarket, etc. often have their own BOM requirements. Even within the confines of Engineering there are multiple BOM incarnations (CAD BOM, EBOM, etc.). Manufacturing is prone to the same practices (PBOM, RBOM, MBOM, ABOM, etc.).

  5. @Ketan, thanks for your insight. I think, your point about “traceability” is the most important one. BOM can be located in multiple systems- to be able to trace the data, interconnect requirements and to see the impact – it will prevent companies from connecting turbine with the wrong gearbox :). Best, Oleg

  6. @Dijon, thanks for comments! The alternative to integrated BOM is when all parties you mentioend (engineering, manufacturing, sales, finance, purchase, etc. will work on their own structured information sets. It happens now in many companies and creates lots of problems. Don’t you think so? Best, Oleg

  7. @Dick, thanks for the proposal! However, your proposal to use all systems together resulted, in fact, the engineers need to use up to 50-90 different screens (user interfaces) at the same time. The number is real and I heard it from one of automotive OEMs. The alternative is to have a single system of references preventing the need in data synchronizations. Just my opinion. Oleg

  8. @Jos, it was a pleasure meeting you during PLM Inno. Unfortunately, I missed your session. The idea to have a single system that keeps all data is utopia (like communism). Btw, it is a very nice and costly utopia :). In my view, the information needs to live where it created. Systems need to be to reference information from other locations. Just my opinion. Oleg

  9. Jos Voskuil says:

    Agree, I do not believe in a single system that keeps all data. I believe in a single point of access to the most relevant data. Another utopia perhaps :) However like all utopia’s (is there a plural) the 80 % rule is often a comfortable target before it gets expensive.

  10. Jos, single point of access is another utopia :). Data needs to be accessible. However, the way to access data can be different depends on the needs. Think about web and data together. This is a realistic model, in my view. Best, Oleg

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

Join 290 other followers

%d bloggers like this: