Keywords

1 Introduction

Modern global saturated and commoditized markets force companies to implement new production and marketing paradigms [1, 2]. The markets are shrinking and companies see service provision as a new path towards profits and growth. Automation equipment production is not an exception. The carried out analysis of the business and information management processes related to an automation equipment producer shows that instead of offering separate products, the company now tends to offer complex products (which may consist of several other products), whole integrated systems and also software units using different services [3, 4]. Product-Service Systems (PSS) assume orientation on combination of products and services (often supporting the products) instead of focusing only on products. This paradigm fits well automation equipment producers, for which tight relationships with customers are of high importance (with possibilities to get valuable equipment usage statistics, analyse use cases, get feedback, etc.). A good way to create new customer value is to provide the customer with PSS configuration possibilities. Both physical and software components are not used individually but in a greater context at the customer’s site (integrating product, system, and service data as well as their valid combinations).

The paper is based on the analysis and modification of the information management processes related to PSS configuration and engineering at the automation equipment producer Festo AG & Co KG. It produces pneumatic and electronic automation equipment and products for various process industries and has more than 300 000 customers in 176 countries supported by more than 52 companies worldwide with more than 250 branch offices and authorized agencies in further 36 countries. For companies with wide assortments of products (more than 30 000–40 000 products of approx. 700 types, with various configuration possibilities) ranging from simple products to complex systems (Fig. 1), it is very important to ensure that customers can easily navigate among them to define needed services.

Fig. 1.
figure 1

Assortment range: from simple products to complex systems.

Full size image

1.1 Background

The overall summary of the background research is shown in Fig. 2. One of the first projects of the considered company related to this problem was launched in 2010 [5]. It was aimed at modification of work and information flows related to configuration of product combinations.

Fig. 2.
figure 2

Information and knowledge management systems developed by the moment.

Full size image

The business process reorganization started with setting up a product ontology originally aimed at product codification (order code scheme) [6]. The resulting ontology consists of more than 1000 classes organized into a four level taxonomy, which is based on the VDMA (Verband Deutscher Maschinen- und Anlagenbau/Mechanical Engineering Industry Association) classification [7]. Taxonomical relationships support inheritance that makes it possible to define more common attributes for higher level classes and inherit them for lower level subclasses. The same taxonomy is now used in the company’s PDM (Product Data Management) and ERP (Enterprise Resource Planning) systems. For each product family (class) a set of properties (attributes) is defined, and for each property, its possible values and their codes are defined as well. The lexicon of properties is ontology-wide, and as a result, the values can be reused for different product families. This is a key enabler for modular product structures achieved by the ability to compare product components and their descriptions.

Then, based on the developed ontology, the complex product modelling design and system has been implemented. Complex product configuration models consist of two major parts: product components and rules. Complex product components can be the following: simple products, other complex products, and application data. The set of characteristics of the complex product is a union of characteristics of its components. The rules of the complex products are union of the rules of its components plus extra rules. Application data is an auxiliary component, which is used for introduction of some additional characteristics and requirements to the product (for example, operating temperatures, certification, electrical connection, etc.). They affect availability and compatibility of certain components and features via defined rules.

Based on the configuration model the process of complex product or solution configuration in accordance with given requirements can be automated. A pilot research project aimed at developing a product configuration tool (called CONFig) was aimed at testing this possibility. The tool supported the configuration process in terms used within the company (company’s knowledge level). In reality, the customers are used to operate different terminology (customer level), which doesn’t correspond one-to-one to that used within the company. Besides, customers from different industries can also operate different terms. As a result, there is a need to create configuration tools that can map customers’ requirements to those used in the company taking into account the context (customer’s industry segment, history of customer’s orders, etc.).

Although some significant results have been achieved in the area of complex product and system configuration, still a lot has to been done to support the whole life cycle of this type of products. We see the most apparent open issues in this context not in the run-time, i.e. configuration and order creation applications, but in the build-time, i.e. setting up and maintaining the required product master data, configuration rules, and application data, and so on. This is one of the goals of the future research.

1.2 Paper’s Goal

The paper investigates the problem of PSS engineering information management in a customer-oriented way and the way it has been solved. Implementing such an application-system view addresses the problem of designing the customer view on PSS selection, configuration and usage (defining user experience, “talking in a customer-understandable language”). The customer should not be aware of distinctions between system types (built-to-stock, built-to-order, engineered-to-order, etc.). To the customer, the sales process should always “feel” the same.

In this paper, we share our vision of required improvements in business processes and information systems at the considered company related to life cycle management for product and system configurations. Though the research results are based on the analysis of one company, the presented work can give significant input to achieve benefits for component manufacturers that tend to become system vendors in general.

The remaining part of the paper is structured as follows: Sect. 2 presents the developed approach to the problem being solved. Section 3 lists the main findings of the carried out research. Some summarizing remarks are presented in the Conclusion.

2 Approach

2.1 Research Approach Used

The used gap analysis methodology was implemented through the following steps. First, the analysis of the current organisation of the information management was carried out. Then, the expert estimation of the company benchmark was done. Based on this, the comparison of the present and future business process and information management organisation was done resulting in creating corresponding process matrixes. This has made it possible to identify major gaps between the present and the future business organization, analyse these and define strategies to overcome these gaps.

Research efforts in the area of information management show that information and knowledge needs of a particular employee depend on his/her tasks and responsibilities. Different stages of the product lifecycle management processes in the company are associated with different roles like product managers, sales personnel and even customers. The representatives of different roles have different needs when interacting with an application like a PSS configurator. A product manager, for example, knows about the products and is able to configure by deciding on technical facts. A customer, on the other hand, may not know about the technical details of the company’s products or even what kind of product he/she may use to solve his/her application problem. This is the reason why technical product details should be hidden from the customer under the application layer.

2.2 Application View

The complex PSS view comes from the application side. After defining of the application area, configuration rules and constraints to the product are defined. They are followed by characteristics and product structure definition. Finally, the apps (software applications) enriching the product functionality or improving its reliability and maintenance are defined. The same applies to the sales stage.

As a result, implementing such application-constraints-system view addresses the problem of designing the customer view on product selection, configuration and processing (defining user experience, “talking in a customer-understandable language”) [8].

As it was already mentioned, based on the different complexity level, the company’s products can be classified as simple discrete components, configurable products or system configurations. Of course, the selection and configuration of these different types needs to be addressed accordingly. But the customer should not be aware of this distinction. To the customer, the sales process should always “feel” the same.

The different stages of the PLM process in the company are associated with different roles like product managers, sales personnel or even customers. The representatives of different roles have different needs when interacting with an application like a product configurator. A product manager, for example, knows about the products and is able to configure by deciding on technical facts. A customer, on the other hand, may not know about the technical details of the company’s products or even what kind of product he may use to solve his application problem. This is the reason why technical product details should be hidden under the application layer. In addition, the selection of the right product for solving the application problem can be based on a mapping between the application layer and a (hidden) technical product layer. In the optimal case a customer does not notice whether (s)he is selecting a discrete product, configuring a complex system, and so on.

As a result, the overall concept of customer-centric view on the products has been formulated as shown in Fig. 3. It includes the introduced above new role of “System architect” responsible for the holistic view to the system and its configuration, description of its functionality and applications, and designing a customer view to it.

Fig. 3.
figure 3

The shift from the product view to the system view.

Full size image

2.3 Changes in Information Systems

The changing requirements on business processes also induce changing requirements on information systems.

In today’s world most companies do product specification with word documents or similar approaches. These documents are handed over to construction. Construction hands over other data, e.g. technical characteristics via PDM systems or CAD files, to manufacturing, and so on. At the time a sales channel is set up for the new product, the initial data from product specification is lost. Thus, a new requirement for effectively setting up sales configurators and after-sales support is a continuous database. Knowledge about the product’s application domain should be formally acquired already in the early phases of new product development. In this case the data is available whenever needed in later steps of the product lifecycle process.

Typically the new product development process is structured in several milestones, such as design approval, technical approval or sales approval. During the entire life cycle, different roles work on product-centered data: product managers, engineers, controllers, marketing, sales personnel, and so on. Thus, either the relevant product data needs to be handed over – and potentially transformed – from a phase of the life cycle to later phases, or there is a single information system with which all the different roles carry out their daily work; every role on their specific view on a portion of the product data. In both cases, one of the major benefits for all concerned roles would be a seamless integration of all product life cycle phases within a comprehensive workflow.

A product modelling environment must be capable of designing modular product architecture. This means that using such an environment, it must be possible to reuse single product models in the scope of system configurations and assign product or system models to application knowledge. This requires the definition of well-formed product model interfaces to allow for modularity. Such interfaces enable a black-box approach, in which all products or modules implementing this interface can be chosen for the complex product/system; i.e. they become interchangeable.

Last but not least, it is also important to support multi-user activities on the different parts of product, system and application models without losing track of changes and implication that such changes have.

2.4 Pilot Case Study Implementing the Developed Approach

The developed approach has been verified on a pilot case for the Control cabinet product. This is a complex product consisting of a large number of different control elements, some of which are also complex products. Due to variety of components its functionality is significantly defined by the software control system. Control cabinets are usually configured individually based on the customer requirements since their configurations are tightly related to the equipment used by the customer.

Before the change, the customer had to order a large bill of materials in order to get the control cabinet. Now, with a holistic view to the control cabinet as to a single complex product including corresponding apps and software services, it can be configured and ordered as one product.

At the first stage, based on the demand history, the main requirements and components are defined at the market evaluation stage.

Then, at the engineering stage the components, baseline configurations based on branch specific applications as well as possible constraints are defined. The result of this is a source data for creating a cabinet configurator tool that makes it possible for the customers to configure cabinets based on their requirements online. At this stage, such specific characteristics are taken into account as components used, characteristics and capabilities of the cabinet, as well as resulting lead time and price (Fig. 4).

Fig. 4.
figure 4

Control cabinet configurator: an interface example.

Full size image

Based on the customer-defined configuration the engineering data is generated in an automatic (in certain cases – semi-automatic) way, which is used for the production stage. As a result, the centralized production of cabinets is based on the automatically generated engineering file (Fig. 5).

Fig. 5.
figure 5

Control cabinet: from online configuration to production.

Full size image

The product maintenance is also significantly simplified due to the system-based view. All the data about this product (not only separated components) is available and can be used for modification of its configuration on customer’s demand.

3 Findings

As it was mentioned earlier, the result of the carried out gap analysis are strategies aimed at overcoming identified gaps:

  1. 1.

    Designing customer view on product selection, configuration and processing.

    There are different types of users, like product managers, sales personnel or customers. These users have different needs when interacting with an application like a product configurator. The customer view and the company’s internal view describe two contrary views addressing the intersection between the company’s product diversity and the customer’s individuality with a common goal: being able to guide a customer in selecting and configuring the right system for his/her application problem. At first sight, diversity and individuality seem to have a lot in common, but the goal behind each is rather distinct. It is important to analyse the customer’s context (especially for offering services): system usage, customer’s industry, who does the maintenance, country-specific regulations, etc.

  2. 2.

    Increasing system modularity/reusability in the context of product combinations and systems.

    The structure of product combinations and systems needs to modularized. Comparable modules have the key ability to be used in multiple configuration contexts. This concerns not only products and components, but also product combinations and whole PSSs assuming building a multilevel PSS engineering model. Thus, a general PSS model architecture needs to be set up.

  3. 3.

    From business processes to IT or vice versa?

    Though it is reasonably considered that the changes of business processes are the driver to changes in the corresponding IT systems, the experience has shown that it is not always the case. Having defined a general strategy, the company can try to implement some pilot particular IT solutions to support existing business processes or parts of them. If such solutions turn out to be successful they could be extended and will cause changes in the business processes.

More detailed steps within the above strategies include:

  1. 1.

    (IT change) Homogenizing and standardizing master data (increasing master data quality; e.g. for being able to compare components, which are necessary to build partially defined combinations and PSSs).

  2. 2.

    (Business process change) Aligning the business processes (improving interoperability and avoiding redundant tasks). When building a new configurator platform, it is important to align business processes like new PSS engineering together with the desired outcome. Doing so can help improving interoperability and avoiding redundant tasks e.g. in data maintenance.

  3. 3.

    (IT change) Implementing tool support for the changed processes (supporting the improved business processes).

4 Conclusions

The paper presents results of the ongoing shift from separate product and component to integrated PSS offering. In particular, it is concentrated on improving user experience in configuring and ordering for configurable PSS. The core idea is the change from the convenient for the company view of the products to the customer-friendly view from the system application perspective, which required an introduction of a new PLM role of “System architect”. The developed business process and supporting information systems made it possible to implement the scenario of the automated production of the customer-configured control cabinet.

The presented work is an ongoing joint research, which is still in an intermediary step of implementation. So far a pilot case for the control cabinet product has been implemented for selected customers. The future work will include achieving automated production of other customer-configured PSS. The research is based on the company Festo AG&Co KG, however, the results can give significant input to achieve benefits for component manufacturers that tend to become system vendors in general.