1 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 [1]. 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 [2, 3] 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 [4]. In addition, the notion of capability has emerged in IS engineering as an instrument for context-dependent design and delivery of business services [5]. 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 [5, 6].

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 [5].

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 [7, 8] 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 [9], 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 Sect. 8 provides concluding remarks and briefly explains the next steps of this research project.

2 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 [10]. 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) [11] and CDD (Capability-Driven Development) [5]. 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) [13], (iii) Ministry of Defence Architecture Framework (MODAF), and (iv) Archimate [14]. There have also been research contributions that provide suggestions on how to model capabilities based on existing modeling methods like i* [15] or Capability Maps [16] or introducing new notations like CODEK [2] to include the elements required to capture how a capability can change or be changed in dynamic environments.

3 Methods

This study belongs to a project elaborated within the Design Science paradigm, in particular, following the guidelines of [7], 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?” [7]. 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.

3.1 Literature Review

In an earlier study [17], 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 [17]. In the latter, the requirements concerning change were identified in the related papers and were associated to enterprise capabilities.

3.2 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 [18] was applied. That is, for each identified change request the interviewers also asked the experts to identify the potential change impact.

3.3 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 [9]. 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 [9], is defined as a desired state of affairs that needs to be attained [10]. 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 [10]. 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.

4 Requirements from Literature Review

This study is a continuation of a capability literature review [17], 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 [17]. 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 [19,20,21]. 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 [22]. 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 [23, 24], 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 [5], 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 [10]. Summarizing, the identified goals that are associated to observing are 2, 9 and 12–15 as shown in Table 1.

Table 1. Goals elicited from the literature review.
Full size table

Regarding supporting change decisions, the decision needs to be associated to a set of criteria [17, 24], for example, rules and constraints [21] 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 [25]. Regarding the decision itself, it may concern selecting among existing variants or alternatives [19,20,21, 24] 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 [17] 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 [5], 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 [26], 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 [17], it has also been associated to capabilities in several studies like [19, 27,28,29]. 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 [17]. 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.

5 Requirements from the Case Study

5.1 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.

5.2 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.

5.3 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.

5.4 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.

5.5 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.
Full size table

6 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.

Fig. 1.
figure 1

The 4EM goals model for capability change.

Full size image

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.

7 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 [31] 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 [32], 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 inter-organizational 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.

8 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.