Social Product Development

Tuesday, March 23, 2010

"Da BOM is Da Bomb" Or Unlocking The Value in Your Bill of Materials

Ok, I know...too much slang? But I couldn't pass up the alliteration or the homonym.

I’ve been thinking about the BOM (bill of materials) a lot lately. There is practically a religious war going on about the BOM, and it’s been going on for a long time, most notably, when PLM really started to take off. The question on the minds of most CIOs is “Should the BOM be owned by PLM or ERP?” After all, they likely spent significant time and resources deploying ERP….and then came PLM to muck it all up.

There are many types of BOMs; the engineering BOM (eBOM), manufacturing BOM (mBOM), and service BOM (sBOM), just to name a few. My colleague, Tom Shoemaker, wrote about this in a recently posted article in Time Compression. Best practices suggest that the best way to create these BOMs is through an associative transformation. Transforming the eBOM into the mBOM and the eBOM into the sBOM, while maintaining an associative link, ensures that changes made in one can be incorporated into the other. Note that BOMs may be generated in many different ways, depending on the type of products your company creates, for example configure-to-order, build-to-order, or engineered-to-order. Jos Voskuil does a nice job talking about this in his blog.

When you consider the BOM, it is so clear that it is jam-packed with valuable information and relationships. I don’t simply mean just the mechanical CAD content and electrical CAD content. But also engineering calculations, manufacturing information, service information, associated documentation, and analytics information about the product like chemical makeup, cost, weight, reliability, etc. More importantly, the relationships between and among the content is extremely valuable, informing why certain versions are being used or have been changed (as indicated by the associated engineering-change-order (ECO)). There is even greater value to be had by digging into the metadata, or “the data about the data,” that is naturally tracked in the BOM by PLM.

Who worked on what, when, and why did they do what they did? The PLM-managed BOM answers this important question. That’s one of the main reasons companies originally explored PLM in the first place. Now imagine using the BOM to find people who can help you answer your questions, innovate with you, and make recommendations. The BOM could actually recommend the right people to talk with based on their history with the BOM.

But it doesn’t stop there. So often people set up their profile (whether in a social network or a company directory) but never think to update it when things change. Say you changed jobs within your company. You’re still a mechanical engineer, but now you are working on an entirely different product for an entirely different industry or geography. Based on your new work and activity, the BOM to which you contribute could recommend that you update your own online profile in the product development system. How about that? Now different colleagues can find you to tap your expertise. And since you’re new to this role, you can find the people who’ve got experience with this industry sector.

The point: there is much more value to be derived from the PLM-managed BOM than was ever conceived of initially. And social computing technology is the key to unlocking it. Marrying social computing to the BOM leverages the inherent relationships and is a core capability of social product development. It's what sets it apart from general social computing and Enterprise 2.0. It's the special sauce.

I look forward to hearing your thoughts on this subject!


  1. Robin interesting thought to combine the BOM with social networking, and I guess I understand where you are aiming at. It is an area full under discussion for the PLM 2.0 concepts.

    As most of my customers are in the before PLM 1.0 world, the main message I try to convey is that the BOM in all its appearances is the central information carrier for a product.

    eBOM/mBOM/sBOM are just different views on the same product. Now the big challenge for every mid-market company is to agree cross departmental on this approach, as currently everyone has his own domain, engineering the eBOM, ERP the mBOM and people are used to work disconnected and optimize only their department

    On the table of the CIO is mostly the question, do we need a PLM system because we already have CAD and ERP and we remember the impact and pains of implementing these systems

    Success with making the BOM more social


  2. Jos, thanks for the feedback. I agree with you on your point that the EBOM, mBOM, and SBOM are different views of the same product, but each tailored for a specific purpose. And I agree the BOM carries tremendous value as the only complete definition of the product.

    One of the key points I try to make here is that these BOMs all need to be associatively linked since they are a function of each other.

    Finally, one area that has not been explored deeply is this concept of leveraging the inherent social connections of the BOM.

    It's a very exciting time for PLM. I look forward to more discussion.


  3. Very interesting. So a person would be an entity in the BOM (or within the meta data). I think that this is a interesting consideration. Now I could be wrong in where you are going with this but lets take for an example a feature in a model and that feature was done on for example Joe's computer and can be assumed done by Joe. Because that feature was done on that computer it is in the metadata and therefor inherently some of the data in the BOM or PLM system. If I could use that data based on that computer I could find out what Joe has been working on and when. Or even a time line on what was designed and when and one could postulate the design intent. This could be critical information for me should anything happen to Joe and he would no longer be with us. Basically it may be another level of BOM or a new BOM to work with. SocialBOM?

    So lets take this one step further and we can have someone tag or flag a item or even better a feature in the model of a part inside of the BOM and put out a question to others in the 'SocialBOM' related to the item for assistance. This would save one from going to one person for help to be told that it is not something they can help with and to go try someone else. It would act as a APB and the appropriate person would likely step up to the plate and help out.

    A potential problem with this is that I could see is creating a firehose of info for people on a project to deal with.


  4. Ben, yep, you got it right. The BOM is already keeping track of who did what, when, and why. Using that information, or the SocialBOM as you called it, to find the right people that can help you should make your job easier.

    I don't envision a fire-hose of information. But rather more of an on-demand model. Where you make the inquiry when you need information. Though, as I mentioned above, the BOM could make recommendations for updating your profile based on your activity in the BOM.

    Expanding this idea to communities of practice (as described by my colleague Greg Marin in his blog by the same title, the BOM could play a significant role in proactively recommending people to join or invite to the community. This could be people in your company who do similar work but in entirely different divisions. wWuldn't it be great to connect them so they can share ideas?

    Ben, thanks for your comments. I look forward to more discussion.


  5. Robin, I think BOM already contains all information for "socializing" - However, the biggest problem, in my view is trying to split Bill of Materials between various domains - PLM, ERP, ....
    You can see some of my additional thoughts about BOM - Best, Oleg

  6. Oleg,
    Thanks for the feedback. I agree with much of what you said in your blog.

    I think the real key here is this concept of BOM transformation or BOM associativity. Similar to CAD, where there is one part model and the assembly, drawing, NC files, etc., point to (or reference) that model, maintaining an associative link, the BOM has several views derived from an initial view, typically the eBOM. That's not to say that other views will use the exact same content. In fact, the mBOM and sBOM will necessarily require additional parts and materials that may not appear in the eBOM. And will necessarily be configured differently.

    True associativity as seen in CAD is not necessary with the BOM, in fact it's not preferred. Companies don't want changes rippling through BOMs uncontrolled. They want tight configuration management to govern the application of changes. But the link between these views is key to:
    1. providing visibility when a change has been made and the points of impact in the product (and all realted BOMs)
    2. preventing or introducing quality issues,
    3. speeding time to market so that manufacturing and service can begin their work before engineering RTM's

    Have a great weekend,

  7. Hi there, awesome site. I thought the topics you posted on were very interesting. I tried to add your RSS to my feed reader and it a few. take a look at it, hopefully I can add you and follow.

    Product Development