This is the fourth chapter in a series of blogs on End-to-End Product Configuration. To get the full background, you can read the first blog here: What is End-to-End Product Configuration? the second one here: Is Product Configuration for Everyone? and the third chapter here: Enterprise Architecture for End-to-End Product Configuration
Bill of Material for a Configurable Product
A key activity in any product configuration process is the creation of the Bill of Material, commonly referred to as the BOM. For traditional, static products, a BOM is generated once for a product, saved, and re-used. This BOM is static in relation to an order, it is completely prepared in advance and unchanged for the specific order. Suppose all possible combinations of products can be prepared in advance. In this case, a static BOM could also be used for configurable products. However, we can’t say that it is truly configured – the configuration process selects a product from a predefined catalog.
For a truly configured product, a BOM for the product is generated after the product has been configured. This Dynamic BOM can be handled in multiple ways, depending on complexity and system setup. Many systems are only capable of using a so-called Super BOM, which is a BOM that has predefined rows for all possible configurations. However, as I explain further in this blog, this way of working is not always practical for end-to-end product configuration. Different stakeholders in the process may have different requirements on the BOM structure.
Different ways to generate a BOM for a configurable product
Need to Restructure the BOM
When setting up seamless end-to-end configuration, one crucial aspect is defining the need of restructuring the product structure for different purposes. Different functions, such as engineering and manufacturing, have different needs and reasons for organizing the product one way or another. These needs typically result in the creation and maintenance of different BOMS, called E-BOMS (Engineering Bill of Material) and M-BOM/P-BOM (Manufacturing or Production Bill of Material). Some of these needs and reasons as you will see in the list below are not so strong. However, there are often enough of them to make it impossible to have the same structure throughout the entire value chain.
- The configurator needs a logical structure where logically-connected things – things that exist or don’t exist or vary for the same reasons – are grouped and turned on and off or changed together as a group.
- Engineering needs a functional and/or locational structure where expert teams develop functional systems and sub-systems, collisions between parts are eliminated, and assembly, maintenance, and service operations are enabled by design.
- Manufacturing and supply chain need a flow-oriented structure that reflects how the supply chain is set up. There is a specific item (part or assembly) for each purchased item and any manufactured or pre-assembled items outside the main assembly flow. This way, purchasing, and internal production orders are created and reported as done.
A dynamic Super BOM is configured and then restructured for Engineering and Manufacturing. Each restructuring operation needs a transformation function that needs maintenance and validation.
The need for restructuring a BOM, of course, is a function of the number of systems in the flow (see the illustration above). If you only have one system, there is no need for restructuring. However, you will have significant challenges to fulfill the needs of all the functions. With more systems, you can easier fulfill the different needs but at the cost of more restructuring.
Dynamic BOM: Modular or Predefined Structure?
This question refers to how the product structure is created in each downstream system. There are two distinctly different ways of approaching this.
In the first way, called a Modular BOM, the complete structure is not prepared in advance in the receiving system. The receiving system only knows items in the structure but not how these items are arranged in the structure. You could say it knows the bits and pieces but not the hierarchy. 
In the second way, also known as a Super BOM, a structure is predefined in the receiving system. The receiving system already knows the complete structure.
The Modular BOM has a clearer master data structure than a Super BOM and less effort to maintain and update multiple structures. The product structure is managed and updated in only one place. However, there are a couple of other aspects that must be considered:
- In most cases, a Modular structure has a higher cost of developing the integration between systems. This is especially true with systems that are not prepared for handling a Modular BOM.
- Some functionality in the receiving system may require knowledge of the product structure beforehand, such as CAD objects mapped to the structure.
- The need to restructure also matters:
- With the Modular setup, restructuring does not happen within the integration of two systems. It must happen inside one of the systems, typically the upstream system. The upstream system must have the capability to manage its structure and manage a second, restructured hierarchy in the downstream system.
- It is possible to have a different structure in the downstream system than in the upstream system with the predefined structure. The integration between the systems puts the right items in the right place in the downstream system.
If your systems and your required functionality allow it, the Modular BOM approach is likely to have the lowest total cost over time. However, there are some systems or functionality requirements that don’t support this alternative. In those cases, the second-best alternative is to use one system as the master for the product structure and transfer all changes from that system. Manually trying to keep multiple structures updated and synchronized is not advisable because of the high workload and quality risks when multiple systems are not aligned properly.
How to Organize the Product Masters
First, what do we consider as a Product Master?
Seamless end-to-end product configuration cannot happen ad-hoc. Each process step needs to be well-prepared and based on templates. We call these templates Product Masters.
In Sales, a configurator using a configuration model is often the best solution for companies aiming to target each customer’s specific needs with a unique solution. For a truly configured product, you also need a master for pricing. If you want to have good profitability control, you will likely need another master for costing. There might even be a need to have a master for delivery time. Most of these functions could be solved in a single configuration, but, due to legacy or special functional requirements, several systems are likely already being used.
Engineering and manufacturing typically also need multiple Product Masters for seamless end-to-end product configuration.
As stated earlier, you should use as few systems as possible to simplify the integration between these. The more you can solve in one system, the better it is from an integration point of view. But, as mentioned, legacy and special functional requirements often motivate multiple, specialized systems.
Seamless end-to-end product configuration is not only about connecting systems. At the level of information flow, it is about connecting the different product masters. And you quickly conclude that you need many Product Masters. That is a lot of models to both build and maintain!
With Product Masters specific to the platform and functional need, the number of models can be overwhelming
However, it may be unnecessary to have specific masters for each platform and function.
First, in the front-end sales configurator, you should only have one master for all “interchangeable” products. As a customer or sales representative, you absolutely don’t want to abandon and start over again in a new configurator, just because a tiny change in required performance creates a need to switch from master 1 to 2.
Second, you should always try to minimize the number of Product Masters per function. This minimization reduces the effort to create and maintain masters, and it simplifies the integration and synchronization along the flow of systems. A genuinely modular product achieves this by harmonizing product architectures and optimizing re-use of parts across a wide range of products.
Ideally, after harmonizing in both the system dimension (horizontally) and the product dimension (vertically), your future Product Master setup could look something like this:
Harmonization of Product Masters in the system and product dimensions can simplify both creation and maintenance.
Finally, try to minimize the number of Product Masters by merging:
- horizontally cross-company functions and systems
- vertically cross a larger scope of end products.
For End-to-End Product Configuration to be Successful, the Back End Must Match the Front End
This is the fourth and final chapter in this blog series about End-to-End Product Configuration. A key aspect is deciding how to sell the products in the front-end, matching with a back-end of systems to work in an efficient way. Working with static products in the back-end while selling unlimited variance in the front-end is a recipe for disaster. If you can match a flexible front-end with a back-end that is set up to seamlessly handle end-to-end dynamic BOMs, product variance can become a true competitive advantage.
I hope you have enjoyed reading these blogs as much as I have enjoyed writing them. If you have any comments or interesting discussion points – get in touch!
Talk to us about Product Configuration!
Over the past decades, we have focused 100% on helping businesses worldwide improve their product configuration and configurability.
We are always interested to hear your story and discuss how you can improve from where you are, let us be your sounding board and reach out to me today.
Alex Ginsburg
Principal, Manager & Partner
+46 8 456 35 00
alex.ginsburg@modularmanagement.com
LinkedIn
