As always, your blog posts inspire interesting debate! I’ll attempt to take off my “Arena hat” for awhile to consider the question more broadly. I’ve worked for numerous PLM companies to date, and each had a unique view on the problem.

In the PLM companies whose primary focus was MCAD, the BOM was always a secondary concept. For them, PLM primarily was focused on driving 3D data to all corners of an organization. Other engineering disciplines where often an afterthought to these providers. These PLM systems were best suited for mostly mechanical companies. Automobiles and aircraft were the strong areas for their PLM deployments (and with good reason!). These companies may have printed circuit boards, or software designers, in their product, but that particular discipline would be outsourced to a vendor or it would be a minor part of the development process that could easily be segmented onto an island.

Other PLM players take a more general view of the matter, and don’t focus on MCAD alone. Companies like Agile and Matrix One (Arena fits here) focus on integrating the needs of multi-disciplinary design and sharing that information with others. There may be PCB designers, MCAD users, software developers, artwork designers and many others involved in the product design. High tech electronics, consumer goods, and medical devices come to mind here. For these companies, management and delivery of MCAD data alone will not suffice. They must capture all the design information from each of the entities, organize it in a logical way, and then manage the approval of this information prior to release to ERP. In these companies I would contend there is no way to capture all the information without a centralized BOM in PLM. Each entity may only be contributing to “their” BOM, but a global BOM is needed for release control of the full product.

OK, so that was pretty long winded. In short, I think a BOM-less PLM can work in mechanically focused companies. There still are questions of data effectivity, dispositioning prior to release, and 3rd party data to consider (think compliance, etc), so a pre-ERP BOM would likely still be wise. For companies involved in designing products across many departments and disciplines, a pre-ERP BOM is an absolute necessity.

For me, the real debate is to when/where a eBOM (engineering BOM) becomes the mBOM (aka pBOM, the manufacturing BOM). Some say the mBOM should only exist in ERP. I disagree, but that is a topic for another day!

best regards,
yoann

If your answers are the same as my company (Engineering, PLM, and YES), then the BOM should be controled in the PLM system. The first two questions are fairly self explanatory. The last question is typically less understood. For 3D models to flow and be used through the value chain, positional information, alternate geometry, simplified models, etc must be integrated into the BOM. ERP system are not designed to manage this information.

So,for me the PLM should manage/control the BOM in the context of the sale options or feature codes and pass this information to the ERP system to take orders, manage demand, control the movement of materials, and doing the accounting functions.

To end it I have a quote that I read somewhere,

“Power tends to corrupt; absolute power corrupts absolutely.”