encoway: From ERP-Based to Sales-Oriented Configuration - Case Studies - Knowledge-based Configuration: From Research to Business Cases, FIRST EDITION (2014)

Knowledge-based Configuration: From Research to Business Cases, FIRST EDITION (2014)

Part IV. Case Studies

Chapter 18. encoway: From ERP-Based to Sales-Oriented Configuration

Björn Höfling, encoway, Bremen, Germany


ERP-based product configuration is often used for supporting business execution processes in companies. Reusing the underlying product configuration models in sales-oriented scenarios leads to additional challenges. In this chapter we describe a sales application called sellAIR, which is the outcome of joint project work of encoway and the German company Boge. With this application, Boge has succeeded in closing the gap between ERP-based product configuration and sales-oriented configuration.


Knowledge-based Configuration; ERP; Sales-Oriented Configuration; Sales Process; ERP Business Excecution; SAP; Boge; encoway

18.1 Introduction: ERP-Based Configuration

Systems for enterprise resource planning (ERP) are integrated software applications for the automation of business processes. Typical examples of such processes in ERP systems are quote and order processing or production planning. For those companies that produce or deal with complex products with a high number of variants, some ERP systems support knowledge-based configuration. Depending on the specific market or supported scenarios, different knowledge representation and reasoning techniques are implemented in these systems. One of the major challenges to be addressed when manufacturing complex products can be summarized by the concept of mass customization, which tries to combine the advantages of mass production with the flexibility of individual customization (see Piller and Blazek, 20141). Configuration systems are a key-enabling technology of mass customization. A simple way of categorizing the application areas of (knowledge-based) product configuration in ERP systems can be shown along with the order fulfilment process. Make to stock (MTS) is a build-ahead production approach that supports mass production. In contrast, individual customization can be done in project-oriented production. In between, the scenario of make to order (MTO) is placed, which can be supported with the help of product configuration. Here, the production process is triggered by a sales order that includes the specific definition of the configurable products in the order.

The German software corporation SAP AG is a big player in the enterprise application software market (see also Haag, 20142). Its enterprise resource planning application is called SAP ERP, which includes a variant configurator called LO-VC (module logistics,variant configuration). Variant configuration is a basic technique that can be used in different business processes inside SAP ERP. The LO-VC can be applied in the modules PP (Production Planning), SD (Sales and Distribution), MM (Materials Management), CO (Controlling), CA (Cross Application Components), and CRM (Customer Relationship Management).

Concerning knowledge representation and reasoning mechanisms, the LO-VC combines different approaches that lead to a high expressiveness for product configuration models. Both declarative and procedural modeling are supported through the following major modeling primitives for dependencies between different kinds of objects:

• Constraints for assigning or checking values in a declarative way by evaluating (in)equations, variant tables, or variant functions

• Procedures for assigning or changing values taking into account the defined sequence of operations (e.g., value assignments, price calculations, visibility changes, and dynamic default setting)

• Preconditions for (dis)allowing values with the help of Boolean expressions

• Selection conditions for including parts in bills of materials

Monotonic behavior of characteristics (a value range can only be reduced during configuration and not enlarged) can be modeled by choosing so-called restrictable characteristics in combination with reducing their values with the help of constraints. The full extent of variant configuration with SAP is described in Blumöhr et al. (2012). For a comparison between the declarative and procedural approach of variant configuration with SAP, see Haag (2010).

The remainder of this chapter is organized as follows. Section 18.2 describes in more detail our view on sales-oriented configuration together with its product models and functional requirements. Section 18.3 provides a concrete case study named sellAIR at the German company Boge. First, requirements are discussed. Thereafter, we present the architecture of the application. We conclude this chapter with a discussion of the achievements of the deployed sellAIR application.

18.2 Sales-Oriented Configuration

Obviously, a company’s sales force would like to have access to their product configurations for being able to make valid statements (technical and commercial) toward customers. But there are many cases where this cannot be done via direct access to the SAP ERP. In addition the ERP product model itself might be necessary but is often not sufficient for the support of sales processes. Vendors of complex configurable products typically have invested a high amount of know-how and modeling time, which is frequently in the area of dozens or hundreds of person-years. This knowledge is manifested in the product model of SAP LO-VC, which is constantly maintained and kept up to date. This is also the right place because it supports many core business processes of the company. Duplicating this product model for sales force requirements would implicate all the disadvantages of redundant data management. Therefore, this big amount of knowledge should be made available for processes that are not directly integrated into the ERP processes without redundancy and should follow the principle of single source of data with SAP ERP as the leading system.

Figure 18.1 illustrates how business execution processes in SAP ERP and sales-oriented processes in external applications can share models. Typically, a configuration model in SAP can be divided into two parts. The high-level configuration is situated in SD (sales and distribution). It is interactive; that is, the user makes configuration decisions in a quote by assigning values to product characteristics of the different line items. The result of this configuration is handed over to the low-level configuration, which is situated in PP (production planning). This configuration is not interactive but determines starting from the results of the high-level, the bill of material (BoM) and the routing. As the knowledge base for the low-level is usually not needed in a sales-oriented process, only the high-level model should be exported and reused.

FIGURE 18.1 Sales-oriented configuration vs. ERP-based product configuration, with the high-level configuration model of sales and distribution (SD) being shared.

18.2.1 Product Models for Sales-Oriented Configuration

Reusing an ERP configuration model as is (without changes) for sales scenarios can be very attractive. But in many cases it is only a starting point for additional improvements. In the following, we will call this improved model a sales-oriented model in contrast to the source product model from the ERP system. Some of the major reasons for these improvements are:

• Entities such as customer applications or machines, context, and environment are not suited for being handled in SAP LO-VC. Only objects used in the logistic processes like products or services can be modelled as so-called configurable materials where any configuration knowledge is attached.

• In the ERP system such a configurable materialis also the only possible starting point for a configuration. But in the early phases of sales-oriented configuration whole ranges of products may be relevant with at least parts of their dependencies. In SAP inferences can only be made when the list of possible configurable materials has been reduced to exactly one.

• Besides a rather simple variant of part-of relation between all parts of the BoM of a configurable material (see Blumöhr et al. (2012), especially on the principle of so called super BoMs,) no other relation typesbetween instances are allowed.

• Often, people with solution or sales know-how don’t have the necessary SAP background and need easier ways of modeling complex dependencies (see Krebs (2014)3 on the encoway Configuration Environment for one possibility).

These reasons lead to the necessity of a higher expressiveness concerning knowledge representation. The following modeling primitives can potentially be added or modified to get from a product model to a sales-oriented model (with the wording of SAP in parentheses):

• Concepts (classes) with parameters (characteristics) including information about defaults, visibility, and the GUI model

• Partonomies (BoM), either bottom-up (from products to systems and solutions) or top-down (from products to, e.g., spare parts); if necessary with additional relation types (for the spare part relation)

• Constraints and rules (dependencies) especially for sales requirements including pricing mechanisms and national or local specifics

18.2.2 Specification of Functional Requirements

Functional requirements represent the user/customer view on the properties to be fulfilled by a configuration. In the following, we discuss three basic forms of stating functional requirements: (1) before product configuration, (2) during product configuration, and (3) after product configuration.

Before product configuration comprises all possible ways in which configuration can be integrated into a sales-oriented software application. This includes especially all ways to navigate to or search for a specific product or system/solution. The starting point in such an application may not be the vendors’ product range but the user’s problem for which he/she wants to get an adequate solution. Even if the user may be able to perform a configuration he/she might not be able to find the right configurable product. One functional task then is to perform a search on the available product range together with a mapping between the user’s requirements and the attributes of the available products. This mapping can be especially difficult if the attribute values are not static for the product but are dynamically defined during configuration (e.g., if the combination of attribute values can identify in a unique way one of the configurable products but each attribute by itself has an open value range when starting the configuration). In addition, the product configuration model in the ERP system may not be intuitive for sales purposes as it is often designed to be optimal for manufacturing purposes.

One important functional aspect during product configuration that is very often required is to have different alternatives for the course of action during configuration. The major ones are (1) free configuration and (2) guided configuration, the latter necessitating a complete description of the course of action (e.g., in the form of sequential tabs with a sequence of attributes). Of course, there are other possibilities between these two extremes. Having easy access to related media content is important, especially for explaining complex attributes or values to the user. For example, in the domain of machinery and components a common functional requirement is to have a graphical visualization of the result of the configuration process, ideally alongside and during the configuration either photorealistic or in 2D/3D CAD. Finally, different and complex ways of supporting changes in user decisions are often required. One example is to allow the choice of attribute values that are forbidden by the knowledge base by doing a replay of all other decisions that can be successfully evaluated without conflict. Those decisions that are not possible in combination with the last one are then presented to the user so that he/she can decide about her/his priorities.

After product configuration covers all logistic processes that rely on the results of the previously mentioned steps. This includes defining the structure of the enclosing document (e.g., quote or order) in a way that supports the sales process. Complex and adaptable pricing mechanisms such as discounting and scaled prices must be supported. A very important functional requirement of almost all sales applications is the generation of attractive documents, for example, for proposals. As this is the final outcome of the process it should try to attract the attention of the customer and influence his/her decision in a positive way. Documents generated from ERP systems achieve this goal often in a suboptimal fashion. Finally, the result of the configuration process should be transferred back to the business process, especially to ERP or CRM. This means, for example, the creation of an offer document in ERP.

Finally, all previously mentioned steps are integrated into a graphical user interface (GUI). Of course, common requirements for this kind of sales applications apply such as conformity to a corporate design and usability optimization. In our case we want to mention two specific issues. Sales applications reusing ERP configuration models usually have much higher expectations concerning the UI compared to their counterparts in ERP because this software can also become their “face to the customer.” The other aspect is the availability of all necessary languages for the sales force including those languages available in the ERP system but not limited to them. Quite frequently not all local sales organizations of a company are running SAP ERP which can lead to missing languages.

18.3 Configurator Application: sellAIR at Boge

Boge is an owner-managed German company founded in 1907 by Otto Boge. It produces compressed air systems for many different application areas, has more than 500 employees, and exports to more than 80 countries in the world. As compressors and other components have a high variability, Boge uses the LO-VC in SAP ERP for product configuration. Therein, approximately 600 configurable products are represented with up to 40 characteristics each. All kinds of modeling primitives for dependencies in LO-VC are used, which means a combination of procedural and declarative modeling. In addition, Boge cooperates with the German company encoway and uses their configuration environment (see Krebs, 20144). Boge and encoway together have implemented in 2007/2008 a sales application called sellAIR. This application was functionally enhanced over time. Figure 18.2 shows a screenshot of this application during the configuration of a product.

FIGURE 18.2 sellAIR: user interface of a sales-oriented configurator.

18.3.1 sellAIR: Application Requirements

Besides the reuse of the mentioned 600 SAP product models, Boge wanted to be able to define solutions/systems for customers. Such a system can include, for example, a compressor, an air filter, an air receiver, and some other components. In addition, the characteristics of different application domains for compressed air systems influence the choice and parametrization of the respective components. An important part of every sales-oriented application is pricing. In the case of Boge, gross pricing includes complex variant conditions for the configuration defined in SAP ERP. Afterward, customer-specific discounts and conditions may be added. For Boge this information is maintained in a CRM (customer relationship management) system based on Lotus Notes calledSalesAssistant. Therefore an important requirement for sellAIR was an interface to the SalesAssistant. This system should also serve as a resource for all kinds of customer data.

The major outcome of sellAIR is a proposal document. It should be attractive as a distinguishing feature compared to the competition of Boge. Product communication (value proposition, unique selling proposition, etc.) must be supported in a very broad way through the possibility of adding additional and individual content together with rich media. The software to be used for the generation of the proposal document had to be image, as both Boge sales force and dealers wanted to be able to make individual changes later on. The resulting proposal document had to be stored in the CRM system for follow-up processes. In order to have no interruptions in the business execution chain, the resulting line items had to be transferred to SAP ERP in case of an order. Finally, sellAIR has to be available offline for Boge field sales force and online for dealers and potentially in the future for customers also.

18.3.2 sellAIR: Application Architecture

Figure 18.3 shows the architecture of the solution fulfilling the given requirements. The involved systems are SAP ERP, the CRM system SalesAssistant, the system d.3 for archiving documents, sellAIR (offline), and sellAIR Web (online). The offline version of sellAIR is used by the sales force of Boge to perform tasks especially at customer sites. It is connected to the SalesAssistant, which is available on all sales laptops. By using the Lotus Notes API, sellAIR has access to all customer data and the generated quote document is stored at the concrete quote object in CRM. For archiving purposes this quote is stored in the d.3 system later on. The customer data and conditions are regularly synchronized between CRM and ERP.

FIGURE 18.3 Application infrastructure at Boge: distinction between offline version connected to SalesAssistant CRM and online version connected to SAP ERP.

The online version sellAIR Web has slightly different goals and users. It is used by customers and dealers of Boge products. Therefore, the functionality has to depend on the respective role of the users. Customers can create baskets with products according to their needs. As a result, they will get a document describing these products in more detail. This basket will then be sent via an email as a request for proposal to Boge and the following process is carried out in the CRM and ERP system. A restricted number of dealers with special rights is allowed to directly transform a basket into an order inside sellAIR Web. The configuration data together with the order header data are handed over to SAP ERP and an order object is created. In addition, an attractive proposal document is created for the dealer, which may be modified and handed over to the dealer’s customer.

In order to configure products according to ERP, the necessary high-level product model master data (materials, classes, characteristics, configuration profile with dependencies, variant tables, GUI models, and translations) is transferred from SAP to sellAIR (both offline and online). This is done with the help of the sellAIR builder environment. An update can be easily triggered by Boge whenever changes in the master data occur. sellAIR builder uses a standard software component from encoway, named K-Connect for SAP LO-VC. The data transfer is performed in two steps: (1) extraction and (2) mapping. The extraction process is technically based on remote function calls to SAP BAPI (Business Application Programming Interface) via JCo (Java-Connector). The result is stored into a database. The mapping process takes this database and maps the content into the different structures of the target system (the encoway configuration environment (see Krebs, 20145)). Dependencies in the SAP variant configurator are available as source code in plain text (following the LO-VC syntax) and have to be parsed and translated from this knowledge representation formalism into the target formalism. A compiler-compiler is used for this task.

In the case of Boge, the SAP product model itself has not been altered. A navigation and search hierarchy was added to the products to allow easier access for novice users. Also, additional text and media was added for enhancing the configuration and result visualization together with document creation. On the sales side, the model was enhanced with a knowledge base for configuration of compressed air systems. Besides a compressor, such systems contain other (configurable) components, such as air filters and receivers. After the necessary user decisions are taken for a system, a configuration is started for each relevant component of the system (corresponding to a product in the LO-VC, but running outside SAP in the encoway configuration environment). The configuration result consists of a list of line items each with its dedicated configuration. This list can be processed by the following steps (document generation and quote/order creation). The sellAIR application is based on standard modules of encoway and adapted to the specific needs of Boge and their clients.

18.3.3 sellAIR: Achievements

sellAIR was launched in 2008. sellAIR Web has been added in 2011 and is publicly available since 2012. The following benefits have been achieved:

• sellAIR replaces an old configuration system with double maintenance of configuration models in SAP and external tooling.

• An automatic actualization process for product configuration models is established.

• Product models in sellAIR are up to date and conform to their ERP counterparts.

• Sales-oriented models are added for system configuration on top of the ERP-based product models.

• Product and system configuration are available both online and offline.

• Navigation and search enable fast access to relevant products.

• The tooling allows fast, technically correct, and individual proposal creation for Boge sales representatives.

• A standardized dynamic generation of multilingual and attractive image Word documents in different variants for different tasks with homogeneous international layout is one of the major achievements.

• sellAIR allows comprehensive data exchange with SalesAssistant (CRM at Boge).

• With sellAIR Web, also customers and dealers profit from the configuration functionality.

• The results of sellAIR Web can be directly transferred into orders in SAP SD (Sales and Distribution).

18.4 Conclusion

We have shown that reusing ERP-based product configuration models in sales-oriented scenarios has many benefits. But additional functional requirements from the sales perspective have to be taken into account. Depending on their placement in the sales process (before, during, or after product configuration), this has different consequences on the configuration task. The spectrum ranges from additional search mechanisms for the right configurable product up to a sales-oriented model for a system or solution on top of the ERP-based product models. The concrete impact of this approach was illustrated with a sales application at the German company Boge.


1. Blumöhr U, Münch M, Ukalovic M. Variant Configuration with SAP. second ed Galileo Press 2012.

2. Haag A. Declarative modeling at SAP revisited – lessons learnt when applying configuration techniques. In: 19th European Conference on Artificial Intelligence (ECAI-2010), Configuration Workshop, Lisbon, Portugal. 2010;57–59.

3. Haag A. Product configuration in SAP – a retrospective. In: Felfernig A, Hotz L, Bagley C, Tiihonen J, eds. Knowledge-Based Configuration – From Research to Business Cases. Waltham, MA: Morgan Kaufmann Publishers; 2014:319–337. (Chapter 27).

4. Krebs T. encoway. In: Felfernig A, Hotz L, Bagley C, Tiihonen J, eds. Knowledge-Based Configuration – From Research to Business Cases. Waltham, MA: Morgan Kaufmann Publishers; 2014:271–279. (Chapter 23).

5. Piller FT, Blazek P. Core capabilities of sustainable mass customization. In: Felfernig A, Hotz L, Bagley C, Tiihonen J, eds. Knowledge-Based Configuration – From Research to Business Cases. Waltham, MA: Morgan Kaufmann Publishers; 2014:107–120. (Chapter 9).

1Chapter 9.

2Chapter 27.

3Chapter 23.

4Chapter 23.

5Chapter 23.