How to Achieve End-to-End Configuration
At Configit, we define end-to-end (E2E) configuration as the complete product lifecycle through the following four phases:
- Engineering, where a product is engineered and designed.
- Sales, where the product is configured, priced, and sold.
- Manufacturing, where it gets manufactured, delivered, and deployed.
- Service, where the product is serviced, upgraded or decommissioned.
An end-to-end configuration approach ensures a smoother process across these phases by providing a consistent view of the product offering throughout the enterprise.
For example, when servicing a product, it’s important to have an up-to-date and detailed understanding of its configuration and install base to service it, replace parts, or upgrade it to add new capabilities.
Changes to engineering or legal requirements is another common challenge that influences the configurations and variability of the product and have to be reflected across all functions.
How do you manage such a change throughout an organization in an efficient manner without it taking three months to propagate?
A Local Event with Global Impact
Several years ago, a tsunami in Japan destroyed a factory that was manufacturing a particular orange paint color. This unforeseen event meant that they couldn’t sell cars with this particular feature of orange paint and would have to stop that order intake.
In this case, it also affected many different sales configurators and websites, including those of dealers and resellers. It would be very difficult and time consuming to update multiple systems with the information that you can’t sell this particular paint color in a certain timeframe.
How do you manage such a change throughout an organization in an efficient manner without it taking three months to propagate?
See How Configit CLM Approach Can Fit Your Needs
Our experienced Configuration Lifecycle Management (CLM) specialists are ready to show you the benefits you can achieve.
For companies that want to achieve end-to-end configuration, Configit’s approach is comprised of three steps:
- The first step is using consistent language across the organization.
- The second step is separating the physical representation of a product from a more logical one.
- The third step is ensuring good integration between the systems.
Step 1: Global Feature Dictionary
Configit uses a global feature dictionary to ensure consistent language across the organization, enabling everyone within and outside of the organization to use standardized codes to describe product variants.
Many organizations think of product variants in terms of parts, or combinations of parts, and use that to create a system. However, if the goal is to excel at handing multiple variants, this is not a ‘best practice.’ We recommend ‘abstracting’ from the parts to use what we call ‘features’ that represent the capabilities of the product.
Having a standardized way to talk about these features across different products and across the organization is essential. For example, a company that deals with electrical products and components should only have one code for a particular voltage. Using different codes for the same thing makes it very difficult to combine two products into one or communicate across the organization.
These feature codes are the key in linking the different functional areas of the organization, not the part numbers and the Bill of Materials (BOM). For example, see below the picture of a little piece of paper which comes from a car. All those little codes at the bottom half are the feature codes. With this paper an engineer at the car factory would be able to tell exactly what parts, features, capabilities, color, and seats the car has. That’s the key information that you need to have when you are communicating across the different aspects of the organization.
This is similar to what we call a feature string. Using a feature string, you can derive different information, such as different types of bills of materials, maybe a product code, the printed documentation, and a 3D CAD visualization. The feature string, or configuration of the product, is the DNA of the product.
Step 2: Physical vs. Logical Representation Product Models
The next step is to separate the logical concept of the variability of the product from the physical one which includes the part numbers and the actual bill of materials.
If you define a product model for the product, you can use this as a communication tool across the different functional areas. Using the product model you can analyze the variability of the product, optimize the feature offering, or combine the model with statistical information to determine probabilities of parts being included in a configuration.
Because the product model is a key element that ties the different functional areas together, it is placed in the middle of the diagram. The four main areas supply information to the model representing their perspective:
- Engineering: specifies technical and legal rules that ensures that the product will work and is legal.
- Sales: provides commercial rules such as country standard features, packaging of the different features, guided selling, and mapping the high-level requirements down to the more technical features, making it easier for the customer to configure the product.
- Manufacturing: defines rules dictated from the manufacturing process, e.g., that certain features require specific manufacturing steps.
- Service: may further specify rules about how a product may be upgraded or serviced.
So, all of these different rules are going into a single (per product) centralized model that becomes the heart of a solution.
Step 3: System Architecture
System architecture refers to how different systems within a large organization get an aligned view on the variability of the products. The three key systems are:
- PLM: where engineering and CAD work is done and the bill of materials is defined.
- CRM: which contains commercial aspects, such as opportunities, accounts, and quotes.
- ERP: contains the manufacturing aspect of executing and manufacturing each individual order.
The key to achieving alignment is to make sure that all of these systems share the same source of truth with respect to configuration. Each of the systems typically has some kind of configuration capability, but only covering the aspect of the world which that system represents. Placing all the rules in one system, and then integrating from these enterprise systems to a centralized configuration engine, is the key to an aligned view.
How do you do this in practice?
This diagram illustrates the configuration management system in green – that’s where you do the features and the rules. Both the engineering and the market rules get defined and can be passed on to a configurator or services exposing the configuration logic.
The information about which features are available is used when you define a so-called “Super BOM” or “150% BOM” in the PLM system. Context around which features can be used in a certain product is needed in order to define the Super BOMs containing expressions referring to the features that select the parts, depending on what features are selected in the configuration process.
From the Engineering BOM you derive a Manufacturing BOM, which are typically synchronized to an ERP system. The whole picture comes together because the CRM system, in the lower left corner, uses the configurator to configure a product. Once the configuration is created, it can be submitted to the ERP system when the customer accepts the order.
The two key processes are the Product Definition process where you create and define the product and push it to the ERP system, and the Order to Delivery, or Order to Cash, where customers order and configure products, and the product is manufactured.
Looking back to the tsunami example, it would be quite simple to propagate the change with an enterprise end-to-end configuration solution in place. All you need to do is create a rule that says we’re not going to offer the “orange” color any longer. If you put that rule into the product model, test, approve, and release it, then that change will be immediately reflected across the different functional areas. And because the website uses the configuration service that comes out of the centralized configurator, the value “orange” has been removed.
Customer Use Case: Reduced Time-to-Market at ABB
This example from our long-standing customer ABB perfectly illustrates this change propagation process. ABB uses configuration solutions in many parts of their organization, including their Low Voltage Circuit Breakers division. Circuit breakers themselves are configurable and often get included in other systems. There are system builders that build up entire racks with equipment in them and these circuit breakers are some of the components that will go inside those racks.
ABB uses Configit Ace® as their configuration system to define features and rules – both engineering and commercial. Their change management process is aligned with their PLM system, PTC Windchill, that makes sure changes in one system (PLM) are aligned with changes in the other one (Configit Ace®). Once the rules have been tested and approved, they are released and used in two different scenarios.
The ERP system does the so-called BOM Solve where it combines the configuration with the Super BOM to get the order-specific BOM. Because the configurator in SAP needs to know about the rules, it uses a configuration service to make sure configuration is correct. This means that customers can also make changes directly within the SAP system if they would like to change an existing order.
The rules are also used in ABB’s Configit Quote® system, a CPQ system that’s integrated to their CRM system. That quoting system also uses the models that come out of the configuration engine.
This diagram illustrates some of the key data entities that are present in the different systems. Keeping copies of information aligned and consistent across these systems is typically done through web services.
ABB has seen a drastic reduction in their time-to-market, due in large part to an elimination of errors in the manufacturing orders and improved collaboration between Engineering, Sales, and Marketing.
Explore ABB's $2.3 Million Success with Configit
See how ABB boosted efficiency and achieved a 76% ROI with Configit's solution.
Implementing an end-to-end configuration solution provides benefits across various business areas, including:
- Engineering: faster time-to-market, optimized variability, increased efficiency, and the assurance to only engineer products that you can sell.
- Sales: reducing errors, making sure that what gets quoted is accurate, and reducing time to close the deal. The configurator provides current, up-to-date, and accurate information.
- Manufacturing: reducing errors and no production stoppages due to misbuilds.
- Service: accurate information about the product’s configuration. The service technician knows exactly what capabilities to expect on the particular product to be serviced.
Henrik Hulgaard is the Vice President, Product Management and co-founder of Configit, a global Configuration Lifecycle Management (CLM) solution provider and a supplier of business-critical software for configuring complex products. He holds a doctorate in computer science from the University of Washington and is an associate professor of computer science. He has published more than 25 articles internationally.