Method Engineering for Integrated Enterprise Balancing

Abstract

Against the background of the current financial crisis and increasing compliance regulations, companies are forced to implement an integrated approach that includes not only risk management, but also e.g. compliance and value-based management. In this situation, the concept of integrated enterprise balancing (IEB) can be applied that integrates risk and return figures to support value-based management while maintaining regulatory compliance. So far, conceptual topics such as the identification of the 'best' risk management approach are often more important than implementation topics such as the rollout of an IEB solution into productive environment. To bridge this gap, we develop and evaluate a situational method that supports the implementation of an IEB solution. This method is comprised of 15 method fragments that support strategic, organizational, cultural, and technical rollout aspects. Furthermore, method configurations are specified that identify only those method fragments that are relevant for certain roles, e.g. project manager or process owner.

Keywords

• Risk Management
• Compliance Management
• Method
• Rollout

-

“Faced with threats from all quarters – recession and credit crunch, heated global competition, continuing Sarbanes-Oxley pressures – companies are making intensive risk management a top priority” [ 21 ]. Against this background, it will not be sufficient to pay a lot of attention to risk management alone. Instead companies are forced to integrate risk management with compliance management and value-based management [ 1 ]. To bridge the gap between these different approaches and to address current corporate requirements, the concept of integrated enterprise balancing (IEB) can be applied. IEB integrates risk and return figures to support value-based management while maintaining regulatory compliance [see 11; 13 and section 3.1].

Up to now, only little attention has been paid to both the implementation1 of risk, compliance and value-based management approaches and to the implementation of such an integrated approach. Conceptual topics or quantitative approaches such as the identification of the ‘best’ risk management approach or the ‘best’ value-based control parameter are often more important than implementation topics such as the identification of activities and resources necessary to put a chosen concept or solution into productive environment [ 40 ]. However, if literature addresses the implementation of risk, compliance or value-based management approaches [see e.g. 5; 20; 23; 26; 40], only some indications about the implementation are given. Structured recommendations or methods supporting the implementation are completely missing. Furthermore, integrated considerations are missing. Instead, mostly particular aspects of an implementation, such as putting a software system into practice or the training of employees, are in focus. Due to the fact that the implementation/rollout of an IEB solution is a complex problem as it is an integrated approach that is related to organizational and IT aspects, the need for a comprehensive methodological support for the implementation of IEB solutions becomes obvious.

Within the European Information Systems (IS) research discipline, but also in other areas of research [e.g. 12], it has been recognized that there is no ‘one-size-fits-all’ method for a problem domain. Instead so called situational methods which are adaptable to a specific problem situation need to be developed. Mirbel/Ralyté [ 28 ] support this statement; however, they criticize that users of a situational method still have to “apprehend the method as a whole and understand all its concepts in order to use it, which can have some negative impact” [28, p. 59] and discourage the users from using the situational method. A user has to perform specific tasks and thus needs his/her own configuration of the situational method [ 28 ]. Thus, situational methods should incorporate method configurations that allow for the user-/role-specific configuration of a situational method [ 28 ].

Based on the previous problem statement, the following research question will be addressed: How can the integrated implementation of an IEB solution in a company be supported systematically where individual requirements of method users are considered? In order to answer this question, we aim at developing a situational implementation method for IEB which is adaptable to the requirements of different method users. Moreover, the paper also contributes to a knowledge transfer within the IS research community. As we present the IEB concept, so far only documented in German language, we make it accessible to an international audience. Consequently the contribution of this paper is twofold: (1) Knowledge transfer by presenting the IEB concept, which so far has been developed in the German-speaking IS community, only and (2) Method construction by developing and evaluating a situational implementation method for IEB.

The remainder of the paper is structured as follows: In the second section, the methodology used in this paper will be explained. Thereafter, the concept of IEB is outlined and a state-of-the-art analysis regarding the implementation of IEB solutions is conducted. In section 4 the situational implementation method for IEB is developed. First, the situ1 The term ‘implementation’ is used in the sense of putting an IEB solution into practice (rollout) in contrast to referring to a software implementation. ational characteristics are described. Second, method fragments are identified that allow for the composition of a situational method. Furthermore, method configurations addressing the requirements of method users are specified. An evaluation of the method fragments is conducted in section 5. In the final section 0, conclusions are drawn and an outlook is given. 2 2.1

Methodology

Design Science Research for IS

The IS discipline is characterized by two research paradigms: behavioral research and design science research (DSR). Whereas the goal of behavioral research is truth and theories are developed and verified, DSR seeks for utility by developing innovative artifacts. Such artifacts can be in the form of constructs, models, methods or instantiations [16; 25]. For the construction of such artifacts two basic activities can be differentiated: build and evaluate. “Building is the process of constructing an artifact for a specific purpose; evaluation is the process of determining how well the artifact performs” [25, p. 254]. The construction of an artifact is a heuristic search process [ 16 ]. Within this process an extensive use of theoretical contributions stored in the knowledge base should be made [ 16 ]. Hence, we use theoretical contributions e.g. from risk management, value-based management or compliance management to build our artifact, i.e. the situational method.

In order to rigorously demonstrate the utility of the developed artifact, different evaluation methods can be used. Amongst others (e.g. case study or experiment), the “informed argument” is suggested as an appropriate evaluation method [ 16 ]. This descriptive design evaluation method is applied by using information from the knowledge base to build a convincing argument for the artifact’s utility [ 16 ]. It is used in this paper. 2.2

Situational Method Engineering

Methods are considered to be DSR artifacts. They “describe viable ways of performing goal-oriented activities in order to solve a real-world problem” [7, p. 41]. Within the European IS community, the method engineering (ME) community has established that focuses on the construction of methods. More than ten years ago it was already realized within ME that there is no ‘one-size-fits-all’ method for a problem domain and that methods therefore have to be adaptable in order to be applicable to a specific problem situation [ 4 ]. Such adaptable methods have been denoted as “situational methods”.

In ME different construction processes for the development of situational methods have been proposed [see e.g. 4; 19; 34]. For the systematization of these approaches, Bucher et al. [ 6 ] suggest to distinguish between situational method configuration and situational method composition. Situational method configuration includes approaches that focus on the configuration of an entire method according to a given situation [ 6 ]. In contrast, situational method composition includes approaches that aggregate so called method fragments [ 4 ] to situational methods depending on the problem situation at hand [ 6 ].

A method fragment consists of a product (i.e. result) and a process (i.e. activities, techniques) part [ 6 ]. As parts thereof, activities describe the main units of work whereas techniques support activities by giving detailed and precise instructions. Both are conducted in order to create a result [ 14 ]. Each method fragment is characterized by exactly one result being achieved by one or more activities that are supported by one or more techniques.

Before identifying such method fragments it is necessary to characterize problem situations in which the composed situational methods could be used. In ME, situations can be described by their context type and their project type [6; 7]. Context type factors, such as the size of a company, influence the content of the method, but they are not influenced by the use of that method. The project type influences the content of the method as well but in contrast to the context type it is also influenced by the use of the method.

Within situational method composition the identification of method fragments is one of the first steps. In order to increase their re-use, the identified method fragments are stored in a so called method base [4; 33]. Thereafter, it is necessary to derive rules that allow for the composition of these method fragments to situational methods in order to address a problem situation at hand. With the help of such rules method fragments can be put in a temporal and logical order; they are also stored in the method base. In this paper, we focus on method fragments; the definition of rules is subject to other research. Based on the identified situation and a method base, situational methods can be composed. These explanations are visualized by Fig. 1.

Method Base Dimension X

Method Fragment

Method Fragment Dimension Y

Method Fragment

Method Fragment Rules Rule A Rule C

Method Fragment Method Fragment Method Fragment Method Fragment Rule B Rule D

Rule B Rule C

Rule A

Situation (context/project type) Composition of a Situational Method Method Fragment Method Fragment Method Fragment . .

.

Following the described procedure, situational methods can be developed that address a specific problem. However, Mirbel/Ralyté [28, p. 59] criticize that users of a situational method (represented by roles) still have to “apprehend the method as a whole and understand all its concepts in order to use it, which can have some negative impact and discourage” the users from using the situational method. A user/role has to perform specific activities and thus needs his/her own configuration of the situational method [ 28 ]. To address this issue, Mirbel/Ralyté [ 28 ] suggest to combine situational method composition and situational method configuration approaches. Each method construction approach starts with situational method composition based on method fragments. Thereafter, the obtained situational method can be configured for each user by only showing him/her those method fragments referring to his/her role and thus supporting his/her tasks [ 28 ]. This implies that roles and corresponding method configurations have to be identified. 3 3.1

Integrated Enterprise Balancing

The Concept of Integrated Enterprise Balancing

The goal of IEB is to support value-based management, to satisfy regulatory transparency requirements and to satisfy legal reporting obligations [11; 13]. Thus, in contrast to existing value-based or risk management approaches, IEB is an integrated approach that is intended to enable corporations to control their activities through coherent, corporate-wide return and risk measures. For this purpose, an IEB architecture is required that provides consistent data from the areas of risk, return, regulation, and reporting (4R) [ 11 ]. Due to the fact that a 4R concept cannot only be implemented by a software system because its implementation addresses different perspectives of a company, an IEB architecture framework [ 11 ] has already been designed in close relation to existing enterprise architecture frameworks [e.g. cf. 41] (see Fig. 2).

4R Concepts

Value-based

Management

Regulations Risk 4RReturn Reporting 4R Strategy 4R Organizat-ion and Business Processes 4R ICT e ltr u u C R 4

Based on 4R concepts that integrate the different 4R areas, requirements are derived that determine the design of the corporate strategy as well as the design of the organization structure and its business processes. These define further requirements for the design of appropriate information and communication technology (ICT) support. While implementing such a 4R concept, the company culture has to be considered as well and adaptations have to be conducted accordingly. In the course of research on IEB, two extensions of this architecture have been proposed so far. The first extension concerns the dimension of 4R concepts. Faisst/Buhl [11, p. 411] presented a performance measurement system that “enables corporations to additively connect return and risk measures on arbitrary aggregation levels and to perform such an aggregation also within multiple dimensions”. In order to make this system operational, specific requirements have been formulated for the level of organization and business process design in a second extension. In [ 13 ] a formal process modeling language has been described that incorporates the 4R requirements by providing elements and relations for depicting events and risk aggregations in process models.

In the remainder of this paper, a situational implementation method for IEB will be developed, supporting a project with which an IEB solution can be put into company practice in a structured and goal-oriented way. Thereby an IEB solution is understood as any such 4R concept including the resulting organizational changes and IT solutions, i.e. software systems. Thus, an IEB solution is regarded as a socio-technical information system. 3.2

State-of-the-Art Analysis Regarding the Implementation of IEB Solutions

IEB is a new approach to integrate risk and return management, value-based management and compliance management. So far, no (situational) implementation method has been developed that supports an IEB solution to be put into practice. That is why literature of the aforementioned research fields will be framed briefly regarding the ability to provide methodological support, instructions, guidelines, etc. This will ease the identification of IEB method fragments in the next section. Next to references from these fields, references from software engineering have to be analyzed as well. This is due to the fact that the phases and instructions of software development processes which also include a rollout phase can also be transferred to organizational projects [ 15 ].

Within risk management, a lot of literature deals with risk management frameworks which allow for the identification of and response to risks in a company [see e.g. 5; 17; 23; 37]. Well-known frameworks are, e.g. the COSO framework [ 38 ] or the risk management framework of the Software Engineering Institute [ 29 ]. However, only few sources [e.g. 5; 23] address the implementation of such frameworks. These sources provide some valuable instructions, but fail to give structured recommendations. Similarly, a lot of concepts have been developed in the field of value-based management [see e.g. 2; 39] without detailing the implementation of these concepts. However, a few authors [see e.g. 20; 40; 42] also give some advice for the implementation of value-based management concepts. New regulations, e.g. SOX or Basel II, have driven research in the field of compliance management. Focus is put on the identification of appropriate controls [ 32 ], or instructions are given on how to integrate these controls into business processes [18; 35]. Though, only little advice is given for the integrated implementation of such compliance concepts. An exception to this is e.g. the work of Menzies [ 26 ] who gives some instructions. Among software development processes, which consist of different phases, the rollout of the system under consideration is one particular phase [ 15 ]. However, specific advice for the rollout of a system is rarely given, and an integrated approach is missing. Nevertheless, necessary activities for the rollout of software systems are specified e.g. in [15; 30]. Thus, these references will be used to derive IEB method fragments particularly in the context of the rollout of the IEB software system.

The brief literature analysis demonstrated that in each research area (each forming an IEB part) references are available which give at least some recommendations on the implementation of corresponding solutions. They will be used to derive method fragments. 4 4.1

Situational Implementation Method for IEB

Characterization of the Situation

Before identifying appropriate method fragments, the situation in which the fragments can be used has to be specified. Following the explanation in section 2.2, context type and project type have to be differentiated in order to describe such a situation.

We assume that the use of a complex IEB solution depends on the size of a company, i.e. that such a solution will presumably more often be implemented in a large company than in a smaller one. Moreover, we assume that implementing such an IEB solution in a large company will require different support than implementing it in a smaller one. Following this argumentation, we will focus on the context type ‘large companies’.

Based on the existing situation in a company (e.g. mature process management, no ITsupport for IEB-related tasks available, etc.), an IEB solution can be implemented in a company focusing on different aspects. Analyzing the IEB architecture presented in section 3.1, the implementation of a 4R concept can focus on 4R strategic aspects, 4R organizational aspects, 4R technical aspects or a combination of these aspects, thereby mostly covering 4R cultural aspects as well. Due to the fact that IEB is a new approach, it is not possible to identify project types that are relevant for companies. That is why method fragments for all of the above mentioned aspects of an IEB solution will be derived in the following section, allowing companies to compose their own situational method in respect of the focus they choose for their IEB implementation project.

Irrespective of the project type of an IEB implementation project, each implementation has to comprise the following three steps [ 40 ]: (1) Execution of main tasks that have to be accomplished during the implementation, (2) Identification of a project team that organizes and conducts the implementation and (3) Identification of obstacles and development of strategies to overcome them. In the following, we will concentrate on the first step. 4.2

Identification of Method Fragments

Based on the previous argumentation, method fragments that support the implementation of an IEB solution will be derived from literature. This is done for all identified aspects, i.e. strategic, organizational, technical and cultural aspects of an IEB solution, whereas the focus is put on method fragments that support large companies. Each method fragment is listed in a table, presenting the activity and techniques as well as the corresponding result.

Strategic Aspect: Analyzing the body of literature, one method fragment addressing strategic aspects of an IEB implementation could be identified: Within an IEB implementation project it is necessary to assure the support of the top management because employees need to recognize that the top management commits to the IEB solution – otherwise employees might not take the new IEB solution seriously [9; 37; 42]. This can be realized by gaining top management as a project sponsor [ 9 ] and by establishing regular meetings to elicit their requirements [ 37 ]. Consequently, resistance in a company will be reduced and the project execution will possibly be faster. Table 1 characterizes the ‘strategic’ method fragment.

Techniques Result

- Gain top management as project sponsor Reduction of resistance - Establish regular meetings to pick up their and possibly faster

requirements project execution

Organizational Aspects: Organizational aspects of a company implementing an IEB solution are its processes. From risk management literature [e.g. 5] it can be derived that IEB solutions have to be integrated into the planning and budgeting processes. The need for the adaptation of these two processes is also true for value-based management approaches [ 20 ]. In addition, the integration into the reporting processes is specified [ 20 ]. Due to the fact that an IEB solution also affects investor relations of a company, it can be further derived that an IEB solution has to be integrated into the investor relations processes as well. In order to integrate an IEB solution into the processes mentioned above, work instructions [15; 30] and process documentations [ 27 ] need to be created or adapted. Moreover, the integration of an IEB solution into the reporting processes might require the adaptation of report templates. All described activities and techniques result in adapted management processes. Next to these processes that are directly affected by the implementation of an IEB solution, business processes also need to be considered because they serve as a basis for the key figures that are analyzed in an IEB solution. This activity is considered to be relevant from the risk management perspective [9; 23] and the regulatory compliance perspective [ 27 ]. In accordance with the activities mentioned before this activity can be realized by creating or adapting work instructions [ 24 ] and by creating or adapting the documentation of the business processes. They can be documented with the help of the 4R process modeling language developed in [ 13 ]. In contrast to existing process modeling languages the 4R process modeling language incorporates the 4R requirements by providing elements and relations for depicting events and risk aggregations in process models. The adaptation of the business processes results in the availability of the necessary 4R key figures. The adaptation of processes often also requires the adaptation of the organizational structure of a company. From the risk management literature [e.g. 5; 23], the regulatory compliance literature [e.g. 27] and the IS literature [e.g. 30] it can be derived that new organizational units and roles such as a risk manager or a compliance manager have to be created and integrated into the organizational structure in order to successfully implement an IEB solution. This activity can be realized by clarifying and defining necessary tasks. Thereafter, job descriptions need to be developed and staff requirements need to be identified. In addition, new organizational units have to be integrated in the overall organizational structure of the company by defining subordination and superordination. Finally, new staff has to be hired. [27; 30] As a consequence, the company has new employees which are represented by an adapted model of the company’s organization structure. Table 2 characterizes the identified ‘organizational’ method fragments.

Technical Aspects: Irrespective of the software development process model (e.g. waterfall model, iterative processes, extreme programming, etc.) that is applied to the development of the IEB software system – which is an essential part of every IEB solution – the roll-out is always an essential phase. Therefore, it is necessary to prepare the steps that are needed to set the IEB software system into operation [15; 27]. This is done by defining the point or period of time when the IEB software system will be rolled out. In addition, the scope and procedure of the rollout have to be specified as well as a breakdown concept has to be developed. All activities and techniques result in a plan that contains detailed information about the rollout of the IEB software system. [ 15 ] In a next step, it is necessary to integrate the IEB software system into the IS landscape of the company [ 27 ]. This can be realized by analyzing the existing IS landscape and the interfaces between its software systems. Thereafter, the IEB software system is integrated accordingly which results in an integrated IS landscape. Eventually, a final inspection has to be done and the IEB software system has to be handed over [15; 27]. In detail that means to define inspection criteria, to execute the final inspection, to write a final inspection protocol and to transfer all product and rollout documents [ 15 ]. After conducting these techniques, the IEB software system can run in the daily business. Table 3 characterizes the ‘technical’ method fragments. 9 Integrate the IEB - Analyze existing IS landscape and its interfaces Integrated IS software system into - Integrate IEB software system landscape the IS landscape

Do a final inspection - Define final inspection criteria Day-to-day 10 and handover the - Execute final inspection operations of IEB software system - Write a final inspection protocol the IEB soft- Transfer all product and rollout documents ware system

Cultural Aspects: The implementation of an IEB solution comes along with the adaptation of the incentive systems for employees/executives [23; 24; 27]. Such an adaption requires that these systems are analyzed before. Furthermore, it is necessary to communicate the new incentives to increase acceptance of the new solution. Another means to increase acceptance is to conduct road shows [15; 30]. Such staff information events, which have to be carefully planned beforehand, are helpful to inform all employees of the company about the new IEB solution. They contribute to a reduction of resistance. To further reduce resistance, it can be deduced from the regulatory compliance [ 27 ] and the value-based management literature [ 20 ] that it is helpful to develop a communication strategy. Therefore, the relevant content that has to be communicated has to be defined. In a second step communication and reporting paths have to be defined. Finally, adequate means of communication need to be identified. [ 27 ] It is not possible to introduce a new IEB solution into a company without providing training and education for the employees and executives so that they can use the new system in their daily work. That is why the implementation of an IEB solution requires training and education [15; 27; 30]. It is useful to provide a key user training first. Furthermore, it is advisable to provide different kinds of training, e.g. e-learning, attendance courses or documents for self-study, in order to address different learning preferences. Consequently employees/executives will be appropriately educated. [15; 27] From IS literature [e.g. 15], a further activity can be derived: to provide an expert team to answer questions of employees. This activity requires the identification of experts that are familiar with the new IEB solution. Furthermore these experts have to be trained in the skilled handling of people which enables them to adequately react on problems. Table 4 characterizes the identified ‘cultural’ method fragments.

The level of genericity of the 15 method fragments presented in Table 1 through Table 4 has been chosen because more generic method fragments will not support the implementation of an IEB solution reasonably. More granular method fragments, on the other hand, would increase the complexity of the situational method which has already been assessed as high at the present level. The method configurations introduced in the following section could be instrumental to reduce the method’s complexity. 4.3

Method Configurations

In the previous section, method fragments have been proposed as a first step of a situational method composition. In order to meet the requirement of Mirbel/Ralyté [ 28 ] for the additional configuration of a situational method, it is necessary to define roles and corresponding method configurations (see Table 5). Thereby a method configuration only consists of those method fragments which support the tasks of the chosen role.

No. Role

1 Project manager 2 Process owner 3 HR department staff 4 Top manager 5 IT department staff

In general, projects such as the implementation of an IEB solution are conducted with the help of a project team that is headed by a project manager [see above and 40]. He/she coordinates all project related activities and assigns tasks that are necessary in the context of the implementation. That is why a first method configuration is defined for the project manager, including all method fragments of the situational method. Within the project team, each member is responsible for certain activities of the situational method. Moreover, due to the complexity of such projects [ 40 ], the project manager mostly falls back on other employees that support the project team. Thus, the definition of further roles is necessary that take into account their specific tasks.

The role of a process owner can be deduced from the literature [e.g. 5]. A process owner is responsible for the integration of the solution into the relevant management processes [ 5 ]. Furthermore, he/she has to make sure that these adaptations are connected to the underlying business processes [ 5 ]. Following this argumentation, the role of a process owner can be defined. A corresponding method configuration consists of the method fragments two to six, because these fragments address process issues. Depending on the organizational structure of the company, it might be necessary to divide this role into sub-roles according to the processes for which responsibilities have been defined.

Most projects require the hiring of new staff or adaptations on the employees’ incentive systems. For that reason, employees of the human resource (HR) department are called in to support the project team [ 40 ]. The method fragments seven and eleven are assigned to employees of the HR department. The adaptation of incentive systems cannot be done by the HR department alone. Instead, assistance of the top management is necessary [23; 42]. Furthermore the top management is responsible for the communication strategy [ 23 ]. Following this argumentation, the project team is supported by the top management especially by conducting the activities specified in the method fragments eleven and 13.

Finally, the role of an IT employee can be identified [ 30 ]. In coordination with the IT department, the operations of the IEB software system will be prepared. Moreover, IT employees will be responsible for the integration of this system into the company’s IS landscape. Finally, the project team will hand over the IEB software system to the IT department. Consequently, method fragments eight to ten are assigned to IT employees. 5

Evaluation of the Proposed Method Fragments

After finishing the proposed steps of the build phase, the constructed artifact has to be evaluated. This can be realized within different steps. First, the utility of the identified method fragments should be proven. Next, the identified roles of possible method users and the developed method configurations should be evaluated regarding their appropriateness. Finally, the interplay of the different method fragments, i.e. the whole situational method, should be evaluated by using it in an IEB implementation project in a company. In this paper, we will exclusively concentrate on the first step of the evaluation, i.e. the identified method fragments will be evaluated regarding their utility for large companies.

Loosely based on the evaluation procedure described by Pfeiffer/Niehaves [ 31 ], the evaluation object, the aim of the evaluation and the evaluation method have to be specified before conducting the evaluation. The method fragments proposed in the previous section are the objects to be evaluated. The aim of DSR evaluation is to prove the utility of artifacts, i.e. to show that they are purposeful and effective [16; 25]. In respect to the evaluation method, a descriptive approach was chosen. Following Pfeiffer/Niehaves [ 31 ], practice descriptions which are understood as descriptions of successful implementations can be used to evaluate methods/method fragments. This is in accordance with the DSR evaluation method “informed argument” [ 16 ] whereupon information from the knowledge base should be used to build a convincing argument for the artifact’s utility.

The evidence of the successful and effective use of the method fragments will be brought by providing practice descriptions that report about successful implementations. However, it has to be recognized that these descriptions only consider parts of an IEB solution such as risk management, compliance management, etc. This is due to the fact that IEB is a new concept which has hardly been addressed in literature and practice yet. In the following five practice descriptions of large companies are presented by briefly describing their implementation project (value-based management, risk management etc.) and the activities they conducted. We picked five German companies that documented their practice experiences in German as well. However, by briefly presenting their experiences we want to contribute to the knowledge transfer explained in section 1.

The first practice description [A] originates from Daimler AG (formerly DaimlerChrysler group), a large German automotive manufacturer [ 36 ]. It is described how Daimler successfully implemented a value-based management approach. As it is shown in Table 6, Daimler pursued a relatively holistic implementation approach incorporating method fragments with strategic, organizational and cultural aspects, although they did not consider IT aspects [ 36 ]. The second practice description [B] has been provided by the consulting company CTcon GmbH [ 22 ]. CTcon gained a lot of experience in the implementation of value-based management approaches because they conducted several of such projects in large companies [ 22 ]. CTcon primarily focuses on the process aspects of implementation projects. Deloitte (Consulting GmbH), a large consulting company focusing on corporate finance, provides a third practice description [C] [ 8 ]. In contrast to the other practice descriptions, Deloitte sees the integration of the software system into the IS landscape as one of the key success factors [ 8 ]. The fourth practice description [D] is from Deutsche Telekom AG, the largest German telecommunications provider [ 3 ]. They describe how they successfully implemented a corporate compliance system. Although they conducted activities from all different aspects, i.e. strategic, organizational, technical and cultural aspects, they only conducted a very small number of the identified method fragments, thereby completely omitting activities that address process issues [ 3 ]. The last practice description [E] is from Dürr AG, one of the leading suppliers of production systems for the automotive industry [ 10 ]. Eckert et al. [ 10 ] explain how their enterprise risk management system was effectively maintained and enhanced. Their focus is in particular on organizational units and roles.

Table 6 exhibits which of the method fragments proposed have already been successfully used in practice (marked with X). It becomes obvious that no single practice description could be identified which justifies all method fragments. This is due to the fact that most practice descriptions do not follow an integrated approach but rather focus on certain implementation aspects. Besides, method fragments 6 and 8 (see Table 6) could not be justified by any practice description. Nevertheless, as argued in section 4.2 they are regarded as being essential for the implementation of an IEB solution. [A] [B] [C] [D] [E] X X X X X X

X X X X

X

X X X X X X X X X

X X X X 6

Conclusions and Outlook

In this paper, we first introduce the concept of IEB which so far has been developed in the German IS community only to an international audience. In doing so, we contribute to a knowledge transfer within the different IS research communities. Furthermore, we develop and evaluate a situational method for the implementation of an IEB solution which is our main contribution. The proposed situational method is comprised of 15 method fragments. 13 of these fragments have been evaluated in respect of their utility for large companies. For the remaining two method fragments, the body of literature provides evidence that their conduction is essential within an IEB implementation. However, their empirical justification is still subject to further research. In addition, we identified different method configurations which enable the adaptation of the situational method to the requirements of different method users, i.e. project managers, process owners, top managers, and HR or IT staff.

Critically reflecting on our research results, the designed artifact is limited in the sense of the evaluation as we used practice descriptions instead of applying the method to a real IEB implementation project. However, as IEB has hardly been addressed in literature and practice yet, it seems to be valid to conduct such an evaluation as a first step.

Further research is necessary in both the build and the evaluate phase. Next to the proposed method fragments and method configurations, it is necessary to define rules which determine the order in which the activities have to be conducted. Regarding evaluation, further research should address the additional evaluation steps introduced in section 5.

References

1. Ad Hoc News (ed.), http://www.ad-hoc-news.de/Credit-Crisis- Produces-Increased- Demand- forSound--/de/Unternehmensnachrichten/19789384

2. Arnold , G. , Davies , M. (eds.): Value-based Management: Context and Application . Wiley, Chichester et al. ( 2000 )

3. Bamberg , A. , Kaven , A. : Deutsche Telekom: Von einem konzernweiten S-OX404-Projekt zur Compliance Organisation . In: Menzies, C . (ed.) Sarbanes-Oxley und Corporate Compliance: Nachhaltigkeit, Optimierung , Integration. pp. 432 -- 441 . Schäffer-Poeschel, Stuttgart ( 2006 )

4. Brinkkemper , S. : Method engineering: engineering of information systems development methods and tools . Information and Software Technology 38 , pp. 275 -- 280 ( 1996 )

5. Brühwiler , B. : Risk-Management als Führungsaufgabe . Haupt, Bern et al. ( 2003 )

6. Bucher , T. et al.: Situational Method Engineering - On the Differentiation of "Context" and "Project Type" . In: Ralyté, J. et al. (eds.) IFIP WG8.1 Working Conference on Situational Method Engineering (ME07) , pp. 33 -- 48 . Geneva ( 2007 )

7. Bucher , T. , Winter , R.: Dissemination and Importance of the "Method" Artifact in the Context of Design Research for Information Systems . In: Vaishnavi, V.K. , Baskerville , R . (eds.) Proceedings of the Third International Conference on Design Science Research in Information Systems and Technology (DESRIST 2008 ), pp. 39 -- 59 . Atlanta ( 2008 )

8. Deloitte, http://www.lz-net.de/studien/pdf/85.pdf

9. Drew , C. : Implementing an integrated system for risk management, planning, performance . Accountancy Ireland 38 , pp. 18 -- 20 ( 2006 )

10. Eckert , S. , Lamparter , G. , Möller , K. : Konzept und Umsetzung eines Risikomanagementsystems bei der DÜRR AG . Zeitschrift für Controlling und Management 48 , pp. 26 -- 36 ( 2004 )

11. Faisst , U. , Buhl , H.U.: Integrated Enterprise Balancing mit integrierten Ertrags- und Risikodatenbanken . Wirtschaftsinformatik 47 , pp. 403 -- 412 ( 2005 )

12. Fiedler , F.E. : A Contingency Model of Leadership Effectiveness . Advances in Experimental Social Psychology 1 , pp. 149 -- 190 ( 1964 )

13. Fill , H.-G. et al.: Modellierung für Integrated Enterprise Balancing . Wirtschaftsinformatik 49 , pp. 419 -- 429 ( 2007 )

14. Gutzwiller , T.A. : Das CC-RIM Referenzmodell für den Entwurf von betrieblichen, transaktionsorientierten Informationssystemen . Physica, Heidelberg ( 1994 )

15. Haux , R. et al.: Management von Informationssystemen . Teubner, Stuttgart ( 1998 )

16. Hevner , A.R. et al.: Design Science in Information Systems Research. MIS Quarterly 28 , pp. 75 -- 105 ( 2004 )

17. Jallow , A.K. et al.: Operational risk analysis in business processes . BT Technology Journal 25 , pp. 168 -- 177 ( 2007 )

18. Karagiannis , D. , Mylopoulos , J. , Schwab , M. : Business Process-Based Regulation Compliance: The Case of the Sarbanes-Oxley Act . In: 15th IEEE International Requirements Engineering Conference (RE '07) , pp. 315 -- 321 . Delhi ( 2007 )

19. Karlsson , F. , Ågerfalk , P.J.: Method configuration: adapting to situational characteristics while creating reusable assets . Information and Software Technology 46 , pp. 619 -- 633 ( 2004 )

20. Knight , J.A. : Value-based management: developing a systematic approach to creating shareholder value . McGraw-Hill , New York ( 1997 )

21. Krantz , M. , http://www.cfo.com/article.cfm/11917608/1/c_2984351?f=related

22. Kückelhaus , M. , Wohlthat , A. : Praxisstatement. In: Weber, J. et al. (eds.) Wertorientierte Unternehmenssteuerung: Konzepte - Implementierung - Praxisstatements. pp. 350 -- 358 . Gabler, Wiesbaden ( 2004 )

23. Lam , J.: Enterprise Risk Management: From Incentives to Controls . Wiley, Hoboken ( 2003 )

24. Lang-Koetz , C. : Ein Vorgehensmodell zur Einführung eines integrativen Umweltcontrollings auf Basis eines ERP-Systems . PhD thesis , University of Stuttgart, Stuttgart ( 2006 )

25. March , S.T., Smith , G.F. : Design and Natural Science Research on Information Technology. Decision Support Systems 15 , pp. 251 -- 266 ( 1995 )

26. Menzies , C. (ed.) Sarbanes-Oxley und Corporate Compliance: Nachhaltigkeit, Optimierung, Integration . Schäffer-Poeschel, Stuttgart ( 2006 )

27. Menzies , C. et al.: Das GRC-Stufenmodell - Nachhaltigkeit , Optimierung und Integration von Governance, Risikomanagement und Compliance . In: Menzies, C . (ed.) Sarbanes-Oxley und Corporate Compliance: Nachhaltigkeit, Optimierung , Integration. pp. 63 -- 424 . SchäfferPoeschel, Stuttgart ( 2006 )

28. Mirbel , I. , Ralyté , J.: Situational method engineering: combining assembly-based and roadmapdriven approaches . Requirements Engineering 11 , pp. 58 -- 78 ( 2006 )

29. Murphy , R.L. et al.: Continuous Risk Management Guidebook . Software Engineering Institute , Carnegie Mellon University, Pittsburgh ( 1996 )

30. Parisini , E. , Wächter , O. : Organisations-Handbuch für die Einführung von ADV-Systemen: Systemplanung, Systemanalyse , Systemeinführung. de Gruyter, Berlin ( 1971 )

31. Pfeiffer , D. , Niehaves , B. : Evaluation of conceptual models - a structuralist approach . In: Bartmann, D. et al. (eds.) 13th European Conference on Information Systems, Information Systems in a Rapidly Changing Economy (ECIS 2005 ). Regensburg ( 2005 )

32. Proctor , P.E. : Select and Implement Appropriate Controls for Regulatory Compliance . Gartner Research , ( 2005 )

33. Ralyté , J.: Reusing Scenario Based Approaches in Requirement Engineering Methods: CREWS Method Base . In: Proceedings of the 10th International Workshop on Database and Expert Systems Applications (DEXA'99) , 1st International Workshop on the Requirements Engineering Process (REP'99) , pp. 305 -- 309 . Florence ( 1999 )

34. Ralyté , J. , Rolland , C. : An Approach for Method Reengineering . In: Hideko, S.K. et al. (eds.) Proceedings of the 20th International Conference on Conceptual Modeling (ER 2001 ), pp. 471 -- 484 . Yokohama ( 2001 )

35. Rausch , T. : Holistic business process and compliance management . In: Pour, J. , Vorisek , J . (eds.) 14th International Conference Systems Integration (SI 2006 ), pp. 301 -- 311 . Prague ( 2006 )

36. Riegler , T. : Wertorientierte Unternehmensführung - Umsetzungserfahrung im DaimlerChrysler Konzern . Kostenrechnungspraxis 45 , pp. 89 -- 94 ( 2001 )

37. Senior Supervisors Group: Observations on Risk Management Practices during the Recent Market Turbulences . Technical Report , ( 2008 )

38. Steinberg , R.M. et al., http://www.coso.org/documents/COSO_ERM_ExecutiveSummary.pdf

39. Velthuis , L.J. , Wesner , P. : Value Based Management: Bewertung, Performancemessung und Managemententlohnung mit ERIC® . Schäffer-Poeschel, Stuttgart ( 2005 )

40. Weber , J. et al.: Wertorientierte Unternehmenssteuerung: Konzepte - Implementierung - Praxisstatements . Gabler, Wiesbaden ( 2004 )

41. Winter , R. , Fischer , R. : Essential Layers, Artifacts, and Dependencies of Enterprise Architecture . In: Society, I.C . (ed.) EDOC Workshop on Trends in Enterprise Architecture Research (TEAR 2006) within The Tenth IEEE International EDOC Conference (EDOC 2006 ). Hong Kong ( 2006 )

42. Young , D.S. , O 'Byrne , S.F. : EVA and value-based management: a practical guide to implementation . McGraw-Hill , New York ( 2001 )