BOM: Manufacturing and Engineering

I’d like to continue discussion about Bill of Materials. I learned a lot from previous posts. Thank you all for excellent comments!

For those, who just joining us, these are links on previous posts:
BOM: Overstructured, Understructured or Lean
Seven Rules Towards Single Bill of Material

Picture 10
So, today, I want to focus on potential differences between Engineering and Manufacturing bills and put some ideas how, I think, these bills can be managed as a single, or more synchronized one bill. A very logical situation I had chance to see in many companiesboth engineering and manufacturing have their own BOM. If you will request part list from both BOMs for the same part number, two different BOMs will appear. And
two bills supposed to be in sync…. However, they don’t. In my view, the fact, these bills are not synchronized can bring a very significant damage to the company nowadays. Increased regulation requirements, IT resource optimizationthis is the only initial list of the reasons why we can prefer to make some optimization around both engineering and manufacturing BOMs.

I will try to figure out why engineers and manufacturers prefer to have their own bills. Engineers don’t understand the manufacturing’s need for more or less levels in BOM. Most of engineers prefer to have fewer levels in the bill, so it will simplify the process of changes. From their standpoint, it will make the process of changes straightforward. Another situation when engineers, indeed, create additional levels of subassemblies. However, in real life these subassemblies are consumed on the shopfloor almost immediately and manufacturing doesn’t see any need to assign Part Numbers to these subassemblies (lean practices). There is also a situation when manufacturing leads to a false conclusion about two BOMs need. One of the examples is when the assembly requires many partsbut manufacturing is not using them all in once, or they are used in different assembly areas. Even more complicated situations may happen in case you are manufacturing configurable product with multiple options. Set of engineering documents and engineering parts can be significantly different from manufacturing bill you’ll have for a particular order. To manage synchronization between these bills can be a huge task, and it will result in high complexity of software (or procedures) used to make this synchronization happen.

The solution for this problem, I want to discuss is to maintain single bill of material with the sufficient level of granular (or I can call it modular) definitions of parts. The granularity needs to be on the level to satisfy both engineering and manufacturing. Engineers need to have the ability to manage parent/component information. At the same time, manufacturing can maintain the operation information and lead time offset data. In the case of manufacturing to order, a unique bill of material will be generated from a modular set of components.

Advantages of this approach will be eliminating costly synchronization between engineering and manufacturing BOMs. The visible disadvantages of such approach is how to implement it using today’s software. I’m not familiar with applications that can provide the level of flexibility to manage bill of material. I assume some service implementation or customization can be done, and maybe you can share your experience about that.

Just my thought.
Best, Oleg


Share This Post

  • Michael Gavlak

    At a former employer, my division used plant specific BOMs in our MRP system for engineering purposes. The rationale was that it was critical for all parts of the organization to understand the effective dates of changes, so the correct documentation was used, and traceability was maintained. Other divisions had separate engineering and manufacturing BOMs, and dealt with the differences.
    For my division, this integrated BOM required product engineering to understand the manufacturing processes, and include additional subassemblies in some limited cases. Sometimes the structure was different in different plants, which required the product engineer to understand those differences, and incorporate that into the other documentation which would otherwise have been missed. Also, they had to work with manufacturing engineering and PC&L to define raw materials numbers and quantities. To support product engineering change analysis, we needed to add BOM structure for “components of purchased assemblies”, which came into manufacturing as a part of the purchased assembly instead of individually. This also allowed us to inform suppliers when component parts they bought needed to be changed.
    I would have preferred that product and manufacturing engineering (and packaging engineering, if that is in the BOM structure) have their own BOM fragments (for ownership, security and traceability of changes), so product engineering could just manage the part to part relationships, and manufacturing engineering could manage the part to raw materials relationships, but our commercial MRP and PDM tools didn’t allow that.
    I envisioned a system which would automatically combine these BOM fragments (which could revise independently and with different effective dates), and provide appropriate views according to the desired usage and effective date. Some examples would be where the manufacturing BOM would not show the purchased subassembly components and would default to the current effective dates, and where an engineering BOM would include all parts and default to show the BOM with all known approved changes out into the future. We got most of this functionality in SAP by exporting the plant specific data, specially entering the component of assembly structure as an SAP “group BOM”, and creating a web BOM viewer with our desired views, reports, and notification automation.
    I would have loved to take the next step, but moved on to another assignment before I had a chance to do it.

  • Vladislav

    Oleg, why not simply engineers and technologist work together?

  • Michael, Thank you for your thoughts and insight. The way you speak about “BOM fragments” is interesting and, in my view, complicated to implement. It is easy to make it separate and as a result of that, issue of synchronization will come immediately. On the other side, if you merge them together, it is very hard to manage them as separate fragments. Have had chance to think about how to implement it? I’m not familiar very much with “SAP Group BOM”… Does it allow you to synchronize Bill of Materials? Best, Oleg

  • Vladislav, What I learned in the past is that “if you don’t fix, it becomes broken”. If I will take it to the engineering and manufacturing/technologist, it means – you need to organize way they work, otherwise it will become complex and won’t work in the end. So, my thoughts is about how to organize their work. It’s obvious (for me) they need to work together. Best, Oleg

  • Michael Gavlak

    BOM fragments isn’t really that hard to implement. It really means several different (single level) BOMs that make up a given part, with no overlap of the components on them. Each can have a separate author/owner, and can change at its own rate. These get concatenated following the effective date rules for a complete BOM for the part. Not every part would have all the different BOM fragments. Top level parts might have the packaging information, low level parts made from raw materials would have the raw material information and intermediate levels might only have the product part to part information. This clears up security and accountability issues, and lets each function control the parts they feel the most ownership of. The change management system and process would determine which of these BOM fragments needs to, and is authorized to change for a given product or process change.
    SAP has group BOMs and plant specific BOMs. A group BOM is not assigned to any plant, and can be copied to create plant specific BOMs, but plant specific BOMs actually run the MRP processing. Components of plant specific BOMs require a significant amount of material master and other setup, where parts just used on group BOMs need very little. A group BOM could be treated like an EBOM for most organizations. We actually specially coded them to keep track of BOMs for plants not actually running SAP, and to track the purchased subassembly components which manufacturing doesn’t want to have to see on their plant specific BOMs. SAP does not automatically display the group BOMs for components in a plant BOM structure, but we had a special web based viewer we wrote to provide these views.
    A part can have multiple plant specific BOMs (and group BOMs), to account for plant to plant differences, and to even allow for different processing in a given plant for things like production batch size, and the system can automatically select from several “production versions” based on rules.

  • Michael, Thank you for great explanations. I’ve been familiar with concept of “modules” in Bill of Material and such group BOMs sounds as something very similar. So, group BOM will play role of phantoms that will disappear when you will transfer it to MRP run…. Very good discussion! Thanks! Oleg