Accounting change in the banking world

Accounting change in the

banking world

Accounting change model applied to Rabobank Nederland

Author: Mr. A. Suichies, BSc

Supervisors: Mrs. Dr. J.S. Hendriks-Gusc University of Groningen Mr. Drs. P.F.H.M. Roemaat Rabobank Nederland

Mr. Ir. K. Dortland Rabobank Nederland

Date: July 29, 2010

University of Groningen

Faculty of Economics and Businesses Department of Accounting

Groningen

Abstract

Challenged by the difficulties in successfully implementing accounting change and the fact that very few attempts to collect the different barriers and drivers to accounting change into one framework exist, this research focuses on theoretical frameworks on factors which (may) positively or negatively influence management accounting change.

Case study research was chosen to apply and check the suitability of the accounting change model of Kasurinen (2002) in a different context and possibly further develop the model. The case study was conducted at Rabobank Nederland, to analyse the implementation of a new management reporting and information system, titled ManRap. Seventeen interviews have been conducted with members of the steering committee, project team and Functional Support as well as representatives of the user organisation (i.e. super users). This selection included people that have taken the decisions, people that have been in charge of the change process and people that have been affected by the change. Results of the interviews have been verified with official internal project evaluation documents to ensure the reliability and validity of the results.

Extensive evidence was found for all influencing forces, mentioned in the accounting change model of Kasurinen. On the basis of the empirical case study, the accounting change model was revised to illustrate the dynamics and continuous character of accounting change. This revised accounting change model helps those responsible for accounting change management by recognising the presence of multiple stimulating and hindering factors in the implementation process of accounting changes and by showing the ability to intervene in case of barriers at all stages of the project. In the end this should contribute towards the understanding and success rate of accounting changes.

Preface

The master thesis is considered the final test before graduating in a master of science. With this final piece of work, I complete my study Master of Science in Business Administration (MBA) specialised in Organizational & Management Control (OMC) at the faculty of Economics and Business at the University of Groningen. The topic of this thesis is accounting change in the banking world. The focus will be on applying the accounting change model of Kasurinen to the implementation of a management information and reporting system (ManRap) within Rabobank Nederland. Evidently, this paper discusses and examines the influencing forces of management accounting change.

I have written this master thesis during an internship at the directorate Control Rabobank Group of Rabobank Nederland from January to July 2010. The opportunity to work within the organisation of Rabobank Nederland has been a valuable experience and provided me with, besides an interesting topic to study, a pleasant and stimulating environment to write this thesis. I would hereby like to thank Rabobank Nederland for giving me the opportunity to combine my graduation with an internship.

Moreover, I wish to pay special thanks to Mr. Drs. P.F.H.M. Roemaat and Mr. Ir. K. Dortland, my supervisors at Rabobank Nederland, for supporting and providing me with useful information and criticism during the progress of my research and stimulating me to keep an eye on the practical aspects of my assignment. Also I would like to dedicate a word of thanks to Mrs. Drs. J.S. Hendriks-Gusc of the University of Groningen. Our pleasant collaboration and fruitful discussions always gave the research some directions or ideas which I had not immediately thought about and useful comments on the areas of the thesis which needed some extra attention.

Useful comments on earlier drafts of the questionnaires for the interviews and survey were given by my company supervisors, Mr. Drs. P.F.H.M. Roemaat and Mr. Ir. K. Dortland, as well as by the actual respondents and interviewees, Mrs. P.J. Kortleve, Mr. F.H.J. van Vliet and Mr. M.W.H. van den Munckhof, for which I am grateful.

I would also like to dedicate a word of gratitude to the interviewees (in the order in which the interviews have taken place): Mrs. P.J. Kortleve, Mr. M. Swart, Mr. H.T. Frissen, Mr. H.W.J. Jawalapersad, Mr. J.W.M. van Rooijen, Mr. J.W. Scholtens, Mr. I. Heine, Mr. F.H.J. van Vliet, Mr. J.H. van Cranenbroek, Mr. H.T.J. Jansen, Mr. H.P.J. Vergoossen, Mr. M.W.H. van den Munckhof, Mrs. A. Creemers-Guichelaar, Mr. J. van Woudenberg, Mr. E.H.B. Bosch, Mr. P.F.H.M. Roemaat and Mr. K. Dortland. In addition, I would also like to thank all the survey respondents for participation in the research. Only by the given interviews and survey responses, I was able to provide the research with a more practical impact, through which actual conclusions could be reached. In addition, I would like to thank all my colleagues at Rabobank Nederland for the great time I had there. Finally, I would like to thank my parents for the absolute support and trust during my studies and my brother for sharing his academic experience in reviewing this master thesis.

With finishing this thesis my years as a student have come to an end. Now I am looking forward to make a new step in life with the start of my professional career and benefiting from all the lessons learned during my studies in both Groningen and Zwolle.

Table of contents

List of figures and tables

7

List of abbreviations

8

List of definitions

9

1.

Introduction to research

10

1.2.4. Case Rabobank Nederland 12

1.3 Outline thesis 13

2.

ManRap

14

2.3.2. SAP Business Warehouse 18

2.3.3. Possibilities and functions 19

2.3.4. User groups 19 2.3.5. System management 20 2.3.6. Consultation structures 20 2.3.7. System support 21

3.

Literature review

22

3.2.1. Formal versus informal change 25

3.2.2. Revolutionary versus evolutionary change 25 3.2.3. Systematic versus unsystematic change 26 3.2.4. Intended versus unintended change 26

3.3 Accounting change model 27

3.3.1. Innes and Mitchell (1990) 27

3.3.2. Cobb et al. (1995) 28

3.3.3. Kasurinen (2002) 29

3.3.4. Discussion 30

3.4 Information systems 31

3.4.1. Management information 31

3.4.2. Management information system 31 3.4.3. Management accounting (system) 33

3.4.4. Management control (system) 33

3.5 Discussion models 34

4.

Research methodology

36

4.3.2. Desk research / Record analysis 38

4.3.3. Survey 38

4.3.4. Interviews 39

4.3.5. Direct observation 42

5.

Results

43

5.1 Institutional theory 43

5.1.1. Formal versus informal change 43

5.1.2. Revolutionary versus evolutionary change 44 5.1.3. Systematic versus unsystematic change 44 5.1.4. Intended versus unintended change 45

5.2 Accounting change model 46

5.2.1. Motivators 46 5.2.2. Facilitators 47 5.2.3. Catalysts 50 5.2.4. Leaders 51 5.2.5. Momentum 52 5.2.6. Confusers 52 5.2.7. Frustrators 53 5.2.8. Delayers 55 5.2.9. Post implementation 56 5.2.10. Future ManRap 58 5.3 Survey results 59 5.3.1. Response 60 5.3.2. Use ManRap 61 5.3.3. Satisfaction ManRap 62

6.

Discussion and Conclusions

68

6.1 Accounting change 68

6.1.1. Institutional theory 68

6.1.2. Accounting change 69

6.1.3. Accounting change model 70

6.1.4. Objective accomplishment 74

6.1.5. System use outside ManRap 75

6.1.6. Desirability of integration systems in ManRap 75

6.2 Limitations 77

6.2.1. Case study 77

6.2.2. Period of time 78

6.2.3. Focus 78

6.2.4. Implementation period 78

6.2.5. Length questionnaire survey 78

6.2.6. Incomplete target population 78

6.3 Scientific relevance 79

6.4 Further research 80

Reference list

81

Appendix

85

Appendix I: Organisational chart Rabobank Group 85

Appendix II: Development financial administration Rabobank Nederland 86

Appendix III: Prince2 process model 89

Appendix IV: Survey 90

List of figures and tables

Figures

Figure 2.1: Project milestones 18

Figure 2.2: SAP BW architecture 19

Figure 3.1: Accounting change model 28

Figure 3.2: Revised accounting change model 29

Figure 3.3: Relationship systems 34

Figure 4.1: Directorates Rabobank Nederland 37

Figure 5.1: Project milestones (actual) 55

Figure 5.2: Summary influencing forces ManRap project 56

Figure 5.3: Frequency comparison response target population and survey population 60

Figure 5.4: Relationship use ManRap and total need management information 61

Figure 5.5: Satisfaction tooling ManRap 63

Figure 5.6: Satisfaction data ManRap 63

Figure 5.7: Grading ManRap and Functional Support ManRap 64

Figure 5.8: Frequency comparison target population and survey population other use than ManRap 65

Figure 5.9: Subject categories other reports 66

Figure 5.10: Comparison characteristics ManRap reports and other reports 66

Figure 6.1: Continuous accounting change model 73

Figure II.1: Chronological overview systems and projects 86

Tables

Table 4.1: Respondents characteristics 41

Table 5.1: Population characterised by directorate 60

Table 5.2: Survey population characterised by category 61

Table 5.3: Top 5 advantages, disadvantages and reasons for use sources 67

List of abbreviations

ABC Activity-Based Costing

ASAP Accelerated Systems Application and Products in Data Processing

BI Business Intelligence

BSc Balanced Scorecard

CPOA Centrale Project & Order Administratie

CRG Control Rabobank Group

FA Financial Accounting

FA4U Financial Administration For You F&C Finance & Control

FTE Full Time Equivalent

GICT Group ICT

HOV HerOntwerp Verantwoord

KPB KostPrijs Berekeningstool

LSA Layered Structure Architecture

Maestro Maximum Effective Steering on Results and Output ManRap Management Reporting (Project)

MAS Management Accounting System

MCS Management Control System

MIS Management Information System

PIM Program and Information Management

PIOB Program Information and Support (Ondersteuning Bureau)

PoC Proof of Concept

Prince2 Projects in Controlled Environments II RECAP Regulatory and Economic Capital System

RfC Request for Change

RG Rabobank Group

RI Rabobank International

RN Rabobank Nederland

SAMBA Samen Beter Administreren

SAP BW Business Warehouse of SAP SAP GUI Graphical User Interface of SAP

SAP R/3 Enterprise Resource Planning (ERP) system of SAP SAP SRM Supplier Relationship Management system of SAP

SAS Statistical Analysis System

SIOB Service Informatie en Ondersteuning Bureau SF&C Support Finance & Control

SME Small and Medium-sized Enterprises SS&F Shared Services and Facilities

List of definitions

ASAP Project management and system application methodology BEx Analyzer SAP BW Excel add-on function

C_SAR Former financial administration system of Rabobank Nederland Clarity System for time registration, planning and capacity management Cognos System for time registration and project reporting (e.g. SS&F, GICT) Essbase System for time registration and project reporting (e.g. Private Clients,

Communication)

FA4U Financial SAP system of Rabobank Nederland KBP Cost calculation tool of Rabobank Nederland

ManRap Management reporting system of Rabobank Nederland Maestro Management reporting system of local banks

Obvion Subsidiary of Rabobank Group on mortgage lending Orbay Subsidiary of Rabobank Group on asset management Prince2 Project management methodology

Prisma Performance Indicator System for the Management (e.g. Private Clients) RaboShop (old) External contracts and personnel information system (HRM system) RaboShop (new)1

SAP SRM; external contracts information system

SAP Centre Former title of Functional Applicative and Functional Technical Support of SAP systems

Sapiens (old) Internal personnel information and salary system, also known as SAP HR BW Sapiens (new)2

Internal and external personnel information and salary system, also known as SAP HR BW

1.

Introduction to research

In the search to understand real world management accounting, change has become an increasingly popular focus for research. As Burns and Scapens (2000, p. 3) point out: ‘management accounting change has become a topic of much debate in recent years. Whether management accounting has not changed, has changed, or should change, have all been discussed.’ Currently, quite extensive and growing literature exists on the drivers of accounting change, change processes, resistance, and the consequences of

change (Lukka, 2007, p. 79). A considerable amount of management accounting change research focused on the drivers and correlates of change (Anderson, 1995; Libby and Waterhouse, 1996), on the ‘conditions of possibility’ for change (Bhimani, 1993; Miller and O’Leary, 1987), on the organisational tensions, conflicts, and resistance toward change endeavours, or failures of change (e.g. barriers to change) (Roberts, 1990; Scapens and Roberts, 1993), or on the influence of institutionalised elements on accounting change (Abernethy and Chua, 1996; Burns and Scapens, 2000).

Another group of researchers have offered general models of accounting change by examining the circumstances and forces which drive the implementation of change (Innes and Mitchell, 1990), whereas others studied the barriers and resistance to change. Cobb et al. (1995)and Kasurinen (2002)attempted to explain management accounting change by incorporating both dynamics into a framework. The primary aim of these frameworks is to examine the factors which have influenced management accounting change and to provide an analysis of how these factors combine and interact. They have shown that different factors relating to the individual, organisation, technology, task and external environment are influential at different stages of an accounting change.

A deeper understanding of the change context could help organisations in their attempts to circumvent the barriers in practice (Kasurinen, 2002, p. 323). Barriers or resistance to change have namely been identified as a considerable hindrance to the implementation of ‘new’ management accounting techniques(Scapens and Roberts, 1993). On the contrary, Innes and Mitchell (1990, p. 16) indicate that the origination of change in management accounting practice is associated with a specific set of circumstances, defined as forces or drivers of change.

To apply, and possibly further develop, the framework of Kasurinen (2002) in a different case, this study will use the accounting change model and its factors to analyse an accounting change within Rabobank Nederland, namely the implementation of a management information and reporting tool, known as ManRap.

1.1

Problem statement

By focusing on a single case study, this thesis presents a contribution to the understanding which elements influence accounting change, and in what way. Furthermore, this study provides empirical evidence how an accounting change occurred in practice. The purpose of the latter empirical research is twofold. First, it is used to apply, and possibly further develop, the accounting change model in a different case. Secondly, it aims to evaluate the change process and examine which further steps are needed within the case organisation. This section will comprise the research objective of this study and the research and sub questions to achieve this objective.

1.1.1 Research objective

The practical research objective of this study entails an evaluation of the change project ManRap within Rabobank Nederland, in order to determine whether a next step in the project (i.e. integration of more systems into ManRap) is desirable.

Introduction to research

1.1 Problem statement

1.2 Research domain

The accounting change model of Kasurinen (2002)will be used for achieving this objective. Kasurinen’s study belongs to the stream of factor studies, which aims to explain what organisational and contextual factors contribute to and hamper the effective implementation of management accounting techniques. The model is used to provide a descriptive and structured analysis of the process by which practical management accounting change has occurred at the level of the firm within a real world setting.

The model helps to identify barriers which possibly could be circumvented in future steps in the ManRap-project, for example integration of other systems into ManRap. The application of the model to the situation within Rabobank Nederland is thus useful in contributing to the decision whether it is desirable to integrate other decentralised systems into ManRap. Additionally if it is desirable, how the change process is better constructed by taking the positive and negative factors into consideration.

The focus of this case study significantly differs from the research objects of Kasurinen (2002) (i.e. implementation Balanced Scorecard (BSc)) and his predecessors Cobb et al. (1995) (i.e. implementation Activity-Based Costing (ABC)). The theoretical research objective is to apply, and possibly further develop, the framework of Kasurinen in a different accounting change. By exposing the model to other types of change projects, it can be tested whether the model is applicable to different accounting changes.

1.1.2 Research questions

The aforementioned research objective is translated into multiple research questions.

1) To what extent can the integration of the decentralised management information systems into ManRap be defined as an accounting change process?

2) To what extent did the forces of change, mentioned in the accounting change model of Kasurinen (2002), influence the change?

3) To what extent is integrating the remaining management information systems into ManRap desirable? 1.1.3 Sub questions

In order to answer the research questions mentioned above, a number of sub questions have been formulated.

1) What is ManRap and to what extent can ManRap be defined and classified as management accounting change?

2) To what extent have the objectives of the first two phases of the ManRap project been achieved? 3) To what extent did the change factors (Kasurinen, 2002), influence the accounting change within

Rabobank Nederland and what were the consequences of these influences?

4) Which management information systems, within the directorates of Rabobank Nederland, are currently not integrated into ManRap?

5) To what extent is integrating these management information systems into ManRap desirable, based on the outcomes of the previous sub questions?

1.2

Research domain

This section gives an overview of the case organisation, Rabobank Nederland, which includes its history, organisational structure and place as well as the case project.

1.2.1 History Rabobank

In 1980 the bank decided to formally adopt the name that it had been using informally for some time - Rabobank Nederland – a combination of the first letters of the two original cooperative banks that sealed the fusion of their identities. Today Rabobank is owned by 147 local banks, all working together to provide financial services and products to the Dutch retail and business markets (Rabobank Group, 2010, History).

1.2.2 Rabobank Group

Rabobank Group (RG) is an international financial services provider operating on the basis of cooperative principles. It offers retail banking, wholesale banking, asset management, leasing and real estate services. Focus is on all-finance services in the Netherlands and on food & agriculture internationally. Rabobank Group is comprised of 147 independent local Rabobanks in the Netherlands plus Rabobank Nederland, their umbrella organisation, and a number of subsidiaries. The group entities maintain strong mutual ties. Overall, Rabobank Group has upwards of 59,000 employees (in FTEs), who serve about 9.5 million clients in 48 countries (Rabobank Group, 2009, p. 96).

The 147 local Rabobanks are Rabobank Group’s cooperative core business. Together, they employ approximately 28,000 FTEs. Committed, nearby and leading in their service offering, they serve about 6.7 million retail clients and about 0.8 million corporate clients in the Netherlands, offering a comprehensive range of financial services. With 1,010 branches, which operate 3,063 cash-dispensing machines, Rabobank forms the densest banking network in the Netherlands (Rabobank Group, 2009, p. 96).

Rooted in the bank’s cooperative structure, clients can become members of their local Rabobank. The local Rabobanks, for their part, are members and shareholders of Rabobank Nederland, the umbrella cooperative (Rabobank Group, 2009, p. 96).

In terms of Tier I capital, Rabobank Group is among the world’s 25 largest financial institutions (22nd position, 2009). Rabobank Group has the highest credit rating (triple A), awarded by well-known international rating agencies such as Standard & Poor’s, Moody’s Investor Service and Dominion Bond Rating Service (Rabobank Group, 2009, p. 96).

1.2.3 Rabobank Nederland

The local Rabobanks and their clients form Rabobank Group's core cooperative business. The banks are members and shareholders of the supralocal cooperative organisation, Rabobank Nederland (RN), which advises the banks and supports their local services on matters of strategy and policy, marketing and product development, and information technology. Rabobank Nederland also supervises, on behalf of the Dutch central bank, the solvency, liquidity and administrative organisation of the local Rabobanks. Rabobank Nederland further acts as an (international) wholesale bank and as a bankers' bank to the Group and is the holding company of a large number of specialised subsidiaries. Rabobank Nederland has an employee base of about 6,200 full time equivalents (FTE) and their head office is located in Utrecht (Rabobank Group, 2010, Organisation). See Appendix I for an organisational chart of Rabobank Group, including Rabobank Nederland (Rabobank Group, 2009, p. 97).

1.2.4 Case Rabobank Nederland

The main objectives of ManRap consist of supplying management information for the business, in an efficient and effective way, and to reduce the control problems related to the presence of multiple MIS-systems and tools. This is primarily done by the integration of several information MIS-systems, operating on a decentralised level, into the central platform of ManRap (Swart, 2005, p. 3).

In this study, the conceptions of (management) accounting change are engaged to the practical issue mentioned above. More specifically, the accounting change model of Kasurinen (2002)will be used in an attempt to identify the factors and implementation approaches within Rabobank Nederland to see how they influenced the change and its success or failure.

1.3

Outline thesis

2.

ManRap

This chapter discusses the change process within Rabobank Nederland, more specifically the implementation of a new central management information system, called ManRap. The implementation process of ManRap consisted primarily of the integration of decentralised management information systems into ManRap. This new system and its implementation affected various departments and employees in their job activities.

2.1

Background

In the past, the majority of the Rabobank Nederland (RN) departments designed their own management information system (MIS) in order to fulfil their need in financial management and control information. This also included hours- and FTE related reports and information. Consequently, there was a large diversity of MIS tools within RN. Some control departments had purchased specific modules (e.g. Cognos and Essbase; both systems for time registration and project reporting), requested ICT to develop a system (e.g. Prisma; Performance Indicator System for the Management) or developed their own Microsoft Excel or Access applications (Swart, 2005, p. 3).

There was no standard regarding the composure and structure of end reports. As a result, some departments composed their monthly reports fully computerised, while controllers from other departments used one or more basic systems (e.g. RaboShop, Clarity, etc.) to select and edit the information for their reports. These different methods and structures caused difficulties in the consolidation of all individual reports for RN (Swart, 2005, p. 3).

Furthermore, the data was too widely spread within the organisation and it was therefore at times difficult to gather all the necessary data. The multiple sources of the same data and the manual alteration created inaccurate and inconsistent data, which led to differences in outcomes for similar reports. As a result, managers could not be sure about the correctness of the data, which resulted in control problems. In order to solve these problems, CRG initiated in 2005, after a successful pilot, the ManRap project which led to the implementation of a central MIS, also named ManRap (Management Reporting) (Swart, 2005, p. 3).

ManRap is integrated into SAP Business Warehouse (SAP BW) and functions as the central and integral platform for management information. ManRap provides a number of central management reports for the department controllers, line- and project managers of RN, RI and the affiliated institutions Obvion and Orbay. Furthermore, ManRap offers the possibility for users to compose their own reports (derived from the standard reports) and perform analyses with the SAP Business Intelligence (BI) tools (filter, down, drill-through, etc.) (Swart, 2005, p. 3).

CRG strives with the implementation of ManRap to:

• supply management information for the business, in an efficient and effective way; • reduce the control problems related to the presence of multiple MIS-systems and tools; • offer possibilities and to create conditions in order to harmonise the MIS tooling;

• reduce the number of direct extractions and reports from the operational and financial systems (e.g. Clarity, Sapiens, etc.) in order to enhance performance (Swart, 2005, p. 3).

Despite the presence of a central platform where management reports can be composed and a central team where new requirements of the users can be requested, users still remain to compose their own reports without using the facilities of ManRap. The procedure standard states that management information system’ users need to present new requirements, regarding their management reports, to the ManRap team. Next, the ManRap team will analyse the (technical and financial) feasibility of the request and if possible carry out the request.

ManRap

2.1 Background

2.2 ManRap project

However in reality, some users present their request to a different department or start to alter the reports themselves, which makes it difficult for the ManRap team to oversee the use of the data as well as to control the quality of the data. In addition, on a decentralised level a number of information systems still exist outside ManRap. An analysis on the desirability of integrating these systems into ManRap is required. In order to understand the role and function of ManRap within the overall development and complete system of financial administration within Rabobank Nederland, Appendix II gives an overview of the developments of accounting within RN during the last ten years. The appendix includes definitions of the relevant systems, which will be mentioned from this point on forward.

In this chapter a distinction is made between ManRap as project and ManRap as system. The following section will start with a description of the ManRap project, after which the ManRap system will be discussed.

2.2

ManRap project

The ManRap project was carried out according to specific methodologies, namely Prince2 and ASAP (Franse and Bui, 2007). The complete implementation process can be divided into two subprojects, namely the proof of concept and the actual ManRap project. Both methodologies and projects will be discussed in this section. 2.2.1 Prince2 methodology

Within the Rabobank organisation a standard method is used for project management, called Prince2 (Projects in Controlled Environments II). This method is a combination of best practices in project management of various companies and is used to direct and control projects in such a way that projects are carried out more effectively and efficiently. Prince2 consists of eight processes and eight components and applies a number of important principles:

• focus on the business case;

• a steering model with a steering committee which monitors three interests (affordability, feasibility and usability);

• management by exception; • product oriented planning;

• standard ‘no go’ for each phase and; • phasing is based on management ‘drivers’.

Managing a project according to Prince2 consists of at least three phases, namely: project initiation (defining objectives and agreements, committed in a project initiation document (PID)), project implementation (realising project result within the agreements) and project end report (discharge and transfer of project result to the business). Appendix III shows the complete Prince2 process model, including all the processes, components and their interdependencies (Raboweb RN, ‘Methods and Processes’, July 27, 2010).

2.2.2 ASAP methodology

In addition to Prince2, the ASAP methodology is used for both project management and system application. ASAP, developed by SAP, is an abbreviation for Accelerated Systems Application and Products in Data Processing and is used to ensure the successful, on-time delivery of a project. The ASAP methodology adheres to a specific road map that addresses the following five general phases:

1. Project preparation: identifying team members, defining project standards, and setting up project work environment;

2. Blueprint: defining business processes, and designing business blueprint document;

3. Realisation: configuring system, transferring knowledge, completing extensive unit testing, and defining data mappings and data requirements for migration;

post-ASAP incorporates standard design templates and accelerators covering every functional area within the system, as well as supporting all implementation processes. Milestones are set for every work path, and progress is carefully tracked by the project management team (Raboweb RN, ‘Methods and Processes’, July 27, 2010).

2.2.3 Proof of Concept

At the beginning of 2005, the head of CRG gave permission to start with the implementation of a Proof of Concept (PoC) for the use of SAP BW within the C_SAR system environment (financial control information; e.g. cost centres, business processes and -projects). The starting point for this PoC was the need for a global analysis of the possibilities of a MIS within RN. It also consisted of an assessment of the benefits and deficiencies of the SAP reports. The BW PoC project team consisted of employees of Support Finance & Control (SF&C) and the SAP Centre3

, complemented with external consultants and experts on MISs. Management team of Group Administration CRG was the target group for the PoC (Swart, 2005, pp. 2-3). Planning of the PoC project consisted of several phases and started with a preliminary analysis. This analysis included meetings with representatives of the SAP Centre and current systems, choice of reports, plan of action and a project design. Next, the reports and corresponding technical necessities were build, after finally the PoC was demonstrated and the end report was written (Control Rabobank Group, 2005a, p. 8).

Two teams were implemented, namely a steering committee and a project team. Project control consisted of two consultation structures, namely a biweekly project meeting in which bottlenecks and progress were discussed by the project team and a monthly steering committee meeting (Control Rabobank Group, 2005a, p. 11).

Objectives

The main objective of the PoC was to determine whether the following objectives could be achieved: • disclosure of FI/CO/MM/PS4

data and hour information within Rabobank Nederland; • present a standardised and uniform reporting area for users of SAP/R3 C_SAR; • unburden the use of SAP/R3 in order to improve the system performance. • cross-entity information could be made available in a consistent manner;

• the most common SAP standard- and custom report could be made available in BW; • SAP BW can effectively provide in the reporting and analysing needs of the RN entities.

Finally, it was important to get an understanding of the necessary development- and control efforts of SAP BW, whether the employees of SF&C could achieve the necessary knowledge and skill levels, and that a basis could be placed for future development (Swart, 2005, pp. 2-3).

Results

The results of the PoC indicated that nearly all objectives could be achieved and that SAP BW was a suitable MIS-tool for Rabobank Nederland for the replacement of existing MISs (e.g. Essbase and Cognos). The project group advice was to implement SAP BW as an integral MIS-tool for RN and the project was given the name ManRap (Swart, 2005, pp. 5-8).

2.2.4 ManRap project

After the positive PoC, the ManRap project organisation was started, including representatives of the RN entities. First, a plan of action was written as well as appointing staff to the project. Next, the information- and reporting needs were analysed, which resulted into a blueprint. Simultaneously, certain technical measures were developed and finally the deployment and aftercare took place (Control Rabobank Group, 2005b, p. 8).

3 _{SAP Centre is an old term for Functional Applicative Support and Technical Applicative Support}

The actual ManRap project was started in mid 2005 and the ManRap team had nearly the same occupation as the BW PoC team with employees of SF&C, SAP Centre and external consultants (Control Rabobank Group, 2005b, p. 10).

Project control consisted of three consultation structures, namely a biweekly project meeting in which bottlenecks and progress were discussed by the project team, a monthly steering committee meeting and a monthly user platform with directorate controllers and a delegation of CRG employees (Control Rabobank Group, 2005b, p. 11).

The end products of the project included the following items: • configured BW (including reports and queries);

• complete input/output model (including establishment of authorisations); • subset of standard and custom reports;

• subset of standard cost reports;

• training of super-users and end users in the control area (Control Rabobank Group, 2005b, p. 13). Since 2005 two phases have been completed, which are described below.

Phase 1

During this phase only the communal operational financial system, called FA4U5

, was disclosed on the central platform of ManRap. FA4U is the financial SAP system of RN and consists of generic financial profit & loss- and balance sheet management reports. FA4U is based on the SAMBA-vision in order to provide the same support on accounting processes at the local bank as at Rabobank Nederland. The general objective of the first phase is to place a fundamental and solid foundation for a wide implementation of ManRap within RN. In practice, all RN departments should be able to compose reports related to the modules Financial Accounting, Controlling and Project System as previous was possible with FA4U or with their own MISs (Business Intelligence CRG, 2005). Phase 1 was started in 2005 and went live early 2006.

Phase 2

In this phase several other communal data sources are disclosed, namely Sapiens (internal personnel information and salary system), RaboShop (external contracts and personnel information system) and Clarity (system for time registration, planning and capacity management). This information is available through standard reports with the SAP Excel spreadsheet add-on, called BEx Analyzer, or Web Portal (web application of SAP, using Internet Explorer). Phase 2 was started in 2006 and went live early 2007. Furthermore, certain decentralised MISs have been eliminated, for example Prisma, Cognos and Essbase, as well as several Access applications. The actual eliminations of these systems occurred in the aftercare of phase 2 and is considered outside the scope of phase 2 (Projectgroep ManRap Fase-2, 2006).

Phase 3

Directly after phase 2 went live in 2007, the plan was originally to implement a third phase of ManRap. This phase was focused on extending the ManRap system for the individual directorates with the aim on becoming the exclusive (financial) management reporting system of RN. It included the elimination of a number of, mostly financially oriented, MIS environments.

Figure 2.1 summarizes the chronological order of the main events of the ManRap project. The figure shows that the ManRap project officially ended in 2007. Since then Functional Support ManRap is in control over the system and via requests for change (RfC) of users the system has been changed multiple times.

2.3

ManRap system

To understand the functioning and characteristics of the ManRap system, the following issues will be discussed: source systems, SAP Business Warehouse, possibilities and functions, user groups, system management and system support.

2.3.1 Source systems

ManRap currently retrieves its data from six source systems and is one-on-one connected to these systems. Because there is no manual processing within ManRap, errors in the source data are not corrected in ManRap, so ManRap is as pure as the source. The source systems are listed below.

• RaboShop (SAP SRM): supporting function for hiring externals for a number of business units of the Rabobank Group. RaboShop contains the contract data (e.g. FTE) of the external employees and is furthermore a web enabled purchase application for catalogue products.

• Sapiens / HR SAP BW:personnel information system of the Rabobank Group and contains the data of the internal and external employees, required for the hours, FTE and project progress reports of ManRap. • Clarity: project management system of RN, which is being used for time registration (for both internal as

external employees), capacity management and project management.

• FA4U (Financial Administration For You): financial SAP system of RN and consists of generic financial profit & loss- and balance sheet management reports, with the following modules Controlling, Finance and Project Systems.

• VAS (VerplichtingenAanmeldSysteem): registration system for obligations in order to improve the financial reporting and to support the process of registering obligations.

• BudgetTool:supports the central and decentralised controllers of RN with preparing, coordinating and consolidating budgets and forecasts. Developed and connected to ManRap in order to enter financial and FTE budget data. This data is subsequently available in several ManRap reports and is based on FA4U (Projectgroep ManRap Fase-2, 2006, pp. 7, 31; Raboweb RN, ‘Programs’, July 27, 2010).

2.3.2 SAP Business Warehouse

ManRap as logical information system makes use of the RABO SAP BW platform. This is a shared platform, which means that besides ManRap several other applications and projects use the platform. A description of the SAP Business Warehouse (SAP BW) architecture is given, in order to understand the functioning of the reports. BW is an integrated, stable collection of data, oriented towards a particular target/target group, and used to support the management’s decision-making process. The architecture principles are used to align demand (i.e. reporting needs) and supply (i.e. data from source systems) in such a way that the objectives of the demanding stakeholders and the system manager are optimally safeguarded in the short and long run. Plan of action Proof of Concept 3.2005 Built ManRap phase 1 9.2005 Plan of Action/Blueprint ManRap phase 2 3.2006 Build Proof of Concept 4.2005 End report Proof of Concept 6.2005 Build ManRap phase 2 9.2006 Plan of action/Blueprint ManRap phase 1 6.2005 Go Live ManRap phase 1 2.2006 Go Live ManRap phase 2 2.2007

The objective of the platform is to introduce a model that is flexible and able to adapt to external changes (e.g. demand and supply). The architecture of the platform consists of three layers:

1. Source layer: layer with several source systems (e.g. Clarity, FA4U, RaboShop and Sapiens) of which data is extracted for the use of ManRap. 2. Data storage and management layer: in different

steps the extracted data is loaded and transformed (e.g. merging of data), after which the data is stored in tables, called multidimensional cubes. The data within the cubes is primarily used for the presentation. 3. Presentation layer: layer with different functions

and tools (e.g. BEx Analyzer and web reports) used for the presentation and analysis of the data for the end user.

This model is useful in increasing the independence on the source system. This means that the hindering on the source system through (re)loading of data to BW is minimized and that in addition, the BW system is only minimally dependent on the source system for (re)loading of data. The aim is to minimize the downtime or performance decline (due to the loading or reloading of data) by minimizing the changes at the supply level (Projectgroep ManRap Fase-2, 2006, p. 16).

2.3.3 Possibilities and functions

ManRap provides a number of integral and uniform management reports. Integral means the data from different sources is combined in reports about specific topics. Uniformity is reached in lay-out and functioning of the reports, as well as in the definitions and data modifying methods. In phase 1 and 2 of ManRap generic custom reports were replicated from the old MIS systems (e.g. Cognos, Essbase and Prisma). Specific reports of the directorates were build manually by the directorates with support of the ManRap-team and Functional Support ManRap.

ManRap contains the following types of reports:

• Financial reports (e.g. income statement, activities overview, etc.); • Hours, on the levels of cost centre, employee, external employee, etc.;

• FTE (e.g. HR information with regard to absenteeism and internal and external FTE);

• Planned hours (e.g. allocation data, planned hours on employee, cost centre and project level). Based on the assigned role (see next section), users have access to a number of reports.

The reports are offered to the users through four different channels: 1. BEx Analyzer, an Excel spreadsheet add-on;

2. Web Reporting, a Web portal;

3. Distribution tool, automatic transfer of ManRap reports via mail; 4. Network directory, availability of project reports on network directories.

A limited group of controllers, project managers and (delegated) budget holders mainly use the first two channels, whereas the latter two methods are used by line-, project- and program managers (Projectgroep ManRap Fase-2, 2006, pp. 5-8).

2.3.4 User groups

ManRap’s user community approximately falls in the range of about 300 users and the average users per day login to the system may vary between 30 to 50. This depends on the reporting period and the data Figure 2.2 Project milestones (Projectgroep ManRap

Overall, four types of end users or functional roles are distinguished in ManRap: (1) controllers, (2) project supporters, (3) project-/program (or activities-) managers, and (4) line managers. This classification segments users based on their possibilities and the reports they will be using. Per role a specific set of activities and functionalities is assigned to be allowed to execute in ManRap, after which a reporting set is determined per type of end user. A further distinction can be made between these user groups:

• Standard user: executing standard reports and navigation steps (i.e. drill-down, drill-through, filtering and column selection using the web tool). Consists of a limited group of project managers and (delegated) budget holders, who want to analyse the figures.

• Analysis user: executing standard reports and navigation steps (i.e. drill-down, drill-through, filtering and column selection using the BEx Analyzer) (e.g. controllers and project managers)

• Distribution user: receiving monthly automatic composed Excel reports (without analysis possibilities) via mail (e.g. (delegated) budget holders).

• Publication user: extracting monthly Excel reports (without analysis possibilities) concerning their reports and programs from a ManRap directory (e.g. project managers and program managers)

• Super user: similar possibilities as analysis user, with the addition of modifying and saving reports with the query designer in the local view6

(e.g. BW specialists who function as first line support of the end users at the directorates).

• Professional user: besides the aforementioned tasks, professional users can create and change reports using the BEx Analyzer in global view7 _{(e.g. Functional support) (Projectgroep ManRap Fase-2, 2006, pp.} 20-21).

2.3.5 System management

CRG is owner of the ManRap application, whereas a combination of Support F&C, Group ICT Management & Operations and Group ICT Program- and Information Management function as the managers of the system. Each business unit that uses ManRap has appointed a super user, who acts as the linking pin between the user organisation and the second line support (Functional Support). A super user is responsible for:

• first line support of controllers within their business unit;

• (proactive) advising to the (control) management regarding reporting possibilities of ManRap; • customising of RN generic queries8

for use within directorates.

Authorisation

‘Roles’ are used within SAP BW to simplify the management of the access rights. In order to get access to the ManRap system, an application must be submitted to the super user of the business unit. Consequently, the super user will decide about the required functional role and authorisation and accordingly will submit a request to Functional Support ManRap. All new users of the Web application and BEx Analyzer receive a short training, which is organised in collaboration between the super users and ManRap project team (Projectgroep ManRap Fase-2, 2006, pp. 49-53).

2.3.6 Consultation structures

The users of the BW-platform are united in the Rabo BW-platform consultation, where agreements are made on the use of the platform.

Super users meeting

Every two months a super users meeting is organised. The super users of the business units as well as representatives of the three support levels attend these meetings. Chairman of the meeting is the manager of SF&C, who also initiates the meetings. During these meetings topics like the status of present issues, RfC’s, and incidents, information about releases, system problems and possibilities are discussed. Furthermore, a prioritisation of the RfC’s is agreed upon.

System owners meeting

Besides ManRap several other systems use the BW system, which means agreements between each other have to be made. Therefore, every two months a meeting is planned, where all system owners make agreements about performance, system load, quality and remedial actions.

Technical meeting

The main focus of the system owners meeting is on organisational issues, therefore a technical meeting is introduced to discuss technical issues. This meeting also takes place every two months with all the system owners.

ManRap Functional Support meeting

Every week a meeting takes place between all the Functional Support members, a representative of Technical and Functional Application Support and the manager Support F&C. During this meeting the outstanding incidents and RfC’s and their solutions, the action list and project progress are discussed (Kortleve, 2006, pp. 13-14).

2.3.7 System support

On the support level of ManRap, the following groups and relevant tasks can be distinguished:

1. Functional Support (department Support Finance & Control at CRG RN); maintenance of the master data and users, identifying demands and requirements of users, control on data integrity, development and maintenance of reports and second line support for end users.

2. Functional Application Support (department Group ICT Support & Operations); modifications in data model, report modifications and third line support.

3. Technical Application Support (department Group ICT Support & Operations); technical support of applications and underlying software and third line support.

Procedure

Support is an integral process, which occurs in alignment according to a set of procedures. When an end user experiences problems or when he or she has a question, they initially contact the super user of their directorate. In case the super user is unable to solve the problem or answer the question, super users will contact Functional Support with a ‘call’, after which Functional Support solve and answers the majority of these ‘calls’. The calls that can not be solved by Functional Support are called incidents. When an incident can not be traced to a known problem with a workaround, a request for change (RfC) is reported to GICT (Functional and Technical Application Support).

From the user perspective, the key elements of the support are Incident Management and Problem Management. Incident Management aims to recover the service as soon as possible and Problem Management investigates the situation when there is something structurally wrong. Such a situation may result in Change Management, in which a change is made in the system settings. Via a RfC Problem Management can request a structural solution at Change Management. Incident Management is carried out by Functional Support, whereas both Problem Management and Change Management are the responsibility of Group ICT Management & Operations.

3.

Literature review

The mainstream conception prevailing in today’s management accounting research community is on understanding the causes, the effects and functioning of management accounting (Malmi and Granlund, 2009, p. 598). The main reason for this focus is to be able to use this understanding, in creating better management accounting practices, both in terms of content and use(cf. Chenhall, 2003, p. 159; Ittner and Larcker, 2001, p. 399).

The dynamics of how management accounting systems arrive at their given state or how they move from that state have received little scientific attention (Innes and Mitchell, 1990, p. 4). Forces that influence (drive or delay) accounting change are identified to a certain extent, however how these factors combine and interact to induce the accounting change is not explained in great detail. In addition, a wide

variety of potential problems related to change implementation exist in practice and the amount even seems to further increase in the future (Kasurinen, 2002, p. 328). Examples of these potential problems include organisational structures (Roberts and Silvester, 1996), organisational culture and power distribution (Markus and Pfeffer, 1983). Consequently, change projects do not always seem to lead to a successful implementation, regardless of how skilfully they are managed (cf. Malmi, 1997; Anderson and Young, 1999).

Challenged by the difficulties in successfully implementing accounting change and the fact that very few attempts to collect the different barriers and drivers to accounting change into one framework exist, this research focuses on theoretical frameworks on factors which (may) positively or negatively influence management accounting change.

Effective management of the implementation of management accounting change is considered to be dependent on both the nature of the implementation process and a wide variety of contextual factors (Modell, 2007, p. 342). The latter factors will be discussed using the accounting change model of Kasurinen (2002), whereas the institutional theory of Scapens (1994), Vaivio (1999) and Burns and Scapens (2000)is used to examine the nature of the implementation process.

The institutional theory will be used to develop a framework for conceptualising and explaining management accounting change and the nature of the implementation process, using four dichotomies (Scapens, 1994; Vaivio, 1999; Burns and Scapens, 2000). In contrast to the functionalist explanations of change underpinning most factor studies, institutional theories are characterised by a more process-orientated approach and can therefore be seen as complementary to factor studies. For example, institutional theories share a concern with the wider social and political consequences of change and draw attention to how change efforts may encounter resistance due to conflicting interests. Factor studies however are aimed at explaining what organisational and contextual factors contribute to and hamper accounting change (Modell, 2007, p. 344).

This chapter will therefore review two influential strands in the management accounting change literature, namely process-orientated research based on institutional theories and factor studies focusing on the implementation of management accounting changes, such as Activity-Based Costing (ABC), Balanced Scorecard (BSc), etc.

The focus of this research is on the implementation of a new management reporting and information system, named ManRap, which significantly differs from the research objects of Kasurinen (2002) (i.e. implementation BSc) and his predecessors Cobb et al. (1995) (i.e. implementation ABC). This new reporting and information system is implemented to standardise and centralise management reporting and includes both financial and non-financial information.

Literature review

3.1 Change

3.2 Accounting change

3.3 Accounting change model

3.4 Information systems

3.5 Limitations

Management reports are used to ensure management control and are part of the overall management control system (Merchant and Van der Stede, 2007). Management control system (MCS) is often related to both management information system (MIS) as well as management accounting system (MAS), because of their extensive interdependencies. Sometimes these three terms are used interchangeably. Bouwens and Abernethy (2000) for example used the term MAS, whereas Abernethy and Guthrie (1994) used the term MIS to study the same concept (i.e. decision-facilitating function of the system).Additionally,Vandenbosch (1999, p. 79) stated for the purpose of his research that: ‘the differences among management information, accounting information, and control information are a matter of semantics. They all help to create, sustain or change organisational order’. In order to make a clear distinction between these systems and to understand their characteristics as well as to discuss the starting point for conducting research on accounting change, the fourth section of this chapter will discuss and define these three systems.

Management accounting researchers are often reluctant to define theory and settle for discussing theorising (Malmi and Granlund, 2009, p. 600). It is argued that a theory must contain the factors (variables, constructs, concepts) which are considered part of the explanation of the phenomena of interest (Whetten, 1989, p. 490). For that reason and due to its importance to this study, this chapter will start with a clarification of the term change.

3.1

Change

Factor studies, like Kasurinen’s study (2002), are mainly focused on explaining what drives and hampers successful implementation of management accounting techniques. His framework pays for example greater attention to the factors involved in changing management accounting practices, and sought to abstract and categorise them into a generalised framework. Hence, his study shares a concern with identifying factors explaining management accounting change, or a lack thereof. However, as Modell (2007, p. 352) also poses, the study has paid little attention to the meanings of the term ‘change’. No specific definition of what constitutes change or accounting change has been introduced.

Hopwood claimed in the 1980s (1983, 1987) that very little is known of accounting change and since then, the issue of accounting change has been subject to considerable research attention. However, despite the extensive research on why and how organisations do change, there has been very little debate about the concept of change itself. Furthermore, whether change can be conceptualised independently from its process and how these factors relate to the practice of accounting is often taken for granted and poorly understood (Quattrone and Hopper, 2001, p. 403). To clarify the latter, organisational change was linked to accounting by stating three roles which accounting can play in relation to organisational change. Firstly, it creates a particular visibility in the organisation by reporting certain items. Secondly, accounting can make certain abstract phenomena appear real and finally, accounting helps to create ‘a domain of economic action’ (Hopwood, 1990, pp. 8-10).

A simple example of change on various levels is given by Quattrone and Hopper (2001, p. 408), who state that organisations ‘change’ when they transform their structure and operations, management control systems ‘change’ when a new information system is implemented and cost accounting systems ‘change’ when cost allocation bases are redefined from direct labour hours to activities. In this case project, a mixture of all three types of change is applicable, since a new management reporting and information system is implemented, accompanied with new definitions, procedures and routines.

Definition

Change is the movement or transition of an entity from one well-defined point of being (state A) to another (state B). Thus the entity, which could be an organisation, an individual or a state of mind, has well defined characteristics at point ‘A’ that change when the entity becomes something else at point ‘B’. During the transition from state ‘A’ to state ‘B’ the object of change is modified, which means it gains and loses identifiable features. Thus, an organisation for example moves from a state of ‘organisation without an ABC system’ to a state of ‘organisation with an ABC system’. This definition is based on the assumption that researchers or managers can identify these two separate states as well as the in- and output of the process of change. Furthermore, it implies that the process of change takes place in a linear, predictable and ordered fashion (Quattrone and Hopper, 2001, pp. 407-408).

In reality, it is not always possible to predict these variables, since local contingencies and chance constantly disrupt the process. As management accounting change is subject to random influences, it becomes rather impossible to consciously plan and rationally execute the change.

Quattrone and Hopper (2001, pp. 426-429) realised these limitations and argue that it is better to replace the conventional definitions of change with the term ‘drift’. Drift is informed by local and unpredictable pathways (Andon et al., 2004, p. 31). The preference of drift over change is based on the following assumptions:

• drift has no implication that individuals are sufficiently conscious of space and time to transcend the contingent factors facing them;

• drift has no assumption that people move from well-defined situations A or B in a linear, predictable and ordered framework;

• drift recognises contingent factors that actors may be aware of, seek to respond to, but carry them along in unpredictable ways.

Drift refocuses our attention on improvisation, tinkering, hacking, deviations from plan and the impossibility of systemic control of organisational and accounting change.

This distinction shows the complexities surrounding the concept of what change means. Providing a rich insight into what constitutes as change and how it relates to the practice of accounting, is necessary to understand the issues discussed further in this study. The next section will discuss a framework for conceptualising and explaining management accounting change as well as the nature of the implementation process.

3.2

Accounting change

Institutional theory challenges the idea of economically rationality and regards that action choices are for a large part contingent on the norms, values and habits embedded in the social setting (e.g. institutions) and are therefore constrained by the social context (Van der Steen, 2005, p. 3). Burns and Scapens (2000, p. 5) tried to explain how organisations succeed in developing and applying new accounting methods using the institutional theory. Their approach is based on the idea that a management accounting system can both shape and be shaped by institutions within an organisation. ‘Institutions can be regarded as imposing form and social coherence upon human activity, partly through the continuing production and reproduction of habits of thought and action’. Institutions and routines create stability and social order through the provision of information on how others may be expected to behave (Scapens, 1994, pp. 306, 313).