Dino Pavlić
email: dpavlic@efst.hr

Maja Ćukušić

Developing a Structured Approach to Converging Business Process Management and Customer Experience Management Initiatives

Keywords: Focus group, BPM, CXM, Customer journey. 1

Both in theory and practice, a lack of a formulated structure to facilitate integrated modeling and analysis of internal business processes and customer experiences external to the organization has been identified by many authors. Tackling this issue, a convergent approach aligning Business Process Management (BPM) and Customer eXperience Management (CXM) initiatives, is proposed in the paper, along with a full set of top-down BPM-CXM models varying in the level of detail. To validate the proposed models, a focus group study with experts in BPM and CXM domains was organized, and the findings are reported and further operationalized using a tool widely used in the EMEA region.

Introduction

In practice, in the context of Business Process Management (BPM) initiatives, customer orientation often remains a mantra, while process optimization efforts are observed through "inside-out" perspective only, disregarding the customers' perspective. The innovative "outside-in" approach to BPM (by actively involving the customer as in [START_REF] Schooff | End of the Road for End-to-End Process Transformation[END_REF]) poses a significant challenge for BPM researchers and experts who are usually focused on process modeling and analysis, as well as for the existing BPM tools and methodologies [START_REF] Bergh | Transforming Through Processes Leading Voices on BPM, People and Technology[END_REF]. Recent research studies stress out the importance of involving customers in internal BP analysis and optimization, as well as in business transformation programs [START_REF] Gersch | Business Process Blueprinting -an enhanced view on process performance[END_REF][START_REF] Trkman | From business process management to customer process management[END_REF][START_REF] Neubauer | An empirical study about the status of business process management[END_REF][START_REF] Schmiedel | Development and validation of an instrument to measure organizational cultures' support of Business Process Management[END_REF][START_REF] Johnston | The Customer Experience: A Road Map for Improvement[END_REF][START_REF] Gloppen | The customer journey as a tool for business innovation and transformation[END_REF][START_REF] Becker | Taking a BPM Lifecycle View on Service Productivity: Results from a Literature Analysis[END_REF][START_REF] Norton | Using the customer journey to road test and refine the business model[END_REF]. However, there are still a number of problems that lead to BPM and Customer eXperience Management (CXM) initiatives not being aligned in practice, for example [START_REF] Straßer | Aligning Customer Journey Management with Business Process Management[END_REF]: BPM is too oriented on cost reduction and efficiency improvements while ignoring customer interactions; Customer Journey Mapping (CJM) as a part of CXM initiatives is too oriented on customer interactions while ignoring the internal processes of the organization; connections between customer journeys and business processes are not well identified; customer journey maps are not standardized; functional silos are not cooperating well; and the key performance indicators (KPIs) between departments are misaligned. One of the reasons for this misalignment is a lack of a model or a structure for integrated modeling and analyzing of internal business processes and customer experiences external to the organization [START_REF] Surbakti | Customer Process Management: A Systematic Literature Review[END_REF][START_REF] Følstad | Customer journeys: Involving customers and internal resources in the design and management of services[END_REF][START_REF] Bergh | The World Is Not Enough: Customer Centricity and Processes. Bus Process Trends 1-7[END_REF][START_REF] Hewing | Business process blueprinting: A method for customer-oriented business process modeling[END_REF], a topic that this paper addresses directly. The concept of BPM-CXM convergence has been presented earlier (in [START_REF] Pavlić | Conceptualizing the convergence model of business process management and customer experience management[END_REF]) while this paper develops it further and presents the results of its evaluation by experts.

The second section of the paper describes the approach to designing BPM-CXM convergence, taking into account the "outside-in" approach to BPM [START_REF] Schooff | End of the Road for End-to-End Process Transformation[END_REF] and building around a well-established BPM lifecycle [START_REF] Dumas | Fundamentals of business process management[END_REF]. It also outlines the feedback from a focus group study that was conducted with the view to demonstrate the feasibility of the concept with experts from the EMEA region. The third section of the paper provides an operationalized top-down view of the convergent approach following the same structure, manifested in several models developed using a tool widely popular in the region. The fourth section of the paper provides plans for further work and concludes the paper.

2

Designing BPM-CXM Convergence

State-of-Art in BPM-CXM Convergence

The convergence of BPM-CXM presents a new concept addressed by several authors and papers that point out the need for research in this field, in particular [START_REF] Gloppen | The customer journey as a tool for business innovation and transformation[END_REF][START_REF] Straßer | Aligning Customer Journey Management with Business Process Management[END_REF][START_REF] Følstad | Customer journeys: Involving customers and internal resources in the design and management of services[END_REF][START_REF] Hewing | Business process blueprinting: A method for customer-oriented business process modeling[END_REF][START_REF] Rosenbaum | How to create a realistic customer journey map[END_REF]. The general idea is that the identification, discovery, analysis, redesign, and control of processes should be performed in convergence with identification, discovery, analysis, redesign, and control of customer experience, and not independently [START_REF] Davis | It's the Customer Journey That Counts[END_REF]. On the one hand, Gloppen et al. [START_REF] Gloppen | The customer journey as a tool for business innovation and transformation[END_REF] promote the strategic use of customer journeys for innovation and business transformation in particular, while on the other, Kumar et al. [START_REF] Kumar | Alternative perspectives on service quality and customer satisfaction: the role of BPM[END_REF] emphasize BPM as a key factor in achieving customer satisfaction. To overcome this and change the "traditional" end-to-end approach to business transformation, Richardson (in [START_REF] Schooff | End of the Road for End-to-End Process Transformation[END_REF]) proposes using a specific type of targeted modeling of customer touchpoints with the organization, and their analysis and optimization in the context of internal organization. This particular standpoint is favored by the authors of the paper, as demonstrated further in the proposed operationalized, prototyped solution in section 3. By incorporating elements of CXM in the proposed solution, customer journey mapping, in particular, a new "outside-in" modern approach to BPM is implemented. Apart from identifying the need for a structured approach for BPM-CXM convergence in the available literature, related issues (listed as in, e.g. [START_REF] Straßer | Aligning Customer Journey Management with Business Process Management[END_REF]) were observed by authors of the paper in several business transformation projects in large companies. Consequently, the operationalization and evaluation of BPM-CXM convergence model constitute the main contribution of this research study.

BPM-CXM Convergence Concept

To formulate and structure the BPM-CXM convergence, design science approach is used [START_REF] Peffers | A design science research methodology for information systems research[END_REF] as a research framework. Standard phases were followed (identification of the problem and motivation, definition of the objectives of a solution, design and development, demonstration, evaluation, and communication) during several workshop events during 2018 when there were multiple iterations of literature analysis, objectives defi-nition, and model formulation with BPM experts resulting in a high-level concept (presented in [START_REF] Pavlić | Conceptualizing the convergence model of business process management and customer experience management[END_REF]) structured around BPM lifecycle and related descriptions and top-down models. BPM-CXM convergence concept (Fig. 1) was the main starting point for discussions as it is structured in a way that would facilitate integrated analysis of customer experience and internal business processes. In general, customer experience is designed and analyzed by using customer journey mapping (as suggested by [START_REF] Lemon | Understanding Customer Experience Throughout the Customer Journey[END_REF]), which is used as an input for BPM initiatives -from strategic identification of processes for initiating BPM initiatives, to analysis and optimization of processes [START_REF] Davis | It's the Customer Journey That Counts[END_REF][START_REF] Vanwersch | A Critical Evaluation and Framework of Business Process Improvement Methods[END_REF][START_REF] Moormann | Customer-Centric Business Modeling: Setting a Research Agenda[END_REF][START_REF] Flint | Logistics innovation: A customer value-oriented social process[END_REF][START_REF] Chen | Supply chain process integration: A theoretical framework[END_REF][START_REF] Lee | Business performance and customer relationship management: The effect of IT, organisational contingency and business process on Taiwanese manufacturers[END_REF]. BPM-CXM convergence approach should reflect the way customer experience can be perceived and analyzed through the whole BPM lifecycle [START_REF] Ruland | Customer experience and its potential to extend business process management[END_REF]. That is why the proposed concept lays precisely on those foundations -it is based on standard BPM lifecycle [START_REF] Dumas | Fundamentals of business process management[END_REF], and is developed further and operationalized (as in Section 3). It reflects the focus on the analysis of touchpoints between the internal organization and the customer external to the organization combining best practices from BPM and CXM.

Evaluation of BPM-CXM Convergence Concept with Experts

A focus group workshop was organized in March 2019 with the purpose to collect target audience (experts') opinions and attitudes about the proposed convergence concept, related issues and model prototypes. As such, it constitutes an integral part of the design process. Since the required knowledge and experience is very specific, the criteria for expert selection were: at least 10 years of work experience in BPM or CXM projects combined, at least two years of experience in each discipline (BPM and CXM projects), regional experience (conducted BPM or CXM projects in at least three countries), and experience in at least three different industries. Within the network, there were six experts that fit the profile. As all the experts have worked on projects in the EMEA region (primarily in Croatia, Serbia, Bosnia and Herzegovina, and Montenegro), the results of the study reflect their understanding and experience that cannot be easily generalized to other regions. However, in terms of the industries, they have worked in various industries, including finance, gas and oil, local government, transport, logistics, trade, telecommunications, and IT. Basic sociodemographic data about the experts are presented in Table 1. Although the structure of the session was preset, the format was kept flexible, to allow the conversation to develop naturally and to elicit views and opinions. Over the course of three hours, the participants were asked 40 questions split into three parts (Expert background, Current state of BPM & CXM initiatives, and BPM-CXM convergence approach discussion & design). The participants were first presented with the focus group purpose and protocol and then were given an overview of the BPM-CXM convergence approach, which included the high-level introduction to the proposed method, as well as all of the operational details (e.g. phases, models, objects, attributes etc.). They were given a short introduction for each question (question examples: Would you adjust the proposed mathematical formula? Would you adjust, edit, or remove any of the elements of the proposed customer journey map?) and enough time to discuss it with other participants and note their individual and consolidated answers. After the focus group, written transcripts by the moderator as well as the participant's notes were analyzed and synthesized in a presentable form.

Within the following paragraphs, consolidated views of the group are presented following the same structure used during the session. Generally, in terms of the problem and motivation of the study, there was a strong consensus, and in terms of the suggestions, all experts contributed considerably and helped to formulate the top-down model prototypes that are presented in section 3. The choice to present the prototypes in a separate section was made due to two different reasons: to differentiate between the elicited feedback from the experts presented in section 2 and additional (technical) commentary provided by the authors of the paper that accompanies the prototypes in section 3; and to provide an operational view on the concept in its entirety. However, the two sections are strongly interrelated with references where appropriate.

Current State of BPM and CXM Initiatives.

BPM Initiatives as Enablers of Amazing CX. All experts agree that at the moment, BPM initiatives do not put enough focus on CX. They are missing information about the actual CX and CX KPIs. There is no proper way of getting the real data about the CX and pairing them with the internal process models. BPM experts are too focused on internal business processes, while communication with CX departments and customers is something that is missing within BPM initiatives. Internal processes are only considered in the context of CXM if a customer is complaining -this is too late since the negative experience already occurred. Overall, there is a consensus that BPM initiatives are not set up as enablers of an amazing CX.

Focus of BPM Initiatives on CX.

There is agreement that BPM initiatives are only sometimes focused on achieving customer's satisfaction. There is a lack of involvement of the CX departments and customers within BPM initiatives. At this point, BPM initiatives are focused on the internal processes and achieving process excellence without actually considering the external/customer perspective. From a theoretical perspective, BPM initiatives are almost always focused on customer satisfaction; however -in real life, this focus often does not exist. Customer Focus within Business/IT Transformations. Similarly, experts report that as a part of business/IT transformations, customer focus often remains just a phrase since no CX departments or customers are involved. Customer focus often is the main driver for business/IT transformations however when it comes actually to perform the transformation, the real link between "classic" BPM, CXM, process execution, and performance management is missing. Customers are often a trigger to start an internal process or IT transformation; however, they are not given enough attention during the transformation process itself. Alignment of BPM & CXM Initiatives. Experts also agree that BPM and CXM initiatives are not aligned and well-coordinated, and this should be improved. It is mainly due to management vision not being defined in a way to support and encourage the alignment. One of the challenges is in getting the real data from the process execution as well as real data about the customer experience and performing consolidated analysis with internal process data. Alignment of Goals and KPIs of BPM & CXM Departments. Furthermore, BPM and CXM departments are considered as not aligned by experts. BPM and CXM departments usually have a completely different strategy, goals, and KPIs. Communication Between BPM & CXM Departments. Another issue regularly observed by the experts is that BPM and CXM departments do not communicate regularly, and they see this would need large improvement. Quality of communication between BPM and CXM departments should be improved as well.

BPM-CXM Convergence Approach Discussion and Design.

Structure of BPM & CXM Lifecycle. Experts find that the proposed BPM-CXM concept (presented Fig. 1) is well structured to support the BPM and CXM convergence considering that CX is introduced as a part of BPM lifecycle.

CX Landscape Positioning Within the Virtual Organization Model. As a part of the "virtual organization" (a term used to denote entry-level models in BP repositories), business process landscape and CX landscape provide a clear entry point to the more detailed models (top-down approach). It was agreed that Customer experience should be placed within a new, separate quadrant of a virtual organization (as further operationalized in entry-level model prototype in section 3).

Scoring the Overall Customer Experience of Customer Journey. Experts suggest that the overall customer experience of a customer journey should be calculated as an average of overall customer experiences on each touchpoint, which is a part of the individual journey. They propose to build a script for automatic calculation within a BPM tool. Elements, Attributes, and Color Coding of a Customer Journey Landscape. Attribute naming and color-coding of a customer journey landscape model (presented in section 3) were evaluated as clear and appropriate. Elements and attributes of customer journey landscape were also assessed as well structured. It was proposed and agreed that the overall customer experience of a customer journey landscape should be calculated as an average of overall customer experiences on each customer journey, which is a part of the customer journey landscape.

Elements, Attributes, and Color Coding of a Customer Journey Map. Attribute naming and color-coding of a customer journey map (model presented in section 3) were also evaluated as clear and appropriate. Elements and attributes of a customer journey map were assessed as well-structured. As an addition to the proposed elements of the customer journey maps, input/output data/cluster were suggested to be added. Within customer journey maps, it was suggested that color indication of the overall experience should be visible on individual touchpoints, as well as customer journey steps. Touchpoints are the "real" connection between the internal organization and the customer external to the organization, and therefore are more relevant for scoring representation. Customer Journey Landscape and Customer Journey Map Ownership. The experts suggested that customer journey owners and business process owners should be separated, like front-end and back-end in software development, however, that they should communicate regularly to make sure their goals are aligned. Also, there could be separate ownership roles for customer journeys and customer journey landscapes. Considering that the customer journey owner should enforce the will of the customer within the internal business processes, customer journey owner and business process owner should not be the same person and should align and communicate regularly.

Elements, Attributes, and Color Coding of a Customer Touchpoint Allocation Diagram.

Elements and attributes of customer touchpoint allocation diagrams were assessed as well-structured. Attribute naming and color-coding of a customer touchpoint allocation diagram are also considered clear and appropriate. Out of 2 proposed options, option 2 of the proposed touchpoint allocation diagram was selected as preferred one by experts and is presented in section 3. It was agreed that customer experience of the individual touchpoint should be calculated by considering the customer feeling and adding a weighting factor/ponder (importance to the customer).

Setting up an Indication of Customer Experience Related to Certain Internal Business

Processes. Overall customer experience linked to an internal business process was agreed to be calculated as an average of customer experience of each touchpoint that is a part of the individual internal business process. Also, the script for automatic calculation would be then necessary to be developed and implemented within a BPM tool in order to represent the impact that certain internal business processes have on positive or negative customer experience. The script could be triggered on an hourly basis.

Establishing a Link Between the BPM and CXM Initiatives by Indicating the Customer

Experience Levels on Value Added Chain Diagrams. Proposed value-added chain diagram which includes customer experience layers and indication (as in section 3), experts agree, would bring various benefits in terms of BPM-CXM alignment compared to the standard value-added chain diagram. By using the proposed method, they agree that there would be a clear link established between the BPM & CXM initiatives, BPM initiatives would be more focused on the customer, and internal resources would be spent more optimally. Also, by using the proposed method and formula within the value-added chain diagrams indicating the associated customer experience, focus on the experience while analyzing the internal business process would be achieved. An internal business process model, value-added chain, which includes the information and indication on the status of customer experience, is found to be the most beneficial part of the proposed BPM-CXM approach. Benefits of the Proposed BPM-CXM Convergence Approach. Here, experts confirmed and found multiple benefits of including customer touchpoints within both high level and detailed internal business process models. They believe that the proposed methodology ensures better process optimization as it would combine both internal and external views on the process. Furthermore, it would ensure better alignment between the classical BPM and CXM approaches. BPM-CXM convergence would ultimately lead to focusing BPM initiatives on those business processes which would have the greatest impact on CX improvement. It would point out that everything that a company or its resources do affect the customer. Internally, the customer would "become alive" as experts state. The proposed approach would enable customer-experience-driven internal business process optimizations as well as achieving true customer focus. It would ensure better alignment between the internal and external view on the processes, thus helping to optimize the processes that would ultimately serve customers in a better way. Indicators to Measure the Effectiveness of BPM-CXM Approach. The effectiveness of the proposed BPM-CXM approach was suggested to be measured through the improvement of customer satisfaction. Also, another way to measure would be through the number of detected pain points related to internal business process, number of detected positive experiences related to internal business process, number of eliminated pain points due to the internal business process optimization. Pitfalls of the Proposed Convergence Approach. No significant pitfalls of the proposed approach were detected. However, one potential shortcoming was identified -the experts emphasized that the ownership roles are not clear enough. It could lead to inadequate governance of BPM-CXM convergent approach. Another aspect that was emphasized as important in considering and implementing the proposed structure was the frequency of the processes that should be considered within the analysis.

Proposing the Set of Models for BPM-CXM Convergence

To demonstrate and operationalize the concepts presented above, and to provide a functioning and structured convergent approach that could be used in practice, a number of model prototypes were developed and evaluated with experts during the course of the focus group, and are presented in this section. These model prototypes are mapped to ARIS Value Engineering (AVE) methodology and ARIS platform [START_REF]Software AG product website[END_REF] due to the popularity of the methodology and tool in the region.

Structuring the Models Around the BPM Lifecycle

The models are structured around the lifecycle [START_REF] Dumas | Fundamentals of business process management[END_REF] phases (as already illustrated in Fig. 1): (1) Internal business processes and customer experience are identified by defining process and CX landscapes within the "virtual organization". They are mapped on a high level; the top-down approach is used. ( 2) Discovery phase includes mapping of asis business process models and customer journey maps. It also includes setting up customer touchpoints as a part of customer journey maps, as well as internal business processes.

(3) Analysis phase includes analysis of internal business processes and customer journeys, with a focus on the analysis of customer touchpoints. The analysis phase is greatly impacted by the new approach since it includes an indication on the level of overall customer experience being positive or negative concerning the internal processes. (4) According to these findings and the analysis performed, processes and customer journeys redesign is performed. ( 5) Process implementation and ( 6) processes and customer journeys monitoring close the (iterative) model lifecycle.

Overview of Top-Down BPM-CXM Convergent Models in BP Repository

Entry-level model. Entry-level model (Fig. 2) (also called "start model" or "overview model" [START_REF] Davis | ARIS Design Platform: Getting Started with BPM[END_REF]), in addition to five "standard" virtual organization elements as proposed by AVE methodology (organizational view, data view and other), now contains CX landscape included in a separate quadrant.

Fig. 2. A prototype of the new entry-level model

This way, a virtual organization or entry-level model includes the same level of details for both internal business processes and customer experience. On this (top) level of detail, both internal business processes and customer experience are represented as a landscape. When clicked on any of the two landscapes, more detailed models are opened.

Customer Journey Landscape. In a more detailed representation, customer lifecycle stage, and customer journeys, which are a part of the specific lifecycle are represented (Fig. 3). Overall customer experience (CX) attribute of a Customer lifecycle stage is proposed to be calculated as an average of Overall customer experience (CX) of all customer journeys connected to it. Overall customer experience (CX) attribute of both Customer lifecycle stage and Customer journey objects are used as a basis for colorcoding of those objects. The proposed method to calculate a value of a customer experience for a single customer journey is described in the next section. The Overall customer experience (CX) falls into ranges unanimously agreed by the experts: 6 to 10 (Very good, i.e. 5), 2 to 5.99 (Good, i.e. 4), -2 to 1.99 (Neutral, i.e. 3), -6 to -1.99 (Bad, i.e. 2), -10 to -5.99 (Very bad, i.e. 1) while the respective stage/journey color-coding is green for very good (5), yellow for good (4), grey for neutral (3), orange for bad (2) and red for very bad (1). On the customer lifecycle stage level, Customer lifecycle stage owners can be defined as an object attribute. Descriptions can be added as a model/object attribute. Customer Journey Map. The model (Figure 4) is composed of various elements describing the journey: customer journey steps, customer touchpoints, channels, inputs, outputs, risks, KPIs, initiatives, ownership, internal process step. Each touchpoint contains a description and customer journey owners are defined as a model attribute. which internal business processes (on a value-added chain level) have the best/worst customer experience. According to this, recommendations are given on which internal business processes should be modified in order to improve customer experience most effectively. The Overall customer experience (CX) on internal business process level is calculated as an average of Overall customer experience (CX) of all Customer touchpoints which are a part of the underlying internal business process model. The Overall customer experience (CX) of the end-to-end value-added chain (higher level internal business process) is calculated as an average of all connected underlying value-added chains. The same color-coding principle is used as presented earlier within this paper.

Optionally, the number of process instantiations and/or revenue per each sub-process (value-added chain) can be added in order to add value to the analysis. Event-Driven Process Chain. On a detailed level, internal business processes are represented by using the event-driven process chain diagrams (EPC), Figure 7. Other than the "regular" elements of an internal business process model, they also contain customer touchpoints to represent the customer interactions with the internal organization as well as the with the internal process steps. Touchpoints include a color indication of the overall customer experience following the same color-coding principle as above.

Conclusions and Planned work

This paper presented an effort to structure and design a BPM-CXM convergence approach. It is focused on the design itself -problem definition and solution proposal and development, which was presented and evaluated with a group of experts with substantial experience in BPM and CXM fields in the EMEA region. The main deliverable of this phase of the research is the verified and operationalized version of the BPM-CXM structured convergence approach, including the prototype models and recommendations for their use. Based on the feedback from the field received so far, it is expected that this research will influence BPM and CXM disciplines by proposing a convergence approach, but also the BPM systems used in practice to conduct BPM projects. There are specific plans by several of the experts that participated in the focus group to follow the proposed approach in delivering their future consulting projects should some preconditions be fulfilled (such as customer motivation, level of engagement of teams from both BPM and CXM departments, freedom to use the methodology of own choosing) but they are also waiting for the implementation evidence. On that note, a new phase of the evaluation of the proposed approach would include implementation in a real-life setting in order to further test the feasibility and value of the proposed convergence approach. The implementation and a follow-up evaluation through in-depth interviews with international experts in BPM and CXM fields that participate in the project are in progress. The findings would be used to adjust the proposed work if necessary, detect issues, and measure the effects of the new approach. In-depth interviews to evaluate the benefits of using the proposed approach compared to the traditional BPM and CXM approached will specifically evaluate the effects of BPM-CXM convergence approach on the internal organization, alignment of business processes of an internal organization with the needs of the customer, and the customer experience itself. Multiple benefits from following the proposed approach are expected compared to traditional BPM approaches. The expected effects would include the following: reduction of emphasis on internal business process mapping or "modelling because of modelling" within the BPM initiatives, reduction of functional silos effect and better alignment between the organizational departments, improved coordination between the organizational departments in defining the key performance indicators, increase of innovation level in organizations, design of business processes which take the interactions with the customer into the account and enable customer expectations fulfilment, development of products and services that are really needed by the customers, rational usage of organizational resources and more.

After validating the theses in a real-life setting, it is expected that the results will influence BPM and CXM disciplines by proposing a new version of the structured convergence approach and instructions for its implementation, but also the BPM systems used in practice as these will need adjustments in terms of available models, objects and methods as demonstrated in the paper.

Fig. 1 .

 1 Fig. 1. BPM-CXM convergence concept (based on [1, 17, 28])

Fig. 3 .

 3 Fig. 3. A prototype of the new customer lifecycle stage model

Fig. 4 .

 4 Fig. 4. A prototype of the new customer journey mapTo calculate the Overall customer experience (CX) attribute of Customer journey object, each touchpoint within the journey (Figure4) is taken into consideration. The overall customer experience (CX) of a Customer journey is calculated as an average of Overall customer experience (CX) attributes of all touchpoints within the journey. Attributes which are relevant for calculation within the touchpoints are Importance to

Fig. 5 .

 5 Fig. 5. A prototype of the new customer touchpoint allocation diagram Value-added Chain Diagram. From the internal business process perspective, highlevel business processes are represented by using the value-added chain diagrams (Figure 6). They include a color indication of the Overall customer experience (CX), which is related to the individual process. They also include customer experience (touchpoints) layer. Based on the relation between the individual touchpoints (which are a part of certain Customer journey) with internal business process steps (which are a part of a certain Value-added chain diagram), the calculation is performed to determine

Fig. 6 .

 6 Fig. 6. A prototype of the new value-added chain diagram (with touchpoint representation)

Fig. 7 .

 7 Fig. 7. A segment of the prototype of the new process model (with touchpoint representation)

Table 1 .

 1 General characteristics of the six experts that participated in the focus group

		Gender Education	Role	Work experience
	Expert 1	Female	MBA	Head of project management department	20 years
	Expert 2	Male	MCS	BPM consultant	10 years
	Expert 3	Male	MCS	Management consultant	13 years
	Expert 4	Female	MCS	Head of organization department	12 years
	Expert 5	Male	MCS	Management consultant	11 years
	Expert 6	Female	MBA	Management consultant	22 years

Acknowledgment. This work is supported by the Croatian Science Foundation [grant number HRZZ-UIP-2017-05-7625].


Georgios Koutsopoulos
email: georgios@dsv.su.se

Martin Henkel
email: martinh@dsv.su.se

Janis Stirna

Requirements for Observing, Deciding, and Delivering Capability Change

Keywords: Capability, Enterprise Modeling, Adaptation, Transformation

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.

Introduction

The degree of dynamism in business environments is on the rise, leading to organizations constantly trying to adapt according to situations existing in their external or internal environment. Organizations struggling to "catch-up" is a common phenomenon and the distance is only going to be amplified as the organizations' rate of change is usually lower than their environment's [START_REF] Burke | Organization change: theory and practice[END_REF]. Therefore, in the area of Information Systems (IS), a challenging task has emerged in the form of providing support methods and tools for the organizations facing constant change. As a response to this situation, various methods have been developed, for example [START_REF] Loucopoulos | Capability Oriented Enterprise Knowledge Modeling: The CODEK Approach[END_REF][START_REF]Architectural Coordination of Enterprise Transformation[END_REF] in order to support the adapting organizations in their constantly changing needs. Enterprise Modeling (EM) is a discipline that has attempted to tackle the abovementioned challenge in various ways. It captures organizational knowledge and provides the necessary motivation and input for designing IS [START_REF] Persson | An Explorative Study into the Influence of Business Goals on the Practical Use of Enterprise Modelling Methods and Tools[END_REF]. In addition, the notion of capability has emerged in IS engineering as an instrument for context-dependent design and delivery of business services [START_REF] Sandkuhl | Capability Management in Digital Enterprises[END_REF]. Capability modeling is one specific area of EM that utilizes the concept of capability. Capabilities are an important aspect of enterprises, since they encompass the majority of the concepts relevant to change, such as, goal, decision, context, process, service, and context [START_REF] Sandkuhl | Capability Management in Digital Enterprises[END_REF][START_REF] Loucopoulos | Enterprise Capability Modeling: Concepts, Method, and Application[END_REF].

In a way similar to any method supporting enterprise transformation, modeling methods need to evolve as well, in order to improve the organizations' ISs. Capability modeling should therefore evolve accordingly, improving not only the way capabilities are implemented during design phase of the system, but also adjustments and changes performed during run-time [START_REF] Sandkuhl | Capability Management in Digital Enterprises[END_REF].

This study is part of a research project aiming to provide methodological and tool support for changing organizations by supporting capability modeling within dynamic contexts. It follows the framework of Design Science research [START_REF] Johannesson | An Introduction to Design Science[END_REF][START_REF] Hevner | Design Science in Information Systems Research[END_REF] and this study concerns the step of the elicitation of requirements for the design artifact, in particular, the envisioned method for capability modeling and analysis. Goals, being a type of requirement [START_REF] Pohl | Requirements engineering: fundamentals, principles, and techniques[END_REF], are elicited from two different sources, literature and a case study in the public healthcare sector of Sweden, and presented as a goal model for the envisioned method. They can be seen as relevant to any similar approach.

The rest of the paper is structured as follows. Section 2 consists of a brief presentation of the basic concepts and related literature. Section 3 describes the methods used for this study. Section 4 presents the requirements elicited from literature. Section 5 introduces the case, along with two specific change implementations and the requirements elicited from the case. Section 6 summarizes the elicited requirements in a goal model. Section 7 presents a discussion of the elicited requirements and section 8 provides concluding remarks and briefly explains the next steps of this research project.

Background

EM is defined as 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 [START_REF] Sandkuhl | Enterprise Modeling: Tackling Business Challenges with the 4EM Method[END_REF]. Concerning applicability, EM is applicable for any organization, public or private, or its part. The focus for capability modeling is enterprises ability and capacity to deliver value, to achieve goals, or to sustain a long term function. The importance of capabilities lies in the fact that it assists a holistic view of the enterprise since it encompasses several aspects due to the association of the concept with several key concepts such as goals, business services, processes, actors, environment. EM has been used to depict enterprise capabilities in several ways including stand-alone modeling approaches like VDML (Value Delivery Modeling Language) [START_REF](OMG): Value Delivery Modeling Laguage[END_REF] and CDD (Capability-Driven Development) [START_REF] Sandkuhl | Capability Management in Digital Enterprises[END_REF]. Several Enterprise Architecture (EA) frameworks include the concept of capability and offer capability viewpoints. Popular EA frameworks that include capability modeling are (i) Department of Defense Architecture Framework (DoDAF) [12], (ii) NATO Architecture Framework) (NAF) [START_REF]NATO: NATO Architecture Framework v.4[END_REF], (iii) Ministry of Defence Architecture Framework (MODAF), and (iv) Archimate [START_REF]The Open Group: Archimate 3.0.1. Specification[END_REF]. There have also been research contributions that provide suggestions on how to model capabilities based on existing modeling methods like i* [START_REF] Danesh | Modeling Enterprise Capabilities with i*: Reasoning on Alternatives[END_REF] or Capability Maps [START_REF] Beimborn | Capability-oriented modeling of the firm[END_REF] or introducing new notations like CODEK [START_REF] Loucopoulos | Capability Oriented Enterprise Knowledge Modeling: The CODEK Approach[END_REF] to include the elements required to capture how a capability can change or be changed in dynamic environments.

Methods

This study belongs to a project elaborated within the Design Science paradigm, in particular, following the guidelines of [START_REF] Johannesson | An Introduction to Design Science[END_REF], according to which a method is considered a design artifact. As with any other artifact, a capability modeling method needs to be scoped and have requirements defined for it. The activity aims to answer the question "What artifact can be a solution for the explicated problem and which requirements on this artefact are important for the stakeholders?" [START_REF] Johannesson | An Introduction to Design Science[END_REF]. In this study, the defined requirements concern the method and not the case since the method developer is considered as the stakeholder and not the case study's organization's stakeholders. Thus, the task performed is defining requirements for the method; not for the included use case. The requirements for a method for modeling changing capabilities have been elicited by using a literature review and a case study and visualized as a goal model.

Literature review

In an earlier study [START_REF] Koutsopoulos | Dynamic Adaptation of Capabilities: Exploring Meta-model Diversity[END_REF], a literature review concerning capability meta-models was conducted. The papers identified in that study are useful for this study as well, often including requirements for modeling capability changes. A part of that study was to identify papers using a snowballing technique on the initial set of papers that was identified through systematic literature review. Several of the papers that were excluded during snowballing for not including a meta-model have been deemed useful to include in this study as a means to identify capability change requirements. The requirements were either directly extracted from papers related to capabilities or indirectly from papers that addressed issues related to change and enterprise information. In the former case, the requirements for capability change were identified using observation, decision support and delivery as the main change functionalities [START_REF] Koutsopoulos | Dynamic Adaptation of Capabilities: Exploring Meta-model Diversity[END_REF]. In the latter, the requirements concerning change were identified in the related papers and were associated to enterprise capabilities.

Case study

The case study was performed at a regional public healthcare organization, which we refer to as RH, responsible for healthcare provision in a Swedish county. The organization desired to remain anonymous, therefore, its real name is not published, along with the names of any collaborating companies. The studied part was the organization's capability to provide its residents with healthcare guidance via phone. To get information about what kind of change request the organization needs to handle, a number of meetings were held. The following activities took place in iterations.

Unstructured group interviews were used to identify change requests that the RH Guidance service had received recently. For this, four meetings were held, initially engaging two experts/strategists at RH, and the last three sessions involving one.

Workshops were held to identify the main actors and their relationships, this resulted in the creation of a value network model; three workshops were held.

Document studies were performed to study the current documentation of the capability under study.

For the analysis of how the identified change request would impact the organization, an experiential approach [START_REF] Kilpinen | The emergence of change at the systems engineering and software design interface[END_REF] was applied. That is, for each identified change request the interviewers also asked the experts to identify the potential change impact.

Requirements -Goal Modeling

The activity of defining requirements is associated to Requirements Engineering (RE).

The aim of RE is to change the current reality by defining briefly and precisely the essence of the desired change [START_REF] Pohl | Requirements engineering: fundamentals, principles, and techniques[END_REF]. In other words, it defines a goal but not how the goal should be fulfilled. The core activities of RE are (i) elicitation, which concerns the identification of requirements from relevant sources which are also identified during this activity, (ii) documentation of the identified requirements and (iii) negotiation, which concerns the identification and resolution of any possible conflicts. Two more cross-sectional activities are validation and management. The result of the process is a set of goals, scenarios or solution-oriented requirements which are generally known as requirement artifacts and comprise a requirements specification.

Various research methods can be applied to define requirements for an artifact like survey, action research, observation, case study, interview and document studies. In this study, literature review and case study are the two methods employed. The overall requirements are expressed in the form of a goal model. Goal, as a type of requirement artifact [START_REF] Pohl | Requirements engineering: fundamentals, principles, and techniques[END_REF], is defined as a desired state of affairs that needs to be attained [START_REF] Sandkuhl | Enterprise Modeling: Tackling Business Challenges with the 4EM Method[END_REF]. Goals are often refined into sub-goals forming a goal hierarchy.

The goal model in this study has been developed using the "For Enterprise Modeling" (4EM) method [START_REF] Sandkuhl | Enterprise Modeling: Tackling Business Challenges with the 4EM Method[END_REF]. The available components in a 4EM Goals Model are goal, problem, cause, constraint and opportunity, however, the model in this study consists only of goals. Regarding the design of the model, the 4EM modeling toolkit used for creating the 4EM Goals Model has been developed in the University of Rostock using the ADOxx meta-modeling platform.

Requirements from Literature Review

This study is a continuation of a capability literature review [START_REF] Koutsopoulos | Dynamic Adaptation of Capabilities: Exploring Meta-model Diversity[END_REF], from which the majority of the requirements for capability change have been derived. That study involved the development of a framework that facilitated the classification of change concepts in the current literature. The main classification found was the division of key concepts into three functionality parts: (i) observation, (ii) support change decision and (iii) delivery [START_REF] Koutsopoulos | Dynamic Adaptation of Capabilities: Exploring Meta-model Diversity[END_REF]. These three should be the main concerns for a method.

The observation part directly refers to the context of the organization and its capabilities. Observing context has been identified as an essential element of change in several studies concerning capabilities and/or change [START_REF] Bērziša | Deliverable 1.4: Requirements specification for CDD, CaaS-capability as a service for digital enterprises[END_REF][START_REF] Fleurey | Modeling and Validating Dynamic Adaptation[END_REF][START_REF] Andersson | Modeling Dimensions of Self-Adaptive Software Systems[END_REF]. What has also been emphasized is that the context that is relevant to an organization and its capabilities remains unclear, therefore, effort is needed to identify which contextual factors are relevant to a capability's performance [START_REF] Zdravkovic | Requirements Engineering for Capability Driven Development[END_REF]. Indirectly, these factors are also affecting whether a capability change is needed and thus should be taken into consideration for inclusion by a capability change method developer. Another part that concerns the context observation is the functional differentiation between a system monitoring itself and the environment [START_REF] Weyns | FORMS: Unifying reference model for formal specification of distributed self-adaptive systems[END_REF][START_REF] Morandini | Towards goal-oriented development of self-adaptive systems[END_REF], or in other words, the internal and external context. This fact is another requirement for a capability change. Finally, any identified relevant contextual factors need to be measured [START_REF] Sandkuhl | Capability Management in Digital Enterprises[END_REF], therefore, these factors need to be associated to Key Performance Indicators (KPIs). KPIs are the way to monitor capability performance and fulfillment of the enterprise. If the goal model does not include ways to measure the goals, KPIs need to be established [START_REF] Sandkuhl | Enterprise Modeling: Tackling Business Challenges with the 4EM Method[END_REF]. Summarizing, the identified goals that are associated to observing are 2, 9 and 12-15 as shown in Table 1.

Regarding supporting change decisions, the decision needs to be associated to a set of criteria [START_REF] Koutsopoulos | Dynamic Adaptation of Capabilities: Exploring Meta-model Diversity[END_REF][START_REF] Morandini | Towards goal-oriented development of self-adaptive systems[END_REF], for example, rules and constraints [START_REF] Andersson | Modeling Dimensions of Self-Adaptive Software Systems[END_REF] that need to be identified prior to not only the decision, but also the processing and analysis of the relevant data captured through observation. This analysis of captured context data needs to be addressed by the method as well, for example with algorithms that monitor the need for adjustments [START_REF] Grabis | Adjustment of Capabilities: How to Add Dynamics[END_REF]. Regarding the decision itself, it may concern selecting among existing variants or alternatives [START_REF] Bērziša | Deliverable 1.4: Requirements specification for CDD, CaaS-capability as a service for digital enterprises[END_REF][START_REF] Fleurey | Modeling and Validating Dynamic Adaptation[END_REF][START_REF] Andersson | Modeling Dimensions of Self-Adaptive Software Systems[END_REF][START_REF] Morandini | Towards goal-oriented development of self-adaptive systems[END_REF] or deciding on the development of an existing alternative. A capability change method is required to provide support for the identification of existing or new capability alternatives that can efficiently produce the same valuable outcome employing variable delivery behaviors. Finally, since capabilities aim to fulfil intentions, a decision needs to comply with these intentions. Goals, objectives, needs, business requirements, desires states etc. are different concepts of intentions [START_REF] Koutsopoulos | Dynamic Adaptation of Capabilities: Exploring Meta-model Diversity[END_REF] that the decision needs to comply with. Table 1 includes goals 3 and 5-8 that have been identified through these findings and are associated to decision support.

The last part of capability change that the method is required to address is the delivery of the capability. Initially, this concerns both the delivery of the capability and the delivery of any change to the capability, or, in other words, the delivery of the transition from an as-is state of a capability to a desired to-be state. Also referred to as transformation or adjustment [START_REF] Sandkuhl | Capability Management in Digital Enterprises[END_REF], it may have several forms. A new capability can be introduced or an existing capability can be modified or retired. This is in line with [START_REF] Henkel | Capability-Based Business Model Transformation[END_REF], with replacing the concept of maintenance with modification in order to reflect the change to a capability. A significant finding in capability and change delivery literature is the association between capability and resource. Besides the fact that the concept of resource is the most commonly encountered concept in existing capability modeling approaches [START_REF] Koutsopoulos | Dynamic Adaptation of Capabilities: Exploring Meta-model Diversity[END_REF], it has also been associated to capabilities in several studies like [START_REF] Bērziša | Deliverable 1.4: Requirements specification for CDD, CaaS-capability as a service for digital enterprises[END_REF][START_REF] Azevedo | Modeling resources and capabilities in enterprise architecture: A well-founded ontologybased proposal for ArchiMate[END_REF][START_REF] Rafati | A Domain-specific Modeling Technique for Value-driven Strategic Sourcing[END_REF][START_REF] Loucopoulos | Requirements Engineering for Cyber Physical Production Systems[END_REF]. Several ways to associate the two concepts have been suggested, for example, as a constraint, but the most common type is that a capability consists of resources. The combination of these resources along with the information describing the relationships and capacities of the resources comprise the capability configuration. In addition, capabilities are also interrelated [START_REF] Koutsopoulos | Dynamic Adaptation of Capabilities: Exploring Meta-model Diversity[END_REF]. Therefore, the method artifact under development needs to address the capability configuration and the allocation of resources to capabilities along with the architecture of capabilities within an enterprise. Based on these findings, goals 4, 10, 11 and 16-20 are associated to capability delivery. Table 1 summarizes the goals for the capability change modeling method that were elicited from the literature review. The method should support addressing the change to an existing capability and to introduce an entirely new way to deliver. 11 To manage capability architecture

The capabilities associated to a capability, along with their relationships of various types need to be modeled in order to facilitate positioning the capability and identify the change's impact. 12 To observe external business context

Decomposing goal no2, it is important to support the enterprise's awareness of its external dynamic environment and the factors that affect its capabilities.

To observe internal business context

There is great value in monitoring the internal environment of the enterprise systematically to identify possible required changes and their possible impact. The method should facilitate this task. Based on the configuration of the capability, the allocation of resources may support enabling a potential and turning it into a capability. Thus, it is important for a capability change method to assist in the association of resources to a capability.

Requirements from the Case Study

Case Overview

RH is a public organization that is responsible for healthcare in a Swedish county. One of the organization's capabilities is to provide healthcare advice via phone to any resident and visitor of the county. The task is performed by specially trained professional nurses. They are being supported by specialized software that incorporates various information sources. The abovementioned capability is known by the 4-digit phone number used by the persons contacting the nurses, namely 1177. The strategic goal of 1177 is to reduce the workload of other healthcare organizations by filtering the cases that are not in urgent need of physicians' attention and support these cases by providing useful advice. RH owns 1177, however, several collaborating public and private organizations are involved by providing resources for it. Being inter-organizational, the configuration of the capability is complex. The complex configuration results in any proposed change in the capabilities of RH to require an in depth analysis of which parts will be affected and how. There are changes proposed that not only affect what is being done but also influence the collaborations with partner organizations in the form of needed or existing contractual agreements. RH and its capabilities associated to 1177 constantly change. The driving forces for change come both via top-down and bottom-up developments. The top-down perspective is associated to politicians pushing for reforms not only to improve overall quality but also to facilitate the residents using the service and reduce costs. The bottom-up perspective concerns changes proposed by the employees and partners involved in the delivery of the capabilities. In addition, the capability needs to be updated because of new technological developments, for example, the desire to use video calls.

Any incoming change request involves an analysis to determine its effects. The method artifact developed needs to address all the relevant aspects. In order to assist the elicitation of requirements for the method, two recent change requests have been selected, (i) an improvement in the guidance support that enables the responding nurses to guide the callers directly to a healthcare provider by assessing their symptoms and (ii) enabling the nurses performing health guidance to book times directly at local emergency clinics. These two change requests have been selected because they include both internal improvements that the callers may be unaware of, as in case 1, and external improvements that affect external partners that the callers are in contact with, as in case 2. Both cases, which are explained in detail below, concern changes affecting external parties and IT systems.

Change Case 1: Guidance Support Improvement

The nurses are using a Guidance support system while handling a caller's case. The system has been developed and is being used nationwide. The caller states existing symptoms and the system presents possible sub-symptoms to the nurse. Different levels of emergencies are handled in different manners, from advising on self-treatment, which is also included in the system, to calling an ambulance or suggesting a healthcare provider. A part of the system provides the nurses with a catalogue of healthcare providers. The provider catalogue is developed and maintained by a private provider, in comparison to the guidance system, which is developed by a national public provider.

An improvement that has been proposed is to associate each provider in the catalogue to a specific set of symptoms that the provider is likely to handle. In this way, the callers can be directed to a provider without the need to reach a diagnosis of their situation in advance. On the contrary, the diagnosis part is skipped and a relevant provider is identified directly through stated symptoms. There are multiple benefits from this improvement. Initially, the delivered service is improved since the patient is guided to providers with the best expertise. In addition, the capability becomes more efficient in terms of cost and effort, along with the fact that there is better use of human resources, especially physicians, who can spend time on handling only the cases that are really relevant to their expertise. While this research project was running, a group of expert physicians had already been formed and started mapping providers to symptoms. The idea was to create a web system that can be used directly, and an XML file containing symptoms and providers that could be used in other systems.

Change Case 2: Time Booking at Emergency Clinics

Another proposed change for RH concerns the 1177 capabilities' direct association to the actual healthcare providers, and in particular, to the local emergency clinics which are also governed by RH. These clinics are meant to treat acute, yet, not life-threatening health problems. For example, they can treat severe allergic reactions, bone fractures or concussions. A resource that is worth noting is the journal system used in the local clinics, developed by a private journal system provider, since it is the one that needs to be accessed by the nurses. More specifically, it has been proposed that 1177's nurses should be enabled to book time slots in emergency clinics while handling acute cases.

To date, the nurses can only suggest a clinic to the caller if they estimate that the clinic can handle the case. This change will benefit not only the callers, providing the convenience of having a booked time which also increases the feeling of safety, but also the main emergency units of major hospitals, whose workload will be reduced by directing less severe cases to the local clinics. In addition, it improves RH's ability to control the flow of the patients, directing them through the booked timeslots to the clinics with the shortest queue at the moment.

Analysis of Changes

This section discusses how the changes related to the three areas of capability change: observation, decision, and delivery relate requirements in the literature.

Concerning the impetus for changing the capabilities is the RH ability to perform observation, which can be seen as related to detecting changes in political, social, technological and economic factors. This is an important fact regarding monitoring of capability context because it provides initial guidelines concerning the selection of contextual factors that should be monitored to identify needed changes or possibilities for improvement. In addition, the contracts needed to perform the changes, as discussed below, also require monitoring the legal context of the organization and the capability. To measure the capability delivery, RH has a number of KPIs established that measures for example the number of residents that ask for guidance. Goal 28 was derived from these findings.

Regarding the decision on capability change in the case, it can be concluded that an important aspect in the two changes was the ownership of capabilities and associated resources. An important finding from the first change is that the ownership of the capability and the resources is significant for the configuration of the capability, along with any included tasks that have been outsourced. Developing new resources as part of the changes requires using existing resources owned by different organizations. For example, developing the symptom-provider system relies on data from the provider catalogue, owned by the private provider, and the expert group, owned by RH. The developed system and XML will in return, feed data to the provider catalogue system. A potential source of conflict and problems lies in the fact that an organization that collaborates with external partners to improve the efficiency of its services needs to have clear organizational boundaries set. This was derived from the case concerning the interactions and agreements among RH, the private provider and the national public provider in the first change, and RH, the journal system provider and the local emergency clinics in the second one. Using an external organization's resources or outsourcing tasks requires clearly stated boundaries set in the form of informal agreements or formal contracts. This will provide certain control over the cross-organizational configuration of the capability. The method should provide support for this type of capabilities and should assist the identification of resource ownership and contact points, either manual or automated, for example in APIs. An additional finding is that configuring a capability through a resource allocation supports the identification of alternatives. That is, reallocating resource sets may enable an existing potential and turn it into a new capability or alternative. The important association between goals 6 and 19 was identified based on these findings, along with the complementary goals 21-28.

Regarding the delivery of changes in the case it could be observed that the first change is a capability modification. Existing resources will be used in different ways to create new resources, and improve the delivery process, without changing the final outcome that is delivered, since it will be still fulfilling the same goal. The second change is a case of introducing a new capability. Even though the resources allocated to the capability are already existing, a new goal has been set and the delivered value is new. Both cases concern the reuse of resources in different manners. Goals 21-28 are also associated to delivery findings.

Considering the interrelated capabilities, it is important to identify new resources, like the symptom-provider system, created through the capability delivery and to take into consideration the needed resources, not only to develop the new resources, but also to maintain it. That may be a way to identify new capabilities.

Requirements

A summary of the goals elicited through the RH case are shown in table 2. They complement the goals elicited from literature, therefore the numbering continues.

Table 2. Additional goals elicited from the case study.

Goal Name Description 21

To specify capability ownership

The ownership of the capability facilitates positioning a capability within its ecosystem. The method should support identifying which actor, organization, unit etc., owns the given capability. [START_REF] Zdravkovic | Requirements Engineering for Capability Driven Development[END_REF] To specify resource ownership

The ownership of resources may be different than the ownership of the capability they are associated with and allocated to. This is common for inter-organizational capabilities. The method should address the possible ownership conflicts and their resolution. [START_REF] Weyns | FORMS: Unifying reference model for formal specification of distributed self-adaptive systems[END_REF] To manage internal resources

In comparison to the external resources that can only be identified, the internal resources of the organization can also be managed and assigned to one or more capabilities. [START_REF] Morandini | Towards goal-oriented development of self-adaptive systems[END_REF] To identify external resources

External resources associated to a capability may not be owned by the same organization as the capability. Identifying them defines resource ownership and the method should support it. [START_REF] Grabis | Adjustment of Capabilities: How to Add Dynamics[END_REF] To identify outsourced tasks

Capabilities are associated to tasks as components of processes that deliver the capabilities. Inter-organizational capabilities include tasks that have been outsourced to external collaborators. The method should support their identification. [START_REF] Henkel | Capability-Based Business Model Transformation[END_REF] To support defining organizational boundaries Task and resource ownership identification is associated to the limits of the organizations, also known as organizational boundaries. The method artifact should include their definition. [START_REF] Azevedo | Modeling resources and capabilities in enterprise architecture: A well-founded ontologybased proposal for ArchiMate[END_REF] To identify collaborating organizations

Organizations providing resources allocated to a capability should be identified as part of the capability's and organization's ecosystem. The method should facilitate capability configuration. [START_REF] Rafati | A Domain-specific Modeling Technique for Value-driven Strategic Sourcing[END_REF] To monitor political, economic, social, technological and legal context Political, economic, social, technological and legal contextual factors are important for the elicitation of the context, which is relevant to a capability's performance.

Goal Model for Capability Changes

The requirements for business capability change are expressed in the form of a goal model using the 4EM approach. Figure 1 depicts the Goals model that integrates goals elicited from both sources used in this study. The main goal 1 in the model is managing capability change. It is refined in goals 2-4 reflecting the three main functionalities, observation, decision support and delivery. Observation, in return, is refined into goals 12 and 13, distinguishing between the internal and external context that needs to be observed and supported by goal 9, the elicitation of the context to observe. Goal 14, which concerns measurement, supports goals 12 and 13 and is supported by goal 15, which concerns establishing KPIs to facilitate measurement. Goal 9 is supported by goal 28 depicting specific context fields that can assist the elicitation of contextual factors. Decision support is supported by goals 5-8, which depict the analysis of context data, the identification of decision criteria and capability alternatives, and ensuring that the decision complies with intention elements. Finally, delivery is supported by goals 10, 11 and 19, depicting management of transition delivery, capability architecture and capability configuration accordingly. Goal 19 also supports goal 6. Goal 10 is refined into goals 16-18 to depict the different categories of transition, which are the introduction of a new capability and the modification or retirement of an existing capability. Goal 19 is supported by goal 20, allocating resources to a capability. It is, in return, supported by goals 22-24, that depict the specification of resource ownership, the identification of external resources and management of internal resources. Goal 22 is also supporting goal 21 and goal 24 is supporting goal 22. Goal 22 is supported by goals 25-27 which concern the identification of outsourced tasks, supporting the definition of organizational boundaries and the identification of collaborating organizations accordingly.

Visually, the model consists of two parts. The upper part, which includes the goals elicited through the literature review, and the lower part, which includes the goals that were elicited from the case study and complement the initial set. The red dashed line depicts the border between the two sets of goals.

Discussion

The two sources of requirements for the method under development have provided requirements that were not only consistent, but also complementary to each other. The fact that the initial set of literature requirements are not all included in the case study requirements does not mean that they do not exist. On the contrary, the majority of requirements are overlapping. This applies to several goals from the literature. For example, in the case study, the need to monitor specific contextual fields, i.e. political, social, economic, technological and legal fields, supports the more generic goal found in the literature; to observe the business context. Therefore, the initial goal of the need to perform observations is present in the case. Even though there has been no explicit mention of the observation part, there were implications of different sources of observed data that motivated change requests. For example, there was political influence and pushing from employees to improve the service and reduce costs using new technologies. Additionally, the attributes of any relevant method supporting observation like PESTLE analysis [START_REF] Law | A dictionary of business and management[END_REF] which seems highly consistent with this study's findings, should be taken into consideration.

The two change requests tackled in the case study have provided the opportunity to elaborate requirements on two types of capability change. Change 1 concerns the modification of an existing capability and change 2 concerns the introduction of a new capability. An interesting observation is that both cases are resolved by the reallocation of existing resources, both internal and external to the organization. This resulted in emphasizing the need for a clear definition of the boundaries of an organization, a task which can be assisted by identifying the resources and tasks that belong to collaborating organizations. Contracts may not be needed in every possible occasion, however, any type of boundary needs to be controlled in order to avoid possible conflicts and problems, even by informal agreements. Any method that aims to support changes and include inter-organizational capabilities should take this into consideration. In addition, as depicted in the goals, there is a significant difference between internal and external resources and tasks. The former can be managed while the latter can only be identified and the method should tackle these specific activities. The goal model has also made possible to emphasize the importance of capability configuration, since it is the only goal that currently supports both decision support and delivery.

A noteworthy fact concerns the increasing frequency of inter-organizational collaborations [START_REF] Ziemann | Modelling of Cross-Organizational Business Processes -Current Methods and Standards[END_REF], leading to inter-organizational capabilities, however, the literature sources have not addressed this issue to date. Capability modeling has not elaborated on inter-organizational capabilities and this provides a great opportunity for the method under development to contribute to this part of changing capabilities as well. The interorganizational capabilities studied in this case can prove as a starting point for researching the behavior of changing inter-organizational capabilities, being private to private, public to public or public to private as in the RH case.

Conclusion

In this paper, we have elicited requirements for developing a modeling method that uses the concept of capability to manage enterprise transformation in dynamic environments. Reusing the systematic literature review findings of our previous work has provided a set of goals. A case study from a public healthcare organization in Sweden has confirmed the main goals derived from literature and complemented the final set with goals concerning inter-organizational capability changes. The result has been presented in the form of a goal model that integrates all requirements from both sources. Concerning future work, the requirements elicited from literature need to be practically validated. In addition, the requirements elicited from the case study belong to a single case and should be validated and possibly refined by enterprise transformation practitioners. The goal model presented in this study is the first step of an iterative process that is planned to proceed in the near future. When defining requirements will have been completed, the development of the method will begin.

Fig. 1 .

 1 Fig. 1. The 4EM Goals model for capability change.

Table 1 .

 1 Goals elicited from the literature review.

	No Name	Description
	1 To manage capa-	Changing an enterprise capability is the primary goal of the method as a
	bility change	response to the ever-changing environment of the enterprise.
	2 To observe busi-	Considering the organization as a system, the environment of the system
	ness context	needs to be monitored to increase awareness of the factors that significantly
		affect changes.
	3 To support deci-	Deciding whether a change is needed and how it should be performed is an
	sion on capabil-	essential part of any change process. The method should support decision
	ity change	making about change of enterprise capabilities.
	4 To manage capa-	The method should support capability delivery. A capability may be deliv-
	bility delivery	ered by several activities that need to be analyzed.
	5 To identify deci-	Any decision on a capability change needs to be based on a structured set
	sion criteria	of relevant criteria. The method should support its identification.
	6 To identify capa-	The method should support identification of alternative capability config-
	bility alternatives	urations during design time, or new alternatives identified through moni-
		toring the capability delivery at run-time.
	7 To analyze ob-	The data captured from the environment need to be analyzed and processed
	served context	according to the factors relevant to the change. The method should support
	data	these activities.
	8 To ensure that	Intentional elements reflect the goals that a capability fulfills. The method
	decision com-	should facilitate the inclusion of relevant intentional elements in the deci-
	plies with inten-	sion towards a capability change.
	tions
	9 To elicit internal	It is important to identify which contextual factors are affecting the capa-
	and external	bility so that they can be monitored properly.
	business context
	10 To manage tran-
	sition delivery

Acknowledgment

We would like to express our gratitude to the employees of RH who took their time in letting us interview them to identify and describe the cases presented in the paper.