This is the third chapter in a series of blogs on End-to-End Product Configuration. To get the full background, you can find the first blog here: What is End-to-End Product Configuration? and the second one here: Is Product Configuration for Everyone?
In my previous blog on the End-to-End Configuration topic, I explained the importance of aligning the front-end and the back-end operating models to utilize a configurable product efficiently. When the front end and back end are aligned, the IT systems can be set up to enable end-to-end configuration. I will use a simple overview of the three fundamental functions of a manufacturing enterprise (Sales & Marketing, Engineering, and Supply & Production) and the core IT systems they utilize that are the core of end-to-end configuration (CRM & CPQ/Configurator, CAD & PLM, and ERP respectively).
There are many possible IT system setups for end-to-end product configuration. In this blog, we will try to give an overview of the core needs and systems involved for the most common approaches.
First, there are two fundamental prerequisites that might look obvious. But due to silos between different company functions and systems, they can cause immense trouble:
A clear data model (or information architecture) with a solid master data approach across all company functions is needed. Each information set should be "owned" by one system only - one system should be the only place to edit (add, delete or change) each information set. Other systems should be read-only slaves for this information set. If the same data must be editable in multiple systems, a shared database for the systems is a way to allow editability from multiple systems without abandoning a good master data setup.
An aligned view on product variance is surprisingly often lacking due to differences in how the assortment is described and treated in the different company functions. Product variance is best described through performance levels, functions, and features from a customer and sales perspective. We call these the Product Properties, and each Product Property has one or several Goal Values. But from a BOM or realization perspective, the variance is created by adding, removing, or interchanging parts. We call them Modules, which are generic, and Module Variants, which are the realizations (components, parts, or sub-assemblies). To make this a bit more concrete, let's look at a practical example.
Imagine a machine that has an infeed that can be electro-mechanical or hydraulic. The machine can come with or without a change device that can also be electro-mechanical or hydraulic. You can combine electro-mechanical infeed with a hydraulic change device, but not hydraulic infeed with an electro-mechanical change device. The choices of functions and features are now linked through this rule of possible combinations. When changing infeed and change device, not only the primary functional parts are impacted. Cabling and piping need to be adapted as well as the control and hydraulic supply systems. The Product Properties with their Goal Values and the Modules with their Module Variants thus must coexist, and the constraints can be described in a matrix format like this:
If we lack this synchronized view across the organization, end-to-end configuration, seamless or not, is impossible.
On top of these two fundamental pre-requisites, there are six critical questions of principal nature that will have different answers for different companies:
The first three are on the system level, and I will explore them in this blog. The last three are about the data structure, and I will take them in the next and final blog about end-to-end configuration.
To answer this question, we must first acknowledge the balance between functionality and simplicity of integration. We always want to involve as few systems as possible but maintain the functionalities needed to remain efficient externally and internally.
If all the flow can be incorporated into one system – typically an ERP system with configuration capabilities – that will allow the simplest set up with the lowest system maintenance cost over time.
This simple setup is mainly used for product-based front ends when the configuration function practically is a selection tool for already predefined fixed products.
When the front-end is configuration-based, the complexity of the configuration model typically increases in a way that will make it hard to find an ERP system with out-of-the-box capabilities that can deliver all mandatory and desired functionality. Some of these complexities may be pricing models for different channels and markets, brand constraints, sales packaging for different markets layered on top of what is technically feasible to configure. Companies with a configuration-based front end will likely have to turn to specialized Configurator providers to find a system with the mandatory and desired functionality at a competitive total cost (cost of IT systems and integrations, cost of configurator maintenance, cost of lost orders, cost of indirect labor, cost of product development, cost of direct labor, etc.)
The second most straightforward setup is when an external configurator can communicate directly to the ERP.
This setup can be used only for true Configure to Order. All orders placed in the configurator are fulfilled by configuring already designed parts. Since the information flow is not passing through the engineering systems, we have no chance of customizing the BOM.
Another thing to evaluate is the need to maintain each delivery's BOMs for aftermarket needs, like service and upgrades. Depending on the complexity of the product and its lifecycle, this may require PLM functionality.
To conclude, this simple setup can be evaluated for product-based front-end companies with complex configuration model requirements or configuration-based front-end companies with a complete platform back end. We must add that to the picture for all companies that need PLM functionality in the information flow.
The third setup includes PDM/PLM in the flow to make sure that there is also an EBOM created for each configuration that can be managed according to requirements from aftermarket, regulatory, or other perspectives.
On top of creating the EBOM, modifications can be made for order-specific or customer-specific parameters.
This setup is flexible and applicable for back-end cases where a new BOM is generated for each order, both for configuration-based and project-based front ends. However, since CAD is not included in the flow, the amount/complexity of Design/Engineer-to-Order is implied to be limited. When parts of the product must be tailored to the specific case, there may be a need to integrate CAD in the information flow.
This setup is the most complex but also the most flexible. The illustration below shows an example with CAD bidirectionally integrated to PLM:
The integration between PLM and CAD enables a much more efficient synchronization between the Engineering Bill of Material and the geometric representation (3D models, diagrams, etc.) from which the drawings are made.
This setup is needed for back-end operating models creating a new BOM for each order when there is a significant amount of design/engineer-to-order. This can be true both in configuration-based, and project-based front ends. Although complex, many companies already have integrations between CAD and PLM, which can also be used for the end-to-end product configuration case.
The fifth setup is specifically for products with a predominantly geometrical configuration problem. The setup enables product configuration from within the CAD environment. It requires a CAD system with a Configurator plug-in (a.k.a. Design Automation) and CAD models set up to allow them to be configured by non-expert CAD users.
The seamless end-to-end flow is illustrated as sequential between systems in all previous visualizations, but this is not always necessary or even the best way. Of course, this is only an issue if three or more systems are involved.
The sequential setup means that the systems are put in sequence.
But if your product is completely stabilized, also known as full Configure-to-Order, systems can be put parallel.
With this setup, you are getting both a configured engineering representation (EBOM) and manufacturing documentation (MBOM) simultaneously.
A significant downside of parallelization is handling changes. With late changes, you may need to re-run the process from the start to get an updated, correct, and synchronized EBOM and MBOM. The other option is to manually update one of the BOMs and then manually synchronize. This decreases efficiency and quality due to the risk of failing to update the second system correctly.
The main advantage of the parallel setup is that parallelism is always less sensitive. If one system or integration is inoperable, it doesn't necessarily stop the entire flow. It can also result in simpler and cheaper system integration.
Bidirectional integration for an attribute or object is typically only needed if a good master data approach is lacking. If the same attribute can be edited in multiple systems, robust and fast bidirectional integration will be a must to stay up to date in all systems. A simple example is a case where the material cost of a component can be edited both in PLM and ERP.
Bidirectional integration across different attributes or objects, where each item is unidirectional, is more commonly needed. This need typically depends on the targeted level of functionality in the end-to-end product configuration setup.
This way of transferring data between two systems in two ways but keeping strict master data management is typical for a good master data approach. Some examples:
In this blog, I have given an overview of what IT systems are needed for end-to-end product configuration and how the order information flows for different cases of front-end and back-end operating models. Choosing the proper setup is a task that needs careful considerations to find a feasible path ahead, balancing performance and flexibility, to cost and risk.
In the next blog in this series on End-to-End Product Configuration, I will dive deeper into the next three principal data management questions within the end-to-end process: BOM restructuring, on-the-fly product structure creation, and product master models. Thanks for reading!
In my fourth and last blog in this series, I will focus on Product Master and BOM Structure for Product Configuration. 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.
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.
Principal, Manager & Partner
+46 8 456 35 00
alex.ginsburg@modularmanagement.com
LinkedIn