# Modeling Products and Services with Enterprise Models

Kurt Sandkuhl, Janis Stirna, Felix Holz

► To cite this version:

Kurt Sandkuhl, Janis Stirna, Felix Holz. Modeling Products and Services with Enterprise Models. 13th IFIP WG 8.1 Working Conference on the Practice of Enterprise Modeling (PoEM 2020), Nov 2020, Riga, Latvia. pp.41-57, 10.1007/978-3-030-63479-7_4 . hal-03434712

HAL Id: hal-03434712

https://inria.hal.science/hal-03434712

Submitted on 18 Nov 2021

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
# Modeling Products and Services with Enterprise Models

Kurt Sandkuhl¹[0000-0002-7431-8412], Janis Stirna²[0000-0002-3669-832X] and Felix Holz¹

¹University of Rostock,
kurt.sandkuhl@uni-rostock.de, felix.holz2@uni-rostock.de

²Department of Computer and Systems Sciences, Stockholm University, Stockholm, Sweden
js@dsv.su.se

**Abstract.** Products and services are essential to an enterprise's operations and hence they need to be designed, developed, and delivered in congruence with the enterprise's business strategy and design. This paper investigates how to identify relevant aspects of products and services to be added to enterprise models by extending existing Enterprise Modeling (EM) languages for product/service modeling. The proposal is to decide on the relevance for EM based on "touch points". The proposal is applied to extending the 4EM method with a Product/Service Model and is based on literature analysis in the area of product and service modeling and on an industrial case study.

**Keywords:** Enterprise Modeling, Product Modeling, Digital Transformation

## 1 Introduction

The business purpose of an enterprise in general is to create value for its clients and revenues for its owners or stakeholders by providing products or services meeting the clients' demands and required environmental, regulatory, and market standards. Thus, products and services are a core element of an enterprise's operations and need to be designed, developed, and delivered in congruence with the enterprise's business strategy and design. Consequently, they should be represented in enterprise models if the modeling purpose relates to them. This is particularly important in application domains with changing business models due to digital transformation (DT) [1]. A typical case of DT is that traditional physical products, even with well-established market positions, change due to the creation of IoT solutions or are extended into offerings in combination with service solutions [2]. Example are energy management systems for buildings, smart manufacturing systems, security monitoring and management systems.

In this context, understanding dependencies between products and services, processes required for product/service delivery, as well as responsibilities and roles for product/service components is important or designing future organizational structures. This is a traditional application field for Enterprise Modeling (EM). However, most EM languages do not offer explicit concepts for product and service modelling. There are many approaches for modelling products in the field of mechanical engineering and production systems, but these approaches are often addressing aspects of (physical)
products (geometric shape, material specification, surface design, mechanical charac-
teristics, etc.) that are outside the scope of EM projects. Integrating these approaches
with EM methods has not been widely done and is considered challenging because of
different methodological and tooling principles. In the context of digital transformation
many companies seek to offer advanced combinations of products and services, which
requires explicit documentation and analysis of their and their customers' business,
products, services as well as digital twins as intermediaries for achieving tight integra-
tion between business operations and efficient runtime management [3].

The focus of this paper is on the investigation of *how to identify relevant aspects of products and services to be added to enterprise models*, i.e. we take the perspective of extending existing EM languages for product/service modeling. Our proposal is to decide on the “relevance” for EM based on two aspects, which we call “touch points”:

* the relationships of product/service-related concepts to existing concepts in the EM language under consideration

* the requirements from industrial practice for expressing links between operations and products/services.

We use the extension of 4EM for product/service modelling as an example.

The rest of the paper is structured as follows. Section 2 presents background infor-
mation from EM and DT. Section 3 describes the research approach used. Section 4
analyzes existing work in product/service modeling. Section 5 investigates require-
ments from an industrial case study to product modeling. Section 6 presents the touch
point approach and the extension of 4EM for product/service modeling. Section 7 pro-
vides concluding remarks and briefly explains the next steps of this research project.

2 Background to EM and Digital Transformation

## 2.1 Enterprise Modeling and 4EM

EM is the process of the creation of an enterprise model that captures all the enterprise's aspects that are required for a given modeling purpose. A key aspect in EM is the integrated view on the various aspects of the enterprise. An enterprise model therefore consists of a set of interlinked sub-models, each of them focusing on a specific aspect like processes, goals, concepts, business rules. Concerning applicability, EM is applicable for any organization, public or private, or its part.

The rest of this section gives an overview of the 4EM method [4]. 4EM is a repre-
sentative of the Scandinavian strand of EM methods. At its core is participatory stake-
holder involvement and the modeling process is usually organized in the form of facil-
itated workshops. 4EM shares many underlying principles of the, so called, multi-per-
spective, approaches that recommend to analyze organizational problems from several
perspectives, such as vision (goals, objectives), data (concepts, attributes), business
processes (processes, tasks, activities), organizational structure (actors, roles, organiza-
tional units), etc. Examples, of other approaches following the multi-perspective prin-
ciple are Active Knowledge Modeling [5], ArchiMate [6], and MEMO [7].
The 4EM modeling language consists of six sub-model types, each of them focusing on a specific aspect or perspective of the enterprise – goals, business rules, concepts, business processes, actors and resources, as well as Information System technical components. 4EM distinguishes relationships with which the modeling components are related within the sub-model and relationships with components of other sub-models. The latter relationship type is called inter-model relationship. They are used to trace decisions, components and other aspects throughout the enterprise model. For example, the motivation for why certain business process exists in an enterprise is established with an inter-model relationship to a motivating goal. 4EM also supports integration with other modeling languages and methods by allowing to define new inter-model relationships between the 4EM components and components of the modeling language to be integrated. This is the approach for the inclusion of the product sub-model in 4EM discussed in section 6.

## 2.2 Digital Transformation

In scientific literature, digital transformation often is discussed in the general context of digitalization and considered as the most complex digitalization phase [8]. The focus here is on the disruptive social and economic consequences which, due to the potential of digital technologies to substantially change markets, lead to new technological application potentials and the resulting changes in economic structures, qualification requirements for employees and working life in general. More concretely, [9] proposed to distinguish between transformation of the value proposition and the value creation when analysing and planning digital transformation. These two “dimensions” can be divided into different steps of digitalization which form the prerequisite for the next step. In previous work, we proposed the following steps [10]:

In the operations dimension, the steps can be defined as (1) replacing paper documents with digital representations, (2) end-to-end automated processing of this digital representation within a process and (3) integration of all relevant processes within the own enterprise and with partners. On the product dimension, the most basic step are physical products without any built-in information or communication technology (ICT). Digitization steps are (1) to enhance the product/service by providing complementary services (maintenance information, service catalogs) without actually changing it, (2) to extend functionality and value proposition of products by integration of sensors and actuators, and (3) redefinition of the product or service which leads to a completely new value proposition or offering. In general, a completed digital transformation would require completion of all three steps in both dimensions.

## 3 Research Approach

This study is part of a research program aiming to provide methodological and tool support for organizations in dynamic contexts, e.g., supporting the process of digital transformation, capability management, product and service design. The 4EM method has been used to support parts of methods for capability management [11]. This work
reports on the extension of 4EM with specific support for product and service design. It follows the five stages of Design Science Research (DSR) [12], namely, problem explication, requirements definition, design and development of the design artifact, demonstration, as well as evaluation. The need to extend 4EM has been identified in the projects it has been applied over the years, hence, in the DSR terms, the problem did not need additional investigations. This study concerns the DSR steps concerning requirements for the 4EM extensions, its construction, and demonstration. The requirements have been elicited from an analysis of existing literature on product and service modeling as well as from an industrial case study. The initial problem definition and requirements analysis led to a conclusion that 4EM extension should address the key aspects of product and service modeling instead of the entire spectrum of this area of modeling. Hence, the research question for the case study was to identify what are the central concepts of product modeling that need to be integrated with EM from use case perspective. Based on the research question, we identified industrial cases of digital transformation that deal with product and service development, i.e. we performed qualitative case studies in order to obtain relevant and original data (see section 5). Qualitative case study is an approach to research that facilitates exploration of a phenomenon within its context using a variety of data sources. Such a multi-perspective view ensures that deep understanding of the subject. The case study used three different perspectives represented by the sources of data: we analyzed documents about business models, products, manufacturing process of the companies; we performed workshops targeting digital transformation and DTs as part thereof; and we interviewed domain experts. Yin [13] differentiates case studies explanatory, exploratory and descriptive. The case study in section 5 are considered descriptive, as it describes the phenomenon of initiating product and service development and the real-life context of digital transformation.

# 4 Approaches to Product Modeling

Based on a literature analysis, we identified approaches for modelling products and services from different fields which are presented in sections 4.1 to 4.5. In section 4.6, we extract the perspectives on product/service models visible in these approaches. The perspectives are input for identification of touch points in section 6.

## 4.1 Feature Model

A feature model describes a product from the customer's point of view by recording functionalities, characteristics, and quality features that are important for the customer and their interdependence. Feature models are frequently used in software development and in the corresponding description of product lines or system families. The semantics of feature models have both a descriptive and an informative function. According to Riebisch et al. [14] feature models are supposed to close the gap between the requirements and the solution. For example, they are used to define products and their variants or configurations, to describe different possibilities or characteristics of a product line, to design new products, and to add new features to an existing product line.
A product is described by means of its properties, that is, features. The features can be divided into further features to create a hierarchy. Not every feature has the same meaning for the product. This results in the following different categories of features:

- Functional features describe the behavior of the product or the way the user can interact with it. The functions of the product can be seen as both static and dynamic functional features.

- Interface features describe conformity of product with a standardized system.

- Parameter features are countable, listable properties of the product, which can be non-functional or result from the application context.

- Concept features represent an additional category to better structure a feature model. The root of a feature model always represents a concept feature. This abstract feature contains a class of solutions.

To adequately describe a certain characteristic of a product family, i.e. a concrete product, the individual relations between the features must be represented. The connections between features can be hierarchical or non-hierarchical. In addition to "and", "or", "optional", and "necessary" relationships, features can be related to each other, for example by means of the following categories:

- Sub-feature relationship: This relationship is responsible for constructing the hierarchy to represent feature associations and affiliations. This hierarchical relationship can also include the semantics of a prerequisite relationship or exclusion relationship.

- Refine relationship: This relationship routes from a feature to a more detailed sub-feature. It includes an actual or partial meaning.

## 4.2 Bill of Material

A Bill of Material (BoM) of a product according to [15] specifies how a product is constructed from its sub-components. A BoM is characterized by its structured representation for identification and selection of products. It can be used with its composition sequences used as a rough construction plan to identify bottlenecks within it or making design and service decisions. Especially with a high number of different variants of a product, it can make sense for a company to know which part is in which product, e.g. to check and refresh the stock of these parts or products (material planning) or use the implicit characteristics to drive forward a product and market analysis.

The BoM model maps a product by placing its components in a hierarchical tree structure can be assigned. A product consists of components that in turn can also consist of components. In the root of the tree structure is the top product. This is the end product, so to speak, and not part of other product, as it does not have a parent node. The leaves of the tree structure are called primary products. They cannot be split into any other components and are mostly purchased from third parties in production. Model components, that have both child and parent nodes are called subassemblies and in the real world titled as components to be assembled. There is only one relation type in the BoM model for specifying Consists-of/belongs-to-meaning. A parent node consists of its child nodes; vice versa, the child nodes belong to the parent node or are part of it.

Two more values are added to the relationship - the number of components that are required for the higher-level product (quantity-per), and the components are given an
additional number to define the sequence to determine in which the components of the
level are assembled to the higher product will be. [15]

4.3 Core Product Model 2

The Core Product Model (CPM)2 according to [16] is an abstract, generic model with a generic semantics. The semantics are domain independent and can be used to extrapolate to a concrete implementation model. CPM2 supports Product Lifecycle Management (PLM) by providing product information for different phases of product design. Thus, some model components at different stages have different purposes.

In early concept phases of product design, when the shape of the product is still is
not fully developed, the functional aspect of the model supports the identification of the
requirements and functions and the allocation of the expected functions of the product.
According to [16], the following object classes can be identified within the CPM2:

- The artifact (asset) is a primary concept of product design and the central concept of the CPM2, which provides a unique physical entity within of a product, be it a component, an assembly or a part of the product. By using artifacts and sub-artifacts, you can construct hierarchy.

- A feature in CPM2 is a part of the shape of the artifact, which has a specific function. For example, an artifact can provide design, analysis or manufacturing features which determines their respective functions. Furthermore, features can arise from features. The feature is also created as an aggregate of function and form considered.

- The function describes what the artifact should do. It can also be considered an
intentional or expected behavior (intended behavior).

- The form of the artifact describes the proposed solution of a (design-) problem. It is specified with its function and represented by their geometry and material.

- The behavior describes, contrary to the function, what the artifact (or the form) actually does. By identifying the inputs and outputs, the behavior of the form evaluated and compared with the expected behavior will be.

- The geometry describes some prominent or visible aspects of the artifact, by specifying and refining the shape. Under Geometry there is also to understand the arrangement of materials in the mold.

- The material is the description of the internal composition of the artifact.

- The specification represents a collection of relevant information about the artifact.
The relevant aspects depend on customer requirements and technical prerequisites. A
specification is composed of requirements or prerequisites.

These objects can be represented by the relation types are related to each other:

- A constraint is a specific common property of a group of entities.

- Entity Association describes a "membership" relationship between core entities of the product.

- Usage is understood as a mapping function from one entity to another entity.

- The path relationship (trace) shows dependencies between particular entities.

- Decomposition: All object classes have their own independent decomposition hierarchy. This means that identical classes can be build a part-of-relationship.
## 4.4 Service Meta-model

For more than 20 years, there has been a discussion about “servitization” in manufacturing industries, as many manufacturers increasingly combine their products with services and solutions [17]. Closely related to servitization and equally relevant for modeling products and services is the research on product-service systems (PSS), such as, engineering methodologies [18], modeling methods and modeling languages for PSS [19]. This research confirms the importance of supporting the modelling of services.

The term “service” can be defined in many fundamentally different ways. [20] discusses some of the problems and contradictions resulting from different definitions. In research and industry, service dominant logic (SDL) receives much attention. According to SDL [21] a service is characterized by, among other aspects, value co-creation. This means that “value is cocreated by multiple actors, always including the beneficiary” [21] and “value cocreation is coordinated through actor-generated institutions and institutional arrangements” [21]. This confirms our view that a model of an enterprise’s services should not be isolated but interlinked with other EM perspectives.

The meta-model presented by [22] builds upon the service blueprinting approach [23]. It integrates its concepts into a formal meta-model and adds concepts for (IT) self-services. The following classes or concepts are present in a service model of [22]:

- “Actions” can be used to represent the sequences of actions (action flows) of different categories of actors in a service process.

- “Actor categories” offer the possibility to represent the communication flow and the four horizontal lines of a service blueprint separating the actor categories (line of interaction, line of visibility, line of internal interaction, and line of implementation). Actor categories are customer, onstage personnel (i.e., service personnel with face-to-face contact with the customer), backstage personnel (i.e., service personnel or system invisible to the customer), support personnel, and management (i.e., service managers responsible for planning, managing, and controlling).

- “Capabilities” reflecting what is required to perform a service (input perspective).

- “Service” representing the actual service (output perspective).

- “Props and physical evidences”: the tangibles with which the customer interacts during the service process.

- “Fail points” for actions that can fail when performed.

- “Constraints” define conditions for services for customer groups. Before provision of the service, the connected constraints rules are checked.

## 4.5 STEP

The STEP approach implements the ISO 10303 standard [24] and combines several concepts of product modeling with each other and specifies a uniform format, for the exchange of product information. The exchange format primarily supports computer-aided systems by standardizing product model data and consistent data management.

STEP has a wide range of applications and is used for different types of products, among others for electromechanical products, fiber compositions, ships, architectural projects etc., but also product life cycle stages are supported. Products before, after, or
during the production process can be mapped and structured can be saved. The native information modelling language for STEP is EXPRESS. EXPRESS provides generic entities, which can deal with attributes, rules, and restrictions which allows forming generally valid data structures. The generic entities are independent of the specific application. Certain domains can use the application-specific resources integrated in STEP. Depending on the purpose of the model, new model components can be added without inconsistencies in data exchange. STEP allows a precise and useful presentation of products, which are suitable for the product is tailor-made. However, the presentation is mostly technical, making it rather unsuitable for interpersonal purposes.

## 4.6 Perspectives in Product/Service Models

The analysis of the approaches presented in sections 4.1 to 4.5 resulted in different ways to structure the information included in existing product modelling approaches, like, e.g., product lifecycle phases (from target setting to end-of-life recycling), stakeholder concerns (user, designer, producer, owner, etc.) or aspects of product realization (function, geometry, material, surface, etc.). We decided to apply the product realization phases as aid to sharpen the view on the actual product information. Table 2 shows the product-related features identified this way.

<table><caption>Table 2: Product-related features extracted from approaches to product modeling</caption><thead><tr><td></td><td>Requirements</td><td>Design</td><td>Construction</td><td>Production</td><td>Operation</td></tr></thead><tbody><tr><td>Feature Model</td><td>Functional and quality features, characteristic</td><td>Interface and parameter features</td><td></td><td></td><td></td></tr><tr><td>Bill of Material</td><td></td><td>Product and sub-components, variants</td><td>Construction plan</td><td>Composition sequence</td><td></td></tr><tr><td>Core Product Model 2</td><td>Functional and quality features, assignment to components,</td><td>Construct hierarchy, intended behavior, technical prerequisites</td><td>Shape, form, geometry, material</td><td>Manufacturing features</td><td></td></tr><tr><td>Service meta-model</td><td>Service catalog, customer groups, constraints</td><td>Action flow for service, fail points, capabilities</td><td>Refined action flows, communication flow, other actors categories, props</td><td>Actions at fail points, solutions</td><td></td></tr><tr><td>STEP</td><td></td><td>2D, 3D geometry, shape, surface, material, composition</td><td>Composition, subcomponents, rules</td><td>Assembly sequence, production system spec., tool spec.</td><td>Maintenance spec., operations flow</td></tr></tbody></table>
# 5 Industrial Case Study

Section 4 presented a view on product/service modeling dominated by the knowledge visible in scientific publications. This section is meant to add a perspective from industrial practice. Our aim is to contribute an indication what perspectives from 4.6 are of visible importance for industrial cases.

The use case company is a medium-sized manufacturer of different kinds of pumps and pumping technologies, e.g. swimming pool pumps, sewage pumps, industrial pumps for heavy environments, and ship pumps. The company is well-established on the European and US-market and has in some market segments a market share of more than 70%. Although the overall business is stable and developing well, the management of the company decided to explore new service opportunities and business models applying digital technologies. Thus, the idea of the company's product management is to integrate sensors into pumps and transmit the information to the back-office by using a data communication node. This general idea can be classified as enhancing pumps into smart connected products [25] or Internet-of-Things (IoT) devices.

From a research perspective, the opportunity for data collection at the case study company in a qualitative case study emerged when the company agreed to start a study on digital transformation options. The study so far included two meetings at the company's headquarter and several interviews by phone or skype. The first meeting was directed to the top management of the company with a focus on clarifying general steps of digital transformation, possible procedures and aspects of the enterprise to be considered. The second meeting was a workshop was directed towards identifying concrete digital transformation options and potential ways of implementation. For the research question given above, this workshop and the preparatory interviews were most relevant and will be in focus of the following.

One purpose of the preparatory interviews for the workshop was to understand the current situation of IoT and sensor integration into the company's products. The key expert here was the research and development manager. Before the interview, guidelines consisting of a list of questions and aspects to explore were prepared. During the interview that was conducted by one researcher and took 30 minutes, notes were taken. As a preparation of the digital transformation workshop, the participants were selected to include all relevant departments of the company (product development, production, marketing, sales & distribution, and services) and members of top and middle management. All eight participants were informed in beforehand about the purpose of the workshop and importance of their participation. The workshop as such included the collection and clustering of new product and services ideas from the participants, joint definition of priorities, and development of a business model prototype for the top 3 product/service ideas. The content of the workshop was documented in photo documentation of collected ideas and clusters, written documentation of the business model prototypes, notes taken during the workshop for capturing additional information regarding ideas and business model.

In the context of this paper, the documented interview and workshop content were analyzed. The product manager stated as one of the motivations for the workshop:
"Our device linking a pump to the Internet is nearly ready. It captures data and puts them into our own cloud. So far, we only capture data about malfunction or energy consumption that is anyhow visible on the pump's display. But we do not have a good idea, how to do business with this data. And we probably need more sensors."

Among the top innovation ideas were (a) smart pumps and (b) pumping as a service, which the workshop participants both related to the need of combining products and services. When discussing the smart pump, the sales representative explained: "We understand that our bigger customers want to have control if our pumps do what they are supposed to do during operations. Some of them call it the digital twin. This would help us to sell pumps to them. We have to use or develop sensors that deliver this kind of information."

Pumping as a service basically aims at selling the functionality of the pump instead of the pump as physical device which would lead to a service agreement where the company is paid for pumped cubic meters or hours of pumping. One of the participants remarked to this idea: "For this, we need full control what is happening with the pump. So, we need something like continuous monitoring which raises alarms if something goes wrong."

When developing the business model prototype for pumping as a service, most of the discussion time was spent on organizational issues within the company: "where does all the information from our pumps arrive, how do we make sense out of it and how do we organize the reaction?" For the smart pumps, the discussion more was about "how do we integrate our pumps in the control system of our customer and what kind of sensors do we need?" Furthermore, the development department mentioned "We would need to know what technical basis our customers use for their control systems and the interfaces we have to provide. But most of our customers have no answers to these questions. Sometimes we get the impression that they simply don't know." In principle, it can be said that all phases of product development and all product-related concepts identified in section 4.6 have some relevance for the case study, as the identified new business models and the resulting products and services will have to be subject of a complete product development lifecycle. However, some concepts were more central and intensely used in the case study:

- The characteristics of the products/services of relevance for business models (features, requirements, etc.)

- The parts, composition and variants of products/services (component, sub-products, etc.)

- The relation of actors and roles as well as organizational processes to products/services

# 6 Extension of 4EM for Product and Service Modeling

## 6.1 The Approach of "Touch Points"

4EM consists of six sub-models for modeling goals, concepts, business rules, business processes, actors and resources, and information system technical components and
requirements. They are designed to be sufficiently general to be able to capture and represent most modeling problems related to organizational designs. The study reported in [26] concluded that considering their generality the expressiveness for product and service knowledge is reduced. Hence, as discussed in the previous sections, this was deemed insufficient as more and more integrations of products and services with the rest of the organization's design needs to be supported, especially in the context of digital transformation. The use case requirements also suggest that 4EM should be extended for this particular modeling purpose instead of suggesting to model the enterprise design issues with 4EM and product-related issues with one of the existing sub-models (see section 2). In this context, one of the most difficult decisions was the level of integration of the product/service sub-model into 4EM and particularly the extent of product or service information to be documented with the constructs of the sub-model. We investigated the following options:

- For a domain-specific modeling language the requirements of the domain are decisive. Thus, targeting the 4EM language for the domain of manufacturing probably would have resulted in a different set of product modeling concepts than for the domain of banking, to take one example. However, 4EM is meant to be application domain independent, which is why we did not specify it for a particular application domain.

- In a design or construction-oriented mindset, we would have used a number of real-world cases and their business requirements to derive requirements to product modeling and define the meta-model accordingly. However, the selection of cases and their domains and modeling purposes would have been affecting or even be decisive to what requirements are visible.

- For the support of specific modeling purposes, such as modeling for digital transformation, the requirements of the domain are decisive.

- Extensive incorporation and use of approaches from other multi-perspective EM languages would violate the minimality principle of the 4EM modeling language.

Finally, the decision was made to use what we termed the “touch point” centric approach. At its core is the principle to only include concepts in the product sub-model which can serve to represent aspects or characteristics of products where the other perspectives (modeled in the 4EM sub-models) “touch” products. The “touches” can be operationalized as follows:

- A relationship type of the sub-model that can be used to connect a concept of the sub-model with a product-related concept indicates a touch point.

- If a product-related concept complements the concepts of a sub-model, this indicates a touch point.

- If a semantic relationship between a product-related concept and a concept of the sub-model can be defined that represents an aspect relevant for the enterprise, this indicates a touch point.

Using the above operationalization, Table 3 shows the touch points for the different 4EM sub-models. The touch points will be modeled with 4EM inter-model links.
<table><caption>Table 3: The touch points between 4EM sub-models and the Product/Service Model</caption><thead><tr><td>4EM sub-model</td><td>Relationship type to connect product-related concept</td><td>Product-related concepts complementing 4EM</td><td>Semantic relationship relevant for an enterprise</td></tr></thead><tbody><tr><td>Goals Model</td><td>"motivates" or "supports" (e.g. goal motivates feature, feature supports goal; product/component supports goal)</td><td>Features, functions and requirements support goals or sole problems of an enterprise</td><td>Feature supports goal; product/component supports goal</td></tr><tr><td>Business Rules Model</td><td>"triggers" delivery of product or execution of service</td><td>Quality aspects or regulations that are subject of rules</td><td>Rules that trigger delivery of services or products</td></tr><tr><td>Concepts Model</td><td>"related_to" (e.g. a concept that relates to and specifies products, services, components or features)</td><td>Attributes of products, services or components</td><td>Specification of concepts related to products, services, components or features</td></tr><tr><td>Business Process Model</td><td>"related_to" (e.g. a process that defines activities regarding products, services, components or features)</td><td>The products, services, sub-components that were subject of activities in a process</td><td>Products, services, components or features are developed and delivered in processes</td></tr><tr><td>Actors and Resources Model</td><td>"responsible_for" (e.g. actor responsible for product or feature)</td><td>Actors' responsibility for products, services, sub-components</td><td>Actors are responsible for Products, services, components or features. Resources required for delivery.</td></tr><tr><td>Technical Components and Requirements Model</td><td></td><td>Product requirements when related to IT components in products</td><td></td></tr></tbody></table>

## 6.2 4EM Product/Service sub-model

The Product/Service Model (PSM) describes what is offered to the enterprise's customers in terms of (physical or digital) products and services, as well as what dependencies exist between them. The components of PSM can be used to describe essential characteristics of products and services in terms of decomposition structure (i.e., products, components) and value proposition for the customer expressed in features. Through links to and from the other sub-models, the PSM shows what processes and actors are involved in the value creation and administrative activities for the different processes and services. The components of the PSM are related to each other through unidirectional semantic links of which the three main types are *part_of*, *is_a* and *requires*. Component types of the Product/Service Model are the following: *product/service* (with the possibility to specialize into *product* or *service*), *component*, *feature*.

*Product/Service*: The model component Product/Service is used if either a combination of products and services is modeled or if the phenomenon under consideration is undecided to become product or service. In case of a combination of product and
service, the naming of the product/service should indicate this by including the product name (substantive) and a verb phrase for the service, for example "ventilation system and providing maintenance". *Services* are intangible and performed by the enterprise only if the customer requests them; the customer usually participates in service delivery. Services can be divided into Components that also can be Services and (optionally) can include Products. Each Service (and also every Component of a Service) should be associated to a Business Process that specifies how the service is provided. A *Product* is produced by an enterprise and offered to its customers in exchange for a (usually monetary) compensation. Products can be physical, digital, or virtual (see also the introduction to this section). Products can be divided into Components that also can be Products and (optionally) can include Services. Each Product (and also every Component of a Product) should be associated to an Actor responsible for the product/component and may be associated to a Business Process that specifies how it is manufactured. When modeling products and their decomposition it may be of relevance to distinguish between different variants of a product, which can be done in 4EM in two ways:

- If the variants originate from the use of different components in the product, they can be modeled with the common product name in the root and the different variants as sub-trees below this root where the top-element in the sub-tree carries the name of the variant

- If the variants originate from a configuration of the product which is not reflected in a difference in components, the variant attribute of the product should be used to describe the variants.

*Component* is a distinguishable part of a product (or service) which is supplied by a partner or produced in the enterprise. If produced in the enterprise, a component should be associated to an Actor responsible for the component and may also be associated to a Business Process that specifies how it is manufactured. If a component is supplied by a partner, it should be associated to an external actor or external process used for procurement of the component.

A *feature* is a characteristic or function of a product (or service), which is of value to the customers (or the target groups) using the product (or service). Thus, features also are distinguishable characteristics of the products and services. Features should be used to model

- what the value propositions to the customers are and has to be taken into account when designing the product/service or marketing it

- what the characteristics of the product/service is that create value for customers and are used or might be used in creating product variants or bundling/packing products/services with other products/services.

The relationship types between the components of the PSM are: *part_of*, for specifying aggregation, *is_a* for specifying specialization, and *requires* to specify that the implementation of a feature require a certain product, service or component. See meta-model of the PSM on (fig.1). For the sake of brevity only one inter-model (IM) link of type goal from Goals Model (GM) motivates PSM modeling constructs is depicted (concepts in grey).
<figure><img src="image_2.png" /><figcaption>Fig. 1. Meta-model of the PSM</figcaption></figure>

<figure><img src="image_3.png" /><figcaption>Fig. 2. Example of a PSM and inter-model relationships</figcaption></figure>

Fig.2 shows an example of a product (PS21) and its components using part_of rela-
tionship as well as features that require the components. Dashed lines are used for inter-
model relationships, e.g. Goal 2 motivates the need to produce PS21 and Feature 3
supports Goals 2.1.
# 7 Conclusions and Future Work

We have investigated the current contributions in the area of product modeling and on the basis of an industrial case study proposed an extension for product and service modeling to the 4EM method. The elaboration of the newly proposed sub-model, namely PSM, for 4EM was based on the principle of “touch points”. That is, touch points needed to be supported with 4EM inter-model links in case there is a need for (i) relationships that connect other 4EM sub-models with components of the PSM, (ii) the PSM components complement the concepts of another 4EM sub-model, and (iii) the connection between concept of the PSM and another 4EM sub-model represents something that is relevant to the organizational design. The proposal for the PSM has been tested in a number of thesis projects and is currently being implemented in the 4EM modeling tool using the ADOxx modeling platform [27].

Concerning issues for future work, in [3] we proposed that digital twins need to support dynamic configuration and adaptation depending on the application context as part of capability management [11]. Hence, parts of organizational capability designs specifying aspects such as context, measurable properties, KPIs, data sources, and capability adjustment algorithms need to be linked to product and service models because these aspects motivate features and components in the product or service design. Capability management also supports model-based generation of monitoring dash-boards that would need to be supported by certain features in the products or services that are being monitored, particularly when it comes to runtime data provision and implementation of the triggering mechanisms in physical products.

# References

1. Matt, C.; Hess, T.; Benlian; A.: Digital transformation strategies. Business & Information Systems Engineering, 57(5), 339-343. Springer (2015)

2. Porter, M. E., & Heppelmann, J. E.: How smart, connected products are transforming competition. Harvard business review, 92(11), 64-88 (2014)

3. Sandkuhl K., Stirna J.: Supporting Early Phases of Digital Twin Development with Enterprise Modeling and Capability Management: Requirements from Two Industrial Cases. In: Nurcan et al. (eds) Enterprise, Business-Process and Information Systems Modeling. LNBIP 387, Springer (2020)

4. Sandkuhl K., Stirna J., Persson A., Wißbotzki M.: Enterprise Modeling – Tackling Business Challenges with the 4EM Method, Springer (2014)

5. Lillehagen F., Krogstie J.: Active knowledge modeling of enterprises. Springer (2008)

6. The Open Group: ArchiMate 3.0 Specification, Published by The Open Group (2016)

7. Frank U: Multi-perspective enterprise modeling: foundational concepts, prospects and future research challenges. Softw Syst Model 13(3):941–962

8. Rifkin, J. The Third Industrial Revolution: How Lateral Power Is Transforming Energy, the Economy, and the World. (2013)
9. Berman, S. J., Bell, R.: Digital transformation: Creating new business models where digital meets physical. In *IBM Institute for Business Value* (2011)

10. Sandkuhl, K., Shilov, N., Smirnov, A.: Facilitating Digital Transformation by Multi-Aspect Ontologies: Approach and Application Steps. IJSM (2020)

11. Sandkuhl, K., Stirna, J. eds: Capability Management in Digital Enterprises. Springer International Publishing, Springer (2018)

12. Johannesson P., Perjons E.: An Introduction to Design Science. Springer (2014)

13. Yin, R. K.: Case study research: Design and methods. SAGE (2002)

14. Riebisch, M., Streitferdt, D., Pashov, I.: Modeling variability for object-oriented product lines. In European Conference on Object-Oriented Programming (pp. 165-178). Springer (2003)

15. Hegge, HMH, Wortmann JC: Generic bill-of-material: a new product model. International Journal of Production Economics, 23(1-3):117-128 (1991)

16. Fenves, S. J., Foufou, S., Bock, C., and Sriram, R. D. CPM2: A Core Model for Product Data. ASME. J. Comput. Inf. Sci. Eng. 2008; 8(1): 014501 (2008).

17. Baines, T., Lightfoot, H., & Smart, P.: Servitization within Manufacturing. Journal of Manufacturing Technology Management, Vol. 22 No. 7, pp. 947-954.

18. Thomas, O.; Walter, P.; Loos, P.: Design and usage of an engineering methodology for product-service systems. Journal of Design Research, 2008, 7 (2), pp. 177-195.

19. Boucher, X.; Medini, K.; Fill, H.-G.: Product-service-system modeling method. In: Domain-Specific Conceptual Modeling. Springer, Cham, 2016. S. 455-482.

20. Alter, S.: Answering key questions for service science. In Proceedings of the 25th European Conference on Information Systems (ECIS), Guimarães, Portugal, June 5-10, 2017 (pp. 1822-1836). ISBN 978-989-20-7655-3.

21. Vargo, S. L., & Lusch, R. F. (2016). Institutions and axioms: an extension and update of service-dominant logic. Journal of the Academy of marketing Science, 44(1), 5-23.

22. Baer, F., Sandkuhl, K., Leyer, M. et al. DESERV IT: A Method for Devolving Service Tasks in IT Services. Bus Inf Syst Eng (2020). https://doi.org/10.1007/s12599-020-00655-y

23. Bitner, M. J., Ostrom, A. L., & Morgan, F. N.: Service blueprinting: a practical technique for service innovation. California management review, 50(3), 66-94, 2008.

24. Pratt, M. J: Introduction to ISO 10303—the STEP standard for product data exchange. Journal of Computing and Information Science in Engineering, 1(1):102–103 (2001)

25. Porter, M. E., & Heppelmann, J. E.: How smart, connected products are transforming competition. Harvard business review, 92(11), 64-88. (2014)

26. Lantow B., Dehne M., Holz F.: Evaluating Notations for Product-Service Modeling in 4EM: General Concept Modeling vs. Specific Language. In proc. of PrOse@PoEM 2019: Ceur-ws.org, vol. 2499, pp. 26-36 (2019)

27. Fill, H., Karagiannis, D.: On the conceptualisation of modelling methods using the ADOxx metamodelling platform. Enterp. Model. Inf. Syst. Archit. 8(1), 4–25 (2013)