What exactly is BOM Management? Is that the same as BOM Configuration Management? Or product variability management? Or Master Data Management? Or a PLM BOM??? The answer seems to be that it depends on who you ask! BOM management is a tough topic because those words mean something different to each company that I work with. Even within a single company, you could ask different departments and get different answers. So I venture in – knowing this is a topic often surrounded by strong opinions and heated debates!
Which bill of materials management or BOM management solution is best for you? I’ve sat on both the selling and buying end of this discussion, and there is no single answer for everybody. It’s like asking – which vehicle is best?
The answer depends on if you’re hauling heavy loads or trying to get someplace really fast. The BOM management discussion needs to be similar – what is it that you need your BOM management system to do for you? Whether you make paper towels or space ships, at a basic level, BOM management is a critical element that takes you from an idea to a delivered product. To have more detailed discussions about BOM management, we need to establish a baseline of some of the key elements involved:
Part: Managing a part bill of materials, also known as the physical product definition or product master, is commonly the main topic of Master Data Management (MDM) discussions. The part bill of materials is where configurations are defined, parts get registered to orderable configurations, manufacturing effectivities are defined, and where decisions on which parts get bought from whom and where parts will be manufactured and stored. This element of a BOM is concerned with Parts – not designs. It is critical to have alignment between the Design and Part BOM definitions. For some customers, Part and Design data are contained in a single BOM. For others, business drivers require this information to be tracked separately. These and many other factors needs to be considered when discussing Master Data Management (MDM) and where this data should live - PLM or ERP. My colleague, Ashok Krishnamurthy, explores some of these issues in his blog on Master Data Management.
Design: In a design BOM (often called the virtual product definition), mechanical designers and engineering are usually focused on generating the 3D components that make up the product. Electrical engineers construct detailed PCB board layouts, wiring diagrams and component placements. Software engineers convert high-level models into source code. The dynamic nature of this work requires flexibility in how the data is organized. It enables designers to work in structures that are most effective for them. The design BOM is critical to drive effective downstream processes – like DMU, weight roll-ups, parts catalogs, service instructions, etc. The better your design BOM, the better all those will be as well. Check out Amin Kaushik's post on PLM BOM and the Next Generation Design BOM for more information on this!
DMU: Digital mock up (or DMU) refers to the ability to virtually view and interrogate your configured BOM throughout its lifecycle. It requires alignment between the design (virtual) product definition and part (physical) product definition. You'll find some great information about how DMU can be leveraged across the organization in Mark Heinrich's discussion about a visual product experience.
BOM Configuration Management: BOM configuration management is the discipline of managing the content of the product definition throughout its lifecycle. From planning (what options do we want to offer to our customers) through development (which design pieces go together to support all valid configurations) and manufacturing (which configurations can be produced at which manufacturing location). BOM configuration management includes the evolution, maturity, and release of product data. We've gone into more detail on this topic in several recent discussion, including the blog series about product configurator software.
Variability: Product variability is part of BOM configuration management, but I’ve found it’s a topic that often gets a lot of attention, so thought I should call it out. Product variability management is all about engineering a product to offer solutions to meet a range of customer needs efficiently. Let’s use cars as an example. When the automobile first rolled off the assembly line, it came in black. Now, when you want to buy a new car you can go to a web site to “build” the exact car you want – from the color, to the transmission, to the stereo system etc. Companies have to find a way to offer the diversity customers are demanding while still remaining profitable (you can’t build a custom car for every person – but you want them to think that you do!) For some companies, product variability management is more about serving various markets. You have basically the same product that needs to be “tweeked” for different markets. That might include packaging with the correct local language, different components based on regulations or availability etc. Effective product variant management is becoming more and more critical to success.
Architecture: To better manage configuration and product variability, product architectures help to organize similar content across several products. A product architecture provides a stable definition of how your product is broken down and organized, and can be used consistently for similar products or for the same product as it evolves. For many customers today, this product breakdown is simply part of the overall product structure. We’re starting to see more and more that this approach is not sufficient. Different users may have different ways that are best for them to organize the product (i.e. some users may prefer a system-based breakdown, a breakdown based on spatial zones, or one based on manufacturing assembly sequencing). For this additional level of flexibility, the product architecture can be separated from the product content so the product content may be organized and navigated in different ways for different users. Many companies are turning to this approach to help rapidly respond to customer needs and introduce new products quicker.
Coordinated Change: Coordinating product change across various product representations is an issue that is gaining more and more visibility as products grow more and more complex. For example, the scope of what makes up a single change often includes mechanical and electrical design updates, part changes, documentation updates, introduction of a new option or rule, etc. To effectively manage “change”, you have to be able to collect together and coordinate all those pieces. The future of change management blog provides a great view of the importance of coordinated change.
I just noticed that as I am writing this I am using the words “bill of materials” less and “product definition” more. I would go back and correct – I wanted to keep it a surprise! But I think it’s ok – it helps me get to this next part.
To us, it has become abundantly clear that one of the problems that come up when you talk about bill of materials or BOM management is that the scope of what people might mean is so broad. To call all those things listed above “BOM Management” is not sufficient. We’ve collected these capabilities into an umbrella we call the Integrated Product Definition. This is an area where we have been leaders, and it continues as a high priority for us – we have the breadth and depth to address these issues like nobody else can.
This is not a topic I can cover alone! I have recruited some of my favorite product managers to go into more details about all the elements I’ve introduced here. Have you heard us talking about something in this area and want to know more? Let me know and I’ll be sure to include in my list of questions for them!
If you're interested in learning more about this topic, you might consider subscribing to our BOM Management label. Over the next several weeks, we will be digging in to more detail on each of these topics.