Consumers and businesses alike buy products in different ways. Depending on their need for customization and the expectations on price and delivery time, the market approach of the seller can range from standardized products to one-off tailoring.
This is my second blog in a series about end-to-end product configuration. Make sure to read up on the first chapter to understand how we define and describe what end-to-end product configuration is and what value it brings. In this blog, I will explore how different types of businesses can leverage product configuration and product platforms. True end-to-end configuration is perhaps not for everyone, but everyone can benefit from analyzing their situation and how they can improve.
When prospective buyers are looking to buy a product, they will have different needs and expectations of flexibility, price, and availability. Based on this, the buyer will look for a seller that can match these expectations. It could be a seller that markets standard products, a seller that configures custom combinations of building blocks, or a seller that tailor makes the product to each individual customer.
The most obvious way to buy a product might be to walk into a retailer to select and pick products from shelves, or have them selected and picked by a clerk. Today, this is gradually shifting towards online shopping, where web pages replace shelves, order picking is done at warehouses, and a logistics service delivers the product. A schematic process from product design to a finished product that the customer can buy can look something like in the illustration below. Depending on the volumes and variation of the finished goods, they may be made to stock or to order. In any case, the product is standardized towards forecasted market needs.
Product-based process
To enable more adaptation of the individual product to individual customer needs, some companies present a configurable product instead. Customers will either explain their needs, their required specifications or pick preferred components to configure their customized product. Even though the product is customized towards the individual customer, the modules used to build them are prepared in advance, like a traditional retail product. What is happening is that we add a final assembly stage between the warehouse and the customer. In this way, customers can expect to have the upsides of the industrialized product (short delivery time, high quality, high cost efficiency) while also getting some of the benefits of the tailored product. Using the same schematic illustration:
Configuration-based process
For products that require even more customization, perhaps more common in B2B contexts than B2C contexts, the product is entirely tailored for the specific customer. One such example could be the construction of a building, where an architect designs the building to fit both the customer's needs and exploit the potential benefits of the plot. Once the architect has finished the design, an engineer will select technical solutions for structural parts and dimension them according to the project's specific needs. The traditional construction process is set up to handle maximum tailoring but at the same time has challenges to reach industrial benefits of delivery time, quality, and cost efficiency. Again, using the same process illustration:
Project-based process
Businesses in all three examples above can benefit drastically from using product platforms. However, since their approach to the market is vastly different, the benefits of product platforms and how to use them might be different. To explain why businesses in all three examples can benefit from product platforms and product configuration, we will separate the operating models into front-end and back-end parts.
End-to-end product configuration doesn't mean the same thing to everyone. Depending on the situation and type of product, you need to apply different ambition levels and solutions. You can describe the way companies operate a product assortment by looking into their front-end and back-end operating models.
Front-end: How is the assortment presented and sold to customers?
Back-end: How is the assortment created in R&D and Engineering, and more specifically, how are the different Bill of Materials (BOMs) created for each individual order?
In the front-end, there are three primary operating models, following the earlier examples:
There are two primary operating models in the back end, depending on if the BOM is created before the order is received and then repeated or constructed individually for each order. Under these two groups, there are six actual back-end operating models, but more about these later:
The front-end and back-end are strongly interlinked, so some combinations can serve you well while others certainly will not.
Even if reality is rarely black and white, it serves as a good model for different prerequisites, opportunities, and difficulties with end-to-end product configuration. Many companies are applying a mix of the various operating modes for one product range, but there is still typically a strong predominance for one of the operating models. We start in the two extremes, Product based and Project based.
Product based, where each product variant is completely pre-defined and then sold repeatedly, is the most used approach for:
From an end-to-end product configuration point of view, a product-based approach has clear advantages. There's no real configuration going on at the order point. You filter through all your product variants to find the best match. After selecting the best match, you use the product identifier (often called product article number or SKU for Stock Keeping Unit) to find all related information. Relevant information related to your selection includes the full product specification, Engineering Bill of Material (EBOM), Manufacturing Bill of Material (MBOM), and so on.
But the product-based approach also has significant limitations and drawbacks. First, if a customer wants a new combination, there is no corresponding product variant. You will only be able to match many customers' needs approximately. Rarely will you have the perfect match. Secondly, you will add lead-time and cost to introduce a new product variant, both for the go/no-go decision process and then for completing all necessary information. Thirdly, since each product variant is separately defined and documented, it must be maintained and updated. These limitations add product complexity to the company, and the wider the product assortment grows, the heavier the complexity burden gets. Finally, the Product based approach creates a non-value-adding focus on the catalog of products with difficult phase-in/phase-out decisions, unnecessary changeovers in production, producing everything in batch. Therefore, a product-based approach should only be used for products with limited assortment size – either based on strategy or very high market expectations on low price and short delivery time.
Project-based is the opposite of product-based. A tiny portion of all necessary information is ready beforehand. Most information for the individual sales case and the product delivery is created during the sales and project engineering phases, which are organized as projects. This operational model, also called Engineer-to-Order (EtO), is most frequently used for very large products such as buildings, plants, ships, and large, low-volume heavy machinery. The project-based approach is used to be able to deliver large products in a wide variety, often case-by-case tailoring is applied.
The reason for this approach is that it is considered too difficult and expensive to design and complete the product range with all necessary variants and permutations. Instead, some basic design and supply chain work is done beforehand during the product development phase, but most of the work including all details are completed during sales and order engineering projects, when the requested product variant is being defined by customer and supplier in a dialogue.
From an end-to-end product configuration view, project based is the most difficult approach since its limitless flexibility requires a lot of manual work to complete and validate the customer specification, quote, product design, manufacturing and purchasing information.
This approach saves "unnecessary" upfront product development in developing products that might never be sold, but it incurs unstable quality, long delivery times, and high direct and indirect cost throughout the value chain.
Finally, the configuration-based approach means that for every sales case and order, a unique combination of pre-defined modules is created. This approach has been frequently used in the automotive industry for the past decades and inspired other industries. The computer industry is another great example where companies such as Dell have been pioneering the online sales of configured products.
There is a certain probability that a configuration has been made before, but since the operating model and the process is set-up to create new combinations efficiently, it doesn't matter. Each configuration is handled as if it would be unique instead of trying to search for matches in historic deliveries, giving advantages in unified processes and minimized variability in quality, delivery time, and cost. It also requires up-to-date product model master(s) to be used all the time, meaning that the risk of copying and reusing an obsolete or faulty specification, design, item, routing, etc. is avoided.
It is important to mention that the configuration-based approach doesn't necessarily mean that you are using CPQ (Configure, Price, Quote) to generate solutions and offers to customers. It means that the product design and the processes are built to create a unique combination from pre-defined parts for each order. To be able to succeed with the configuration-based approach your product and processes must be designed accordingly. A CPQ solution in the front-end can of course be an important part, but even more important is a supporting back end; that the product has a modular design, where individual modules can be interchanged to meet different customer requests and that the entire value chain is set-up to efficiently create and deliver a new combination each time.
The configuration-based approach may require a more complex system set-up than product based, to manage the product architecture over its lifetime, but once that is in place a very wide and agile assortment can be launched and efficiently managed over time.
With an agile assortment, updates and new functions, features, and performance levels can rapidly be introduced across all the product range.
As already stated, the first primary back-end operating model is about creating a fixed Bill of Material that is repeated until updated or discontinued. The second primary back-end operating model is set to create a new Bill of Material for every order and delivery.
For each primary back-end operating model there are secondary back-end operating models that explain how the standard and custom BOMs are created.
The creation of new product variants (SKUs) is typically made by starting from the most similar current product and then manually adding, removing, or changing parts as required to get to the new product and its BOM. Sometimes there is a need to create a completely new product, starting from blank. But after that new product variants to expand the range are again created by copying and changing the most similar product.
Repeat fixed BOM by Copy-paste-change standard product
This operating model only works well for small product assortments, with a limited number of end-product variants. As soon as the variance increases and the assortment grows bigger, this operating model becomes inoperable due to the lack of harmonization between products.
You could think that since most products are stemming from the same original source, they should be well harmonized. However, every copy-paste-change operation is independent, and each product is managed in isolation, so they will not be harmonized.
R&D, Engineering and all down-stream functions will suffer from unharmonized product structures and lacking commonality of parts. The difficulties and complexity cost associated with developing new products, maintaining products, procuring all parts, and producing all product variants grows exponentially as the product portfolio grows bigger.
Many companies have realized that they need a wide product assortment and at the same time need to harmonize product structures and create commonality of parts to gain leverage and scale in R&D and Supply Chain.
Instead of developing isolated, individual products, they develop a product platform from which a variety of products can be generated. Each platform consists of an assortment of interchangeable parts and a product structure template, and these two assets are used to create new product variants through new combinations of parts populating the product structure template. At the end, each product variant (SKU) is still fully documented with a fixed BOM.
Frequently, new functions, features and performance levels are required, in order to stay competitive. Existing parts are then modified, or new interchangeable parts are developed, and a multitude of new product variants can be generated if the interface is kept. Now and then, some new requirements or a new technology can't be absorbed by the existing platform(s), and a new platform needs to be developed from scratch or by developing (parts of) an existing platform.
Create a new fixed SKU based on a Product Platform
Despite the advantages of "platform based" versus "copy-paste-change" creation of standard products, it is worth noting that the term product platform is ambiguous and is commonly used for everything from a standardized chassis with all other parts being product unique to a fully modular product platform where all interfaces are standardized, and parts are interchangeable. In the first case you will only get platform advantages in the chassis while all other parts still lack platform leverage.
Finally, even if platform based, you still need to live with the 4 main disadvantages of creating and maintaining a catalogue of standard products:
Start-from-blank means that the paper is essentially empty at the beginning of each delivery. It is not a very desirable operating model, but it is frequently used in the construction industry and other industries where nothing is repeating and everything is case-by-case – surrounding, product, design and engineering teams, supply chain set-up, assembly organization, etc.
From end-to-end product configuration’s point of view this operating mode will not be commented on any further since it is incompatible. You might be able to configure bits and pieces, but never any major part of the delivery, if you are not willing to change your secondary back-end operating model.
In this operational model, the entire base of historic deliveries is searched for the best match. In rare lucky cases there is a perfect match that can be copied directly without any engineering need. However, more commonly there are some differences that need to be engineered, so called engineer-to-order. There might be some tool support to search the historic deliveries, but mostly the process relies on personal knowledge to find the best match, since the best match is not only a matter of most similar specification. Also, the time factor is important, since you don't want to copy a delivery with many obsolete parts, due to design or supply chain changes that occurred after that delivery.
Create new BOM by Copy-paste-change historic delivery
This operational model is similar to Copy-paste-change standard product back end, but with a significant difference. With standard products back end, we assume that these are kept updated, ready to be ordered. With copying historic deliveries, these are supposedly not kept updated, opening up risks for copying obsolete parts with issues that have actually already been fixed in later designs.
From the front-end point of view, copying historic deliveries also create challenges since you normally don't know beforehand how good a match you will find:
This makes the sales process very person-dependent and difficult to support with tools.
There also needs to be a consequence analysis of every change in customer requirements to understand the impact. Sometimes the result could be that the copied historic delivery should be changed. It will create frustration both for customers and internally when seemingly small changes have big consequences on product, price, or delivery terms.
This operating model is also more or less incompatible with end-to-end product configuration. You can implement tools to help find the best match, applying algorithms for balancing between adherence to specification and age and obsolescence of parts. But you can never automate or really streamline the understanding of technical impact from deviations between the new order and the historic reference.
To overcome some of the disadvantages with Start from blank or Copy-paste-change historic deliveries, some companies have stabilized the core of the product, but still keep other parts of the product flexible to adapt or tailor to each individual case:
The core of the product should be a flexible and maintained modular product platform from which a variety of different deliveries can be generated. The product platform should never be subject to uncontrolled adaption to the surrounding – all necessary variants, as for example different layouts, should be enabled by the flexible product platform. Finally, the core product should normally always be included in the mandatory scope of delivery.
But there are still pain points related to the case-by-case tailored portion of the deliveries. Here the quality, delivery time, and efficiency problems are still present and at a lower scale you will still suffer from process variation, difficult pricing, and margin degradation.
At the highest ambition level, all parts of the product are included in a flexible modular product platform. This is the required state for seamless end-to-end product configuration for a customized product, all the way from the front to the back end.
As with platform-based standard products, you should make sure to look at the total picture and your level of harmonization across platforms. As time has passed, you will typically have a situation where you have too many platforms with too little harmonization between them. Product structures have deviated and too few parts are common or interchangeable cross the platforms.
The front-end and back-end are tightly linked in end-to-end product configuration, especially when making it seamless by integrating systems end-to-end. We have compiled a navigator with the combinations of front-end and back-end, with the typical drawbacks and things to watch out for in each combination.
No matter if you make standardized products, configure products towards specific requests, or tailor them in projects, you can benefit greatly from understanding where you are, and how you can improve from there, considering product platforms and product configuration.
Some might find that changing the front-end approach or adding another brand and channel with an additional front-end approach will increase the approachable market and its appreciation of the products. Others can be reassured that they are doing the front-end right but the back-end operation is not aligned with the front end, causing huge product level complexity to maintain and legacy to carry. They may find themselves being outsmarted or overtaken by new competitors without the luggage.
Some might of course also find that they are already aligned in the front and back end. Most companies can still improve by consolidating and unifying platforms to create further leverage and scale, or by adding more efficient system and process support to develop, govern, and sell the product.
In my next blog, Enterprise Architecture for End-to-End Product Configuration, I will try to give an overview of the core needs and systems involved for the most common approaches.
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