In my previous post “Search for the right BOM – I’m feeling lucky? “, I started to discover possible ways to handle Bill of Materials in the organization and extended enterprise. Thank you all for your comments. I think we had a good conversation, so  I’d like to continue now in slightly different direction. Before I speak  about the diversity of Bill of Materials I’d like to say that the core of this approach is to have multiple Bill of Materials for various aspects of product development (such as Design, Engineering. Manufacturing, Maintenance etc.). So, we have multiple Bill of Materials. These multiple Bill of Materials are managed normally by different systems. By using of this approach we have several possible combinations of BOM within an organization. 

But there is opposite approach: There are NO multiple Bill of Materials. Instead we have systems that define a single BOM for the organization where all relevant pieces of information are connected and synchronized. According to the type of information you are looking for, you can extract a subset of this information from the overall Bill of Materials system. This overall BOM structures managed and synchronized among all groups within an organization. Therefore, this approach can simplify the way different pieces of product-related information are managed in an organization.

 How can you organize this synchronized Bill of Material overall? There are many technological approaches that can be mentioned here – PLM with federated Bill of Material capabilities, data warehousing, business intelligence, PIM, and enterprise search. Even if these approaches are sensitive from the standpoint of synchronizing information between different enterprise systems, all of these technologies have the potential to be used for this purpose.

 I would be interested to know if you see the practice of a synchronized Bill of Materials applicable in your organization. 

I’d like to continue discussion I started in my earlier post – Seven Rules Towards Single Bill of Materials. So, what are possible collisions on the way to the single bill of materials?. So, let’s take design, engineering and manufacturing bills. When I look on opposite sides – design and manufacturing, the purpose, and as a result, how these bills look like. Design bill started from CAD and, obviously, take as a starting point, design structure. So, we can get very structured bill of material. As opposite, manufacturing bill of material foundation is manufacturing process. The levels of manufacturing bill are driven by manufacturing process definitions, stocking and other elements of manufacturing process. What is the role of engineering bill? Do we need it?

If I’m looking from the perspective of needs, it looks like engineering bill is not needed (wait for a moment, don’t kill me now :)). Design Bill provides information about how my product structured. Manufacturing Bill provides information how my product will be assembled (or build). However, I found distance between these structures / views is a huge, connection between them is not obvious. This is, in my view, place where product lifecycle technologies need to be focused – to step beyond pure design or manufacturing structures to engineering level and build lean engineering bill of material that will become master BOM in the organization.

What are the advantages of such approach? Master Engineering Bill will be able to connect design elements, especially those that related to custom manufacturing and will provide set of configurable modules. Master Engineering bill will support different techniques to create a condition-based structures and many others. From Manufacturing side, engineering bill will get required information about Item Masters.  Different elements – design and manufacturing, will be interconnected in this engineering bill, so no more missing parts or impossible product options.

What are the disadvantages of such approach? I see two major problems – need to build unified data structure and synchronization work between department and people. The multiple bill of material approach solves problems of people collaboration and communication. Each department has their own bill, they are working on. The problem is in the end – missing parts on the shop-floor, missed dates or high product cost. In order to support, single Engineering Master Bill of Material, we need to find right technologies that allow to people to work simultaneously on different pieces of this bill, synchronize, change, update. This collective bill of material should be supported by PLM technologies looking on how to collaborate between design and manufacturing.

Just my thoughts.
Best, Oleg

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

BOM Management. Multiple BOM Views. These topic are always drives lots of discussion in a real life and online. There is no question about importance of BOM in product development, engineering, manufacturing… Literally, you cannot do anything without Bill of Materials.

Few weeks ago, I came with the topic that generated a very good and healthy discussion – Will PLM Manage Enterprise BOM? A bigger part of the discussion happened in PLM LinkedIn group. You need to have LinkedIn user to access that. In a nutshell, the discussion was about an influence PLM and ERP both have on BOM management in the organization. The topic is not restricted to PLM and ERP. However, it is clear that PLM and ERP are playing major roles in how BOM managed in organization and how enterprise BOM management solution can be architected.

BOM Golden Rule

I’m sure you are familiar with Golden Rule. Satirical definition of this rule says “Whoever has the gold, makes the rules“. Here is manufacturing definition of the rule – “Whoever owns the BOM, makes the rules“. This is very true in many aspects and it explains a lot of what happens in every manufacturing organization in terms of how enterprise systems are positioned. They people work in the majority of organizations these days can be summarized as following – don’t touch my BOM. You can think about design / engineering, manufacturing, sales, supply, plant and many others. Every department or organization is creating their own BOM and then trying to synchronize it during product development process with other BOMs.

I’ve seen multiple attempts to create an alignment between various enterprise systems. Here is an example of product vs. transactional alignment between PLM and ERP provided by one of my blogging buddies – Edward Lopategui from E[E] blog. I took the following passage from LinkedIn discussion:

I think part of the problem is the divide between PLM and ERP, where PLM has always been product focused while ERP is transaction focused. While few dispute that PLM has the superior BOM capability, the ERP transactional dependencies perpetuate the legacy need to continually instance MBOM on the ERP side. And since PLM does not have an acceptable equivalent of those transactional capabilities, expect the divide to continue into the foreseeable future.

You can explain what are differences between BOM in PLM and ERP from product, system and technological standpoint. However, the political influence in organization can make this type of effort meaningless. One of my permanent discussion opponents, Dr. Michael Grieves (Consultant at NASA and author of Product Lifecycle Management: Driving the Next Generation of Lean Thinking book) provided the examples of factors here:

Where the MBOM resides is going to be dependent on both technical, political, and legacy factors. Technical factors include the complexity of the product, how often the MBOM changes and who drives those changes, whether an MES system exists,… Political factors include whether the strategic direction is toward ERP or PLM. Legacy factors include what systems are currently in place for MBOM control. Compounding these issues is that ERP companies are moving into PLM solution spaces and vice-versa.

EBOM vs. MBOM

From technical standpoint, it is relatively easy to explain the difference between EBOM and MBOM. The first (EBOM) represents they way product is designed (structure, models, functionality, configurations, etc.) The variety of characteristics are depending on the type of manufacturing and processes. Manufacturing BOM defines how product will be produced (including aspects of material ordering, routing, different manufacturing plants, etc.).

EBOM and MBOM are not entirely different but data structures and attributes used in both are often not overlapping. Some engineering attributes and structures are not relevant for MBOM (or cannot be stored using MRP/ERP systems). On the other sides, MBOM information is often irrelevant and not needed for engineers and designers.

The thing that makes everything complicated is a process between these two worlds. The “throw over the wall” manufacturing concept co-exists together with tightly collaborative process of work on EBOM and MBOM. Engineers are requested to provide information about product (EBOM) as early as possible in the development cycle. At the same time, manufacturing planning can get back to engineering in order to finalize and optimize product. Very often, both BOMs (but mainly MBOM) can be used for external planing systems.

What is my conclusion? BOM is one of the most important information pieces in product development. It comes on different stages of development – design, engineering, manufacturing, supply, etc. Because of different reasons – technical, political and organizational, the most widely adopted BOM implementation practice is to split BOM into separate pieces (views) reflecting application domains. At the same time, modern business and manufacturing practices require better integration of processes around BOM. PLM vs. ERP. Engineering BOM vs. Manufacturing BOM. The debates about how to organize them in a better way are heating up in every organization. Just my thoughts…

Best, Oleg

Manufacturing BOM (MBOM) is an interesting topic. After all design and engineering operation, MBOM defines how product is going to be actually manufactured. While most of PLM / ERP debates about MBOM are going around "who owns what", the most fascinating part that I found in MBOM is related to the nature of manufacturing planning. The root problem is related to the way we can optimize MBOM or actually optimize the production, which is usually done by material planners using so-called planning BOM. It made me think about some black magic that needs to happen between engineering and manufacturing. Let speak a bit more about it.

Navigate back to my BOM 101 articles from the last year – How to modularize the Bill of Materials and How Many Levels Do You Need in BOM? One of the fundamental problems BOM layering and structuring needs to optimize production schedule. It can be only done by the team of people – including engineers together, manufacturing process and material planning people. Interesting enough, often you need to have sales and business people in the room – only these people can give you some data to predict manufacturing capacity, scheduling and potential optimization.

It made me think about a potential for PLM to play a role of collaboration platform between all these people to come with the solution around product configurations, engineering options, manufacturing optimization and what is most important product cost. I can see this is one of the fundamental problems PLM can solve as a collaborative platform connecting engineers and manufacturing.

PLM can provide an information structure to keep variety of product families, engineering BOMs, planning variants, supplier information and manufacturing planning together in order to optimize product and manufacturing production schedule and cost. All together is a real benefit of PLM implementation that can pay off very fast.

What is my conclusion? Manufacturing is getting more and more complex these days. People wants to have more personalized and configurable products. At the same time, companies need to slash cost. What was possible to solve by throwing engineering BOM or even CAD drawings over the wall of manufacturing is nearly impossible in 21st century. Old way to go from engineering to production planning will make your manufacturing obsolete, product cost skyrocketing and your company out of business very quick. Modern collaborative tools including PLM holding multiple bill of materials are needed to solve it. Just my thoughts…

Best, Oleg

Manufacturing process optimization is one of the biggest challenges in product development these days. Companies are looking how to low the cost, optimize manufacturing process for speed and to deliver large variety of product configurations. The demand for these improvements is very high. The time when engineering were throwing design"over the wall of engineering" is over. Engineering and manufacturing people should work together to optimize the way product is designed and manufactured at the same time. Which, in my view, leads to one of the most critical element of this process – Manufacturing BOM (MBOM).

In one of my earlier posts, I addressed the challenges PLM systems has to manage BOM. PLM vendors are recognizing the importance of manufacturing solutions. However, it is hard to deliver MBOM in PLM. It related to CAD roots of PLM products, historical disconnect of engineers from manufacturing processes, complexity of synchronization between multiple BOMs and problems of integrating with ERP systems. Vendors are encouraging companies to use PLM technologies to manage MBOM and to push right product MBOM information to ERP for execution. The advantage of that is the ability of PLM to deliver accurate product information derived from design and engineering BOM.

However, there is another side in this story- manufacturing planning. Fundamentally, MBOM is created by manufacturing engineers and it reflects the way product is built. It usually structured to reflect manufacturing assembly operations, workstations, ordering process, etc. In other words, MBOM is a reflection of manufacturing process based on information from product design. Company can decide to improve manufacturing process for existing product. It means most probably no changes for CAD design and EBOM, but will require to create a new version of MBOM.

As a result of that, MBOM has dual dependence of both correct engineering information from PLM system and manufacturing constraints and part information management by ERP. Both are absolutely important. By placing MBOM in PLM system company can create a complexity of manufacturing process planning in ERP. At the same time, ERP system (more specifically manufacturing modules) are not providing dedicated BOM planning tools capable to handle information from EBOM and MBOM simultaneously.

What is my conclusion? Manufacturing BOM is stuck between a rock and a hard places. It must reflect manufacturing process and stay connected to both PLM and ERP environment. It creates a high level of complexity for existing technologies and tools. To create a cohesive environment to manage MBOM is tricky and usually requires significant services and customization. Just my thoughts…

Best, Oleg

The only thing that is constant is change. This is very much applies to everything we do around BOM. Engineering and manufacturing eco-system are full of jokes about engineering changes. You maybe heard about renaming "engineering change order" into "engineering mistake order" as well as the correlation between number of engineers and number of ECOs in a company. However, the reality – change orders are one of the central elements of engineering and manufacturing life. And it is primarily related to bill of materials. Once defined, we keep changing BOMs through the lifecycle of the product. ECOs are helping us to do so.

In my yesterday post (Manufacturing BOM dilemma), I discussed the complexity of manufacturing BOM. Fundamentally, MBOM is reflecting manufacturing process, which is by itself defined by both – product information coming from engineering department and by part and other related information coming from manufacturing systems (MRP / ERP). The collaboration between these two systems is never easy. This is one of the reasons why MBOM management process is struggle to find the right place in many companies.

One of the suggestions made in comments was to use PLM system as BOM manager and run ECO/ECR processes each time we need to make a change in bill of material. Such process will insure ERP will be always updated with the last information about BOM. My initial thinking – this is very straightforward way to manage it and I’ve seen it in many companies. On second thought, maybe there is a better way to manage that.

As I mentioned before, changes to the bill of material are a controversial topic. My hunch every company should have a policy how to manage BOM changes. From my experience I can classify three major type of changes to bill of materials: 1/mistakes; 2/materials and/or parts changes; 3/arbitrary changes (liabilities, etc.). In many situations, BOM changes can lead to significant cost related to material scrap, additional material planning, etc. On the other side, every change related to materials, process optimization and manufacturability should be synchronized back into PLM system. So, maybe, ECO/ECR is not a right way for engineering/manufacturing collaboration these days?

The life was good when engineers were able to through BOM over the wall of manufacturing department and finish their job. This is not a reality we live in today. Engineering and manufacturing should maintain a very close relationships by developing and optimizing manufacturing processes. Sometimes, the solution is purely manufacturing. However, very often, redesign or additional level of product engineering optimization required to reduce product cost or bring product to market faster. Maybe it is a time for both engineering and manufacturing department to develop new practices how to collaborate on BOM? Abandoning old fashion ECR/ECO processes for engineering/manufacturing collaboration can be a first step into this change.

What is my conclusion? Engineering and manufacturing process planning are tightly coupled these days. In many situations both product development and engineering planning must go in parallel to achieve desired level of optimization. It requires new type of processes and software enabling new level of BOM collaboration. Old fashion ECR/ECO method may not work. Just my thoughts…

Best, Oleg

Data ownership is an interesting topic. Our life is getting more digital every day and we are asking many interesting questions about who owns data about us. Who owns the data about our Facebook profiles, who owns social media data we created and many others. While still there are some gaps in understanding who owns the data about our digital life, when it comes to business use cases, the things are also very complex. Ownership of information is one of the most fundamental things in enterprise business. Engineering and Manufacturing companies are living it every day. If you deal with enterprise data, you are probably familiar with the term – master data. Usually it leads to many discussions in organization. Who owns the master data about design, bill of material, item, etc.

These are questions that need to be answer to allow to enterprise system to functioning properly. In one of my old posts I shared my view on Ugly truth about PLM-ERP monkey volleyball. Until now, the demarcation line of engineering vs. manufacturing was somewhat acceptable in most of the situations. I tried to capture this status in my Thoughts about BOM ownership article. However, things are going to change.

PLM and ERP are getting into new round of debates about ownership of data. It comes as a question raised in engineering.com blog – “PLM should take over ownership of the manufacturing BOM too”, says Siemens PLM’s CEO, Chuck Grindstaff. Navigate to this link to read the article. Management of EBOM and MBOM as well as many other BOMs is a very complex problem that cannot be solved in an easy way. One of the key problems is the need to synchronize information between BOMs. However, synchronize is probably a wrong word. These BOMs are not identical and requires application of very tricky logic to keep them in sync. To solve it is a big deal for many companies and they will demand it from vendors. Therefore, I’m very confident that, after all, PLM vendors fight over BOM will require to solve data synchronization problems.

At the same time, manufacturing is changing. One of the most visible trends in manufacturing is mass customization. We are moving from mass production methods toward total customization. The demand for configuration is growing and customers are requiring sophistication of engineering to order manufacturing processes applied to a broader range of products and services. Bill of materials is a center piece of these processes. What was done before by configuring a small set of preconfigured modules won’t work in a new reality of manufacturing and mass customization.

My attention was caught by a set of articles about Mass customization by Kalipso. One of them was published on Innovation Excellence blog – Modern Mass Customization – Rule 3: Honor the Order, Abandon the BOM. These articles are worth reading. Here is my favorite passage that outlines a special role of BOM in mass customization manufacturing process:

The relevance of the BOM greatly diminishes as a company transitions to a ‘to-order’ product offering. For mass customizers, a Bill of Materials, or more appropriately, a Bill of Modules, is a transient artifact. It is entirely possible that a given BOM may only be built a single time, and for a single order. Mass customizers should shift their perspective of the BOM from the identity of the product, to the technical details of the order. The identity of the product then becomes the governing logic that permits a range of configuration possibilities.

As the purpose of the BOM changes, so changes the purpose of PLM and the systems that support it. Rather than originating in PLM, BOM details originate with the order itself, ideally using a customer-facing product configuration system. As long as the order and corresponding BOM are compatible with the business rules that govern configurations, these details can be passed on directly to production systems for manufacturing (ERP, MRP, MES) without making a pit stop at PLM. PLM thus transitions from a tool for managing the lifecycle of a BOM, to a tool for managing the lifecycle of modular components that are used by the configurator.

I’m not sure about “abandoning the BOM”. However, article made me think about some elements of BOM management that are going to change. One of them is granularity of BOM. What I can see is the overall transition of BOM management into more granular process of configured components. In order to do so, PLM and ERP will have to re-think the way ownership and synchronization is happening. The question of “ownership” of granular product definition is getting less relevant. To manage smooth synchronization process is much more important.

What is my conclusion? Modern manufacturing trends are going to transform enterprise systems as we know them. Mass customization is one of them. PLM and ERP are two main systems that involved into process of engineering and manufacturing. To support mass customization product engineering and manufacturing these systems will have to interplay in a completely different way. In my view, the demand to support mass customization and other complex manufacturing processes is leading PLM vendors to want MBOM badly. However, here is change that can come as a result of rethinking of BOM management. In the future, Bill of Materials should not be owned, but intertwined and shared between PLM and ERP. Ownership of data will become less relevant. The new reality of data sharing and collaboration is coming. Daydreaming? Just my thoughts…

Best, Oleg

MBOM (Manufacturing BOM) is a tough problem. Initially, you might think about it as an easy problem. Especially, since companies are managing MBOMs in MRP/ERP systems for a while. However, I think, the time when MBOM was simply originated in MRP system to fulfill demand planning and production orders are gone. And it brings lot of questions and, raise attention from software vendors and implementers. PLM vendors are in the first line of companies demanding the change in the way MBOM is handled.

MBOM is really hard if you want to keep it in sync with rest of product data in engineering and manufacturing. It starts from the moment of time, you understand that your engineering BOM and manufacturing BOM are not the same thing. I touched it earlier in my post – 4 reasons why is hard to deliver MBOM in PLM. The initial creation of MBOM can be technically straightforward. It mostly end up by adding date effectivity element into BOM structure. Within time it gets complicated. And one of the main reasons is synchronization of data. It goes mostly around management of engineering change.

MBOM is a central place to capture the impact of engineering changes and to insure changes are managed correctly and reflected into manufacturing process with relevant dates and references to engineering data (EBOM). The priority of changes are not equal. Organization must handle these priorities and it can result in significant cost differences. Fundamentally you can think about mandatory changes and optional changes. The first one is the change organization will be implementing at any cost. It usually result of failures and regulatory changes. The second one is more interesting. This is where all new development, innovation, design improvements, cost reduction and other things are coming. This is a place where play with effectivity date can be tricky and complex. The sequence of steps are as following:

1- Engineering release or ECO transmit the data about changes in EBOM, which serve as a source of change and provides all required engineering information

2- Manufacturing should introduce these changes into planning process. Timing is important and this process is formal. Some of companies connect it to so called MCO process.

3- All dependencies must be discovered and reflected in changes of MBOM and manufacturing planning.

The last step brings a significant complexity. Engineering information (as it comes from EBOM) often comes incomplete and doesn’t contain all data that must be reflected in a change. There are multiple reasons to that, but in general, engineering view of a product is different from manufacturing one. One of the most typical examples is related to part interchangeability. But, I can see many others too. To synchronize changes between EBOM and MBOM is very complex. However, this complexity and challenges can turn MBOM into next cool thing in PLM.

What is my conclusion? EBOM to MBOM synchronization is a complex process that requires significant data manipulation, data discovery and careful operation. It cannot be automated and it requires a lot of consideration from engineering and manufacturing people. The complexity of modern product and manufacturing processes are introducing the new level of challenges in the way to manage EBOM and MBOM. This sync is critical and companies are demanding tools that can help them to handle it in the right way. Just my thoughts…

Best, Oleg

BOM Management. Multiple BOM Views. These topic are always drives lots of discussion in a real life and online. There is no question about importance of BOM in product development, engineering, manufacturing… Literally, you cannot do anything without Bill of Materials.

Few weeks ago, I came with the topic that generated a very good and healthy discussion – Will PLM Manage Enterprise BOM?  A bigger part of the discussion happened in PLM LinkedIn group. You need to have LinkedIn user to access that. In a nutshell, the discussion was about an influence PLM and ERP both have on BOM management in the organization. The topic is not restricted to PLM and ERP. However, it is clear that PLM and ERP are playing major roles in how BOM managed in organization and how enterprise BOM management solution can be architected.

BOM Golden Rule

I’m sure you are familiar with Golden Rule. Satirical definition of this rule says “Whoever has the gold, makes the rules“. Here is manufacturing definition of the rule – “Whoever owns the BOM, makes the rules“. This is very true in many aspects and it explains a lot of what happens in every manufacturing organization in terms of how enterprise systems are positioned. They people work in the majority of organizations these days can be summarized as following – don’t touch my BOM. You can think about design / engineering, manufacturing, sales, supply, plant and many others. Every department or organization is creating their own BOM and then trying to synchronize it during product development process with other BOMs.

I’ve seen multiple attempts to create an alignment between various enterprise systems. Here is an example of product vs. transactional alignment between PLM and ERP provided by one of my blogging buddies – Edward Lopategui from E[E] blog. I took the following passage from LinkedIn discussion:

I think part of the problem is the divide between PLM and ERP, where PLM has always been product focused while ERP is transaction focused. While few dispute that PLM has the superior BOM capability, the ERP transactional dependencies perpetuate the legacy need to continually instance MBOM on the ERP side. And since PLM does not have an acceptable equivalent of those transactional capabilities, expect the divide to continue into the foreseeable future.

You can explain what are differences between BOM in PLM and ERP from product, system and technological standpoint. However, the political influence in organization can make this type of effort meaningless. One of my permanent discussion opponents, Dr. Michael Grieves (Consultant at NASA and author of Product Lifecycle Management: Driving the Next Generation of Lean Thinking book) provided the examples of factors here:

Where the MBOM resides is going to be dependent on both technical, political, and legacy factors. Technical factors include the complexity of the product, how often the MBOM changes and who drives those changes, whether an MES system exists,… Political factors include whether the strategic direction is toward ERP or PLM. Legacy factors include what systems are currently in place for MBOM control. Compounding these issues is that ERP companies are moving into PLM solution spaces and vice-versa.

EBOM vs. MBOM

From technical standpoint, it is relatively easy to explain the difference between EBOM and MBOM. The first (EBOM) represents they way product is designed (structure, models, functionality, configurations, etc.) The variety of characteristics are depending on the type of manufacturing and processes. Manufacturing BOM defines how product will be produced (including aspects of material ordering, routing, different manufacturing plants, etc.).

EBOM and MBOM are not entirely different but data structures and attributes used in both are often not overlapping. Some engineering attributes and structures are not relevant for MBOM (or cannot be stored using MRP/ERP systems). On the other sides, MBOM information is often irrelevant and not needed for engineers and designers.

The thing that makes everything complicated is a process between these two worlds. The “throw over the wall” manufacturing concept co-exists together with tightly collaborative process of work on EBOM and MBOM. Engineers are requested to provide information about product (EBOM) as early as possible in the development cycle. At the same time, manufacturing planning can get back to engineering in order to finalize and optimize product. Very often, both BOMs (but mainly MBOM) can be used for external planing systems.

What is my conclusion? BOM is one of the most important information pieces in product development. It comes on different stages of development – design, engineering, manufacturing, supply, etc. Because of different reasons – technical, political and organizational, the most widely adopted BOM implementation practice is to split BOM into separate pieces (views) reflecting application domains. At the same time, modern business and manufacturing practices require better integration of processes around BOM. PLM vs. ERP. Engineering BOM vs. Manufacturing BOM. The debates about how to organize them in a better way are heating up in every organization. Just my thoughts…

Best, Oleg

The post BOM: Apple of Discord between PLM and ERP? appeared first on Beyond PLM (Product Lifecycle Management) Blog.

Manufacturing BOM (MBOM) is an interesting topic. After all design and engineering operation,  MBOM defines how product is going to be actually manufactured. While most of PLM / ERP debates about MBOM are going around “who owns what”, the most fascinating part that I found in MBOM is related to the nature of manufacturing planning. The root problem is related to the way we can optimize MBOM or actually optimize the production, which is usually done by material planners using so-called planning BOM. It made me think about some black magic that needs to happen between engineering and manufacturing. Let speak a bit more about it.

Navigate back to my BOM 101 articles from the last year – How to modularize the Bill of Materials and How Many Levels Do You Need in BOM? One of the fundamental problems BOM layering and structuring needs to optimize production schedule. It can be only done by the team of people – including engineers together, manufacturing process and material planning people. Interesting enough, often you need to have sales and business people in the room – only these people can give you some data to predict manufacturing capacity, scheduling and potential optimization.

It made me think about a potential for PLM to play a role of collaboration platform between all these people to come with the solution around product configurations, engineering options, manufacturing optimization and what is most important product cost. I can see this is one of the fundamental problems PLM can solve as a collaborative platform connecting engineers and manufacturing.

PLM can provide an information structure to keep variety of product families, engineering BOMs, planning variants, supplier information and manufacturing planning together in order to optimize product and manufacturing production schedule and cost. All together is a real benefit of PLM implementation that can pay off very fast.

What is my conclusion? Manufacturing is getting more and more complex these days. People wants to have more personalized and configurable products. At the same time, companies need to slash cost.  What was possible to solve by throwing engineering BOM or even CAD drawings over the wall of manufacturing is nearly impossible in 21st century. Old way to go from engineering to production planning will make your manufacturing  obsolete, product cost skyrocketing and your company out of business very quick. Modern collaborative tools including PLM holding multiple bill of materials are needed to solve it. Just my thoughts…

Best, Oleg

The post PLM and Magic of MBOM planning appeared first on Beyond PLM (Product Lifecycle Management) Blog.

Have you heard about “150% BOM”? BOM management terminology is confusing sometimes. Ed Lopategui gave a shot to explain it in his last GrabCAD blog – 150% BOM: Buy Two, Get One Free. The following passage was my favorite:

A 150% BOM isn’t sorely in need of some fitness training or sadly overdrawn at the bank. In fact, a 150% BOM is just another name for a variant structure, or more specifically, a configurable BOM. Configurable BOMs have one or more optional components and/or modular subassemblies, which, when properly set, define a specific variation of a product. In effect, a configurable BOM is many possible BOMs loaded into just one product structure. When left unconfigured, the BOM contains more parts and subassemblies than needed, i.e. more than 100%. Hence, the term 150% BOM. So why 150% and not 110% or 117.32%? That’s just the we way we roll in BOM town.

Variant structure, configurable bill of material, modular BOM… the industry invented multiple names to cope with the complexity of communication and product development processes in manufacturing organizations. The core idea of modularization or configuration is not directly related to assembly to order process (ATO), but used widely for configurable and complex products. You can see 150% BOM, 200% BOM and similar BOM organization maintained by engineering department to facilitate creation of final products from predefined parts and sub-assemblies. The product development is actually divided into two essential steps – create your modular (150% BOM) and create a planning bill of a specific product. The last one will allow you to roll out cost and delivery time.

So, why engineers created 150% BOM concept? Do we really need that? In my view, the approach was a way for engineers to manage the complexity of product structure and product variation. You can see it for product configurations and also in bill to order (BTO) situations where complex product development is managed in a way of product technological foundation combined with features developed for specific customer. With absence of better tools, Excel spreadsheet becomes the best product configuration environment and matrix with 150% BOM is the simplest model to present that.

Ed’s blog made me think about future of “150% BOM” and matrix BOM organization. In my view, the concept will disappear in the future. In my view, the complexity of product environment is growing. In many situation, to produce 150% BOM is not feasible anymore. With the level of product complexity, mix of mechanical, electronic and software components, ability of engineers to bring them all together into one 150% BOM can be not practical and even less efficient. We will need to invent new tools to manage the complexity of configurations and product data. With growing demand for personalization, we are not far from the situation, PLM and ERP systems will have to roll out bill of materials individually configured for a specific customer (and this is not only in aerospace and defense industry).

What is my conclusion? Growing complexity of products, move to mass customization, regulatory and cost pressure, global manufacturing – this is a reality of modern manufacturing environments. We need to develop a new approach how to manage product development and manufacturing of these products. Product configurations and BOM is a centerpiece of this approach. A simple 150% BOM spreadsheet will be replaced with new BOM tools. Just my thoughts…

Best, Oleg

The post Why 150% BOM will be obsolete in the future? appeared first on Beyond PLM (Product Lifecycle Management) Blog.

The only thing that is constant is change. This is very much applies to everything we do around BOM. Engineering and manufacturing eco-system are full of jokes about engineering changes. You maybe heard about renaming “engineering change order” into “engineering mistake order” as well as the correlation between number of engineers and number of ECOs in a company. However, the reality – change orders are one of the central elements of engineering and manufacturing life. And it is primarily related to bill of materials. Once defined, we keep changing BOMs through the lifecycle of the product. ECOs are helping us to do so.

In my yesterday post (Manufacturing BOM dilemma), I discussed the complexity of manufacturing BOM. Fundamentally, MBOM is reflecting manufacturing process, which is by itself defined by both – product information coming from engineering department and by part and other related information coming from manufacturing systems (MRP / ERP). The collaboration between these two systems is never easy. This is one of the reasons why MBOM management process is struggle to find the right place in many companies.

One of the suggestions made in comments was to use PLM system as BOM manager and run ECO/ECR processes each time we need to make a change in bill of material. Such process will insure ERP will be always updated with the last information about BOM. My initial thinking – this is very straightforward way to manage it and I’ve seen it in many companies. On second thought, maybe there is a better way to manage that.

As I mentioned before, changes to the bill of material are a controversial topic. My hunch every company should have a policy how to manage BOM changes. From my experience I can classify three major type of changes to bill of materials: 1/mistakes; 2/materials and/or parts changes; 3/arbitrary changes (liabilities, etc.). In many situations, BOM changes can lead to significant cost related to material scrap, additional material planning, etc. On the other side, every change related to materials, process optimization and manufacturability should be synchronized back into PLM system. So, maybe, ECO/ECR is not a right way for engineering/manufacturing collaboration these days?

The life was good when engineers were able to through BOM over the wall of manufacturing department and finish their job. This is not a reality we live in today. Engineering and manufacturing should maintain a very close relationships by developing and optimizing manufacturing processes. Sometimes, the solution is purely manufacturing. However, very often, redesign or additional level of product engineering optimization required to reduce product cost or bring product to market faster. Maybe it is a time for both engineering and manufacturing department to develop new practices how to collaborate on BOM? Abandoning old fashion ECR/ECO processes for engineering/manufacturing collaboration can be a first step into this change.

What is my conclusion? Engineering and manufacturing process planning are tightly coupled these days. In many situations both product development and engineering planning must go in parallel to achieve desired level of optimization. It requires new type of processes and software enabling new level of BOM collaboration. Old fashion ECR/ECO method may not work. Just my thoughts…

Best, Oleg

The post MBOM collaboration and cost of change appeared first on Beyond PLM (Product Lifecycle Management) Blog.

Engineering.com article by Verdi Ogewell earlier today is introducing a next step of PLM vs. ERP battle for ownership of manufacturing BOM. Navigate to the following link to read a very provoking interview with Siemens PLM CEO Chuck Grinstaff who says – “PLM should take over ownership of the manufacturing BOM too“.

I’ve been writing about the complexity of manufacturing BOM before. You can refresh your memories with the following two articles I wrote earlier this year: Manufacturing future will dependent on solving old PLM-ERP integration problems and Manufacturing BOM is the next cool thing in PLM.

BOM topic is fascinating and incredibly important for PLM companies. It boils down to the ability of PLM to control the complexity of variety of product definitions. The complexity of modern manufacturing environment is skyrocketing. Think about a combination of multiple disciplines involved into the process of design, engineering, manufacturing and support. Mechanical, electronic and software components are tightly integrated to produce modern airplanes, cars and other highly sophisticated products. However, to solve design complexity is just a beginning of the road. The next huge problem is to solve manufacturing problems. It all comes to manufacturing planning, procurement and shopfloor control. After, eventually, you end up with the result, which is represented by “as built” product data, support and maintenance systems.

To demonstrate complexity of BOM transformation I created a diagram below. What you can see below is different views of product data. It usually represented as a different views of Bill of Materials.

The following quote from Engineering.com article is one of my favorite to describe the importance of product data modeling. According to Chuck Grinstaff of Siemens PLM:

How important is the BOM issue among businesses? ”Incredibly important”, claims Chuck Grindstaff, and it’s not just a matter of semantics, ”The real issue around the Bill of Materials, whether for engineering, for manufacturing, for test or for procurement, is that each of these views of the product are important to the consumer of the BOM. Every view of the ‘bill’ needs to reconcile to other views and must remain accurate within the context of the total product during each stage of development. We believe that each of these viewpoints needs to be configurable from a common definition; from a single source of truth into the context for each of the engineers. For that reason it’s important to get it right. You can call it ”a battle”, yes, but the point still is that a PLM system is the best environment to manage this complexity.”

PLM vendors arguing towards full control of all aspects of BOM by PLM platforms and tools. The main battle is with ERP systems. Historically and traditionally, ERP companies are controlling part of product data starting from manufacturing planning and going future towards procurement and as built representations. It created well-known status of engineering vs. manufacturing balance. However, future demands of deep manufacturing integration brings PLM vendors to think that to take over MBOM (or more specific, manufacturing planning BOM) will deliver better solution for product complexity management.

The desired status for PLM vendors is to push ERP down towards procurement only and manage manufacturing BOM as part of PLM database. Here is another passage from Engineering.com article quoting Peter Billelo of CIMdata explaining why it can be reasonable from PLM vendors’ standpoint:

”ERP solutions generally do not actually optimize or have development tools for defining what the manufacturing BOM is. They just focus on executing a defined Bill of Material. So if I look at what Siemens is doing they are based on developing what that mBOM should be and optimizing that BOM. Quite frankly I don’t see any of the ERP vendors spending much time, if any time, at all at actually doing that. That said it makes sense for Chuck to claim the ownership since they have the tools to make changes, analyze and optimize the BOM.”

Engineering.com article made me think again about complexity of data management and integration in product development. It is certainly complex thing to manage multiple aspects of product data – design, engineering and manufacturing. To ensure data accuracy, both PLM and ERP systems must be well synchronized, which requires multiple very complex data transformation. The “sync” is king of the road on the PLM-ERP highway connecting engineering and manufacturing organizations.

Current enterprise data management paradigm is based on the RDBMS architecture that fundamentally provides a storage for all aspects of product data. TeamCenter is probably one of the best systems to support the complexity of product data representation. By moving manufacturing planning BOM to TeamCenter (or other PLM system), PLM vendors can decrease complexity of data synchronization between two complex views – engineering and manufacturing planning. ERP system role in this situation will be limited to procurement function and management of master production schedule.

However, Siemens PLM is not alone in their desire to take control of complete product structure management and all aspects of BOM. My earlier article – PLM and Zero BOM errors speaks about how Dassault Systems ENOVIA strategy to simplify the complexity of BOM synchronizations between design and engineering environment. This is a bit different aspect, but still represents the desire of PLM companies to solve BOM synchronization problem.

What is my conclusion? The problem of data synchronization between different BOM representations is a real one. The level of complexity is huge. PLM companies are trying to leverage their sophisticated data platform to control the overall product data complexity. The fight is two fold – technical and political. The heart of every CIO is usually with ERP system. PLM companies need to think how to deliver technologies to solve the level of integration complexity. In my view, this is a key to win MBOM battle. Just my thoughts…

Best, Oleg

photo credit: elcovs via photopin cc

The post PLM vendors’ fight over BOM will require to solve data synchronization problems appeared first on Beyond PLM (Product Lifecycle Management) Blog.

MBOM (Manufacturing BOM) is a tough problem. Initially, you might think about it as an easy problem. Especially, since companies are managing MBOMs in MRP/ERP systems for a while. However, I think, the time when MBOM was simply originated in MRP system to fulfill demand planning and production orders are gone. And it brings lot of questions and, raise attention from software vendors and implementers. PLM vendors are in the first line of companies demanding the change in the way MBOM is handled.

MBOM is really hard if you want to keep it in sync with rest of product data in engineering and manufacturing. It starts from the moment of time, you understand that your engineering BOM and manufacturing BOM are not the same thing. I touched it earlier in my post – 4 reasons why is hard to deliver MBOM in PLM. The initial creation of MBOM can be technically straightforward. It mostly end up by adding date effectivity element into BOM structure. Within time it gets complicated. And one of the main reasons is synchronization of data. It goes mostly around management of engineering change.

MBOM is a central place to capture the impact of engineering changes and to insure changes are managed correctly and reflected into manufacturing process with relevant dates and references to engineering data (EBOM). The priority of changes are not equal. Organization must handle these priorities and it can result in significant cost differences. Fundamentally you can think about mandatory changes and optional changes. The first one is the change organization will be implementing at any cost. It usually result of failures and regulatory changes. The second one is more interesting. This is where all new development, innovation, design improvements, cost reduction and other things are coming. This is a place where play with effectivity date can be tricky and complex. The sequence of steps are as following:

1- Engineering release or ECO transmit the data about changes in EBOM, which serve as a source of change and provides all required engineering information

2- Manufacturing should introduce these changes into planning process. Timing is important and this process is formal. Some of companies connect it to so called MCO process.

3- All dependencies must be discovered and reflected in changes of MBOM and manufacturing planning.

The last step brings a significant complexity. Engineering information (as it comes from EBOM) often comes incomplete and doesn’t contain all data that must be reflected in a change. There are multiple reasons to that, but in general, engineering view of a product is different from manufacturing one. One of the most typical examples is related to part interchangeability. But, I can see many others too. To synchronize changes between EBOM and MBOM is very complex. However, this complexity and challenges can turn MBOM into next cool thing in PLM.

What is my conclusion? EBOM to MBOM synchronization is a complex process that requires significant data manipulation, data discovery and careful operation. It cannot be automated and it requires a lot of consideration from engineering and manufacturing people. The complexity of modern product and manufacturing processes are introducing the new level of challenges in the way to manage EBOM and MBOM. This sync is critical and companies are demanding tools that can help them to handle it in the right way. Just my thoughts…

Best, Oleg

The post Engineering change and EBOM to MBOM synchronization complexity appeared first on Beyond PLM (Product Lifecycle Management) Blog.

In a traditional engineering, “over the wall” approach is a reflection of sequential operations – marketing, design, manufacturing, testing and production. Each stage of development process is carried out separately. As you done with one stage, you can move the the next one.

Pieter Hamans‘s article Creating a Manufacturing Bill of Materials made me think about sequential bill of material management process again. Although Peter mentioned that ideal BOM management system can support all objectives simultaneously, the following passage explains the reality EBOM vs MBOM separation:

A frequently made distinction is that between Engineering BOMs and Manufacturing BOMs. An EBOM is typically created in the engineering department and may originate from a Computer Aided Design or CAD software. It reflects the component structure from a functional perspective, and often also per technical discipline: there may be a mechanical design and an electrical design for example. To support collaborative engineering Product Life Cycle management (PLM) of Product Data Management (PDM) systems have been introduced. On the other hand we have the MBOM to support the manufacture of the product. The MBOM is typically maintained by logistics professionals and is used in an Enterprise Resource Planning (ERP) system. The MBOM drives material planning and product costing. Often there is some work to be done to convert an EBOM into an MBOM.

The article provides a good summary of situations you typically can find in discreet manufacturing when managing part ordering, production and manufacturing logistic. Flattening of BOM, consumable and by-product items are good examples of things that usually not coming into EBOM.

At the same time, EBOM vs MBOM divide introduces one of the highest level of complexity in engineering and manufacturing systems. I captured below the picture from the article.

I think, the appearance of two clouds can highlight the problem even more. The data is flowing between two systems and creating inefficiency in change management. Two data structures EBOM and MBOM are managed by two separate systems. Things can fall between the cracks. To bring design or engineering change to manufacturing takes time and can introduce potential mistakes. Low visibility on manufacturing plan and components availability and cost leads to sub-optimal design and engineering decision.

EBOM vs MBOM divide was introduced by historical sequential engineering. It was good back 20 years ago, but it is completely inefficient in the new era of connected engineering and manufacturing processes. New business processes are demanding higher visibility in engineering, manufacturing and supply chain. The split between EBOM and BOM cannot stand against the demand to optimize engineering and manufacturing.

The connection between EBOM and MBOM is highly demanded. It will come in many ways. One of them is better integration between existing systems. Integrated change management system with search capabilities can be a solution deployed on top of existing PDM/PLM and ERP repositories to manage all transactions and changes.

Cloud technologies has a potential to connect information. Instead of replication of existing PDM/PLM and ERP repositories to the cloud, the new system organization can come into place. Cloud services is one of the key technologies that can stop the divide between EBOM and MBOM.

What is my conclusion? Historical divide between EBOM and MBOM leads to inefficiency in engineering and manufacturing. Future development of PLM and ERP systems will eliminate the divide by introducing new integration technologies and unbundling services helping to manage information in a more efficient and connected ways. Just my thoughts…

Best, Oleg

The post The death of EBOM vs. MBOM divide? appeared first on Beyond PLM (Product Lifecycle Management) Blog.