Keywords

1 Introduction

In manufacturing industries, industry 4.0 and digital transformation are interrelated fields that both motivate the development of digital twins. Industry 4.0 is a concept attracting much research and development over the last decade, including reference models [1], applications [2], standards [3] and supporting methods [4]. A core idea of Industry 4.0 is to connect physical devices (e.g., manufacturing systems and the objects they produce), digital components (e.g. ERP or MES systems) and human actors along production processes for the sake of seamless integration and continuous monitoring and control [5]. Digital twins (DT) support this core idea and can be defined as “a dynamic virtual representation of a physical object or system across its lifecycle, using real-time data to enable understanding, learning and reasoning” [6]. Digital transformation, in general, denotes adopting digital technologies, such as industry 4.0 related technologies or DTs, in the digitalization of an organization’s business model and its operations (cf. Sect. 2.3). Several researchers emphasize the importance of industry 4.0 for digital transformation [21] or, vice versa, that digital transformation motivates the implementation of industry 4.0 [20]. However, DTs as an element of digital transformation or digital transformation as driver for DT development are not included in the aforementioned work. A literature analysis (see Sect. 5) confirmed that digital twin research predominantly focuses on technological questions of DT design and operations. So far, organizational and business model related aspects of DTs are only sparsely covered in research which motivated this paper. In response to this, the paper’s objective is to investigate how DT solutions are integrated into organizational structures and business models of manufacturing enterprises, and what motivates the development of DT from a digital transformation perspective.

Enterprise Modeling (EM) is a versatile approach and is able to tackle various organizational design problems by means of multi-perspective conceptual modeling. EM captures organizational knowledge about the motivation and business requirements for designing IS [7]. Hence it has the potential of capturing and representing the organizational motivation for DT design. A key aspect of operating and managing DTs is to configure and adjust them according to the situational changes in operations. Capability Management, and in particular Capability Driven Development (CDD), has been proven applicable for managing information systems (IS) in changing context [10]. E.g., CDD supports generation of monitoring dashboards from models that include context elements, measurable properties, KPIs as well as rule-based based adjustments based on context data. In concrete terms, the goal of this paper is to analyze the suitability of EM and capability management for the purpose of supporting the development and management of DTs from an organizational perspective. We have chosen the 4EM and CDD methods for the purpose of this study because they have already established integration mechanisms between themselves and with other modeling languages.

The rest of the paper is structured as follows. Section 2 gives background to EM, CDD, and digital transformation. Section 3 describes our research approach. Section 4 presents two case studies. Section 5 summarizes the main requirements for developing Industry 4.0 solutions found in literature. Section 6 discusses the requirements from Sects. 4 and 5 with respect to CDD. Section 7 discusses an example of a capability model for the purpose of DT development. Section 8 provides concluding remarks.

2 Background

2.1 Enterprise Modeling and 4EM

EM is the process of creating an enterprise model that captures all the enterprise’s aspects or perspectives that are required for a given modeling purpose. An enterprise model consists of a set of interlinked sub-models, each of them focusing on a specific perspective, like, processes, goals, concepts, actors, rules, IS components.

4EM [7] is a representative of the Scandinavian strand of EM methods. At its core is participatory stakeholder involvement and the modeling process is usually organized in the form of facilitated workshops. 4EM shares many underlying principles of the, so called, multi-perspective, approaches that recommend analyzing organizational problems from various perspectives, e.g. AKM [12] and MEMO [11]. 4EM consists of six interconnected sub-model types for modeling a specific aspect or perspective of the enterprise – Goals Model, Business Rules Model, Concepts Model, Business Process Model, Actors and Resources Model, as well as Technical Components and Requirements Model. 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.

2.2 Capability Driven Development

In [10] the concept of capability thinking and a method to capability management are introduced. It is an organizational mindset that puts capabilities in focus of the business model and IS development. Capability thinking emphasizes that capabilities are not self-emergent, instead they should be planned, implemented, controlled, and adjusted. In doing so they need to be addressed from the perspectives of (1) vision (e.g. goals and KPIs), (2) enterprise designs such as processes and IS architectures, (3) situation context incl. measurable properties, as well (4) best practices such as process variants and patterns for dealing with context changes. Capability as a concept allows reasoning about these four aspects of the business in an integrated way because enterprises need to know how to realize the business vision and designs as well as what needs to be changed depending on real-life situations. The definition of capability is the ability and capacity that enables an enterprise to achieve a business goal in a certain context [10]. Successful implementation of capability thinking will lead to capability management as a systematic way to plan, design, develop, deploy, operate, and adjust capabilities.

CDD is a method supporting the four perspectives of capability thinking. CDD consists of a number of method components each focusing on a specific task of the capability cycle, such as Capability Design, Context Modeling, Patterns and Variability Modeling, Capability Adjustment Algorithm Specification, as well as method extensions for dealing with certain business challenges such as supporting business process outsourcing and managing service configuration with the support of open data [17].

2.3 Digital Transformation

In scientific literature, digital transformation often is discussed in the general context of digitalization and considered the most complex digitalization phase [13]. Its focus 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. [14] proposes 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 [15] we have proposed the steps for the dimensions of operations and product digitization.

In the operations dimension, the steps are (1) replacing paper documents with digital representations, (2) end-to-end automated processing of this digital representation within a process and (3) integration of relevant processes within the enterprise and with partners. On the product dimension, the departure point for digitization are physical products without built-in information or communication technology. 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. A completed digital transformation requires 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 and capability management. It follows the five stages of Design Science research [16], namely, problem explication, requirements definition, design and development of the design artifact, demonstration, as well as evaluation. This study concerns the first two steps for the design artifact supporting DT design and management from an organizational perspective. This part of our research started from the following research question which is based on the motivation presented in Sect. 1: RQ: In the context of digital transformation, how are digital twin initiatives emerging and what are the driving forces for starting implementation projects?

The research method used for working on this research question is a combination of literature study and descriptive case study. Based on the research question, we identified industrial cases of digital transformation suitable for studying the origin of DT developments, i.e. we performed qualitative case studies in order to obtain relevant and original data (see Sect. 4). Qualitative case study is an approach to research that facilitates exploration of a phenomenon within its context using a variety of data sources. This ensures that the subject under consideration is explored from a variety of perspectives which allows for multiple facets of the phenomenon to be revealed and understood. Within the case studies, we used three different perspectives, which at the same time represent 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 [18] differentiates case studies explanatory, exploratory and descriptive. The case studies in Sect. 4 are considered descriptive, as they describe the phenomenon of initiating DT development and the real-life context in which it occurs.

Based on the results of the case studies, primarily case study requirements to DT development, we selected research areas with relevant work for these requirements and analyzed the literature in these areas. The purpose of the analysis was to find existing approaches and methods for modeling DT and how they are integrated into the business. This work limits the focus on DTs in manufacturing, although they can also be used in other application fields. To summarize,

  • The case studies explore whether business models and organizational context are really relevant from industrial perspective. We focus on the early phases of DT realization, i.e. decision making and specification,

  • A literature study explores whether existing research work covers modeling approaches for business models and organizational context of DT.

4 Industrial Case Studies

4.1 Case Study A: Producer of Pumps

Company A 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 or ship pumps. Company A is well-established on the international market with a market share of more than 50% in some segments. Although its business is stable and developing well, the management decided to explore new service opportunities and business models applying digital technologies. More concretely, 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 datalink. This idea can be classified as converting the pumps into smart connected products or Internet-of-Things (IoT) devices.

The opportunity for data collection at company A emerged when the it agreed to start a study on digital transformation options. The study so far had two workshops at the company’s headquarter and several interviews. The first workshop was directed to the management with a focus on clarifying general steps of digital transformation, possible procedures and aspects of the enterprise to be considered. The second workshop was directed towards identifying concrete digital transformation options and potential ways of implementation. For our research question, the second workshop and the preparatory interviews were the most relevant and will be in focus of the analysis.

One purpose of the preparatory interviews for the second 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. The interview took 30 min and was conducted by one researcher; notes were taken. As a preparation of the digital transformation workshop, the participants were selected to include all relevant departments of company A (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 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 three product/service ideas. The workshop was documented in photo documentation of collected ideas and clusters, written documentation of the business model prototypes. Notes were taken to capture additional information regarding ideas and the business model.

The product manager stated as one of the motivations for the workshop: “Our datalink device 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 topic of digital twins. When discussing the smart pump, the sales representative explained: “We think that our bigger customers want to have control if our pumps do what they are supposed to do in their installations. 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 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 a bit like a digital twin, but for our internal purposes.”

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 was more about “how do we integrate our pumps in the DT 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 DTs and what interfaces we have to provide. But most of our customers have no real answers to these questions. Sometimes we get the impression that they simply don’t know.”

4.2 Case Study B: Tool Produces for Automotive Industry

Company B is a subsidiary of a major automotive manufacturer responsible for producing tools for the metal parts of chassis production, such as roofs, doors, side panels, etc. These tools, called (press) forms, are developed individually for each car model variant in an iterative process of casting, milling and/or welding, and polishing. Active components, such as cutters, hydraulic springs or punchers are integrated into the actual form. Putting the forms into operation in a press shop requires a try-out phase to fine-tune the forms’ precision. Company B is doing the largest share of its business with the automotive manufacturer. It also serves other automotive and truck suppliers. Due to its unique specialization on forms for a specific metal, company B is well-positioned in the market. However, its management aims to increase efficiency and flexibility in the business model to be prepared for possible future market changes.

This case study emerged when company B decided to investigate radical digital innovation focusing on disruptive ways of working or technologies instead of gradual optimization or increase in efficiency. A workshop was planned to investigate the potential for radical innovation concerning the possibilities for drastic and seemingly unrealistic changes, like, reduction of production time for forms to 10% of the current value, no setup time of the production system or internal logistics requiring no staff.

Preparation and execution of the workshop was similar to what was described for the first case study: the selected participants represented all relevant departments of the company (design, production, logistics, procurement, human resources, economics, service and customer care), mostly represented by the head of the unit or senior experts. All ten participants were informed beforehand about purpose of the workshop, the need to think “out-of-the-box” and the importance of their participation. The workshop included the collection and clustering of radical transformation of products and of operations, joint clustering and definition of priorities. Based on the priorities, an initial evaluation of the top three options for radical transformation of products and the top three transformations in operations was done. The content of the workshop was documented in photo documentation of collected ideas and clusters, written documentation of the evaluation results, and notes. The workshop was conducted by two researchers: one facilitator and one note taker. In this paper analyzes the documented content.

For radical transformation of internal operations, one of the clusters identified was named “digital twin of the own factory”. The primary intention was to always have a real-time status of all resource in the own production system including facilities, parts and staff. For the radical transformation of the products, one of the clusters was the DT of each individual form on the customers’ site. It is expected that a fully digitalized and automated press shop would need full control and real-time monitoring of the complete production flow and all components of the press shop. In this regard, the workshop participants discussed how to set up the cooperation with press manufacturers and logistics companies to discuss standards for the DT.

4.3 Case Study Analysis

The case study requirements (CSR) are derived from analysis of the two case studies and are presented in the following with a short motivation from the cases.

CSR1: DTs have to support the goals and business models of the company.

Both companies did not have any ongoing DT activity before the start of the digital transformation initiative. Once the workshops explicated ideas for service and business models that demand DT-like functionality, DTs were seriously considered and finally selected for implementation. In both cases, the primary goal is not to implement DT per se but to provide services or create a platform which can be facilitated by DTs.

CSR2: DTs are part of operations in an enterprise – either to support manufacturing execution in the own or the client’s production, or to facilitate value-added services on the customer side, like, e.g. predictive/preventive maintenance.

The concept of DT and envisioned functionality appeared in the use cases in different shapes: a) the DTs of the company’s products installed at the clients’ sites for the purpose of offering services depending on (real-time) data supply and monitoring (e.g., pumping-as-a-service requires monitoring of the pumps installed at the clients’ industrial facility), b) the DT for the control of a facility possibly integrating various components (e.g. the DT of the manufacturing facility of company B or the DT of a ship which has a pump of company A installed), and c) the combination of a) and b), i.e. the company’s product monitored in a client’s facility. E.g., the form of company B with remote monitoring for purposes of preventive maintenance and local monitoring for optimizing production in the press shop. Options a) and b) require different information to be aggregated, displayed, and monitored.

CSR3: What aspect of reality has to be represented in a DT depends on the organizational integration and the intended business model of the company.

CSR1 sates that DTs must be supporting a company’s business model. When implementing business models, this means that the digital twin has to provide the information about status or operations of the product required for the value creation underlying the business model. E.g. in case A, pumping-as-a-service requires to capture the performance of a pump to be able to invoice the provided hours or pumped volume, the energy consumption of the pump, and the status of lubricants to avoid problems in the service.

CSR4: Identification of features and parameters that have to be visible in the DT can be supported by developing business model prototypes and investigating organizational integration.

In both case studies, the options for new DT-based services were subject to an initial feasibility study. This study started from the definition of what service has to be provided for the customer, what information and functionality are required for the services (i.e., specification of features and parameters) and how this information is processed and used in the enterprise to deliver the service (i.e. the organizational processes).

CSR5: Component developers request a better methodical and technical integration of DTs (platform) development and component development.

In particular in case B, the case study company made clear that the development of a smart form would require collaboration with the manufacturer of the press for implementing the vision of a smart press shop. In case A, a similar request emerged when discussing the integration of pumps in complex systems, like, e.g. a cruising ship. Both cases showed the need for technical agreements (interfaces and platforms) and methodical agreements with the digital twin provider.

CSR6: Business models and organizational processes are subject to continuous improvement and so are DT features and parameters.

During development of business model prototypes, in both cases a kind of roadmap for stepwise implementing and extending services and business model was discussed, and the actual prototype intended to cover only the first stage. An expectation was expressed that the first stage would have to be extended based on the feedback of the customer and lessons learned from operations. With respect to modeling support, our recommendation is to explicitly model organizational context and business models as preparation of the DT design.

5 Requirements for Digital Twin Design from Literature

DTs are usually designed and operated in the context of industry 4.0. In the field of production systems, there is a substantial amount of work on DTs. In the context of this paper, the intersection of digital transformation and DT as industry 4.0 solution is most relevant. Mittal et al. [20] investigated what manufacturing small and medium-sized enterprises (SME) need to successfully adopt industry 4.0. As a result, 16 specific requirements for SME were identified including smart manufacturing solutions for specialized products, which includes DTs. Schumacher et al. [21] proposed a maturity model for assessing Industry 4.0 readiness and identify nine dimensions of maturity and 62 maturity items in their Industry 4.0 Maturity Model. The maturity items include technology and product related aspects, like digitalization of products, product integration into other systems, and DTs. Considering the objective of this research our primary focus is on supporting the fit of the DT to the organization’s needs in the industry 4.0 program, which, as discussed previously, can be supported by modeling. There have been several investigations of the needs for modeling support for industry 4.0. Hermann et al. [9] present four main principles of industry 4.0, namely:

  • Interconnection supporting various aspects of communication between actors, such as human to human, human to machine, and machine to machine.

  • Information transparency requires supporting the identification and linking of various data types and sources, e.g. sensor data, process execution data, and factory designs, which in essence leads to DTs. A part of this task is the creation and monitoring the surrounding environment and situational properties related to the factory, i.e. the application context needs to be modelled and monitored. Some of the context information might also be needed in advance which requires using the means of predictive data analytics. All data needs to be presented to participants in the industry 4.0 design, depending on the criticality and relevance.

  • Decentralized decisions. The design should be able to combine local as well as global information to support decentralized and autonomous decision making.

  • Technical assistance. The decentralized decision making needs to be supported by assistance IS that are able to aggregate and visualize content in various formats suitable for different application contexts.

Wortmann et al. [8] report on a systematic literature review and in terms of the expected benefits for modeling for industry 4.0 puts forward the following: reducing time (development time, time-to-market), reducing costs (of development, integration, configuration), improving sustainability, and improving international competitiveness. This is in line of what are the general intentions of allying development methods and tools. In the context of industry 4.0 modeling addresses cyber aspects, physical aspects, or cyber-physical aspects of which the latter is the least researched and for which the least number of contributions have been elaborated. Wortmann et al. indicate that the current trends include methods for modeling digital representation, failure handling, human factors, information management, integration, process, product, configuration validation and verification, as well as visualization. The areas of product modeling, validation and verification, and information management attracting the most attention right now. Human factors and visualization are addressed by considerably fewer contributions. However, this study focused mostly on methods that have proven useful for IS design and development, and these methods do not support a holistic view on design that integrates organizational and human aspects with the more common IS aspects.

The analysis of the current state of modeling for the purpose of designing industry 4.0 solutions, including DTs, calls for a number of areas of advancements, as follows.

Concerning modeling and model management:

  • Support for integrated multi-perspective views on all aspects of, such as, business and organizational, IS architecture, implementation, and operation at runtime.

  • Integration of different artifact kinds such as models, 3D drawings. In this regard, Wortmann et al. call for the integration of models in the engineering, deployment process, and operation processes. To achieve alignment, the integration should start with the business design and requirements for the engineering process.

  • Supporting design models with runtime data and, consequently, extracting models that can be used in later design iterations from runtime data. Using runtime data for the purpose of assessing the performance of designs, especially reusable designs that are applied in several operational installations.

Concerning adaptation and adjustment:

  • Support for adaptation and adjustment of the solution according to changing business goals and requirements as well as application context.

  • The solution should have built-in means for runtime adaptations that do not require re-design and re-deployment.

Concerning continuous lifecycle management:

  • Supporting visualizations of runtime data in design models, e.g. by specifying what data should be presented and in what format. Management dashboards and presentation views can be generated from models.

  • Support of the management of the complete lifecycle including design and runtime.

With respect to the latter, [8] discuss the possibility of adopting the DevOps principles for developing industry 4.0 solutions. The proposed vision for such a lifecycle is similar to the CDD process [10], discussed in Sect. 6.

6 Analysis

6.1 Discussing the Requirements from Literature and Case Studies

First, we will discuss the requirements from Sect. 5 and how the three main topics of (1) modeling and model management, (2) adaptation and adjustment; and (3) continuous lifecycle management, can be addressed by EM and CDD. This will be followed by a discussion of the case study requirements.

Modeling and model management. It calls for multi-perspective views to integrate various aspects and artefacts of the organizational design and align them with the DT design. Multi-perspective EM methods, such as 4EM, are suitable for supporting this. The organizational aspects need to be linked with capabilities and DT designs. A part of this task would be modeling the context information that affects the operation of the DT. Since DTs are operated continuously the runtime data allows the assessment and improvement of the design models. E.g. the Context Modeling component supports the design by officering a set of measurable context elements that are already available in the context platform. CDD includes a component for Reuse of Capability Designs supported by a pattern repository that captures pattern performance data over time [19]. This information is valuable for new as well as for improving the existing designs.

Adaptation and adjustment. DTs need to be operated continuously, in various situations, and according to various business models. It can also be expected that these change under the lifetime of a DT. In this respect EM can be used for capturing the business dimensions of change, and CDD components for Capability Design and Context Modeling are to be used for capturing changes in the application context. Components for Reuse of Capability Designs and for Runtime Adjustments can be used to specify automatic adjustments or reconfigurations of the solutions including the DTs.

Continuous lifecycle management pertain to two key aspects. First, visualization of operational and contextual data at runtime and then using this data and information to create new business models and DT designs as well as to change the existing ones. Part of the CDD method is generation of capability monitoring applications from capability design models and context models. Similarly, a monitoring dashboard for DTs can be generated from capability models, because it allows specifying KPIs and context elements together with their calculation from measurable properties that can be assembled from various data sources – internal application data as well as external environment data. Concerning the second aspect, the lifecycle support, CDD is focusing on capability design and context-based adjustment of IS. To include DT designs in capability designs would need having a more explicit integration with EM as well as dedicated tasks for designing the functionality of DTs. This would imply that the DT is designed together with the capability as a solution to a business goal. Such an approach would contribute to ensuring that the DT fits the business design. The CDD method is also supported by a tool environment which would be needed to monitor context and runtime data, calculate KPI values, and, if necessary, to trigger adjustment algorithms.

Table 1. Requirements from case studies supported by the CDD method components
Full size table

The requirements elicited in the case studies are to a large extend addressing similar issues to the requirements from literature. Table 1 summarizes the CDD support.

The requirements from literature and the case studies point to the need for the extension of the DT design with the aspects of business motivation and lifecycle management. The following modeling artifacts and practices contribute to this purpose:

  • Enterprise models to capture the business models. Later they can be linked with the DT design models repressing the technical details of the DT.

  • Capability design models to represent the more detailed designs of the DT.

  • Context models to show the dependence on local and global data in the environment as well as to adjustments of the DTs and their monitoring dashboards.

  • The capability design models and the enterprise models need to be linked to establish the business motivation and fit of the DT.

  • Capability designs and context models should be used for generating dashboards for DT management. Key data types that have the potential of being useful here are context data, KPI, historical data about performance of reusable components.

  • The models used need to be reasonably open and extendable in order to be able to incorporate additional perspectives of modeling.

6.2 Supporting the Continuous Way of Working

Concerning requirements CSR5 and CSR6, they can be supported by the CDD’s method components as discussed in the previous section, but they also call for the establishment of a new way of working. It needs to support the core tasks of development and management of efficient DTs, such as, capturing the business motivation, design of the DT, and delivery and operation of the DT. The CDD process, which shares similarities with the DevOps principle of continuous development and operation, has the potential of being adapted for this purpose. Wortmann et al. [8] also call for this kind of approach to DT development and operation. The case study requirements suggest that to make the DTs more fitting to the business model, explicit focus should be on the issues such as business goals, processes, and integration with the IS architecture. These are issues suitable for EM. Figure 1 proposes a DT development and management lifecycle that incorporates three sub-cycles – EM, DT Design, and Delivery and Operation. The internal steps and tasks in the sub-cycles follow the established procedures in [7] for EM and in [10] for Design and Operation. The following artifacts support the transition between the sub-cycles (grey arrows in Fig. 1):

  • EM provides explicated knowledge about the business motivation for the DT in the form of enterprise models.

  • Capability design provides (1) capability based digital twin design that are executable in the sense that they are integrated with the physical twins, and (2) generates the monitoring applications for digital twin management from the context model.

  • The delivery and operation sub-cycle provides data types (e.g. context element types, measurable properties, KPIs) of available data used at runtime of the digital twin. This allows extending the existing designs as well as selecting existing and obtainable data in new designs. The Design provides best practices and reusable components on which the EM sub-cycle can base new business developments.

Fig. 1.
figure 1

An overview of the envisioned capability-driven cycle of management digital twins.

Full size image

7 Feasibility Demonstration

Figure 2 illustrates the feasibility of the CDD use with a fragment of a capability model consisting of goals, capabilities, and context modeling elements. The digital transformation workshop at company A identified an option to develop a pump-as-a-service product. When prioritizing the options, this option was top rated and, hence, converted into Goal 1 to develop pumping-as-a-service. It was refined into three sub-goals aiming at low maintenance pumps (1.1), possibility for real-time monitoring (1.2) and development of a preventive maintenance service (1.3). KPIs were set for all three sub-goals. The goal model is shown on the right side of Fig. 2 and follows the 4EM notation.

Fig. 2.
figure 2

A capability model for operating product as a service.

Full size image

From a capability perspective, pump-as-a-service can be considered in more general terms as product-as-a-service capability if company A wants to offer other physical products as a service. The core sub-capabilities of product-as-a-service are real-time monitoring a product at the client site (which motivates the digital twin) and a reliable product without downtimes. The capabilities are visible in the center of the model.

The left side shows the context elements and the measurable properties on which they are based, in which context sets they are included, and their relation to capabilities. These context elements are calculated from the measurable properties and monitored once the capability is implemented. This also specifies the data to be provided by the DT. An example for a context element is the total energy consumption of the pump measured by the energy consumption of the motor and the energy recuperation achieved by the installed power converter. This context element is required for providing the product as a service (as part of the cost structure) and also for evaluating when to trigger preventive maintenance. From this model the CDD Environment would be able to generate a monitoring dashboard for Capability 1.2. It would display energy consumption, product status, and lubricant level as runtime properties of the application for operational monitoring. For a more strategic view on the capability fulfillment of KPI3 and KPI4 also need to be monitored. For brevity reasons, context and KPI calculations as well as the operational processes linked to the capabilities are not shown in the model.

8 Concluding Remarks and Future Work

The starting point for our work was the analysis of two industrial cases on how digital twin initiatives emerge and what the driving forces for starting implementation projects are. An observation from both cases is that digital transformation and development of new business model options are a motivation and driving force of DT implementation. Both case studies resulted from the need of companies to explore innovative products or services based on digital technologies, embedded into their operational processes and structures. DTs are considered as a way of integrating innovative products/services into the operational context, which leads to requirements for DT functionality and implementation. In summary, we see clear support for our conjecture that DT have to be integrated into the organizational structures and business models of manufacturing enterprises. Furthermore, we analyzed requirements for DT development from literature. Requirements pose a number of issues concerning a model-based design and management with a particularly strong emphasis on establishing a good fit between the business issues and DT-based solutions. This is an area to which EM and CDD have the potential of contributing. In this regard we have proposed an integrated lifecycle and discussed how capability-based DT designs could be used. The initial feasibility demonstration gives reason to the assumption that this approach is promising and should be pursued.

Concerning future work, we plan to investigate to what extent existing technically motivated DT implementations are used for new services or products and cause digital transformation in the enterprise and how the design of the DT features can be included in the capability design. We also aim to establish a development environment for the proposed way of working by integrating components of the CDD Environment with the modeling support by the ADOxx tool.