Variety is still on the increase in many areas of the manufacturing industry. Without the use of powerful IT systems it can no longer be managed effectively. Product models representing the portfolio in IT systems must cover all the relevant aspects of the products. In order to meet the requirements of the increasing digitization of all product lifecycles – from design to maintenance and service, products also have to be mapped in IT systems in an appropriate, consistent manner.
encoway has a great deal of experience especially in the modelling of sales configuration models for a variety of product categories. I will now summarise our most important practical experience in the form of individual tips.
1. Design first – then start modelling!
Start off with a model concept. Decide at an early stage, which functions are to be anchored in the configuration model and what the added benefit for users of a configurator is. For example, should the focus be on being able to easily check for a proper combination of components, modules and product options? Or do your users need help with the detailed technical design of your products? To find out, first answer the following questions: How complex is the expected calculation logic? In what form is the design knowledge – which may well be hidden in a “mystical C-DLL” – available?
Often, a configuration project offers the opportunity to record your company’s knowledge in a structured form. Decide at an early stage which individuals are able to provide expertise for creating the model. Give them the space and time they need in order to do this! If your company has an existing configuration solution which is to be replaced by a new system, then you should consider the functions offered by the old solution. A new software solution that does not provide all the important features of your old Excel configuration spreadsheet will probably always have an acceptance problem.
2. The art of selecting the right modelling approach
At the beginning of any project configuration there is the question of the appropriate modelling approach. Two modelling approaches are common: BOM-based modelling and class-based modelling, whereby mixed forms are also possible. Both approaches have advantages and disadvantages. They differ regarding the effort required for the initial construction, the complexity of the set of rules and the effort needed for service and maintenance.
A position-centric BOM approach is suitable if you are a mechanical engineer and want to create a model for the configuration of a sales BOM without any profound technical design logic. For design models in which requirement-based, technically correct configurations have to be found, the class-based approach tends to be the right choice. It has all the necessary expressive power thanks to its feature-based logic.
When selecting a configuration approach, consider the following:
- Which product data already exists in the company?
- How do the other systems process the configuration data?
- Who is involved in the creation and maintenance of the model?
- How often are assemblies or product lines modified?
The answers to these questions provide the basis for deciding on the most appropriate modelling approach and a realistic planning of modelling tasks.
The encoway configuration platform supports both of these approaches. For more complex scenarios, they can be combined. An automatic transfer of KMATmodels from SAP LOVC to the encoway platform is possible. It is important to get advice regarding the correct choice of modelling approach at an early stage in the project. Our modelling experts will be happy to help you!
3. Define clear interfaces
Have you prepared your manufacturing processes for the production of a multiple-variant product portfolio? Have you done this by means of modularisation and the creation a product kit? Then make sure that you continue to systematically follow this approach with your product models! With a clearly defined “internal view” of your products, your configuration models can be used again more easily in other contexts. Clearly defined interfaces in the form of combinations of features are also the basis for the integration of new configurable products or assemblies in existing configuration applications. Therefore, a configuration model created today to sell your equipment more effectively via your sales force can also be used next year by an application consultant on your website for presenting your solution expertise.
This does, however, only work when models of similar products are presented in a similar way on their external interfaces. The same applies to the use of multi-level BOMs for representing your product structures. Delimit each hierarchy level using a clearly defined external interface.
4. Keep product and application logic separate
As mentioned just now, it can be very advantageous to gradually expand a configurator based on existing configuration models to create a solution configurator. For this reason, configuration logic should be modelled in such a way that it can be used in different contexts. An important step in this direction is the clear separation of the technical and sales rule sets from the control of the UI logic of the interface.
A modularisation of the configuration knowledge means that every product “knows” its internal logic, and higher level models define the possible combinations in system and solution configurations. The reusability of the modelled relationships is thus improved. The logic for controlling the organisational area – for example for the visibility of input fields, for the use of dynamic mandatory fields, for generating characteristics for visual control of an interpretation or for the calculation of data sheets – can be as complex as you want it to be. As regards the model, it should be clearly separated from the buildability and sales logic.
The encoway standard configurator provides an easy-to-use interface for configuration in sales with minimal modelling effort. It offers a variety of options for structuring the configuration sequence. For the implementation of more complex design tools or applications with special design requirements the encoway experts can draw on a wealth of experience gathered in the course of over 15 years.
5. Define test scenarios
Make sure that you define test cases for various configuration scenarios at an early stage. In this way you will ensure the sustainable management and maintainability of your configuration model. Define these in the form of user input and expected configuration results. It will then be easy to ensure correct configuration results, for example when further developing the model or updating your product data.
Introduce automated model tests to create the basis for regular automation. Automate model tests as the basis for the regular updatability of your models. This is especially useful for frequent changes in your product portfolio. And it allows you to “refactor” your model at a later stage, i.e. to make structural changes – because the demands on a configurator and the product structures are certain to change over the years.
6. Get documenting! Right from the start!
As a product modeller you will surely be familiar with the following situation: you quickly developed the first model of the product. You saved the product structure on the file share as a printed photo of a whiteboard. And the set of rules is still firmly lodged in your memory. Two years later, however the situation is entirely different: you have two new colleagues to assist you with modelling and they keep asking things that only you can answer. Product management has defined a number of new restrictions which only limit the product variance from a marketing perspective. But you simply cannot remember the rules with which you defined the technical dependencies between the components concerned at the time.
Here there is only one remedy: discipline. Document your models right from the start! Describe clearly and in plain language the special challenges behind the configuration problem. This will help new colleagues to get off to a quick start. To provide an overview, illustrate your product structures in graphical form wherever possible. Right from day one, name the dependencies that you show in the form of calculations, combining tables or even programmed functions, in accordance with a consistent scheme. It is best to note not only the functionality, but also the reason for the modelling – for example whether it was because of technical, sales or other restrictions.
As you can see, there are quite a few things that have to be considered in order to obtain a successful, safe and flexible product model. I hope I have been able to provide some useful tips with this insight into our experience.