PLM and ERP: Separated by a common Bill of Materials (BOM)

PLM and ERP: Separated by a common Bill of Materials (BOM)

bom-lifecycle

Yesterday, I had a privilege to share my thoughts about Bill of Materials and BOM management during my keynote at ProSTEP iViP Symposium in Stuttgart. That was my first time at ProSTEP conference. The first day is over. I will be publishing  updates in my live blog here.

The discussion about Bill of Materials is always interesting and entertaining. BOM is a centerpiece of every engineering solution. As an organization you have to manage different aspects of Bill of Materials during design, engineering, manufacturing and support stages. These days, as companies are moving from selling products into services, support and maintenance BOM is getting more into the focus of discussions. After all, Bill of Materials is complex topic. On the following picture you can see multiple dimensions of BOM complexity:

bom-complexity-1

In every organization, Bill of Materials has two notions  – technical and political. The first one is absolutely important. The following three characteristics are absolutely important if you think about reliable BOM management solution: 1/ ability to manage multi-disciplinary data; 2/ scalability; 3/ user acceptance. User acceptance is a tricky thing. The demands of people in an organization about BOM are different. Engineering, manufacturing, support, supply chain, sales – these organizations have want to see BOM differently.

enterprise-bom

However, regardless on the role of a person in organization, the following demands are absolutely critical: 1/ No errors (each mistake in BOM is painful and can lead to significant problems in an organization ; 2/ No painful date re-entry (nobody wants to enter information into BOM multiple times); 3/ No painful synchronization of data between PLM, ERP and other systems.

bom-management-demands

Below you can find a full deck of my presentation:

 

What is my conclusion? Bill of Materials and BOM is a very interesting topic. My hunch, it is getting even more in the focus of people as products are getting more complex. These days every single product is a combination of mechanical, electronics and software. Manufacturing companies are selling it as a services. Customers are demanding configurability, high quality and low cost. How to manage all these things together? The following three questions are absolutely important when you think about BOM management – 1/ How to support connected processes in an organization? 2/ How to stop synchronizing BOM between silos (PLM, ERP and others)? 3/ How PLM and ERP can support a concept of “single BOM”? Just my thoughts…

Best, Oleg

PS. If you want to discuss more about BOM management, please feel free to contact me directly.

 

Share

Share This Post

  • Menk Slot

    Hi Oleg,

    BOM discussion was always one of the big
    topics in PLM. I think it is an utopia to have 1 single BOM. If someone
    comes up with this solution, life would be more simple.

    The question you have to ask: Why do companies want
    multiple BOM’s?

    The reason is simple:

    If you look at the mechanical part. Most of the BOM is
    coming directly from the 3D CAD Assembly. But to have a correct solution you
    will have a Part Structure and a Design Structure. The Design Structure is
    directly generated by the CAD Assembly. In the Part Structure the engineer can
    have non-geometrical Parts, like oil and glue.

    The Electronic Engineer has also his structure, also defined
    as a Design Structure. The physical Parts should be merged with the Part
    Structure from the mechanical department.

    For the software developers you will have the same
    situation.

    In this case you can merge the Mechanical, Electronica
    and the Software Design Structure into 1 Part Structure, the so called E-BOM.
    The E-BOM can be an 150% BOM to define all the Configurations in one single
    BOM. A lot of companies also define Alternate parts in this BOM.

    Effectivity can be managed based on Date.

    If you want to do some Configuration Management, you
    have to manage several Stadia of the BOM. In your example the Product Lifecycle
    axis.

    For manufacturing I need already 2 Baselines:

    Should Build
    As Build

    In the Should Build Baseline, you have to define which
    parts will be used for a specific configuration. In this case effectivity will
    be based on Unit Number or serial number.

    In the As Build Baseline the alternate parts needs to
    be selected for every configuration.

    Effectivity can only be based on Unit Number or serial
    Number.

    Of course there are some possibilities to make a
    combination of the Should and As-Build Baseline.

    I agree that more companies go from deliver products
    to deliver services. To handle this you need to have control of the product at
    your customers site. To manage this you need to control the As Maintained
    Baseline. The As Maintained Baseline can be created from the As Build.

    For the As Maintained Baseline it is important to keep
    track of all the changes during Operations.

    The As Maintained Baseline is used for the Maintenance,
    Repair and Overhaul (MRO). An important part of MRO is to manage which parts
    has to be replaced after Operation time.

    The changes will be managed based on Unit Number or
    Serial Number, but it is also necessary to control this over time, because you
    need to know when which part was replaced. That brings an extra complexity that
    only can be controlled with Date Effectivity over the Change Management.

    If you look at all of these complexity, it is
    impossible to manage all of this in one single BOM. The complexity described
    here is not only a problem for Airplane Companies, but you can see this complexity
    also at companies who build Medical Devices and Machines.

    I can think of more cases where it is impossible to handle
    the complexity in one single BOM, but that is perhaps for the next time.

    Regards,

    Menk Slot

    http://www.plmconsult.nl

  • beyondplm

    Hi Menk, thank you for this great overview of BOM use cases!

    You’re absolutely right about different aspects of BOM management (you can see some of them in my deck – look for BOM complexity dimensions). Unfortunately, you didn’t attend my keynote. So, “single BOM” paradigm may have two versions – 1/ to think about how to use the same structure to manage all BOMs – eBOM, mBOM, sBOM… ; 2/ to manage different aspects of BOM as an information set that can represent each characteristic of the product – design/engineering/manufacturing/etc. in the way, which will allow data consistency.

    The last one can be promising, but requires a higher level of communication and agreement in organization. It will also raise a question about what tool(s) can be used for that purposes.

    Today, information about different BOMs you mentioned in your comment is located in different systems in a disconnected way, which requires synchronization and data duplication. Ideally, single consistent BOM approach can improve quality of the bill of materials and eliminate duplications.

    A potentially first step in BOM improvement can be done by eliminating EBOM/MBOM duality. In your example it is “should build” and EBOM structure.

    I agree, BOM management is a complex topic and it is hard to find two companies that are doing it in exactly the same way.

    Again, thanks for your comments!

    Best, Oleg

  • Pingback: LIVE BLOG: ProSTEP iViP Symposium 2015()

  • Pingback: [updated May 4th] LIVE BLOG: ProSTEP iViP Symposium 2015 | Daily PLM Think Tank Blog()

  • Melissa Strahl

    I have a question. We are currently using Agile as our PLM tool, and XA (Infor) for our ERP system. In Agile every bom change results in an agile revised bom, however when we push it through our adapter we have to control the bom revisions using dates in our ERP. Does anyone know a good way to control bom revisions in ERP or how to manage the data staying in Sync?
    Thanks
    Melissa

  • beyondplm

    Melissa, the general rule for ERP is to manage BoM via effectivity mechanism. It is true for BoMs and for Item masters (parts). You can consider revision as a sub element of Part Number, but it might not be a good idea in some specific cases.
    I can think about few additional options, but I really need to get more data about the way you manage data. Feel free to reach me out via email – oleg [at] beyondplm [dot] com.

  • Melissa Strahl

    Thanks for your response. I am not sure if you are familiar with Agile but currently we aren’t using the effectivity date fields that are out of the box in Agile, we created a separate “override” date field which translates through our adapter. So for example
    123456 (Assy)
    del 789
    add 987
    In agile when the change is released it will delete the remove item from the assy and add the new immediate for that assy version. When it goes through our adapter (as long as that override date field is blank) it will push the end date of the delete out to 12/31/2016 and add the new part effective from date to start on 12/31/2016. Our planning department plans the new and updates the effective from and to dates in our ERP system. We find this to be flawed because Agile is supposed to be the master but our erp really is driving the dates. However if we out a specific date in that override date field the adapter will make the changes in ERP per what is in that field
    We don’t use revision control in our erp system so I am thinking that your suggestion would be to use the effectivity dates in Agile. that way Agile and XA match. My worry about that is if the date shifts in our ERP system how do we update Agile? the change is released at that time and is locked so we can’t updated it
    Thanks
    Melissa

  • beyondplm

    Melissa, the dirty idea our of my head is to keep “transaction history” attached as an additional field in ERP. It will allow to you to identify last transaction and put there information such as Agile version or timestamp. More fundamental problem is that you don’t keep correlations between ERP and PLM items (maybe I missed that). This is something that transactional adapters are missing, because of their architectural nature. We can brainstorm more ideas if you want :). Best, Oleg

  • Melissa Strahl

    Thanks again for your response. I am not sure what you mean by correlations. We attach EC numbers to all changes which are search able in both agile and XA, they really are identical data with the exception of within agile when you remove a part it removes, and in XA it has that future end date until planning decides when the new part will implement, so there is a “purgatory” for the change once it hits ERP until implementation

Subscription Options:

Subscribe via RSS

Popular Posts

Recent Posts

Archives

Blogroll