One-Touch Product Configuration is the concept of having an automatic chain of events from a sales opportunity until the delivery of a product, unbroken by manual intervention. It can be viewed as a digital thread of information that seamlessly connects the sales situation to a detailed product configuration and into a production order. The connection can be two-way. Information can flow between the system in the other direction, such as accessing cost data and delivery lead time in the sales configurator.
One-Touch Product Configuration is the automatic information transfer across the different functions in the sales-to-delivery process
As the term One-touch implies, it is accurate, efficient, and fast. However, it may be a challenge to reach for complex products that are engineered to order.
Some of the apparent benefits of one-touch product configuration are
- Fast and tactical response in the sales process
- High level of efficiency in the order to delivery process
- High quality in the order and delivery processes. Both regarding avoiding errors and offering the best solution for the specific need.
- And an increased possibility of extracting additional value in other areas of your business, such as after-sales.
In this blog post, I focus on two of the three fundamental prerequisites to enable one-touch product configuration. And with a real-world example, demonstrate how a product master was restructured to enable implementation.
Modularity, Configurability, and Information Modeling are Key Enablers
There are three fundamental prerequisites for one-touch product configuration: Configurability, Modularity, and Information Modeling. They are closely tied to the very core of the business, namely the product itself and the production process.
Modularity and Configurability
Configurability is a quality of the product platform design; it explains how well the product can be configured towards the requested specification or variant.
Modularity is another quality of the product platform design; it explains how many unique parts are needed to configure the requested products.
Depending on the type of business, configurability and modularity can be interpreted differently and of different interests.
Configurability is typically measured as the number of unique parts required to create a new product variant for a product-based business. The more configurable the product platform is the fewer parts needed to create a new product variant, and vice versa. Modularity for a product platform in a product-based business is defined as the relation between the number of product variants and the number of unique parts needed to create them. Hence, with many product variants and few unique parts, you would have a high level of modularity.
For project-based and configuration-based businesses where the number of possible products is practically endless (each order is unique), the above definition of modularity does not really add value. However, configurability is still a relevant measurement, defined as the average share of the BOM configured from a pre-defined assortment of parts rather than engineered for a specific order. For a deeper read on this topic, check out this article on the secrets behind successful product configuration.
Modularization is a method to separate different parts of the product by standardized interfaces. The parts (modules) should be separated based on what needs to vary and what needs to be kept common in the product based on market needs, company strategy, and operational requirements.
Modularization will, by definition, improve modularity. When done well, modularization also improves configurability. However, this does not imply that you have to redesign and modularize your products to get to One-Touch Configuration. Modularization is an excellent approach to improve profitability and growth. However, it usually involves significant product development and investments, and the timing may not always be suitable for that.
What Level is Needed?
Modularity and configurability are vital enablers for one-touch configuration, but how well do they need to be? I would say that a reasonable level of modularity is sufficient. This would generally mean that several parts are reused between different product variants in your platform. More importantly, no disruptive core technical concepts or product structure changes occur. Minor exceptions in a product architecture tend to show up over time due to changing market demands or generations of design as variants of interfaces are acceptable and rarely a significant obstacle.
As for configurability and one-touch configuration, the higher, the better. Consistent one-touch configuration can only be reached with 100% configurability. If we have 90% configurability, 10% of the average BOM must be engineered for the specific order, thus not fulfilling the definition of one-touch. However, pushing for one-touch configuration for parts that are configured from pre-defined parts can have an enormous value in the real world.
Information Model
For a complex product, the information model tends to be a more crucial part of enabling One-Touch Configuration than the level of configurability - the information model ties into the necessary information flow and the configuration model itself.
One-Touch Configuration requires a focus on not only configurability but also information modeling
Identifying Modules
If we start with the information flow, it is vital to identify a common entity in your architecture. This common entity can be shared and easily communicated across the different functions in the company - so that the order configured by sales can be translated into a production bill of material (BOM).
To enable One-Touch Configuration, all involved parties must have an aligned information model
This entity is what we usually call a module, or more specifically, module variants. A module defines content regarding functions and technical solutions. Module variants are the physical realizations that deliver different performance levels or other types of variance needed in your product.
By connecting a module variant specification, we now have a set of basic information that can be used to establish the selection rules in the configuration model. Additional information can be connected based on what may be needed in a sales situation. For example, cost to provide valuable input on profit margin or specific delivery conditions and lead-time.
Furthermore, assigning an ID to the module variants lets us map each variant to the corresponding assembly in different structures, such as an engineering BOM or a production BOM.
The Module Variant as the Shared Information Object
Identifying the modules becomes very important for a couple of reasons. Defining them at the wrong level adds unnecessary complexity, both in administrating the module variants and building and maintaining the configuration logic.
The essence of restructuring the product master for one-touch configuration is all about that - to identify suitable modules in an existing design. By following a process like Modular Function Deployment (MFD), you end up with the correct definition of modules in your product.
Product Master Restructuring: A Real-Life Example
Some years ago, we worked with a client that wanted to replace their existing configurator tool with a new solution. Apart from needing a more modern tool, they also suffered from a high maintenance load in maintaining the configuration model and specification documentation in the engineering department. These inefficiencies created bottlenecks in development projects, resulting in delayed or incomplete product launches and ultimately lost sales.
The interesting thing was that the client's product design was modular with a high level of configurability. The main issue was the information model and, to a larger extent, the level at which the modules were identified. By restructuring the product master based on the MFD method, we defined a system that was much better suited as a base for the configuration model and the product specification framework. These improvements were all accomplished without significant redesign. Read the full case story about Alfa Lavals One-touch Configuration journey here.
Generic Product Structure
We can conclude that defining the right modules is crucial, but what else is essential in the information model? There must be a structure to which the modules can be connected to define their position in the configured product. The simplest way of doing this would be to keep all the modules in a flat structure. In most cases, and especially for more complex products, it pays off to create a structure that cleverly supports the configuration logic.
The configurator should determine which module variant should be chosen in each position of the product structure. By building a generic product structure that supports the flow of configuration logic, we get a model that is easy to understand and efficient to maintain.
I probably need to elaborate on the somewhat fluffy part about "supports the flow of configuration logic". However, some other important components in the information model need to be explained first.
Product Properties
Product properties are, in essence, the specification items that we use to define variants on a product level, a module level, and levels in between when needed. A product property has a range of goal values that define the different values it can take, e.g., different performance levels.
Suppose we make a simplified example around a battery used in a handheld vacuum and assume it would be specified by voltage, max discharge current, and charging capacity. These are suitable properties on the module level if we have identified the battery as a module. However, on the product level, it would make more sense to specify a property like runtime since that directly speaks about the product's performance.
Hierarchy of Configuration Rules
Now let's assume that we have specified a runtime of 45 minutes for a specific product configuration. To select or configure the correct battery variant, additional input is necessary. It could be how much weight the product can carry and operational conditions like floor type. With this information and dimensioning rules for the battery, based on performance and operational conditions, the correct battery module variant can be selected and added to the configured BOM.
By arranging the dimensioning rules and the module variant specification hierarchically in the generic product structure, we can establish the basic logic of the configuration model. For the battery example, we would put the battery dimensioning rules on the global product level and determine the battery selection in the whole product, as shown in the picture below.
Hierarchical configuration rules as defined in PALMA
If we extend the example above, presuming that there would be several batteries in a product, each of them should be possible to configure individually. We put the dimensioning rules locally in different branches of the structure, and now they rule the battery selection from that level and downwards. We can build complex models and reuse common information sets, such as dimensioning rules and module variant specifications. But maintain a good overview supported by the visual product structure representation.
The information model described is very well suited to use with a constraint-based configurator. Which, in most cases, is the best solution for complex products. It is also beneficial to use with other configurator types since having a well-organized and documented product structure with identified modules is fundamental for One-Touch Configuration.
A Good Structure is a Stable Foundation for Product Architecture Improvements
This blog demonstrates that implementing One-Touch Configuration does not necessarily require a disruptive product redesign. Most configurable products are suitable from a configurability perspective. The key is to structure the information smartly based on needed variance. A structured and repeatable method to do this is using Modular Function Deployment.
To enable One-Touch Configuration, a unified information model is necessary to define the lowest denominator of information across the different stakeholders in the process. One such information object is the Module Variant. Combining module variants with a generic product structure allows for hierarchical configuration rules uncoupled from the assortment. Using these together enables a very efficient, flexible, and maintainable structure.
Best of all? Reaching an excellent information structure is not where we end. It's where we start. With a stable foundation, we are set to implement further modularity improvements such as standardized interfaces. Using standardized interfaces can drastically reduce the internal complexity and increase speed-to-market – while improving the customer value of the product.
Download a PDF of the blog to keep in your back pocket or share with a colleague
