Benefits Realisation in Post-Implementation Development of ERP Systems: A Case Study

Enterprise Resource Planning (ERP) systems influence organisational performance and business strategies significantly. However, identifying, managing, and realising expected benefits of ERP is challenging. The existing ERP research has largely focused on the implementation phase leaving post-implementation development understudied. Yet, post-implementation development ensures continuing benefits. This paper documents a single-case study on benefits realisation in post-implementation ERP development. The results imply that benefits realisation practices can improve job satisfaction while lack of it can lead to unused solutions. Outdated and evolved business processes, complicated further by workarounds, hinder on-going ERP development. Consequently, benefits realisation is hindered as well. Moreover, when subsidiaries are unable to identify new benefits on their own and while the benefits may even vary from one subsidiary to another, the complexity of benefits realisation increases. Altogether, the article highlights four empirical findings on issues influencing post-implementation benefits realisation and four issues on post implementation ERP development in general.


Introduction
Enterprise Resource Planning (ERP) systems are standard software packages integrating processes from various business functions by utilising shared and integrated databases and workflow standardisations [1,2]. These systems are complex due to their size and influence on business processes, but also due to their risk factors and benefit opportunities [2,3]. As ERP systems require expensive investments, also the question of ERP benefits becomes nontrivial [4,5]. Johansson et al. [4] highlight that various underlying factors can generate benefits, but no coherent ways to manage them exist. Perhaps due to the complexity, many organisations merely assume that the anticipated benefits from ERP will actualise without formal practices [6,7]. If benefits realisation has so significant importance and moreover, if organisations understand the importance, formal practices should be used widely. However, literature indicates otherwise [8]. The purpose of this study is to examine this contradiction.
The vast body of ERP research is heavily focused on the initial system implementation phase, leaving less attention to the post-implementation phase [5,9]. However, new capabilities are introduced during postimplementation, and new benefits appear [10]. While it is important to understand how benefits from IS investments can be obtained, organisations often fail to realise them [11]. As benefit realisation practices appear often insufficient even within the ERP implementation phase, the question how these practices are handled postimplementation arises as well and a research gap prevails [5]. Addressing this, we posed the following research question: How benefits realisation in the post-implementation phase of ERP systems is managed? The related challenges, together with organisational practices and methods in use, were examined.
The rest of this study is structured as follows. In Chapter 2, benefits realisation and ERP literatures are reviewed and theoretical patterns for further analysis are identified. Chapter 3 outlines the research methods, followed by the case study and results. In Chapter 5, the implications are discussed and finally the study is concluded in Chapter 6.

Background and theoretical patterns
Benefits management is "the process of organising and managing such that potential benefits arising from the use of IS are actually realised" [12]. A five-phase process, the "Cranfield model" was developed in the mid 1990's to improve the ability of managing and realising benefits [12]. The process steps are: a) identifying and structuring benefits, b) planning benefits realisation, c) executing benefits realisation plan, d) evaluating and reviewing results and e) identifying potential for further benefits. The aim of the process is to improve the recognition of achievable benefits among relevant project stakeholders and to ensure that the investment leads to the targeted benefits throughout its lifecycle [3]. Research of benefits management has increased since the development of the Cranfield model and the model has been well cited since [8].
However, organisations often follow few or no formal practices for benefits realisation [7,8,13]. Various challenges exist, e.g. insufficient management practices, focus on delivering technology instead of benefits, lack of adequate evaluation criteria for success, unsatisfactory use of business cases, or overstated benefits [3,7,14,15]. Benefits realisation can be enhanced with formal practices, setting effective target benefits with clear measurement criteria, and not aiming to realise all benefits at once [3,8,16,17]. In addition to methods developed particularly for benefits realisation, organisations could also utilise business cases or established project management as tools to improve benefits realisation [3,7,12,13,15]. However, a method alone guarantees no success, competence on using it and on-going commitment is needed too [3,8,13].
Complexity of ERP systems complicates also benefits identification and realisation [3]. Benefits may also vary from one organisation to another [18]. Yet, only little interest towards systematic ERP benefits follow-up exist [4]. While ERP projects may surpass their budgets, formal practices to ensure benefits remain undone [6]. Organisations may claim just to know if the projects are successful or not [4]. In other cases, the ERP benefits are regarded as selfevident, and the realisation procedures appear expensive and complex [6]. The missing practices of ERP benefits realisation might be due to various organisational challenges. For example, the practices are considered expensive and difficult, negative pre-assumptions hinder adoption of the formal practices, and management processes to seize all benefits remain insufficient [4,6,18]. Potential solutions reside in the alignment of benefits and project management practices and in better understanding of the complexity and context dependency [3,19]. An ERP investment is often viewed as a merely technical issue, while its business aspects may be ignored [3].
ERP systems are long-term strategic investments, which is why evaluations should be done over long time period [20]. The literature of ERP lifecycle models also acknowledges the long-term life span [10,21]. Shanks et al. [21] divide the lifecycle into planning, implementation, stabilisation and improvement (i.e., post-implementation). In the light of the literature, organisations can have various challenges with benefits realisation in post-implementation development of ERP systems, such as communication challenges, workarounds and the complexity of the system [9]. However, the literature clarifies little, if at all, how organisations manage the issue, or what kind of tools or methods are used.
The mainstream literature of benefits management thus leads us to formulate three theoretical patterns (cf. [22] and the methodology section below) for analysing benefits realisation of ERP post-implementation efforts: Pattern 1. Systematic approach to benefits realisation is assumed to improve benefits delivery of ERP development projects. Pattern 2. Planning for the benefits realisation has more important role in project success than merely justifying the project, it can improve the relationship of IT and business and cooperation of stakeholders. Pattern 3. ERP post-implementation a) is a merely technical project or b) its benefits are considered self-evident, so that no systematic methods or practices for benefits realisation are needed. These patterns are used to analyse the results of the study and to discuss the contributions of the study in context of existing literature.

Research Method
As in-depth research reports focusing on the post-implementation phase remain rare, this study was regarded as a meaningful, even revelatory, single-case study [22]. Qualitative data involves recorded interviews, documents, and one of the researchers had access to the ERP artifact itself in the target organisation. Table 1 shows the data sources related to analysis units. The candidates for the interviews were identified and selected from different business units and IT department to represent the key stakeholders usually initiating and implementing ERP development efforts. In total, seven persons were interviewed. Four from IT, two business managers and a management team member. We utilised five informants to discuss about specific recent post-implementation projects as well as topics related to overall ERP development. Two informants (IT and management team member) discussed merely ERP development generally. The data about projects and the overall ERP development was analysed based on the theoretical patterns identified with the previous research ( [22], cf. section 2 above). We also allowed additional observations to arise from the data. All in all, the aim of selecting the case study methodology was to get a rich, in-depth understanding of what happens in the post-implementation efforts invested in ERP with regard to the benefits realisation.

Results
The target organisation produces consumer electronics. The headquarters (HQ) reside in Finland, coordinating 20 subsidiaries and ca. 1300 employees globally. The current ERP system became operational in the early noughties. Due to the maturity of the current system, the organisation represented a valuable case regarding postimplementation development of ERP system as well as eventual practices related to benefits realisation.
The post-implementation development of ERP can be roughly divided into small-scale and large-scale projects. The large-scale projects require more discussion and formal investment approvals. However, the most postimplementation development takes in small-scale projects involving no formal organisation-level guidelines to manage benefits. Five specific post-implementation projects were discussed with the informants. The selection was based on three reasons: a project needed to be recent, clearly described in the company documentation and the data needed to be available. Table 2 characterises the projects in light with the themes of business case, project management, documentation, scope creep and benefits. In general, we observed quickly that no coherent ways to manage ERP development existed and few or no organisational benefits realisation practices were used throughout every project. However, some projects revealed evidence of more formal elements of benefits realisation practices. In connection to ERP system development in general, the findings were classified under the themes of business case and analysis, project management, follow-up, and challenges. Business cases were considered often to be insufficient or totally absent. Due to the lack of the business case, either the project scope or schedule can expand. The documents revealed that pre-studies were conducted with large-scale projects. As a result, business cases and investment proposals, including e.g. analysis of alternative solutions, costs, risks and benefits, were created.
The intended benefits were not always clear, and the stakeholders were confused about the sought objectives and benefits. In general, project management practices varied. Documents show that large-scale projects had dedicated project managers, steering groups and business might also have dedicated resources. However, most projects were small-scale where formal project management practices were used less frequently. Scope creeps, i.e. requirements added during projects and expanding the scope, often occurred with all sizes of ERP development projects.
In projects with proper final meetings, the solutions were reviewed with regard to explicated benefits. Yet, the IT representatives assumed only low-level follow-ups on benefits realisation. Lack of follow-up resulted, at worst cases, in unused add-on solutions thus leaving the development efforts with zero benefits.
Although the organisation-wide ERP system had been in use for many years, several local business processes in the subsidiaries could remain unknown. When developing ERP solutions in these circumstances, new benefits are likely to emerge unplanned. Several recent projects had encountered old, manual business processes while a few New requirements were introduced during the project Benefits realisation was followed-up, but anticipated benefits were not realised at the time of the study local workarounds existed. Also, past development projects had created variance to the business processes among subsidiaries. Hence, all benefits were not possible to anticipate at the corporate level. It was further discovered that the ERP development, and consequently benefits realisation, faces also another type of challenge, personification. That is, some projects were directed by personal interests of individual business managers or IT personnel and the anticipated benefits were not articulated to the project group, making it unclear whether and to whom the development was beneficial. This phenomenon was reported by participants on both the IT and business sides.
The results of the pattern matching revealed slight dispersion between the individual post-implementation projects and ERP development in general, while we saw traces of all the above-set theoretical patterns in the big picture (Table 3). In the following, let us discuss the phenomena observed in the particular projects. Data supporting the first pattern was observed in all five projects and in the context of ERP development in general. Although the interviews involved also data contradicting the first theoretical pattern to some extent, it can be concluded that our informants considered more often that a systematic approach to benefits realisation improves benefits delivery of ERP development. Only one of the analysed projects showed evidence to contest the second pattern. Although extensive planning was conducted, no evidence indicated that it would have improved relationships between IT and business or stakeholder cooperation. However, evidence regarding the rest of the projects and the general level development suggested that planning plays a significant role in stakeholder relationships and cooperation. Therefore, the second pattern was interpreted to be largely supported by our data. The third pattern inflicted the most dispersion. The data suggested that in well-planned projects (1 and 5), benefits realisation was not considered self-evident nor the projects were regarded as technical endeavours since an active approach from the business stakeholders was evident. Consequently, we interpreted that more systematic approaches to follow the benefits realisation were desirable. Projects 2, 3 and 4 were regarded either as mainly technical or the benefits were perceived so self-evident that no follow-up was considered necessary. In these projects, the responsibility was readily handed over to IT, which holds the technology-centric view on development, or the benefits were considered as self-evident making follow-up unnecessary. Paradoxically, the individual projects thus could still acknowledge that more systematic benefits realisation should be in place, while the general-level IT development could consider post-implementation projects as merely technical.
There were no systematic organisation-level approaches to manage benefits realisation. In some projects, more formal project management practices were used, and thus elements of benefits realisation could be identified. Business cases, with benefits or ROI calculations, were created if the project encountered resistance (Projects 1 and 3) or an investment approval was required (Project 5). Yet, many projects were initiated without business cases, justification, or pre-defined benefits. Further, emerging benefits were often realised ad hoc, which resulted project scope, schedule, or cost to expand (Projects 2, 4, and 5). (Cf . Tables 2 and 3).
A number of challenges of benefits realisation were identified: varying interest of the subsidiaries, unknown business processes, insufficient or absent business cases, new emerging requirements, uncontrolled identification and realisation of new benefits, insufficient identification of how to achieve the benefits, and lack of schedule for the realisation. Ultimately, a few of the newly developed add-on solutions were not taken to use at all. Some projects were managed by IT although the focus of the project was on business processes (3) or technology was only a partial element of the project (5; see Table 2). One major challenge emerged from the management of ERP development. The ERP development was conducted at the headquarters largely on request of business units. No systematic benefits identification was done at the subsidiaries. Hence old, often manual processes were in use. Due to lack of centralised evaluation to identify potential for further benefits, the process overlooks the inabilities of the subsidiaries to identify new benefits on their own. Consequently, the ERP system was not utilised or elaborated to its full potential.
In the individual projects, many practices were regarded to enhance benefits realisation. Formal project management practices were used in some projects and business cases were created even more often. These practices improved stakeholders' understanding of the justification and aimed benefits, and thus improved the cooperation. In some cases, the benefits were followed or identified after the projects (Projects 1, 3, and 5; Table 2). Further, when new, emerging benefits were identified those were often included to the project which enabled the realisation, but resulted the scope, schedule or costs to expand. The evidence also indicated if the development project was managed as joint effort between business and IT, the optimal outcome was received (Project 1).
Formal project management methods, at least to some extent, were used in some projects with regular meeting practices, project progress monitoring assisted by collaboration, and project management tools. Project documentation was done with normal office software and the technical documentation was done by IT with specific tools. No formal benefits realisation practices were used at the organisational level.

Discussion
In this section the main findings are listed followed by discussion of their contribution in relation to previous literature. Our four key findings on benefits realisation practices of post implementation ERP development are: 1. a systematic approach to benefits realisation can prevent expansion of scope, schedule and costs of projects, 2. the systematic approach can increase job satisfaction, 3. insufficient benefits realisation practices allow personal interests (rather than organisational targets) to direct development projects, and 4. insufficient benefits realisation practices can result in unused solutions.
Additionally, we recognised four findings on post-implementation ERP development in general: 1. old or evolved business processes can be unfamiliar to the IT and to business managers responsible of ERP development projects, complicated further by unknown workarounds, 2. various development projects throughout the years can create variance to the business processes among subsidiaries, 3. subsidiaries might not be able to identify new ERP benefits on their own, and 4. benefits vary between subsidiaries which complicates the ERP development projects.
A systematic approach to benefits identification or justification was identified as beneficial, while no such approach was adopted in the most projects. Business cases and project justifications were done more regularly with large-scale projects where project success factors, i.e., costs, scope and schedule, were followed. These findings are largely in line with the prior literature [8,13]. The lack of a business case was considered to cause either the project scope or schedule to expand and the lack of proper project management practices was seen to cause further issues. The prior literature offers some solutions. Badewi and Shehab [19] argue that the role of project management in realising ERP benefits is critical although that alone does not ensure benefits realisation. Zwikael et al. [17] suggest that clear target benefits help to clarify the project targets and improve project performance. It is thus argued that by adopting a systematic approach to benefits realisation, expansion of scope, schedule and costs of projects can be prevented or, at least, mitigated.
The interviewees highlighted the importance to know the objectives and benefits of on-going development efforts. This, in turn, provides sense of meaning in the work and it further can increase overall job satisfaction. This aspect is largely overlooked in the literature. Although Ward and Daniel [3] identified that organisations, succeeding in IS investments, define more benefits related to such themes as collaboration and individual job satisfaction, they do not address the impact of systematic approach to benefits realisation as a source of job satisfaction. Ward and Daniel [3] highlight good relationships between IT and business as a project success factor. This suggests that the anticipated benefits should be shared in the projects. However, our data revealed that this was often neglected, resulting in confusion. In order to succeed in post-implementation ERP development, the project teams thus should be able to share and communicate the main targets [9]. We propose that a systematic and communicative approach to benefits realisation thus influences positively on job satisfaction among post-implementation ERP stakeholders.
The empirical evidence confirmed two major reasons for the insufficient follow-up practices. The projects were either considered merely technical endeavours or the benefits were considered self-evident without need for followups. These issues have been also recognised in the previous literature in relation to initial ERP implementations [6,13]. However, this matter inflicted variance in the evidence. In some projects, more follow-up was done, while some ignored it. One explanation is the scale of the projects. Larger projects had more systematic project management practices. Another explanation for such variance was personification. Personal interests influenced which projects were carried out and how. Personality of managers and management style have been identified by Osnes et al. [9] to influence ERP implementation projects. Similarly, Ward and Daniel [3] reveal that stakeholders' perception of personal benefits can influence project scopes. Hence, literature acknowledge the issue to some extent. Yet, in this study, it was revealed that personification can have significant impact on various aspects of post-implementation development projects. The insufficient follow-up practices have also led to the situation that all developed solutions had not necessarily been taken into use at all. It was acknowledged that some development projects fail or due to changed circumstances the developed solution might not serve relevant purposes anymore. Still, this was mostly considered as an existing problem. The prior literature has not fully addressed this issue. Ward and Daniel [3] recognise the failing IS projects and Ashurst et al. [13] explain that successful IT solutions do not alone guarantee meaningful business benefits. However, the literature has not identified that insufficient benefits realisation practices can, as such, contribute to emergence of unused solutions. The current ERP system implementations at the Case organisation started in the early noughties. However, old, often manual, business processes, were still in use. Development projects conducted over the years have created variance in the business processes among the subsidiaries. These local business processes can be largely unknown to the IT and business managers responsible of the post-implementation development. The prior literature has not, however, identified these issues. Although workarounds have been identified in the literature [9], some noteworthy aspects were identified in this study. Workarounds were identified as a part of business process evolution resulting either from subsidiaries' inability to utilise the ERP system or to solve process issues without system development. Workarounds remain often invisible to the headquarters. These issues characterise post-implementation ERP development which in turn complicates the projects and benefits identification significantly. The subsidiaries might not be able to identify realisable benefits on their own, but due to the unknown processes it is very challenging to identify the benefits from the headquarters either. This issue is further complicated by the varying benefits among the subsidiaries. While Osnes et al. [9] have discovered that a good implementation strategy helps in postimplementation and that early focus should be directed on the post-phase, especially regarding the requirements for maintenance, further research on practices to tackle this issue would be needed.

Conclusion
This paper presented a single case study on benefits realisation in post-implementation development of ERP systems. Systematic benefits realisation approach and solid planning improves project success by preventing expansion of scope, schedule and costs and ultimately improving job satisfaction whereas poor practices result confusing projects. However, in a few projects, ERP development was considered either as a technical project or the benefits were seen self-evident making systematic approaches to realise benefits unnecessary. Although variance existed depending on the project size, the insufficient follow up can, at worst, result unadopted solutions wasting the development resources. One explanation was that personal interests of business managers or IT personnel often directed and prioritised the development projects. Consequently, personal interests, rather than organisational targets, directed development projects posing a considerable risk for failure of benefits realisation.
Due to the long lifecycle of ERP systems in a multinational context, new types of challenges emerge beyond those identified in our predefined analytical patterns and prior literature. Old business processes were occasionally used aside of the ERP system, or the development projects, conducted throughout the years, had modified business processes incoherent in relation to each other. As a result, these business processes were largely unfamiliar to IT and business managers responsible for the development projects. This matter was further complicated by local workarounds occurring even outside the ERP system making them hard to identify from the headquarters or by the ERP development teams. It was also identified that the subsidiaries might not be able to identify new benefits on their own and furthermore, the benefits vary between subsidiaries. These unique characteristics complicate benefits realisation in post-implementation development of ERP systems and suggest a need for continuing research and practical endeavours for improved practices for the field.
The long ERP lifecycle complicates benefits identification and realisation in the later stage of the postimplementation exposing new kind of challenges, such as those revealed in this study. The prior literature has largely not recognised these challenges in connection to post-implementation as the research focus has been on implementation phase. While our study provides exploratory evidence of such issues, further research on proven post-implementation practices and solutions to enhance on-going benefits from ERP systems and to tackling the recognised issues would be needed.