Keywords

1 Introduction

Saturation and globalization of modern commoditized markets requires companies to apply new models for production and marketing [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 at different PLM stages 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. 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. These tight relationships enable the possibility to get valuable equipment usage statistics at the PLM stages beyond the production and sales, i.e., analyse use cases and get direct user feedback.

Achievements in the area of artificial intelligence (AI) open new possibilities for increasing customer satisfaction from customer-driven design to reduced lead-time. The current wave of progress and enthusiasm for AI began around 2010, driven by three mutually reinforcing factors: (1) the availability of big data from sources including e-commerce, businesses, social media, science, and government, which provided raw material for (2) dramatically improved machine learning approaches and algorithms, which, in turn, relied on (3) the capabilities of more powerful computers [3]. Therefore, adaptation of information management in companies to the new trends is mandatory to succeed in the current situation.

This trend opens a whole new world of business models allowing companies to transform from product suppliers to service providers or even to virtual companies acting as brokers. For example, Rolls-Royce instead of selling aircraft engines now charges companies for hours that engines run and takes care of servicing the engines [4]. Another famous example is Uber, that does not only provides taxi services, but it does this without actually owning cars and acts just as a connecting link between the taxi drivers and passengers. Timely changed business model can provide for a significant competitive advantage (e.g., the capitalisation of Uber in 2015 was between $60 and $70 billion, which was higher than that of GM ($55 billion) [5]).

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 software services [6, 7]. 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. These tight relationships enable the possibility to get valuable equipment usage statistics, analyse use cases and get direct user feedback [8,9,10].

However, implementation of this paradigm requires significant changes in information management at nearly all stages of the lifecycle [11]. The paper investigates the problem of PSS information management at different PLM stages in a customer-oriented way and presents the way it has been solved.

2 Proposed Approach

The paper is based on the analysis and modification of the business and 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), it is very important to ensure that customers can easily navigate among them to define needed services.

The used “gap analysis”-driven methodology was implemented through the following steps. First, the analysis of the current organisation of the product information management was carried out. Then, the expert estimation of the company benchmark was done. Based on this, the comparison of the present and desirable 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 desirable 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 [12, 13]. Different stages of PLM processes in the company are associated with different roles like product managers, sales personnel, and other including customers. The representatives of different roles have different needs when interacting with an application like a PSS configurator [e.g., 14]. 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. As a result, the overall concept of customer-centric view on the PSS has been formulated. It includes a new role of “system architect” responsible for the holistic view to PSS and its configuration, description of its functionality and applications, and designing a customer view to it.

3 Product Lifecycle Support for PSS

PLM encompasses the processes needed to launch new products, manage changes to existing products and retire products at the end of their life. In this sense, typical product life cycle stages are development, introduction, growth, maturity and decline [11]. The development stage is when new products are conceived and prepared for manufacturing. For variant-rich products, the stages introduction and growth as well as the maturity are typically supported with product configurators. The decline stage, in contrast to previous ones, is the latest stage at which either a considered product is completely phased out or well-suited successor products are sought.

The development stage is distinguished from the introduction and following stages in the sense that development deals with setting up product master data, structures and configuration rules. The stages from introduction to maturity use this data for effective sales supported by product configuration.

Product lifecycle support for PSS differs from that for products. Major differences arise from the point of view to the products.

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

Table 1. Product information priority at different stages of PSS life cycle.
Full size table

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

4 Identified Goals and Related Strategies

The result of the carried out “gap analysis” has made it possible to identify two major gaps and strategies aimed at overcoming these:

  1. 1.

    Designing customer view on PSS selection, configuration and processing.

There are different types of information users at different PLM stages, like product managers, sales personnel, or customers. These users have different needs when interacting with an application like a PSS 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 analyze the customer’s context (especially for offering services): system usage, customer’s industry, who does the maintenance, country-specific regulations, etc.

  1. 2.

    Increasing PSS 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.

Below, these issues are considered in detail.

4.1 Designing Customer View on PSS Selection, Configuration and Processing

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

As it was mentioned, different information needs of different roles (product managers, sales personnel, customers, etc.) are the reason to hide the technical product and service details under the application layer. In addition, the selection of the right system for solving the application problem can be based on a mapping between the application layer and a (hidden) technical layer. In the optimal case, a customer does not notice whether he/she is selecting a product or configuring a complex system.

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

Fig. 1.
figure 1

Customer-centric application view

Full size image

4.2 Increasing System Modularity/Reusability in the Context of Product Combinations and Systems

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

In today’s world, most companies still do product specification with Microsoft 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-centred 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 system modelling environment must be capable of designing modular system 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 system and product model interfaces to allow for modularity. Such interfaces enable a black-box approach, in which all products and software modules implementing this interface can be chosen for the complex product/system; i.e. they become interchangeable. For the user, the complex details of product models on lower levels of the system architecture remain invisible. The user decides based on the visible characteristics of the “black box”.

Finally yet importantly, it is also necessary 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.

5 Pilot Case Study

The developed approach has been verified on a pilot case for the Control cabinet system. This is a complex system consisting of a large number of different control elements, some of which are also complex systems. Due to variety of components, its functionality is significantly defined by the software control subsystem. 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 compile a large bill of materials by deciding individually for every single component, in order to get the control cabinet. Now, with a holistic view to the control cabinet as to a single complex PSS 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. 2).

Fig. 2.
figure 2

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. 3).

Fig. 3.
figure 3

Control cabinet: from online configuration to production

Full size image

The new business process made it possible to reduce the time from configuration to delivery from several weeks to few days (depending on the required components). 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.

6 Conclusion

The detailed steps identified within the described in the paper strategies include:

  1. 1.

    Change from the single convenient for the company view of products to the user-friendly PSS views from the various perspectives.

  2. 2.

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

  3. 3.

    Aligning the business processes of different PLM stages (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.

  4. 4.

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

Step 1 required an introduction of a new role of “system architect”. Step 2 has mostly been achieved by defining the common ontology and forcing the use of globally defined attributes [16, 17]. Regarding steps 2 and 3, some tools for the current business organization have been implemented. The productive use of all these tools proves that the ideas behind the common ontology work well. The developed business process and supporting information systems made it possible to implement a pilot scenario of the automated production of the customer-engineered control cabinets.

Though the work presented in the paper is based on the experiences from one company, it however, can give significant input (for example, following strategies identified above) to achieve benefits for component manufacturers that tend to become system vendors in general.