Why BOM Management Is Complex?

Why BOM Management Is Complex?

bom-complexity-manufacturing

My last post about Manufacturing BOM raised few interesting comments online and offline. One of them by Jos Voskuil  was pretty straightforward – “What is a big deal about MBM”? Jos pointed me on his earlier post – Where is MBOM? This post as well as few other articles I posted earlier – Why companies are not ready for single BOM? and BOM 101: 5 Don’ts for BOM management made me think why BOM is so complex. I wanted to share these reasons and ask your opinion. Here are my top 3 list of issues that are leading to significant BOM management complexity: 1- Items/Parts identification; 2- Views; 3- Synchronizations. Let me go and explain more specifically what I mean.

1 – Item / Part Identification

Item Master. Item. Part. Assembly. Product. You name it… But whatever you call it, you come down to the way (and format) to identify Parts. Part number is probably the simplest wayto identify things in product design, manufacturing and support. The next question – what Part Number? Things are simple only on the surface. As soon as you dig inside, you find yourself surrounded by manufacturing part numbers, design parts, suppliers part numbers, support parts and many others. The information about them resides in multiple data databases, spreadsheets and systems.

2- Views (or Product Views or BOM Views)

You may think about bill of material as a list of parts and everything else you need to make a product. However, very fast it gets complicated with product configurations, manufacturing information, suppliers,  As-built BOM and maintenance parts. To differentiate and manage all this information is not a simple task.

3- Synchronizations.

As I mentioned before, bill of material information (multiple BOMs) are usually managed by different systems. Often (in case of PLM) multiple BOMs are managed by PLM system itself. Now think about change processes and updates. Each one generates a sequence of updates and dependent operations that needs to be done to synchronize BOMs and keep them in a consistent status. Indeed, one of the most complex tasks in BOM management.

What is my conclusion? BOM is not simple thing as you might think from the beginning. To keep system in sync with diversity of data and processes takes time and effort. Variety of product development and manufacturing approaches, global deployment, etc. How to overcome the complexity of BOM management? Look forward to learn about BOM management complexities you are facing developing and implementing BOM management solutions.

Best, Oleg

Share

Share This Post

  • PERASSO Gregory

    For me, Synchronisation deals mainly with Configuration Management. And notably Change Management and effectivities …
    In traditional manufacturing companies. Change and effectivities are only managed (as mBOM) in ERP. But how to control that the Product we build is the one we have design if Change and effectivities are not cross systems (PLM AND ERP – from eBOM to mBOM … and xBOms)

  • beyondplm

    Gregory, thanks for your comment! Yes, synchronization is clearly related to configuration management. In different companies it called differently, at the end of the day it comes to effectivities and changes. Product configurations can be also management outside of ERP and MBOM (depends on the situation).

  • pgarrish

    The complexity you talk about is certainly not new Oleg, it’s just that we want to put it all in one place now and it shows up all the flaws in processes and working methods that have been around for years. Plus, as we try and put these processes in PLM, we try and police them – so the little shortcuts and workarounds that kept things moving in the past no longer work – and PLM gets blamed for screwing it up. Simple example – planning need to revise a part to change (say) a condition of supply. They used to manually rev the part in their system and send a chit to manufacturing who manually updated their system. Now it’s all managed in PLM and sent to ERP via an interface – so its a part revision like any other… it takes too long, costs too much and everyone moans. The fact is, it always took time and cost money, but it was hidden and spread around (design spent nothing, but manually tracking the change cost someone).

  • beyondplm

    Pgarrish, you are absolutely right! We apply policies and strict rules that absolutely needed. However, in many situations (and thanks for this brilliant example!) we ask people to pay the price in reduced efficiency. I’m expecting few folks disagree and say that this is a tax for process organization. This is true, however, this is the place where future PLM innovation should be applied to make it easy.

  • pgarrish

    We have to be careful talking about ‘reduced efficiency’. Taking longer is not necessarily less efficient if the job is done to higher quality. My suspicion is simply that we bring all the costs together and expose them – they were always there (and in many cases, they were a lot higher than had been admitted to) but they were hidden (accidentally or deliberately).

    I have seen a lot of examples where the desire to ‘fast track’ simply mortgages the problem (with interest) to further down the process. Skipping 3D modelling for manufacturing changes to turn them around faster, but causing ongoign designs to fail as the virtual mockup was now inaccurate.

  • beyondplm

    I think “longer” is probably wrong way to say that. The point is that information access /data exchange, etc. should be supporting decision making and real time activity. In other words, if design alternative depended on some information that become available after long transaction between PLM and ERP happened, we can be in the situation when it “too late” to decide. It is like slow GPS navigation at the moment of time you need to exit highway. Without information, you take any decision and need to manage rest of navigation based on the decision you took blindly. At the same time, your example with “skipping 3D model” is a perfect one to show that opposite is also true. So, information and processes should be adaptive to real decision management needs.