Undoubtedly, Bill of Material (BOM) discussions are one of the more compelling topics in Product Lifecycle Management (PLM).   Just try to avoid it at the airport.  Scott Pigman’s latest post at PLM Dojo, Why You Should (or Shouldn’t) use Multiple BOMs  (see what I mean about the airport?) poses some intriguing questions regarding the future of BOM management in the enterprise.  Specifically, with improved tool capability to separate and subsequently align part BOMs (aka Engineering BOMs or EBOMs) to maintain independence over troublesome CAD assemblies, are we headed to a future proliferation of BOMs throughout the enterprise or will that recurring single BOM dream (or nightmare) someday be realized?

Sometimes the confusion runs thick, after all the term “Bill of Material” is an unfortunate anachronism – based on the paper parts lists of the distant past.   Product structure is a more sensible term, but even that can bring controversy.  Regardless of naming shenanigans, BOM separation (explosion?) has been a necessary evolution – because of the inherent differences in understanding a product from drastically different perspectives, be it design, manufacturing and process planning, or service/maintenance.  Hence the invention of EBOMs, MBOMs, BOPs,  and/or SBOMs.  Sadly, someone awhile back missed out on the opportunity to call at least one of these the Fabrication BOM, which could have made the FBOM a standard business term.  Too bad…  Regardless of acronym, the distinct product structures are necessary because of variable cardinality.  In other words, there is not a one-to-one relationship between nodes in each structure.  Most products are designed from a systems breakdown and perspective, but must be manufactured from a more integrated perspective.  For example, one aerospace design might detail a whole aircraft hydraulic system that is broken across all manner of individual manufacturing builds and only becomes a complete system when the aircraft is finished.  Understanding precisely what is the correct relationship between structures is the exercise that is accountability or reconciliation.

It’s important, however, to differentiate that the modern BOM view is not necessarily the ideal.  The federated BOMs are typically what we do today, based on what the tools can do, and how the tools (be it PLM or ERP) have been segregated into their respective niches.  It works well enough, and has proven on average more successful than trying to forcibly carry a unified BOM throughout an enterprise.  However, I don’t think anyone considers that the ultimate solution.  A Doomsday BOM, if you will.  Federated BOM’s suffer from the need for coordination, consolidation, and accountability, which when multiplied over multiple layers of change and disparate data models becomes time-consuming and complex.  Which also means expensive.

What’s been long been talked about is a singular, or more precisely a composite enterprise BOM.  A structure that would belong to no one, but also everyone.  The trick is allowing each discipline the freedom and flexibility to utilize a composite BOM according to their needs without drawing out an explicit requirement for a separate structure.  It’s a vision many consider a pipe dream especially considering multi-headed dragons, but I like to think when properly motivated such a problem might very well be solvable.

But as Oleg Shilovitsky mentions in The Ugly Truth of Multi-BOM Management, the problem is often not the BOMs, it’s the BOMers.  I.e. organization politics, traditional responsibilities, silos, and decidedly marked corporate territories.  As Oleg wrote:

“Technology is easy part, but people are really hard.  This is one of my favorite quotes. The ugly truth of BOM management is the fact it requires people management and agreement across organization. Multiple BOM can be done using separation and data island controlling. Very often you can hear about technological challenges of single BOM organization. Much rare situation is when organization is moving to people and organizational constraints. People’s ego and organizational issues are often playing a key role in decision to go with one of BOM management strategies.”

And with that in mind we get to CAD-Part alignment, which is becoming an increasingly popular way to isolate variability in CAD assemblies from the official engineering BOM, either from discerned organizational necessities, or conflict avoidance.  It’s the sum of all fears: painful cleansing of bad CAD practices and organizational silos erected over the years, some inconsequential and others egregious .  Yes engineer who somehow manages to include the entire airplane in every one of his bracket assemblies, I’m talking about you.

Unlike say EBOM and MBOM, the structure between CAD and EBOM is very closely coupled.  They should be the best of buddies.  Cardinality is consistent and most of the variabilities are exclusions – stuff in the CAD that doesn’t belong in the EBOM and vice versa.  These relationship are quite manageable with certain CAD integrations (NX and Teamcenter for one), but depending on the CAD practice and data history, the transition may be painful.  It’s also true that depending on the combination of CAD and PDM or PLM system, achieving the necessary exclusions and cardinality and being able to verify that it’s correct may range from difficult to impossible.  And that quite frankly is an area where customers of these very systems should necessarily demand more flexibility.  But in the meantime, there’s CAD-Part Alignment.

Think about it as an opportunity.  Could you not bother cleaning house?  Aye.  Unify and you may die.  Separate and you’ll live… at least a while.  And dying in your beds, many years from now, would you be willin’ to trade all the days from this day to that for just one chance, one chance to earn CAD data quality!?  <<a spaceball is shown twirling in the air in slow motion and is planted upright in a cubicle wall>>

What say you, BOMers?