1 Developing a configurator requires a deep understanding of the configurable product. The configuration logic must encompass the way product components may be combined and customized, as well as how the integrity of a configuration can be verified. When products evolve over time, the configurator must be adapted accordingly. Product Managers are intimately familiar with the features and capabilities of a product and drive its development. By enabling them to specify the configuration logic of a product, the time required to introduce new products or respond to changes in existing ones can be reduced significantly. In order to achieve this, an environment must be provided that facilitates the implementation of configuration logic in an efficient and intuitive manner. In this paper we try to identify the key aspects of such an environment and present our experiences in realizing a product configuration system based on our findings.
Creating and maintaining a product configurator is usually a
complex task [
For reducing the creation and maintenance expenses for configurators, it is the target to give product managers the tools to create configurators themselves.
This article focuses on the very practical problems product managers face in building product configurators. Further on we identify key elements of an optimal configuration system environment. This leads to new approaches in the way the data is being entered, calculated and presented through the web. Notable findings will be presented in the last section.
As described in Ecker [
2.1
Relational data structures need to image the product data in tables.
These tables follow either a predefined [
But even in predefined schemata the problem remains, that the data of the product need to be squeezed in this predefined form. The challenge here is, to find a way to maximize functionality and readability which are adversary.
Our experience has shown that the majority of the product managers quickly lose sight on the complexity of the data structures they develop.
Problems:
The product managers are forced to establish an extra documentation layer to keep the system manageable.
The complexity especially for rule driven visualizations outruns many product managers’ capabilities.
The chronology the system has to calculate the rule needs to be defined by the product manager. This is discovered as a major weak point in terms of error and debugging expenses. 2.2
Code allows the product managers to transcript even most complex rules. The product manager does not have to follow a predefined schema at all.
Problems:
The period of vocational adjustment is very high.
This informal freedom, however, quickly leads to a lack of lucidity, which makes this form of product data unpopular for product managers who are not software developers.
It demands a high skill level in software development from the product manager Developing a configurator by coding is time consuming and expensive Future adapting and enhancements are also expensive and time consuming 2.3
Just like with the relational form there is a schema, but here they are called classes. The product manager can define an individual classes for every product. The main difference to the relational form is that the rules create dependencies, not the entities of the database.
That gives the product manager the ability to freely transcript the product rules into the system without the need of creating a database structure or a schema fitting his requirements first.
Problems:
The period of vocational adjustment is moderate.
This form demands a very sophisticated user interface to guide the user properly.
Because of the fact, that the class is individual for each product, the system can create it, while the product manager models the product.
Classes can also be derived (inherited). So the product manager can easily create variations of the product data. 3
There are several key aspects which define an optimal product configuration environment which support the product manager in building the product configurator.
As a result of our experience and findings we created a
configurator management system which fulfills the requirements
described in this paper. This system is call Combeenation[
The Configurator Management System Combeenation from IndiValue GmbH.
Showing the user interface designer of a front door configurator. 3.1
The process of creating product data is usually defined by the following steps:
This iteration is continuously repeated, until the product data is
finished for publishing. The described process is called
progressive evaluation [
Progressive evaluation can be very time consuming. Especially testing (opening a test configuration, navigating through the configurator to the point of interest, collecting the test data, closing the test configuration) is very expensive.
If a system would save the data instantly give instant feedback even into every displayed data affected by the changes including an always open test configurator, the time needed for modelling product data would greatly be reduced.
Leitner et al. [
Concerning the user interfaces of the configurator management system many user interfaces are IT oriented. That means the interface is built on the necessities of the system, the data structure and the underlying technology that runs the configurator system.
As described in Ko et. al. [
The key aspect in this area is to create a user interface for a configurator management system that focuses on the product itself instead of the technical system. The product in its actual visual appearance should always be visible to give instant feedback of the changes made. The components, the properties, the rules and the controls the product manager has to work with needs to be presented in a continuous and integrated way, regardless how these items are used for. This reduces the times needed to jump between screens, menus or pages.
The user interface of a configurator plays a key role for both,
consumers and product managers. Leitner et al. [
Customize the customization process: Adaption of the user interface depending on the type of customer.
Provide starting points: Initial design from which the customer can continue the configuration process.
Support Incremental Refinement: Tradeoff analysis (i.e. product comparison functionalities).
Besides these key principles, the arrangement of user interface
elements of the configurator as well as the kind of process
navigation (i.e. handling, ease of use, guidance through the
configuration process) affects the customer’s satisfaction with the
configurator [
In mass production industries it is common to integrate values (sizes, angles, weights, etc.) into the structure data (i.e. CAD systems). That is okay as long as the products do not change much after they are released to market.
In mass customization [
These requirements can be met by separating the configurable values from the rules and structure data. This way different sets of values can be easily combined with different versions of rules and structure data.
How difficult/easy it is to apply a small change in an established
structure with/without this separation will be defined by the
viscosity of the system [
To supply such a flexible system it is important to make this separation. That also has to be taken care of in the user interface, so that the product manager knows, which parts (values vs. rules) of the product are stored where. 3.4
We experienced, that product managers working with configurator management tools, which do not separate the user interface designer from the product designer, struggle with data duplication.
Some applications need to be displayed on different devices (desktop, tablets, smartphones), or on different channels (websites, apps, social media channels …), or some of them need to be refurbished to meet new requirements.
In order to create several different user interfaces for the same product, they have to also duplicate the product data. That leads to more data, which greatly increases the workload of the product manager, if this product data needs to be modified.
By separating the product design from the user interface design environment the product manager can address these requirements. 4
To meet the needs described we developed a system for creating product configurators. In order to make the use of the system for the product managers as easy as possible, we have chosen to use these standards and technologies:
HTML5: For maximum acceptance and further developments we have chosen to use HTML5 for Visuals are crucial and the biggest part of the mission. Most users valuate product primarily on its visual appearance. This applies for consumers just as for product designers. We put a lot of effort into providing a flexible system for the visual representation of the product.
Changes in the visual will be applied in real-time. Instead of rasterized graphic formats we use scalable vector graphics (SVG) for a better image quality. The visual editor is interactive and you get what you see (WYSIWYG). After the configuration process is ended by a user each scalable vector graphic can be converted to a PNG or PDF file, making it easy for further processing or printing.
The usage of SVG also allows us the enable custom fonts,
gradients, patterns, mask, filters and many other effects. For more
information about SVG see [
Our system is built with low response times in mind, since
researches have shown that higher latency times have a negative
influence on the user acceptance, no matter if that is for consumers
or product managers [
We experienced that latency times need to stay below 250ms otherwise most users interact with the same UI element again (e.g. clicking a button).
This speed must be achieved with any representation of the changes: simple values, results of complex chained calculations, visuals, and so on. 4.3
To achieve quick response times, it is necessary to split the calculations on the server and client side. The product manager, however, must not be confused. It always must be clear on where the calculation will be done, because there are advantages and disadvantages with either method:
The advantages of server side computations [
Big data necessary for a calculation does not have to be transmitted to the client Product rules are knowhow of the company which needs to be protected. Some product managers don’t want to transmit this knowledge to the browser of the client. Our system won’t transmit the company’s knowledge to the
client at any time. Just the results are transmitted and presented to the client.
Virtual machines, which are hosted in a datacenter, offers far more computation power than a client device. Progress is always saved. If a user catches up later he may continue where he left the configuration (also on other devices).
It would be possible that more users collaborate on the same product.
The system needs to be designed to scale up on demand. This can be done through distributed computing with automatically adding virtual servers if needed. This is especially difficult to implement if the machines work with stateful sessions.
To take a good mix of both advantages it is possible let the system operates on server side calculation for the product design rules and on client side calculation for the UI design rules.
This way calculations of the product itself are done on the server and calculations concerning the user interface (i.e. jumping to a certain page based in input data) are done on the client.
The separation of product design and UI design environments (see 3.4) allows the system to intuitively distinguish between both methods. 4.4
Most systems on the market cover one part of the mission. The other parts are done by other software tools which needs to be connected via interfaces.
A common thing for instance is, to create a product configurator
by using an ERP-software [
That leads to this constellations: Both systems hold their own product data. Many parts of these 2 data sets need to be redundant on both systems. And there is a third set of data: the interface itself hold data, too.
Product managers struggle with the big amount of human resources needed to keep these data sets up to date.
It is less maintenance works if all the modules needed for
product configuration are handled by one system [
All the modules of this single system run on this one set of data, and any module of that system can directly and without conversion access the data needed to fulfil its function. Combeenation provides such a system.
We have highlighted the problems and drawbacks of current systems, which product managers use if they want to build a product configurator. Further on we emphasized key aspects which are needed for such a solution, including a responsive and easy to understand user interface and a strict separation of data and rules.
With these findings in mind we built the configurator
management system Combeenation [