Keywords

1 Introduction

Increasing environmental volatility, new business models, and the globalization of organizations mean decision making is becoming more and more complex. In this environment, managers rely on management control systems (MCS) as they translate strategy into action and monitor the impact of these actions on their organization’s performance [17]. At their core, MCS consist of an IT-enabled corporate planning and reporting system [2, 33].

Brynjolfsson and Hitt [7] emphasize the importance of leveraging IT for business value as follows: “Today, the critical question […] managers are facing is not does IT pay off but how can we best use computers?” While researchers still debate on how to design IT-enabled planning and reporting capabilities that better address individual business needs [17, 23], IT management most often does not apply a systematic method to manage their resources, but rather follows software vendor promises or consultancy advices.

We propose a concept of maturity models (MM) to address this issue. Based on the stages of growth theory [40], they consist of multiple archetypal levels that represent the evolution of a certain domain [14]. In information systems (IS) MMs describe the extent to which a capability becomes more mature along a defined evolutionary path depending on the IT resources deployed. They can serve as powerful tool for designing and using IT effectively and efficiently [5].

MMs have increasingly gained the attention of both researchers and practitioners in recent years. Since the 1970s [9, 16], a variety of MMs has been developed. Becker et al. [5] reported more than 1,000 articles over a period of 15 years referring to MMs, and Mettler and Rohner [37] found more than 100 different versions from domains including knowledge management, project management, and business process management. Although MMs assess the current status of firm capabilities [48], there are two major points of criticism. First, MMs lack a theoretical foundation [45, 46]. To overcome this shortcoming we will use findings from the resource-based view (RBV) [4]. It is widely used in management research and provides researchers with a “robust framework for analyzing whether and how IT may be associated with competitive advantage” [36]. Second, Mettler and Rohner [37] found that MMs rarely provide firm-specific guidance on how to move from one maturity level to the next leveraging IT resources.

The objective of this chapter is therefore to develop a method to systematically adjust MMs from the knowledge base to firm-specific business needs, in our case, to finally arrive at individual IT-enabled MCS capabilities. We apply findings from the RBV to guide the development process of our method.

The chapter follows the tenets of design science research (DSR) in IS [21]. After a brief introduction of MCS we review the state of the art in MM research for MCS in order to identify the research gaps that motivate our method development (Sect. 2). We introduce the RBV as our design theory (Sect. 3.1) before we apply their findings to inform the development of our method (Sect. 3.2). Using an interpretive case study in the chemical sector we demonstrate how to adjust a MM from the knowledge base to develop the proposed firm-specific IT-enabled MCS capabilities (Sect. 4). Finally, we discuss our results before we lay out avenues for future research (Sect. 5).

2 Maturity Models for Management Control Systems

Corporate management formulates and implements value-creating strategies [8]. It thus encompasses formal instruments to coordinate and control an organization [2]. MCS, in turn, constitute such formal instruments, as they are defined as “formalized procedures and systems that use information to maintain or alter patterns in an organizational activity” [51]. The purpose of these systems is “to monitor decisions throughout the organization and to guide employee behavior in desirable ways in order to increase the chances that an organization’s objectives, including organizational performance, will be achieved” [27]. Although research on MCS is predominantly driven by function, IT support is regarded as an important enabler [18].

As a measure of the effectiveness and efficiency of IS design and use, maturity can be defined as “the state of being complete, perfect or ready” [50] or, in a sense more specific to IS research, “a measure to evaluate the capabilities of an organization” [48]. A MM’s scope is determined by its application domain and its focus area [53]. In order to specify the state of the art of MMs for MCS, we conducted a literature review according to vom Brocke et al. [56]. Using a keyword search in scientific literature databases, we first accessed EBSCOHost, SpringerLink, ABI/INFORM, and ScienceDirect. We limited our database search to title, abstract, and keywords. In a second iteration, we searched Google including MMs published in practitioner-oriented outlets. Our keywords covered both accounting information systems (AIS)-related as well as IS-related terms (Fig. 1).

Fig. 1
figure 1

Search strings used for the structured literature review

Full size image

After a closer look at the title, abstract, and keyword we identified 30 publications for an in-depth analysis. Studying the content of these papers, we examined 20 different MMs for our analysis (Table 1). Ten papers were excluded due to the fact that they were lacking MMs or just described previously published ones. Our findings are presented in four main columns (1–4) where each column is decomposed into further dimensions. (1) MCS cover both planning and reporting as their most important capabilities; (2) To gather a wide range of MMs we searched the AIS in particular and the IS domains in general. (3) Most of the MMs origin in practice, not in research. (4) Finally, the column methodological support marks MMs if they provide the user with a method to adapt existing MMs.

Table 1 Maturity models for corporate management
Full size table

MMs that address either planning or reporting are more or less equally covered in our findings. Furthermore, Table 1 shows that most MMs addressing MCS capabilities are developed in the IS and less in AIS domain. Moreover, the examined MMs predominantly origin from practice as opposed to research. Thus, specifying our general criticism on MMs (Sect. 1), a first shortcoming of MMs addressing MCS capabilities is that they often lack a theoretical foundation. Furthermore, large chunks of MM research focus either on the (generic) development of MMs (e.g., [5]) or on the development process itself (e.g., [33]). We could neither find a single MM that provides a method that either guides the application and especially the adjustment of MMs to firm-specific business needs, nor the development of individual IT-enabled MCS capabilities. Existing MMs are often either too generic [11] or too specific [12]. Furthermore, our research indicates that MMs rarely provide prescriptive statements on how to advance from one maturity level to the next by leveraging IT resources.

We believe MCS and its MMs complement the “modern” AIS domain. If they are used to evaluate and design AIS, they provide a fact-driven evolvement of corporate management beyond “pure” state-of-the-art extrapolation. However, methodical support is required to raise their acceptance in general and in particular in AIS. Hence, this article introduces a method to systematically adjust MMs according to individual business needs to develop firm-specific IT-enabled, in our case, MCS capabilities.

3 Method Design

3.1 Design Theory

To overcome the shortcoming that MMs lack a formal theoretical foundation we follow Pöppelbuß et al. [46] who call for a theoretical foundation of MMs based on the RBV. The RBV states that every company consists of an individual bundle of resources [4]. The postulate of resource individuality, determining the uniqueness of every organization’s resource combination, accounts for a probable sustainable competitive advantage. This comprehends two key propositions: First, resources are heterogeneous. Second, resources are immobile. Four attributes characterizes every resource: valuable (V), rare (R), inimitable (I), and non-substitutable (N)—VRIN. The peculiarities of these attributes determine the likelihood whether a resource is able to establish a (sustainable) competitive advantage [34]. In IS research, the RBV’s core elements are IT capabilities (e.g. project management, programming) and (in-)tangible IT assets (e.g. hardware, software). IT assets are an input or output in a transformation process which is represented by (IT) capabilities [57]. As Nevo and Wade [41] have illustrated the combination of IT and non-IT assets form IT-enabled capabilities. Thus, the combination of both IT and non-IT assets is a prerequisite to enable organizational capabilities with IT.

Patas [42] made a first attempt to base the MM concept and its components in theory. Using the RBV he converts basic MM components into RBV elements as depictured in Fig. 2. A MM’s structure is typically based on the Capability Maturity Model (CMM) for Software Engineering. According to Fraser et al. [14], MMs usually define a number of maturity levels, a concise descriptor for each level, a description of the content of each level, several dimensions to concentrate on a certain domain aspect (e.g., corporate planning in corporate management), and a set of elements and activities (e.g., knowledge, business practices, software, hardware, etc.) for each level. MMs should also encompass an assessment instrument, usually in form and function of a questionnaire that helps to evaluate the current maturity level of a capability [33].

Fig. 2
figure 2

Maturity model cube

Full size image

The most basic elements of the RBV are IT assets and non-IT assets transformed into IT-enabled capabilities. Elements and activities are the most granular MM components defined at each maturity level within a dimension. We therefore convert elements and activities into the constructs assets (both tangible or intangible and IT or non-IT) and dimension into the construct IT-enabled capabilities. While dimensions were able to cover, for instance, solely IT elements such as software and hardware, now capabilities require a combination of IT and non-IT assets to be considered IT-enabled. The MM component focus area expresses a certain class of non-IT or IT assets. We convert focus area into the construct asset class to reflect a stream of assets evolving along the determined IT-enabled capability evolution path. In this course, we leave generic description of maturity level and level descriptor unchanged as the RBV defines no equivalents. However, they constitute some descriptive constructs that are required for the MM documentation. Figure 2 shows the relations of the constructs that form the so-called MM cube.

The MM cube shows the maturation path for a single IT-enabled capability (e.g., IT-enabled corporate reporting). We decided to depict five levels on the MM cube because MMs generally define five levels [37]. IT assets are located on the x-axis and non-IT assets on the z-axis. The y-axis represents the maturation path based on the stages hypothesis. Every single elementary cube represents a combination of IT and non-IT assets on a particular maturity level. Slicing the cube horizontally returns an IT-enabled capability layer that shows all IT and non-IT assets and their combinations on a particular maturity level. Slicing this cube vertically returns the maturation path for a single asset class showing all possible combinations with either IT or non-IT assets.

3.2 Constructing the Method

We adopt the process framework proposed by Sirmon et al. [52] to structure and bundle resources before the capabilities are deployed. Once again, each of those three processes is divided into three sub processes. We intend our method to be applied according to March and Smith [31] as “… way of performing goal-directed activities…” in order to adjust MMs from the knowledge base to firm-specific business needs with the goal to develop individual IT-enabled capabilities. Therefore, we complement our method with a preparing process. Subsequently we describe the entire method consisting of the three main processes preparing, bundling, and structuring as illustrated in Fig. 3.

Fig. 3
figure 3

Adjusting MMs to individual business needs to build firm-specific IT-enabled capabilities

Full size image

Preparing comprises the two sub processes mapping, and assessing. Mapping projects the selected MM on the MM cube in order to prepare it for subsequent adjustments. Therefore, the chosen MM has to be first analyzed in order to map the relevant components (assets classes, IT assets, non-IT assets, etc.) to the MM cube. If the mapping sub process reveals that, for instance, the selected MM provides no IT assets or no non-IT assets, another MM might be more appropriate or the current MM has to be extended within the following sub processes. Subsequently, assessing the as-is situation returns the current maturity level and the missing assets in the organization’s portfolio according to the MM cube.

Structuring the asset portfolio consists of the three sub processes acquiring, accumulating, and divesting, whereby not all sub processes have to be necessarily carried out. To close the asset gaps revealed during the assessment, two sub processes are suggested. While acquiring refers to deciding whether the missing assets have to be bought, accumulating deals with the question whether those assets should be better engineered. More clearly, make or by decisions have to be made. Finally, divesting decisions are required. On the one hand, some assets might be out-of-date and are therefore not state-of-the-art technologies. On the other hand, some assets might be very expensive in their maintenance. Therefore, an analysis from an economic perspective should reveal divestment opportunities when this process step is performed [47].

Bundling deals with developing or altering IT-enabled capabilities. It is detailed by the following disjunctive non mutual exclusive sub processes stabilizing, enriching, and pioneering. Stabilizing refers to minor changes and improvements on an IT-enabled capability to keep it “up-to-date” by changing some parameters of an elementary cube; for instance, training an employee in its current working domain. Enriching refers to the extension or elaboration of an existing IT-enabled capability. This sub process can be accomplished with a dicing operation. For example, enriching refers to extending a software application with new modules (SAP extended with SAP CRM). Regarding pioneering, Sirmon et al. [52] emphasize that it “… may involve the integration of completely new resources that were recently acquired from strategic factor markets and added to the firm’s resource portfolio.” If only non-IT assets are mapped to a MM cube, the capability has to be redesigned by incorporating IT asset classes to form firm-specific IT-enabled capabilities.

4 Demonstrating the Method

4.1 Research Design

Demonstrating the applicability of an IS artifact is an important activity in DSR in IS [21]. Peffers et al. [44] consider case studies as an appropriate method to accomplish this task. Case studies are recommended to answer “how” or “why” questions [58, 60]. As we focus on “how” our method works in practice, we demonstrate that it can be used to systematically adjust MMs from the knowledge base to individual business needs with the goal to finally develop firm-specific IT-enabled capabilities (Sect. 1).

We studied three organizations in the Chemical sector that were merged into a joint venture (JV) during our research period from October 2011 to March 2012. The management board decided to design a new organization including the IT infrastructure, business processes, compensation systems, etc. They were curios whether our method can be applied to analyze corporate management’s agenda covering the design and development of IT-enabled corporate planning and reporting capabilities. Based on our findings, the companies’ benefits were an assessment of the as-is situation using a MM for MCSs before the JV was formed. Additionally we provided them with an evaluation of their transformation agenda to establish and design IT-enabled planning and reporting capabilities.

4.2 Case Setting, Data Collection and Analysis

Before entering the field, Darke et al. [10] recommend specifying the constructs that are going to be demonstrated. Besides maturity level descriptor, generic maturity level description, and IT-enabled capabilities, our constructs cover IT and non-IT assets as well as asset classes. To instantiate our method we have specified a prior IT and non-IT asset classes taken from Patas et al. [43]. In so doing, we “[…] create[d] a framework which takes account of previous knowledge […]” [58]. In detail, the IT asset (ITA) classes are: technological assets (ITA1), e.g. hardware and software; technological quality assets (ITA2), e.g., modularity, availability, security; IT external relationship assets (ITA3), e.g., information sharing with customers and suppliers. Non-IT asset classes are human assets (NIT1), e.g., cooperation, ability to learn, enthusiasm, skills; knowledge assets (NIT2), e.g., business process knowledge; business assets (NIT3), e.g., business work practices and templates, key performance indicators, strategies. Specifying constructs before entering the field helped us to analyze whether planning and reporting capabilities are designed to qualify as IT-enabled.

Located in Europe, Organization A was a large division of a listed group with revenues of approx. €3.7 bn. It had more than 1,400 employees and produced styrene plastics. Organization B, employing about 1,200 people with revenues of about € 2.1 bn., was also located in Europe and produced ethylbenzene and styrene monomer. Organization C specialized in the production of synthetic terpolymers was located in the United States. Although it employed more than 1,500 people, in terms of revenues (0.8 bn.) it was the smallest organization. The new JV is located in Europe with about 6.5 bn. revenues and with more than 3,100 employees. Notably, as it mainly sells commodities it acts in a volatile environment with volatile prices but has also some R&D (Table 2).

Table 2 Key figures prior to and after forming the JV
Full size table

For data collection we used multiple sources as recommended in Yin [60] and documented in Table 3. Data collection was conducted from October 2011 to March 2012. Two researchers were involved, including an assistant professor and a doctoral student in the end of his third year.

Table 3 Data sources and methods
Full size table

4.3 Instantiating the Method

Preparing

Within selecting we chose the KPMG corporate performance management MM summarized in Table 4 for two reasons. First, it is used in practice, but was developed rigorously in collaboration with academia. All maturity levels are empirically derived using the Rasch algorithm [33]. Second, in contrast to the majority of published maturity models, it comes with an assessment instruments that we applied to evaluate the as-is situation before the JV was formed.

Table 4 MM for corporate planning and reporting capabilities [28]
Full size table

The MM summarized in Table 4 has no defined IT and non IT-asset classes. Mapping the MM to the MM cube requires first to elicit necessary assets both for planning as well as reporting capabilities on every maturity level. We used semi-structured interviews, described in Table 3, and asked four interviewees about instances of our pre-specified constructs for each maturity level and we briefly assessed the as-is situation to gather background information about the pre-JV situation. The two researchers jointly conducted the interviews. After summarizing the outcomes, removing repeatedly mentioned assets, generalizing the assets (for instance, replacing SAP ERP by the system class ERP systems), and comparing them with the MM, we returned the results to our interviewees asking for comments. As they did not come up with change requests, we mapped the assets to the MM cube (Fig. 4). The next sub process, assessing the JV’s as-is situation, was straight forward. Due to the early situation of the JV and the decision to design a completely new organization from scratch, only five figures were reported to the management board on global and on regions level and virtually no planning was carried out until January 2012. Although, according to Fig. 4 some assets were already deployed, we evaluated the as-is situation at L0 of both planning and reporting.

Fig. 4
figure 4

Conceptualization of the results and their mapping to the MM cube

Full size image

Structuring

According to the structuring process, management made different decisions that fit into the sub processes acquiring, accumulating, and divesting. For instance, most IT technological assets (ITA1) can be acquired from the factors market. Hereunto, the JV’s management board planned to roll out a standard ERP system, a data warehouse, as well as advanced BI analytics including a dashboard. They planned to enable their planning and reporting capabilities with IT over the next 2 years. Conversely, accumulating refers to assets that are hard to acquire; thus, assets that have to be developed. Analyzing the pre-JV situation for planning and reporting, the JV owns very diverse non-IT assets. With respect to their reporting capabilities, they were not lacking human, knowledge, and business assets evaluated at L4. However, we observed a broad variety of maturity levels within the asset classes. For instance, in Organization A accountants were acting as business partners. They have experience in communicating with the board and also know how to formulate data queries using advanced BI tools. Divesting decisions were also made. The three organizations were running seven different ERP system instances in total. To overcome the disadvantageous heterogeneity in their IT architecture, the board decided to acquire a state of the art system instead of facing the effort related to integration tasks and the corresponding political issues.

Bundling

Depending on the actual case the decision has to be made whether one or all three sub processes have to be carried out [52]. In the JV case, stabilizing is not reasonable, as incremental improvements require the existence of IT-enabled planning or reporting capabilities. However, we found indicators that the management tried to enrich their capabilities. For instance, on global and regions level the management accounting department formed groups consisting of accounting employees from all three pre JV organizations. The goal was to improve the non-IT assets NIT1, NIT2, and NIT3, classified on lower maturity level by mixing them with the more advanced assets for IT-enabled planning and reporting. Workshops were also organized to support this goal.

Pioneering entails a major challenge especially in the situation of forming a JV when new resources have to be incorporated. According to the project plan, the JV aspired to achieve maturity level L4 regarding their IT assets. However, our analysis revealed that management had no clear vision how to build unique IT-enabled planning and reporting capabilities. The project plan was mainly concerned with the implementation of IT assets completely disregarding non-IT assets. In contrast, the MM cube suggests combining and integrating IT and non-IT assets to form firm-specific IT-enabled planning and reporting capabilities (Fig. 4).

5 Conclusion, Limitations and Future Research

The objective of this chapter was to develop a method to systematically adjust MMs from the knowledge base to firm-specific business needs to form IT-enabled capabilities. Using a MM for MCS, we demonstrated how to apply our method and how to provide management with an individual view on their IT assets and non-IT assets. Our contribution to research is twofold. First, while research most often deals with the MM development itself, we introduced a method adjusting MMs to develop firm-specific IT-enabled capabilities. Second, we demonstrated how the RBV can be translated into action. Practice benefits from our findings as we introduce a comprehensive view on organizations’ IT-enabled capabilities and force managers to jointly consider their IT and non-IT assets according to their individual business needs. In this respect, managers can choose a MM that fits best their needs and adjust it in order to design firm-specific IT-enabled capabilities.

Shortcomings are that our approach does not constitute a comprehensive method according to method engineering. We do not define components such as roles, techniques, meta model, results, or tools [6]. Particularly, techniques could be valuable to support the different sub processes such as mapping or divesting decisions. Furthermore, we only demonstrated how to adjust one MM and then analyzed the suitability of the method to develop firm-specific IT-enabled capabilities. We did not evaluated whether our model will work with other MMs as well. In future research our method needs to be extended towards its comprehensiveness to support MM adjustments without any ambiguity. Moreover, as the RBV is associated with firm performance and competitive advantage, our approach could be studied under the light of IT business value or even the dynamic capability view [54].