Single Bill of Materials in 6 Steps

by Oleg on January 16, 2013 · 11 comments

Last week I started the discussion about about modern BOM challenges. That discussion made me think more about the idea of unified and consistent Bill of Materials that can be shared across the company (single BOM). In my view, this is a clear paradigm shift from what we know today as “multiple BOMs”. How to move from well-known multiple BOM paradigm to single BOM? If you are PLM manager, IT or implementation service company, you need to be prepared for the discussion that will involve all organizational stakeholders. In the post, I’m trying to identify steps in this discussion. I identified 6 steps – structure, part numbers, extensions, end items, ECO and BOM sharing with some comments.

1. Structure: Phantoms, Modularization, Planning Bills

The “beauty” of  multiple BOM strategy is in segmentation. In your silo, you decide how to organize Bill of Material. Historically it gave a lot of advantages. By trying to combine it together, you can face discussions about how to create BOM compartment to fill a particular process and/or organization needs.

2. Part Numbering

One of the fundamental conversation about BOM is related to Part Numbers. In the past, discussion about part numbering schema raised lots of controversy. Many companies historically tied to using so-called intelligent part numbers. Be prepared to switch towards something more easy and straightforward. The process of Part Number assignment is also very important.

3. Specific extensions to the BOM

Each company has their own little secrets about what to add/exclude items to BOM. In most of the companies, this is a place that will be very hard to transform. The discussion about adding “nuts and bolts” as well as some other specific materials to BOMs can be endless. Be prepared.

4. End items

Large amount of end items can make your BOM strategy very cumbersome. The sales and business people need to take a part in this discussion. In most of the cases, you can delete end items and switch to the strategy to use options for the same purpose.

5. How to deal with ECO?

The question of dealing with engineering changes is critical. You need to have an ability to make a change easy without restructuring of BOMs (or, at least, with a very small effort). The ability to find a way to present ECO process will be critical. Another critical process to clear is new product introduction.

6. BOM sharing

The effort to create a single BOM experience is useless if you cannot share BOM holistically in an organization. If people are not accessing the same model, the same data at the same time it will destroy the idea of a single BOM.

What is the conclusion? Depends on the nature of your business, one of these topics can become a key and showstopper for your organization to transform into the single BOM. Some of you will disagree of structures and some you will not have a system to share BOM across the organization. The multi-BOM paradigm evolved during many years as a result of fundamental organization silos. However, these days, the efficiency how organization can resolve the problem of connected cross department processes is a dominant one. BOM is a lifeblood in these cross-department processes. If you switch to a single BOM, you have an opportunity to optimize processes. Just my thoughts…

Best, Oleg

Share

Tagged as: Bill of Materials, BOM, PDM, PLM

  • Mvrinat

    Oleg, do you have any industry reference for single BOM usage today? I think it is still an unmatched, while necessary, step.

  • beyondplm

    Mvrinat, I don’t have much industry statistics about single BOM usage. In my view, most of organizations are following multi-BOM (silos) paradigm. There are some attempts from PLM software vendors, but even so, for most of them- single means located in single place (PLM system). I appreciate if you can share any information. Best, Oleg

  • http://twitter.com/FredSmithPTC Fred Smith

    Why not have the best of both worlds: a single, logical, comprehensive structure, AND multiple BOMs? The higher-level concept of a “product structure” is crucial for modern product development. If we think of a product structure as a tree (a majestic pine, perhaps), then a BOM would be like one of those automobile air freshners that you hang from a rear-view mirror. Think of a BOM as a “slice” through the product structure for a specific purpose. In PLM systems, BOMs are implemented as complex filters of the product structure. So, you can view an as-designed or as-planned, or variant or configuration, etc., BOM, but behind the scenes, these are each different views of one underlying product structure, which greatly simplifies the problems of change management and auditing.

  • beyondplm

    Fred, thanks for the comment! I like your view on BOM as “a single, logical, comprehensive structure” with application of “filters”. However, filter imply the fact of stopping the practice to copy multiple branches of BOM structures. One of the important benefits is to define BOM rules based on a single consistent structure (model). Best, Oleg

  • http://twitter.com/FredSmithPTC Fred Smith

    Depending on your meaning, a BOM rule may be implemented by a filter. In general, we should seek to eliminate copies of data, in any form or system(s). Instead, I prefer a “reference and augment” approach. For example, a more specific BOM could refer to a less specific one with additional information. We should only copy a part/BOM if we want to capture it’s essence, then change it (a design re-use scnario). But in that case, we need to maintain the “copy” history so that we can audit why a reference was inadequate.

  • beyondplm

    Thanks for this clarification. It makes sense. Data should not be copied because of “systems”. Only in case it means different “instance” of data (eg. serial BOM)

  • Klaus

    Hello Oleg, I’m actually surprised by your conclusion.
    Usually you are an advocate for connected systems, praising cloud and internet technology to “break the boundary of a single database”. If a single database limits the flexibility of departments and the “scalability (…) for future information discovery”, how restrictive will a single BOM be?
    Companies which are maintaining a unified single BOM are doing it mostly because of the limitation of the system in use. It probably does not provide the flexibility to manage several BOMs or to keep them in synch. The BOM building process was quite often dominated by the implementation of a MRP system. When we implement PLM systems in design departments we discover always additional engineering BOMs, maybe maintained in excel sheets, on drawings or
    on paper and not in a central system, but they are there because they are necessary.
    Imagine what functionality a system would have to provide to be able to manage a unified single BOM on the one hand but keep on the other hand the liberty for every department to adjust the BOM as needed. It would have to be able to manage different structures, handle contradictory
    classifications, control lifecycle changes, document different as-… configurations,reflect supplier changes, follow price developments and so on.
    To agree on a unique single BOM today limits the flexibility for the individual department to change it processes tomorrow.

  • beyondplm

    Klaus, thanks for your comment! Actually, I’m very happy by the face this post got you by surprise. Yes, I’m advocating to break the boundary of a single database. But, here is a point… It is all about “flight for the BOM ownership”. Word “single” is reflecting “single database” to most of enterprise software folks (MRP, ERP, PLM…). However, this is not true, in my view. I want people in manufacturing company to reference BOM as a single entity. You ask me what does it mean technologically? From the technological standpoint, the question I’m asking is how to develop a way to have BOM federated between different systems and keep it single at the same time? Does it make sense to you? Best, Oleg

  • Tom

    Oleg,

    in my organisation (large particle accelerators for medical systems), we currently use one single BOM across the company, for a given product. This BOM is however a tricky compromise between engineering needs and manufacturing needs: eng’s want the BOM to reflect the architecture of the product (Vaccuum System, Magnetic System, etc, …). Manufacturing people want the BOM to reflect the stage of manufacturing so that ERP can order parts accordingly in due time. They “do not care” about architecture.

    So today with a single BOM means nobody is really satisfied –> We are now looking for PLM solutions, that are supposed allowing differents BOM for the same product: an engineering BOM and a manufacturing BOM. Looks promising, tough we are afraid about the hassle of synchronizing these BOMs when for instance a revision occurs.

    In conclusion, I tend to prefer one single BOM for a given product, but then how to structure it to reflect both engineering and manufacturing needs?

    Thanks

    Tom

  • beyondplm

    Tom, thanks for comments and sharing your issues! You’re absolutely
    right! The concept of single BOM needs to solve the issue of
    “synchronizing” siloed BOMs, which becomes a mess of every PLM system in
    the market. In my view, there is no single PLM system that can provide
    this functionality. Best, Oleg

  • Pingback: What Cloud CAD-PDM Hybrid Means for PLM? « Daily PLM Think Tank Blog

Previous post:

Next post: