To achieve maximum efficiency in the sales-to-delivery process, automation is a key component, with one-touch configuration as the ultimate goal. However, many companies need help with creating, documenting, and managing the product architecture configuration model, which limits their automation potential. A well-defined product architecture enables data-driven decision-making and streamlines the flow of product information to all business areas within your company. Here are six best practices for effectively defining and managing product architecture data.
The Product Architecture Configuration Model and Why It Matters
The product architecture configuration model includes all the data and information needed to fully describe products and the product variants grouped under the architecture. This classification consists of a variety of data sets describing various aspects of the product architecture, each relevant to different departments, including:
- Product properties
- Customer data
- Market segments and customer needs
- Modules, module variants, and interfaces
- Configuration rules
- Generic product structures
- Information on pricing
- Product configurations
- Sales information
- Market launch plan
- Technical specifications
- Forecasted sales volumes
- ...
The data sets listed are only a sample. In general, to classify product architecture data, a distinction must be made between data that is needed directly to describe the product architecture (e.g., generic product structure, modules, module variants, and configuration rules) and metadata that provides additional information (e.g., customer needs, market segments, and anticipated sales volumes).
Let's illustrate this with the example of a modular product portfolio of lamps: Important product architecture data that must be clearly defined and structured includes, for example, information regarding the lamp base, adjustable positions for the lamp arm, dimensions of various models, product characteristics such as the length of the lamp arm, and customer segments.
Figure 1. Example product - Product components of a lamp
Well-organized product architecture data is the key to successful end-to-end product configuration. However, more than organizing all these data sets in different drawers is required. Instead, it is a matter of linking the different data sets to create a central, uniform information model. This linking serves as the basis for automating the processes in the sales-to-delivery process and enabling end-to-end configuration.
Figure 2. Centralized and standardized information model for product architecture data
Best Practice 1: Create a Uniform Configuration Logic for Sales and Production
A common problem when managing product architecture data is discrepancies between the configurations used in sales and those required for technical implementation. During sales, a configurator generates a bill of materials based on customer requirements. This must be translated into technical requirements for the product so that a suitable bill of materials can be generated for production in the first place. If handled well, this procedure can involve little effort. There is also a considerable risk of discrepancies if the "sales model" isn't well connected with the "manufacturing model."
Companies should try to harmonize the configuration logic for sales and production so that when customer requirements are entered into the sales process, bills of materials can be generated directly. In addition, this makes it possible to check directly during the sales meeting whether the configuration sold is technically feasible.
Figure 3: Aligned configuration logic for sales and production
Best Practice 2: Structure Your Product Architecture Data in a Modular Way
The more extensive and complex the product portfolio, the more data the company must handle. However, the challenge lies not only in managing the sheer volume of data but also in classifying and structuring the data sets correctly. Let's look at the previously introduced example of a modular system of lamps. Each lamp variant is defined by several different product properties, including, for example, the length of the lamp arm, the shape of the lamp head, and the specification for the matching light bulb.
All this information must be correctly classified and grouped before it can be linked in the next step to provide a unified information model. Central to this point is the distinction between the module and the module variant.
Figure 4: Correctly classified and grouped product architecture data
Best Practice 3: Define Your Modules and Module Variants Correctly
Modules are functional groupings of components that can be combined via standardized interfaces and represent the core of a modular building block system. It is important to note that the module is an abstract placeholder in the generic product structure. In contrast, the module variant is the concrete realization of a module that fulfills specific properties.
It is this distinction that companies often need to remember when working out their modular product architecture. Without a clear separation between modules and module variants, the latter cannot be assigned in the generic product structure, which makes the configuration rules for the product range considerably more complex.
There are several approaches to defining modules. In the case of our portfolio of lamps, for example, the modular breakdown of the lamp arm could be done in three different ways. The following graphic gives an overview of the three options and the respective assignment of the module variants.
Figure 5: Three options for module definition and the respective assignment of the module variants
Best Practice 4: Select the Right Granularity for Your Module System
To manage the many stages of a modular product system, we recommend the using PALMA, a software solution for product and requirements management. The key focus of this feature-rich tool is tracking a module system. With a 360-degree view of the product, stakeholders can feel more confident in introducing new module variants based on the profitability of the entire module system. This method eliminates sub-optimizing customer requirements that may not be profitable enough to justify the introduction cost of a new module variant. In many ways, this approach is like Model-Based Systems Engineering (MBSE), where a single source of truth is created by an information model instead of using a document driven approach.
Figure 6. Optimum balance between the number of modules and variants
Best Practice 5: Combine Codes and Descriptive Labels for Your Data Sets.
A look at many companies' product databases reveals a collection of various codes and acronyms representing different product characteristics and information. For example, in our portfolio of lamps, the light colors of warm white and cool white might be coded as "WW" and "KW."
What works well for computer programs and for working with Microsoft Excel spreadsheets makes it difficult for employees to grasp the information content of the codes and abbreviations. Especially for new employees, it can be challenging to understand the system and learn all the codes. Companies should, therefore, not rely exclusively on codes when naming their data but should also use descriptive labels that are easier for employees to understand.
Best Practice 6: Specify Module Variants Based on Concrete Product Properties
Conversely, however, a lack of readability of product data for computer systems can also lead to problems. The need for more readability is particularly true when it comes to the specifications of module variants. Here, companies often make the mistake of giving module variants descriptive names instead of specifying them using concrete product properties. Let's look at this using the example of the lamp product portfolio.
In this case, the eight module variants for the lamp arm would be given descriptive names such as "Arm_20cm_Blue" or "Arm_40cm_Green". However, these designations need to be more readable for computer systems and configuration tools. In addition, the configuration rules have become increasingly complex, with a growing number of module variants, and must be revised regularly.
To avoid this problem, module variants should be specified via concrete product properties, each of which can be assigned a definite value. The various product properties and values can then be organized in a matrix that a configurator can easily read.
Figure 7. Concretely specified product properties, readable by configurators
Summary: Well-structured and Linked Product Architecture Data is the Key to Successful Product Configuration
Product configuration, especially end-to-end configuration, enables companies to reduce their efforts when offering new customized product variants. This shortens lead times while increasing cost and resource efficiency in all company areas that provide the product.
A prerequisite for successful product configuration is carefully structuring and preparing product architecture data. External support and analysis are a great way to learn and improve existing data and processes for future and scalable maintenance.
In this blog article, we have presented various approaches to better structure product data handling. The essentials to start are the creation of a uniform configuration logic for sales and production, the correct definition of modules, and the specification of module variants based on concrete product properties.
Want to Know More?
For detailed insights into the best practices presented here and further tips for correctly handling product architecture data, we recommend our webinar "Best Practices in Defining Product Architecture Data." You can download a recording of the English-language webinar at any time here.
To discuss the topic covered, learn more about PALMA, or request a demo, please email me.
AUTHOR