Keywords

1 Introduction

Capability management is expected to contribute to a new level of productivity in developing and deploying IT-based business services offered by digital enterprises to their customers. One of the key features in capability management is to explicitly capture the delivery context of business services and to provide mechanisms for configuring an existing information system (IS) or generating its delivery according to a capability design (see Sect. 3). Work on capability management so far emphasizes the technology perspective of capability design and delivery, for example as designed in the Capability Driven Development (CDD) approach of the EU-FP7-project Capability-as-a-Service (CaaS) (see Sect. 3).

The initial application of capability as a construct for supporting context dependent design and delivery of business has been promising (c.f. for instance [1]). As the next step of making the CDD approach practicable, this paper ponders on the question of what is the potential of capability management in general and the CDD approach in particular when it comes to business model innovation? The paper addresses this question by considering a case study from business process outsourcing as an example. The aim of the paper is to apply an established business model conceptualization as a framework for analyzing the case study and to compare the possibility to identify business innovations with and without defined capability characteristics. The business model conceptualization provides a number of partial business models that represent perspectives on the business model (see Sect. 2.1). Based on the comparison, we will identify the most promising partial business model for assessing the business innovation potential.

The remainder of the paper is structured as follows: Sect. 2 summarizes the background for the work from the areas of business models and capability management. Section 3 presents the main aspect of the CaaS approach to capability design and delivery which includes essential aspects of capability management. Section 4 introduces the case study including a selected business service. Section 5 analyzes the case study from Sect. 4 using the business model conceptualization from Sect. 2 and the capability design and delivery approach from Sect. 3. Section 6 summarizes the work and draws conclusions.

2 Background

As a background for the work presented in this paper, this section briefly summarizes work in the areas of business models and capability management.

2.1 Business Models

Business models have been an essential element of economic behavior since decades, but received significantly growing attention in research with the advent of the Internet [4] and expanding industries dependent on post-industrial technologies [3]. In general, the business model of an enterprise describes the essential elements that create and deliver a value proposition for the customers, including the economic model and underlying logic, the key resources and key processes.

Zott and Amit identified three major lines of work in their analysis of recent academic work in business model developments [14]:

  • Business models for e-business scenarios and the use of IT in organizations

  • The strategic role of business models in competitive advantage, value creation and organizational performance

  • Business models in innovation and technology management.

For analyzing the business innovation potential of capabilities, we consider both value creation based business models for the service industry and approaches from e-business as promising [2, 12]. For the purpose of this paper, the proposal by Wirtz seems to be most suitable due to the explicit identification of six partial models: capital model, procurement model, manufacturing model, market model, service offer model, and distribution model. In this way the essential parts of value creation are covered. The capital model is subdivided into financing model and revenue model. The financing model describes the sources of the capital that is necessary for business activity. The revenue model provides means to generally systemize business models by four dimensions: direct or indirect generation of revenue, as well as the transaction-dependent and the transaction-independent generation of revenue. The procurement model describes production factors and their sources. Here the distribution of power between suppliers and demanders is an important aspect. The manufacturing model covers the combination of input factors to new goods and services. Demand structures as well as the competitive situation are described by the respective sub-models of the market model. The service offer model defines which IT services are provided to the customers, while the distribution model focuses on the channels that are used to make the IT services available to the specific customer groups. Wirtz has proposed a categorization of e-business models by the kind of IT service offered (see Fig. 1).

Fig. 1.
figure 1

Partial models of the integrated business model [12]

Full size image

2.2 Capability Management

The term capability is used in different areas of business IS. In the literature there seems to be an agreement about the characteristics of the capability, yet there is no generally accepted definition of the term. The definitions mainly put the focus on “combination of resources” [6], “capacity to execute an activity” [5], “perform better than competitors” [8] and “possessed ability [13]”.

The capabilities must be enablers of competitive advantage; they should help companies to continuously deliver a certain business value in dynamically changing circumstances [9]. They can be perceived from different organizational levels and thus utilized for different purposes. According to [10], performance of an enterprise is the best, when the enterprise maps its capabilities to IT applications. Capabilities as such are directly related to business processes that are affected from the changes in context, such as, regulations, customer preferences and system performance. As companies in rapidly changing environments need to anticipate variations and respond to them [7], the affected processes/services need to be adjusted quickly. i.e., adaptations to changes in context can be realized promptly if the required variations to the standard processes have been anticipated and defined in advance and can be instantiated.

In this paper capability is defined as the ability and capacity that enable an enterprise to achieve a business goal in a certain context [16]. Ability refers to the level of available competence, where competence is understood as talent, intelligence and disposition, of a subject or enterprise to accomplish a goal; capacity means availability of resources, e.g. money, time, personnel, tools. This definition utilizes the notion of context, thus stresses the variations of the standard processes.

To summarize, capabilities are considered as specific business services delivered to the enterprises in an application context to reach a business goal. In order to facilitate capability management, we propose business service design explicitly considering delivery context by an approach that supports modeling both, the service as such and the application context.

3 The CaaS Approach to Capability Design and Delivery

Business services are IT-based services that digital enterprises provide for their customers. Business services usually serve specified business goals, are specified in a model-based way, and include service level definitions. To ease adaptation of business services to new delivery contexts, changes in customer processes or other legal environments, the CDD approach, developed in the CaaS project, is to explicitly define (a) the potential delivery context of a business service (i.e. all contexts in which the business service has to be potentially delivered), (b) the potential variants of the business service for the delivery context, and (c) what aspect of the delivery context would require what kind of variation or adaptation of the business service.

The potential delivery context basically consists of a set of parameters or variables, the, so called, context elements, which characterize the differences in delivery. The combination of all context elements and their possible ranges defines the context set, i.e. the problem space to cover. The potential variants of the business service, which form the solution space, are represented by process variants. Since in many delivery contexts it will be impractical to capture all possible variants, we propose to define patterns for the most frequent variants caused by context elements and to combine and instantiate these patterns to create actual solutions. If no suitable pattern is available, the conventional solution engineering process has to be used. The connection between context elements, patterns and business services has to be captured as transformation or mapping rules. These rules are defined during design time and interpreted during runtime.

The above simplified summary of the CDD approach has been further elaborated by defining meta-model and method components (available in [11, 17], respectively), by specifying a development and delivery environment, and by performing feasibility studies.

In order to implement the CaaS approach, a capability development and delivery environment was designed and currently is under development. The main components of the environment are capability design tool, context platform, capability delivery navigation application, as well as capability delivery application. The architecture of the environment is shown in Fig. 2. The main functional components of the environment are as follows:

Fig. 2.
figure 2

Components of the capability development environment

Full size image

  • Capability modeling module - provides modeling elements defined in the capability meta-model and models the required capability including business service (e.g. business process model), business goals, context and relations to delivery patterns.

  • Pattern composition module - identifies appropriate patterns for capability delivery and composes the patterns together. It supports incorporation of external resources into the composition. If some of the patterns required are not available then the modeling of missing information is supported and new patterns can be proposed and documented.

  • Repository of capability patterns - storage and maintenance of available capability delivery patterns.

  • Context platform - captures data from external data sources including sensing hardware and Internet based services such as social networks. It aggregates data and provides these data to subscribers.

  • Context modeling module - represents the context data in terms of the capability modeling concepts and provides means for context analysis and amalgamation.

  • Capability assessment (evaluation) module - performs assessment of financial and technical feasibility of the proposed capability.

  • Capability integration module - generates the capability delivery navigation application, which also incorporates algorithms for capability delivery adjustment.

  • Capability delivery navigation application - provides means for monitoring and adjustment of capability delivery. It includes monitoring module for monitoring context and goal KPI, predictive evaluation of capability delivery performance and delivery adjustment algorithms. The capability delivery adjustment algorithms are built-in in the capability delivery navigation application. The algorithms continuously evaluate necessary adjustments and pass capability delivery adjustment commands to the capability delivery application.

Capability delivery application is developed following the process and technologies used by a particular company. The CDD methodology only determines interfaces required for the CDA to be able to receive capability delivery adjustment commands from the capability delivery navigation application and to provide the capability delivery performance information.

4 Case Study from Business Process Outsourcing

The industrial case study presented in this section is a part of the CaaS project. It is carried out at. SIV.AG from Rostock (Germany). SIV offers different kinds of business process outsourcing services. The target group for these services is medium-sized utility providers and other market roles of the energy sector in Germany, Bulgaria, Macedonia and several other European countries.

Energy distribution companies are facing a continuously changing business environment due to new regulations and bylaws from regulating authorities and due to competitors implementing innovative technical solutions in grid operations or metering services, like intelligent metering or grid utilization management. In this context, both the business processes in organizations and IS supporting these processes need to be adaptive to changing organizational needs. Examples for typical business functions are assets accounting, processing and examination of invoices, meter readings, meter data evaluation, automatic billing, customer relationship management, maintenance management, inventory management, order management, and project management.

A key service area of SIV.AG is business process outsourcing (BPO), i.e. the performance of a complete business process for a business function by a service provider outside an organization. This service has to implement potential variations of the clients’ way of performing business. One variation is inherent in the business process as such. Even though core processes can be defined and implemented in standard software systems, configurations and adjustments for the organization in question are needed. The second cause of variation is the configuration for the country of use, i.e. the implementation of the actual regulations and bylaws. The third variation is related to the resource use for implementing the actual business process for the customer, i.e. the provision of technical and organizational capacities. Basis for these services is SIV’s software product kVASy4. Integrated with the business process environment, the “native” kVASy4 services providing business logic for the energy sector are implemented using a database-centric approach.

As an example for a BPO service offered by SIV, we will in the following describe the MSCONS business service. MSCONS is offered by SIV due to defined business goals. A business goal is defined as desired state of affairs to be attained [16]. The goals in this case are modeled using the 4EM-Approach [15]. Due to the relationships between the SIV.AG and its customers, a distinction was made between customer goals and SIV goals, i.e. customer goals are more operational whereas SIV follows strategic business goals. This can be considered as a support relationship. Respectively the main goal of SIV is to deliver constant business value to its customers, which supports to efficiently control business processes goal of the customer. Goals can be refined into sub-goals, thereby forming a goal hierarchy. To efficiently control business processes, customers aim to optimize case throughput and to achieve a high process quality. Both can be considered as subordinate goals in the use case.

According to the CaaS approach, business goals require capabilities to be successfully fulfilled. Enabling the SIV´s customers to optimize their case throughput requires SIV to deliver capabilities for them to route their processes in accordance with the workload. For this case, this capability is called “Dynamic Business Service Provider (BSP) Support”.

The high level business process “message validation” is required by the capability “Dynamic BSP Support”. In particular, the industrial case implements the MSCONS (Metered Services Consumption Report Message) validation processes from a global view. The purpose of the global process in MSCONS use case is the transmission of energy consumption data from one market role to another role. By regulatory requirement, all data must be sent by e-mail and its format must comply with the international UN/EDIFACT standard. In addition to this requirement, national variants of the EDIFACT standard may exist that add further constraints to the syntactical structure of exchanged messages. Thus, messages must not only comply with the international but also with the national EDIFACT standard, which are subject to periodical change by the regulatory authorities, with usually two releases per year.

An invalid message causes an exception to be thrown. Currently, all of these exceptions are treated manually, involving a knowledge worker; dynamic aspects, such as the handling of exception by customer under certain conditions, are not taken into account. Offering dynamic capabilities to route the exception handling process requires recognizing the application context, in which the exception is thrown. e.g., the customer might prefer to outsource his processes to SIV.AG if there are huge numbers of errors when validating the MSCONS message. The process outsourcing might depend on the backlog size, exception type and available resources at SIV, which are arranged with a service contract between SIV and the customer. As a result, two process variants are of use – the handling of the exception by customer or by SIV. The CaaS approach applies patterns for the implementation of the respective process variants that react to the anticipated changes in context and adjust the capability delivery process properly.

5 Business Model Analysis and Innovation Potential

To illustrate business model analysis and identification of innovation potential, we selected the MSCONS business service discussed in Sect. 4. Starting from an analysis of the partial business models according to Wirtz’s approach we will discuss innovation potential in Sect. 5.1. In Sect. 5.2 we will extend the MSCONS business service to a capability using the CaaS approach and, discuss business innovation for this capability as well as compare it to the findings from Sect. 5.1.

5.1 Analysis of MSCONS Business Model

When analyzing the business model of the “MSCONS” service in Table 1, we assume that the IT-infrastructure for providing the service and the software platform (kVASy ERP system, EDIFACT messaging, document management, etc.) already have been installed, i.e. the focus is on the service as such. The actual analysis consists of describing the different partial business models in order to expose the different aspects of the business model.

Table 1. Business model of “MSCONS”
Full size table

Business model innovations can be identified by going through each and every partial model, analyzing each model for potential alterations in the current status and examining the effects on the other partial models. e.g., if for the demand model a new target group is identified, this might have immediate effects on procurement and manufacturing model. One of the traditional ways to identify innovations potential is, however, to take a value chain perspective and analyze whether business should be extended to neighboring parts of the value chain. A change in the procurement model to no longer outsource account printing but to do it in-house would be such an example, which again has the effects on most other partial models.

5.2 Capability Analysis Regarding Business Innovation Potential

Following the CaaS approach for capability design and delivery, capability modeling includes as an initial step to capture the delivery context of a business service in a context model with specified relationships to business goals of the enterprise [18]. When doing this for the MSCONS business service, three main business drivers are identified, which cause variations and thus provide stimulus for changes. The first business driver is the contractual aspect, which specifies parameters such as backlog threshold as well as the process variant to be implemented regarding the backlog size, such as “if the backlog size exceeds the agreed threshold, then the case is routed to customer”. The second business driver, payload aspect, includes information of the service call such as the market role, the faulty message and the exception type etc. The last driver, the operational aspect, is related to both SIV Services personnel deployment plan and the kVASy-operating environment. These are captured as variation aspects, which are further elaborated to identify context elements. Table 2 illustrates the context elements, their properties and allowed ranges.

Table 2. Context elements as causes of variability
Full size table

Using the context model with the above context elements, the business service MSCONS can be extended to a capability by providing adaptations of MSCONS for all desired delivery contexts, e.g. by using patterns, and by controlling and configuring MSCONS for these different delivery contexts using the capability navigation application.

From a business model perspective, the extension from a business service to a capability will not make the business model described in Sect. 5.1 invalid or obsolete. The initial MSCONS business service still can be offered. However, as the context elements identify potential variations in the business service caused by a change in delivery context, these variation points form starting points for identifying changes in partial business models which eventually will lead to changes in MSCONS and the overall business model.

The variation aspect “operation” with its context element “operating platform” can serve as an example. The three different context element values are “data center”, “cloud” and “customer”. Each of these values can be considered as representing variants of the existing business model: MSCONS operated in the own data center, in the cloud, in the customer’s data center, or as a mixture between own data center, cloud and customer’s data center. If it would make sense to actually distinguish the business model for these variations depends on the effects on the other partial models. However, the investigation of potential innovations can start from the context elements.

6 Summary and Concluding Remarks

Based on an example of a business service from BPO in energy industries, the paper showed how to decompose the underlying business model into different partial models according to Wirtz’s approach. When extending the business service into a capability by – as a first step - modelling the context for service delivery, the context model proved to be useful for identifying potential variants of the existing business model and thus potential business innovations, as the context elements represent starting points for changes in the partial business models.

The main limitation of our work is that we have analysed only the business model for one business service. More services will have to follow to develop our observations into clear implications. Furthermore, the business model analysis was done by a researcher from the field, not by a practitioner from the company. Future work will have to include a validation of the results by a practitioner.

The business model analysis resulted in a so far unrecognized option for capability modelling. We had a strong impression during analysis that the different partial business models could actually help identifying context elements in capability modelling and thus help defining more complete and precise capability definitions. For example, the use of a different supplier for accounting printing was identified as part of the procurement model. This indicates that there probably is one more variation aspect which should be part of the capability definition.