Components carry out their work unseen in a wider context by most people. But which components does a customer need for their current requirements? And what does a functional combination of multiple components look like? The average customer is not familiar with the large number of possible combinations and needs support in order to minimise their risk when making purchasing decisions. As a component manufacturer, you can use this to your advantage by offering specific sales support for the compilation of systems. You can thus protect your customers from selecting non-functioning combinations and positively influence their purchasing decision.
How you, as a component manufacturer, can use functions and application situations for a more customer-friendly selection process is described in my first article on the subject: “How component manufacturers define added value for customers in terms of functions and systems”. You can provide ideal support for this system business by using a configurator and thus offering your customers real added value. By means of a configurator, customers are able to select and order their individual components independently and their needs are addressed for the wider context with comprehensive support during the assembling of the parts. In this article, I will deal with three steps that are necessary for the successful establishment of a system configurator:
- Defining a modular product architecture
- Assembling the data required for the individual products and the interdependencies of the products
- Linking the sales-related presentation with the logistical processing
First of all, just a few words to ensure that we are all at the same level of understanding: A system is defined as the grouping of a number of components that fulfil their own functions, but typically cannot be operated separately. In order for the components to together create added value, i.e. to perform overlapping tasks, they have to be able to work together effectively. Certain combinations are advisable on a technical basis or in terms of content or sales activities whilst others are not. These combinatorics must be formally defined for a system configuration.
1. Defining a modular product architecture
In the first step, we define the modular product architecture. A practical example can illustrate this very well. The electrical and automation specialist Phoenix Contact manufactures products and solutions for various sectors, including electronics housing and terminals for control, communication and circuitry in the automation of plants. For example, a modular electronics housing from Phoenix Contact consists of a lower section, one to four upper components, and the connection technology. The connection system itself consists of a pin strip and a connector. The pin strip is mounted on the circuit board inside the housing, and the connector is inserted through the upper part into the pin strip. Both the lower and upper components and the pin strips and connectors are items that can be sold individually. They are, however, only used by the customer as part of a combination of components and therefore have no direct benefit on their own.
The connection technology can be used with various characteristics to implement the system, for example different current, voltage, number of poles etc. At the start of the configuration, the type of connection system is not yet clearly defined. The user starts with a generic product structure and successively decides on the details in the course of the configuration. The product architecture must therefore be modular. Using clearly defined interfaces between the system components, it is possible to map the combinability of various elements of the same type. Specifically, the interface is defined by a set of features for which the corresponding values of all components are available. At Phoenix Contact, these are for the usable types of connection technology, for example the properties current, voltage, number of poles, height, width and design.
Carefully consider the terms you use for your product architecture and adopt the language of the customer whenever possible! A technical configuration is important to distinguish between buildable and non-buildable configurations. However, customers often use very different words to describe their requirements. Address your customers in their own language by creating a sales view of the configuration and mapping this on the existing technical details. You may also like to refer to the first part of this series “component manufacturers”.
When selecting a component, the most important criteria are the function and a number of technical features. The same function can be served by different types of components, resulting in comparability and / or exchangeability at the sales level. The technical characteristics are needed to filter between matching and non-matching combinations at a technical level, for example in the connection technology via current, voltage, number of poles, height, width or design. In this way, a sort of “black box” is created: each component that complies with the interface (i.e. has appropriate values for the given set of characteristics), can be used for the system.
The components in a system can themselves be configurable products. Phoenix Contact offers, for example, housing, in which the lower section is itself configurable. The combinatorics are created in this case by selecting the appropriate colour, length and conductor plate width. In such cases, we simply integrate the existing product model including the rule set into the system configuration. A “multi-level configuration” is thus created. The only requirement for this is that the model of a configurable product serves the externally required interface. In this case, the complexity of the product is hidden behind the “black box” and this is invisible for the system. The users still describe their requirements purely from a sales point of view.
2. Creating the processes for data supply
In order to build up a system configurator, not only the master data for the individual components of the system are required, but also a description of the big picture and the possible combinations of the components with one another.
The technical data for the individual components should already be known. In this article, it is assumed that a system configuration is built on the basis of existing component business. The term technical data refers to characteristics of the features. In the example from Phoenix Contact, these are, among other things, height, width, type of connection technology, power supply, number of poles, diameter and material. This data is already known from the early stages of the product development process, for example from the design stage. The most important step is the definition of a suitable data transfer process.
If components within a system are themselves configurable products, the corresponding rule set should also already be known. Then, the most important step is to define a data transfer process. If the rule set is not yet available in the current systems but exists in written form in documents – or in the minds of the employees – it should be formally processed for the configurator in a suitable acquisition process.
The source of this existing configuration knowledge is typically product management, the design department or the logistics team. The rule set to reliably organise multi-variant products is often already available in ERP systems. encoway offers not only the opportunity to create new product models in its own modelling environment, but also, for example, the integration of existing product models including rule sets from SAP LO-VC.
The interdependencies of the components must also be included in a system configuration. These combinatorics are often rather simple and most individuals with specialist knowledge are implicitly aware of them. A configurator, however, requires the formal preparation of this knowledge. The task at this point is therefore to acquire and map the relevant knowledge that exists in the minds of the experts.
3. Interaction of the sales display with the logistical processing
A system configuration is not merely a sales topic! We must create the necessary conditions to also be able to process the systems created by the customer at the point of sale. The main prerequisite is that systems are processed as orders and – depending on the requirements of the customer – supplied in a pre-assembled form. The customer should receive exactly what they have ordered and not a just an incoherent “bag of items“.
Traditionally, component manufacturers optimise their logistics processes via the mass production of standardised products. As a result, economies of scale are achieved. An order-related production process runs in the background: the individual products are produced based on a forecast and kept in stock. When an order is received, they are taken from the warehouse, packed and shipped. The focus on non-order-related production is thus historically explainable and justified.
However, the high level of combinatorics in the systems business ensures that a non-order-related combination of the individual components is economically unfeasible and perhaps even impossible. A purely order-based production is also impractical: you would lose the positive economies of scale. The only advisable process from a business point of view is therefore a combination of non-order-related production of the individual components and the order-specific compilation, assembly and, if required, refinement of the systems ordered.
To achieve this, we combine non-order-related and job-specific steps in one order. Typically, this is combined into the ERP system within a single order number. In addition to the compilation and assembly, the production of customised components or a special finish may also be included. At Phoenix Contact, a customer-specific component might, for example, be a special colour for the housing which is not part of the standard range. A customised finishing could, for example, include special cut-outs in in the upper section to allow access to operating elements for the electronics inside the housing. We carry out the necessary work steps together with the component-level parts list in the order. This is therefore possible – at the very latest – directly before packing and shipping. However, depending on the proportions of standard and job-specific work necessary, it is advisable to carry this out at a much earlier stage.
Components are always part of a larger whole. Although they may be purchased individually, they are always operated in a wider context.
Ensure against non-functional assemblies received from the customer by directly offering and marketing complete systems that have been tested for their buildability. You already have some of the required data from the existing component business. And you can also handle the additional relevant combinatorics using the three steps described here.
I hope this article helps you to successfully communicate your product combinatorics to the market in the form of systems. I will be very happy to answer any questions you have and to receive your feedback. In a large number of customer projects, encoway has accumulated extensive experience in variant management from which your company can benefit.