How to Achieve End-to-End Configuration

End-to-end means consistent use and smooth, efficient propagation of changes, which is, of course, not a simple thing. For companies that want to achieve E2E 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.

Key Element #1: Global Feature Dictionary
We use 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 build up a system that way. This is not a ‘best practice’ if your goal is to excel at handling your variants. You have to abstract from the parts using what we call ‘features’ that represent the capabilities of the product.

For example, a car’s paint color is a more abstract concept than individual parts. Paint color will influence many parts, such as the bumpers, the handles, the side mirrors, and the actual car.

Having a standardized way to talk about these features across different products and accross 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.

Feature codes are the key in linking the different functional areas of the organization, not the part numbers and the Bill of Materials (BOM). The feature string, or configuration of the product, is the DNA of the product.

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. Based on that 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.

Key Element #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.

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 each supply information to the model representing their perspective:

• Engineering: speficies 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 spefic 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.

Key Element #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.

Example: An End-to-End Configurator Solution at ABB
This example from our long-standing customer ABB 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.

Benefits – Integrated Configuration Lifecycle Management
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.

Across the various business areas you can expect to see a number of benefits when implementing an end-to-end configuration solution:

• 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 the 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.

For more information, you can watch our webinar on this topic by clicking here.