=Paper=
{{Paper
|id=Vol-1420/ilog-paper5.pdf
|storemode=property
|title=Changing Business Information Systems for Innovative Configuration Processes
|pdfUrl=https://ceur-ws.org/Vol-1420/ilog-paper5.pdf
|volume=Vol-1420
|dblpUrl=https://dblp.org/rec/conf/bis/SmirnovKSOSK15
}}
==Changing Business Information Systems for Innovative Configuration Processes==
https://ceur-ws.org/Vol-1420/ilog-paper5.pdf
Changing Business Information Systems for Innovative
Configuration Processes
Alexander Smirnov1,2, Alexey Kashevnik1,2, Nikolay Shilov1,2, Andreas Oroszi3
Mario Sinko3, Thorsten Krebs4
1
St.Petersburg Institute for Informatics and Automation of the
Russian Academy of Sciences, 39, 14 Line,
199178 St.Petersburg, Russia
2
ITMO University, 49, Kronverkskiy pr., 197101
St. Petersburg, Russia
{smir, alexey, nick}@iias.spb.su
3
Festo AG & Co. Ruiter Straße 82,
73734 Esslingen, Germany
{oro, sni}@de.festo.com
4
encoway GmbH, Buschhöhe 2,
28357 Bremen, Germany
krebs@encoway.de
Abstract. The dynamic globalized markets cause an increase of competition
and require companies to perform strategic changes in their business processes.
This is one of the reasons for component manufacturers to offer not only
separate products and components but also whole integrated solutions to their
customers. However, this requires significant changes both in the business and
information management processes that are related to configuration. The paper
presents the challenges caused by the above changes and some solutions aimed
at achieving higher efficiency of information management processes as well as
supporting information systems for delivering standard, customized and custom
products and solutions to the customers.
Keywords: product configuration, system configuration, business process,
variant management.
1 Introduction
Today, dynamic globalized markets cause an increase of competition and require
companies to perform strategic changes in their business processes [1, 2]. Component
manufacturers are challenged to offer not only separate products and components but
also whole integrated solutions to their customers. Such solutions might consist of
multiple physical devices as well as services. One of the consequences of this is
appearance of “complex products”, which consist of other products (both regular
products and complex products) and often include software units using different
services [3, 4].
Copyright © 2015 by the authors. Copying permitted for private and academic purposes.
This volume is published and copyrighted by its editors.
62
We had a chance to analyse the business and information management processes
related to configuration of product combinations and systems at the automation
equipment producer Festo AG & Co. It produces pneumatic, electronic automation
equipment and products for the process industry 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.
The presented work, however, can give significant input to achieve benefits for
component manufacturers that tend to become system vendors in general. The major
benefit is a guided selling with industry and application specific view, steering of the
customers in the e-channels with an easy to use configuration for components,
product and system combinations.
Figure 1 shows the intended change in business strategy. The major goals are
reducing the effort in producing products and reducing the time-to-delivery to the
customer. Both goals should be reached by having less engineering activity (ETO) but
more products that can be assembled based on a pre-defined modular system (ATO).
In this sense it is intended to make use of the “economies of scale”.
Products of different complexity require distinct handling in the process from
request to delivery. We differentiate three levels of complexity:
• PTO – pick to order: A product is order-neutrally pre-fabricated and sold as a
discrete product. This means that no configuration is necessary to identify the
correct combination of components. The different combinations already exist and
for the user it is a selection process rather than a configuration process. No order-
specific production is required.
• ATO – assemble to order: The different components a product can be composed
of are pre-fabricated but the correct combination of components is left open for
order clearing process. The product itself is order-specifically produced from these
existing components.
• ETO – engineer to order: A product is based on a known set of pre-fabricated
components (like in the ATO scenario) but the specific customer need requires
additional engineering activity. In this case new components need to be
engineered, constructed and fabricated in order to fulfil a customer order and
product the order-specific product.
For the logistics processing, this distinction between the levels of product complexity
requires different treatment within the process. PTO products should have the shortest
delivery time to the customer and therefore are produced to stock. These discrete
product variants have an own material number in the ERP system and are pre-
fabricated (these products are marked as “FEHA” products in Figure 1). ATO
products, on the other hand, are fabricated on-demand, which requires a configuration
model for these types of products (these products are marked as “KMAT” products in
Figure 1). The same holds for ETO products, which, in addition, require manipulation
of the configurator output in order to include the engineering input.
The used “gap analysis”-driven methodology is reflected in the paper structure. First,
the analysis of the current organisation of the information management has been
carried out (sec. 2). Then, the expert estimation of the company benchmark has been
done (sec. 3). Based on this the comparison of the present and future business process
and information management organisation has been done resulting in creating
63
corresponding process matrixes (sec. 4). This has made it possible to identify major
gaps between the present and the future business organization, analyse these and
define steps to overcome these gaps (sec. 5). Major results are summarized in the
Conclusion.
Fig. 1. Sales increase through process optimization and automation from request to delivery
2 Present Information Management Organisation and Drawbacks
The business process reorganization started with the building of a product ontology
originally aimed at product codification (order code scheme) [5]. This operation was
done automatically based on existing documents and defined rules of the model
building. The resulting ontology consists of more than 1000 classes organized into a
four level taxonomy, which is based on the VDMA classification [6]. 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 used in the company's PDM and ERP 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 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 description consists of two major
parts: product components and rules. Rules of a complex product include the rules of
its components and extra rules. Additional product characteristics and requirements
(for example, operating temperatures, certification, electrical connection, etc.) are
described via auxiliary rules called “Application data”. They also affect availability
and compatibility of certain components and features. In addition they allow
customers to find the right product without any deep knowledge about the company’s
products. The customers are able to configure an unknown product simply by
describing his problem situation (the application of the future product).
The developed so far integrated knowledge management workflow is presented in
Figure 2 and is described in detail in [7]. At the first stage, the major product ontology
64
is filled with generic classifications of products and their components. This is done
via two tools: NOC and CONCode, since recently developed order code scheme
differs from that used before. However, since multiple customers are used to operate
with the old classification it has to be maintained.
Fig. 2. Developed integrated knowledge management workflow
In addition to the data mentioned in the picture technical data should be used in the
configuration process and product selection process. Such data are actually
maintained based on the classification in the PDM System. As they are not available
in the NOC and CONCode they could not be used in the configuration at the moment.
Further there is no process how to handle application data.
For the running configuration application, there is a need to combine these data,
sales, technical and application.
At the next stage, the product managers and product engineers design new products
and solutions based on existing products and components (the CONSys tool). If a new
product or component is needed, its implementation can be requested from the order
code structure team. Together with new products and solutions, the appropriate rules
and conditions are designed as well (e.g., acceptable load, size, compatibility
constraints, etc.).
Based on the built 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 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
65
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.). This is
one of the goals of the future research.
3 Comparing Festo to the Competitors
In this Chapter we describe the expert estimation of the company benchmark. An
external team of experts has analysed and rated Festo’s competitiveness compared to
other companies in the same business segments. The results are presented in figures 3
and 4. The white circles denote estimations for the “best” companies for each
particular criterion; the black circles denote the estimation of the Festo’s
competitiveness.
Comparing Festo with other companies in the area of component configuration
(Figure 3), the first impression is that Festo is a benchmark in all categories in selling
components through the web shop, modelling a configurable product, web interface,
automatically generation of CAD models. However, since selling systems and product
combinations is now one of the strategic business fields different estimations should
be considered (Figure 4). For these use cases Festo is still below the benchmark. The
complex products with a very high variety have a complex customer interface, and no
industry or customer specific views.
Company Benchmark
Fig. 3. Festo is benchmark in the area of the component configuration
By today new products and systems need to be implemented by new applications,
which results in:
• Enormously multiple expenses (no scaling effect – no standard solution as basis)
• Growing number of projects by limited capacity
• Delay in product releases (Time to Market)
• Permanent, high maintenance costs through higher support efforts
66
Company Benchmark
Fig. 4. In the area of system configuration Festo is clearly below the benchmark. Existing
solutions are island solutions.
The previously developed workflows and information systems supporting products
from the design phase to putting them to the market and further has appeared to be not
efficient enough for the new business strategies. As a result, there was a need to
design new workflows and supporting software systems to increase efficiency of
designing and maintaining new complex product ranges. One of the efficient ways to
address the before mentioned aspects is to develop and integrate a configuration
platform supporting a modular product architecture (e.g., [8]). Since Festo recognizes
that new workflows intelligently supported by information systems is currently a
critical and strategic issue [9, 7], long-term research activities have been launched
aimed at complex product support at Festo.
4 Future Business Organisation
A joint research aimed at business process review has been carried out. In this review
the two major processes “PLM and data management” (with a focus on new product
development and the product change process) and “configuration and logistics
processing” (including PTO, ATO and ETO strategy scenarios) were analysed. In
order to do so all the key company’s personnel was interviewed and process matrixes
based on the notes were created. These process matrixes describe the current state in
the respective processes. The current states were then reviewed together with the
company personnel for identifying the most outstanding “pain points”. Based on this
input process matrixes describing the desired future processes (i.e. a state of the
process in 2020) were drawn.
A “process matrix” is a diagram similar to flow charts. In such a diagram the
process steps are aligned according to two axes: horizontal swim lanes group the steps
that are carried out by a specific person or role (i.e. group of persons with the same
67
tasks) while vertical swim lanes group the steps according to time. For the new
product development process, for example, the lanes from the left to the right are
product definition, planning, realization, production, series run, and so on. Milestones
like “production release” can be mapped to the borders of two adjacent swim lanes.
The whole idea of the desired business organization is presented in Figure 5. It is
all centralized around the configuration model. Then, the strategies of the
customization levels are shown with corresponding results. The “Material No.” here
stands for a standardized product available for the “pick to order” (PTO) strategy. The
deeper customization strategies require the “bill of material” (BOM) definition either
at the stage of assembly, production or engineering. These are followed by activities
both internal (for the company) and external (for customers) associated with the
strategies. Obviously, for a customer there has to be as little difference as possible in
selecting a PTO or configuring ATO or ETO strategy scenario products or systems.
The customer should only see the complete product range without a need of
understanding what is available PTO and what is available ETO (the only differences
could be in lead time).
Fig. 5. Layer-based model of the desired business organisation
Variant management [10, 11] is seen as a key activity in the process of business re-
structuring. The main idea of variant management is to optimize the number of
product variants offered to a specific market segment (i.e. “outer variety”) while
reducing the complexity of product development. Production costs are typically kept
low by producing a small amount of modules that are generic and common for
multiple products within the same portfolio (i.e. “inner variety”). The interested
reader is referred to [12].
In Figure 6 the new product development process is addressed on a high-level by
the process steps “product management”, “construction”, “production / logistics” and
“sales / marketing”. Within the new product development process the distinction
between “inner variety” and “outer variety” can occur multiple times: typically
68
between construction and production, between production and logistics and between
logistics and sales. Thus, the main lever of variant management is to compare two
different views on a product family (the need / market view with the engineering /
construction view) and then improving reuse of modules and eliminating the main
variant drivers; which are typically also cost drivers.
Fig. 6. Variant management and its effects on the major activities and processes around product
configuration and order processing.
Having a coherent product database capturing all relevant data from early stages of
the new product development process until the sales and marketing stages enables
using this data for comparing the different views on the product family. This, in the
long run, enables effective variant management. At the same time most of the data
required to describe a product for sales is already present, because this data can be
extracted from early product specifications. This means that a single coherent product
database can be used to reduce redundant work for data creation as a “side-effect”.
4 Identified Gaps and Ideas on How to Address Them
In order to gain the desired improvements of the business organization described in
the previous chapter – i.e. standardizing the configuration and logistic handling of
product combinations and system configurations, still some gaps need to be bridged:
• (Re-)Structuring the product portfolio (understanding which products are
important and which are not):
The company offers a wide variety of products all over the world. The products
have different complexity and there is regional distinction when it comes to logistic
handling and sales numbers. The product portfolio should be segmented according
to the importance of products for the different sales areas.
69
The company is currently defining which products should have the shortest
order-to-delivery time and for which products it is acceptable that the production
and delivery takes a bit longer. This decision is based on sales regions and market
segments such that a product can have different order-to-delivery times in different
regions. The implementation of this segmentation has impacts on a production
decision: PTO, ATO and ETO products. Vice versa, the production has impacts on
delivery-times. This is why the sales view on delivery times is clearly separated
from the logistics view on production times. As a result, some complex product
combinations or systems are pre-fabricated and sold as PTO products, so that they
can have a short delivery time.
• Designing customer view on product selection, configuration and processing
(defining user experience, “talking in a customer-understandable language”):
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 user should not be aware of this
distinction. To the user, the sales process should always ”feel” the same.
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. 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 an 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 user does not notice whether he is selecting a
discrete product, configuring a complex system, and so on.
• Homogenizing and standardizing products and product components (less ETO
and more ATO products):
One of the main reasons for re-structuring the business organization is to
improve sales of product combinations. In order to do so a homogeneous modular
system is needed; i.e. the components and products must have the same
characteristics, the need to be “comparable”.
This step has mostly been implemented by defining the common ontology. New
products are integrated into this ontology and thereby must adhere to the given
structure and use the pre-defined characteristics. However, there still are some old
products that were developed before the ontology was defined and use a different
product structure and naming system. In order to reach “comparability” between
the whole product portfolio and with such enable modular product architecture, the
description of old products must be transformed to match the new ontology.
• Increasing product modularity / reusability in larger contexts (i.e. product
combinations and systems) (less ETO and more ATO products):
In addition to the previous step, the structure of product combinations and
systems needs to modularized. “Comparable” modules have the key ability to be
used in multiple configuration contexts. General product model architecture needs
to be set up.
70
This is one of the major fields of research in the area of configuration [13-15].
In the coming years we will implement a single product configuration platform that
is able to deal with all the different types of products, i.e. selection of simple
Fig. 7. Reusable products within modular product model architecture are treated as "black
boxes".
discrete products, configuration of simple products as well as configuration
of product combinations and systems. The configuration model architecture needs
to be well-thought out in order to achieve modularity and reusability. This means
that on the side of configurator build-time there is a large potential of reducing
(redundant) work by reusing the configuration model of a product in the larger
context of product combination (Figure 7).
In a modular configuration model architecture the reusable product model is
created once and can be included into larger contexts; it is then treated as some sort
of “black box”. In order to include “black boxes” into larger system models, the
“interface” of this box needs to be well-defined. Talking about product models
such an “interface” can be seen as a fixed set of characteristics that are known from
the outside. These characteristics need to encapsulate all variability of the product
such that selecting values for all interface characteristics results in a complete and
consistent configuration of the module (e.g., [16]).
• 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 product development and product lifecycle management
together with the desired outcome. Doing so can help improving interoperability
and avoiding redundant tasks e.g. in data maintenance.
• Homogenizing and standardizing product master data (increasing master data
quality; e.g. for being able to compare product components, which is necessary to
build modular product combinations and systems):
In one of the previous steps we already homogenized and standardized products.
This means that product descriptions adhere to a given structure and have common
characteristics. Designing product model architecture for the configuration
platform also requires good product master data quality. The goal here is being
able to compare product components, which is necessary to build modular product
combinations and systems.
This step has mostly been implemented by defining the common ontology and
forcing the use of globally defined attributes in the NOC tool. This tool enforces
the use of globally defined characteristics, which makes product descriptions
71
“comparable”. However, currently this is limited to sales-related characteristics
(characteristics in the company’s ERP system). The approach should be extended
to include technical attributes (characteristics in in the company’s PDM system)
and application attributes (currently not globally pre-defined) as well. After doing
so the configuration models are always coherent for all the abstraction levels: i.e.
logistics-oriented, sales-oriented or application-oriented. For example, having a
global definition of application characteristics allows for generic specification of
product applications and “under-the-hood” selection and configuration of different
types of products without technical background.
• Implementing tool support for the changed processes (supporting the improved
business processes):
Last, but not least, the configuration platform (run-time application) as well as
the data supply route (build-time tools) need to be implemented. This includes
building configuration models according to the general product model architecture.
Some tools for the current business organization have been implemented. The
productive use of all these tools (except CONFig) proves that the ideas behind the
common ontology work well. Currently, there are multiple tools that have to be
used within a single business process. In the future prospective a single tool for the
different data creation steps is sought, which would support the whole process of
building up a well-structured product portfolio and the corresponding product
configuration platform. This includes data from new product development (storing
structured data from early stages like product specifications) via creating logistics
and sales-oriented configuration models up to designing and structuring the
configuration workflow within the configuration application (see also Figure 5).
Conclusions
The paper analyses gaps in the major business processes around product configuration
that are required for efficient support of new types of products (integrated solutions)
for both internal use and for customers. The gaps have been identified in the
following areas: product portfolio; customer view on product selection, configuration
and processing; products, product components and master data homogenization and
standardization; product modularity / reusability; business process alignment; and IT
support. The solutions to these gaps have been identified.
Presented work is an ongoing joint research, which is still in an intermediary step
of implementation. The future work will include refinement of the achieved so far
results, as well as variant management research as a way to optimize the number of
product variants offered to a specific market segment while reducing the complexity
of product development.
The research is based on the company Festo, however, the results can give
significant input to achieve benefits for component manufacturers that tend to become
system vendors in general.
Acknowledgments. The paper is due to the collaboration between Festo, encoway
and SPIIRAS. Some research results have been developed under projects funded by
72
grants # 15-07-08092, # 13-07-00271, # 14-07-00378 of the Russian Foundation for
Basic Research. This work was also partially financially supported by Government of
Russian Federation, Grant 074-U01.
References
1. Zhang, M.-R., Yang, C.-C., Ho, S.-Y., Chang, C. H.: A study on Enterprise under
Globalization Competition Knowledge Management and Creation Overhead Construction.
In: Journal of Interdisciplinary Mathematics, 17(5-6), 423-433 (2014)
2. Erdener, K., Hassan, S.: Globalization of consumer markets: structures and strategies.
Routledge (2014)
3. Ceschin, F.: Product-Service System Innovation: A Promising Approach to Sustainability.
In Sustainable Product-Service Systems, Springer International Publishing, 17-40 (2014)
4. Wallin, J., Parida, V., & Isaksson, O.: Understanding product-service system innovation
capabilities development for manufacturing companies. Journal of Manufacturing
Technology Management, 26(5), 763-787 (2015)
5. Oroszi, A., Jung, T., Smirnov, A., Shilov, N., Kashevnik, A.: Ontology-Driven Codification
for Discrete and Modular Products. Int. J. of Product Development, Inderscience, 8(2), 162-
177 (2009)
6. VDMA, German Engineering Federation (2014), http://www.vdma.org/en_GB/.
7. Smirnov, A., Kashevnik, A., Teslya, N., Shilov, N., Oroszi, A., Sinko, M., Humpf, M.,
Arneving, J.: Knowledge Management for Complex Product Development: Framework and
Implementation. Proc. of the 10th International Product Lifecycle Management Conference -
PLM13. Springer, 409, 110-119 (2013)
8. Sabin, D., Weigel, R.: Product Configuration Frameworks - A Survey. In: EEE intelligent
systems. IEEE Computer Society, 13(04) (July/August), 42-49 (1998)
9. Bernard, A. and Tichkievich, S. (Eds.): Methods and Tools for Effective Knowledge Life-
Cycle-Management. Springer, 588p. (2008)
10.Saidani, O., and Nurcan, S.: Business process modeling: a multi-perspective approach
integrating variability. Enterprise, Business-Process and Information Systems Modeling.
Springer, Lecture Notes in Business Information Processing, vol. 175, 169-183 (2014)
11.Rock, G., Theis, K., and Wischnewski, P.: Variability Management. Concurrent Engineering
in the 21st Century: Foundations, Developments and Challenges. Springer, 491-519 (2015)
12.Avak, B, Variant Management of Modular Product Families in the Market Phase: VDI-
Verlag, Düsseldorf, ISBN 3-18-318016-2 (2006)
13.Levandowski, C. E., Jiao, J. R., and Johannesson, H.: A two-stage model of adaptable
product platform for engineering-to-order configuration design. Journal of Engineering
Design (2015),
http://www.tandfonline.com/doi/abs/10.1080/09544828.2015.1021305#.VaUbBtztlBe.
14.Salonitis, K.: Modular design for increasing assembly automation. CIRP Annals-
Manufacturing Technology, 63(1), 189-192 (2014)
15.Lettner, D., Hehenberger, P., Nöhrer, A., Anzengruber, K., Grünbacher, P., Mayrhofer, M.,
& Egyed, A.: Variability and consistency in mechatronic design. Concurrent Engineering .
(2015) http://cer.sagepub.com/content/early/2015/05/13/1063293X15585008.abstract.
16.Savolainen, J.: Past, Present and Future of Product Line Engineering in Industry: Reflecting
on 15 Years of Variability Management in Real Projects. Proceedings of the Eighth
International Workshop on Variability Modelling of Software-Intensive Systems - VaMoS
'14 (2013)
73