As I have mentioned previously I have a 10 year old son. Having a ten year old son affords me the opportunity to watch cartoons with him without raising suspicions that I am a grown man with adolescent tendencies. We have watched a fair share of Clone Wars. In my opinion Clone Wars is a muddled mess with a questionable timeline especially when compared to the 6 Star Wars Movies. Much like Clone Wars BOM Wars is a constant conflict with confused foes and shifting battle lines. After my last article, The PLM State: The Balancing Act between PLM and PDM, and the following discussions about product data management (PDM) and product lifecycle management (PLM), I felt compelled to discuss the derivative engineering Bill of Material (EBOM) usually created in PDM tools or directly from CAD data and how different PLM tools allow for the transformation of this information into a more useful manufacturing BOM (MBOM). What I have realized after doing a little research is that this seems to be a pretty sensitive issue and a number of famous PLM bloggers have already weighed in on the topic. I hope to provide a more focused discussion specifically on the issues that occur as companies commit to leveraging information from engineering to create their initial BOM's in PLM. Most of the companies I have worked with that decide to leverage engineering data for BOM's begin the transition with misconceptions and have to adjust their expectations and methodologies to allow for the realities of using engineering data in a process that involves a larger and differently structured product map. I will also leverage the hard work and valuable thoughts of previous authors to provide you with a helpful perspective on the longstanding conflict between EBOM's and MBOM's and how middle ground can be found in the PLM environment.
As with any complex discussion, it is important to define the terminology to make sure everyone understands the frame of reference. I found a helpful article titled "PRODUCT STRUCTURE AND BILLS OF MATERIAL", adapted by DRM Associates from the CONFLOW Project that defines things quite well and really outlines the key issues around maintaining separate EBOM's and MBOM's. I particularly liked this sentence. "In theory, the BOM can and should be produced automatically by the CAD system but in practice there is usually human intervention or even re-entry." I think that sums up the status quo quite nicely. The article continues about the reasons for human intervention and re-entry centering on an inability to push information back to the design system which is not really a true or a valid reason and the need in manufacturing to produce different structures which address needs for mass production and efficient purchasing which is a key reason for maintaining separate BOM's. The article also provides some interesting graphics highlighting the differences between the two types of BOM's. It is difficult to know when this article was actually published but it definitely is non-partisan and spells out an unclouded vision of the issues around using EBOM's in the enterprise.
A more biased perspective is presented in a white paper from Arena titled, "The Manufacturing BOM: Critical for Successfully Building a Product". Arena is a software as a service (SAAS) PLM vendor that has very little to offer from a CAD integration perspective and based on their model would prefer to just manage metadata. In spite of their obvious slant to justify the capabilities of their application I think Arena does a very good job of summarizing the challenges around the EBOM. The article brings up a very good point that not only do most EBOM's lack the level of detail necessary to satisfy most manufacturing organizations but there also may be multiple EBOM's for one product. They also acknowledge that the level of detail required for a MBOM would be impractical for a design engineer to address. This sentence captures the issue quite well, "Mechanical BOMs commonly list printed circuit board assemblies (PCBAs) as a single item because adding hundreds of tiny components is tedious, slows work on the CAD model and adds little value to the mechanical design process."
Chris Williams in his blog, The Vuuch Voice disputes the idea of multiple BOM's in an article titled"Da BOM is Da BOOM". He claims everything is really done in Excel. I think this may be an oversimplification but I am sure Excel still lurks around helping people communicate outside of PLM. The things I like most about this article are the links to so many other great articles on this topic. Chris obviously put a lot of thought into his article and spent some time researching it or just happened to write it after a cluster of other good articles on the topic. Chris is really trying to get beyond the tools and capabilities and address how companies really work to get product developed and I think it may depend on what capabilities your PLM system offers. Each major PLM system handles the multiple BOM issue differently. The question that I think is raised by this article and the links to the others is how many companies really start out developing product structure in their CAD systems versus building it out in other tools and then using the CAD system to populate the structure with design data? Is it realistic to expect that a structure created in a CAD system is really representative of the structure needed in the PLM to manufacture the product? Are you potentially hindering the productivity and the capability of the PLM by building it around the CAD data?
In the end I think the middle ground is always best in these discussions. I do not think CAD data is the "be all end all" of product structure. But I also think there is inherent value in a system that can reconcile CAD/EBOM's to the MBOM and systems that offer this capability have an advantage over those that do not. This cuts both ways. Systems that are geared towards CAD can be just as hindering as those that offer no provisions for leveraging CAD. Having tools and structures that can import CAD information while offering interfaces and structure for creating BOM information from scratch or modifying EBOM's is critical. From my observations most of the PLM vendors grapple with this issue in numerous ways. Some offer the ability to create different types of views of BOM's based on roles. Others allow for the EBOM to be imported and changed while maintaining links to the original EBOM. Variant and site support also allows some capabilities for maintaining links between different types of BOM's and many companies customize their PLM tools to accommodate their need for different types of BOM's that are still interrelated. I think this is an area that all vendors need to improve to better impact product development and to finally banish Excel to the dark corner where it belongs. The ideal feature set is an application that can import CAD information from PDM or directly from the CAD system and allow it to exist in this state but also be referenced and manipulated for the MBOM. The system should have a good set of BOM creation and editing tools and allow for product structure to exist independent of CAD data. Sometimes companies create the structure first and sometimes it is derived and a good PLM system needs to support both of these types of use cases. So maybe one day we can end the BOM war and the need to label BOM's as EBOM's or MBOM's and have PLM systems that can seamlessly meld the two together. Just think, peace in our time, maybe it's just a dream but I think several of the vendors could make it work if they really listen to the customer's needs.
[Edit: Repost from 2011]
