Application of ERP Implementation Methodology Framework

Published Date: 02 Mar 2018

Chapter 1

Introduction

This chapter will begin with a presentation of the background of my research area. The presentation will thereafter be followed by a problem and Significance of the research that will result in the objective and research question of my study.

Background

Over the past years innovation has arguably become one of the most discussed and sought after organisation-capabilities. It is recognised as a major goal of economic activity and one of the most important instruments through which organisations can gain advantages over their competitors. In order to survive in highly competitive business environments, companies have to continuously change their business processes. New conditions in the marketplace have provided a special stimulus to modelling business processes: product expansion, competitive sales conditions, development of global distribution networks, better informed customers, and the orientation of businesses towards satisfying the individual needs of the customer. In the light of this, business process reengineering has often been employed, and information technology is a frequently utilised approach used to improve business processes.

This study stressed the necessity for organisational restructuring in the context of global information connectivity. Business Process Reengineering is an organisational method demanding radical redesign of business processes in order to achieve greater efficiency, better quality and more competitive production (Hammer and Champy, 1993). It means analysing and altering the business processes of the organisation as a whole.

A business process includes activities and tasks that cross functional and/or organisational boundaries. Information technology (IT) is the most important factor in enabling newly redesigned processes. Modern information technology is oriented towards business processes and communications between persons using these processes, and is therefore called process and information technology (Ould, 1995). In that way, Business Process Reengineering can be described as organisational process redesign, with the direct influence of IT.

At the same time organisational expenditure on Enterprise Resource Planning (ERP) has also grown significantly during the 1990s and beyond. ERP systems have been adopted by the majority of large private sector organisations and many public sector organisations in the UK, Europe and the industrialised world in general. We would not expect this growing trend to materialise unless significant advantages were to be expected from the introduction of ERP systems. It is because ERP systems have such a significant impact on the organisation, the working practices of individuals and on human interaction that we wish to explore their impact on innovation.

Origin of the term ERP

In the 1960s, no manufacturing company could afford to own a computer. Therefore, both manufacturing and inventories were handled on the basis that companies must hold enough stocks to satisfy customer demand, and that customers would order what they had ordered in the past, quantity and time wise. There after manufacturing management systems have evolved in stages over the past 30 years from a simple means of calculating materials requirements to the automation of an entire enterprise. In the 1970s and 1980s, over-frequent changes in sales forecasts, entailing continual readjustments in production, as well as inflexible fixed system parameters, led material requirement planning (MRP) and master production schedule (MPS) to evolve into a new concept called manufacturing resource planning (MRPII) in 1980 (Kakouris & Polychronopoulos, 2005). Finally in the early 1990s the generic concept Enterprise Resource Planning (ERP), incorporating all the MRPII functionality, in addition to Finance, Supply Chain, Human Resources and Project Management functionality (Anderson, 1982; Wallace, 1986; Wilson et al., 1994). Figure1 illustrates the gradual evolution of the Enterprise Resource Planning with respect to time.

Enterprise resource planning systems are commercial software packages that enable the integration of transaction-oriented data and business processes throughout an organisation (Markus and Tanis, 2000). The key elements of an Enterprise Resource Planning system according to Miller (2003) are: one large real-time database which reduces data redundancy and improves accuracy; integrated business process that cut across business functions such as supply chain management; and seamless transitions between business transactions.

According to Newman (2003), Enterprise Resource Planning Systems are "software modules for different business functions that are linked by a common database to produce an integrated enterprise-wide system."

Enterprise Resource Planning packages, the enterprise system that makes company stick together, it is a nervous system of every corporation, large or small, when you check inside it tells what's going on, it helps you act as what nervous system do, how to react, to treat the information about competitors, about products, how do you get best out of it. It pays employees, makes billing, run accounts, interacts with customers, ships goods, basically it runs the process of any company and helps accelerate business innovation for your customers. They build process factories for enterprises, which are so flexible and configurable for the identical companies so that they can do different things with the same factories and Helping Companies Become Best-Run Businesses.

ERP integrates key business and management functions and provides a view of the happenings in the company, in the areas of finance, human resources, manufacturing, supply chain, etc. (Davenport, 1998; James and Wolf, 2000). An ERP solution is valuable when it represents the characteristics demonstrated in Figure 2.

Significance and objective of research

In the 1990s, customers experienced more costly and complex ERP implementations then they expected (Eschinger et. al., 2003). One research group found that the average ERP implementation took 232 months, had a total cost of ownership of $15M, and rewarded the business with an average negative net present value of $1.5M (Wailgum, 2008).

Because of their wide scope of application within a business, ERP software systems are typically complex and usually impose significant changes on staff work practices, Implementing ERP software system is typically not an "in-house" skill, so even smaller projects are more cost effective if specialist ERP implementation consultants are employed. The length of time to implement an ERP system depends on the size of the business, the scope of the change and willingness of the customer to take ownership for the project. A small project (e.g., a company of less than 100 staff) may be planned and delivered within 3-9 months; however, a large, multi-site or multi-country implementation may take years (for more details see table 1 and table 2).

Although implementing an ERP system may be costly and time-consuming, its benefits are worthwhile. However, there are a number of examples where organisations have not been successful in reaping the potential benefits that motivated them to make large investments in ERP implementations (Davenport, 1998). The research is also predicting that ERP new license revenue will have fallen 24% in 2009, as companies severely rein back implementation and expansion projects. While the organisation expects ERP spending to rise slightly in 2010, vendors will be fighting hard for every available dollar, and that should translate into cost savings for customers (Kanaracus, 2010). Therefore year 2010 is predicted to be different and better in terms of ERP implementation.

According to Langenwalter (2000), Enterprise Resource Planning implementation failure rate was from 40% to 60%, yet companies try to implement these systems because they are absolutely essential to responsive planning and communication (see Appendix 2 for ERP solution satisfaction). The competitive pressure unleashed by the process of globalisation is driving implementation of Enterprise Resource Planning projects in increasingly large numbers, so methodological framework for dealing with complex problem of evaluating Enterprise Resource Planning projects is required (Teltumbde, 2000). All ERP vendors came up with solution and build their implementation methodology which they recommend to all their clients to utilise the approach during their implementation and continuously looking for improvements in those methods. Therefore the Research in this subject will value the investment put in by the companies in these projects.

The primary objective of this dissertation was to explore the application of ERP implementation methodology framework by different vendors when implementing ERP and to find commonalities or diversion in the ways of improvement by them.

Therefore the key research questions that are the focus of this study are:

• To what extent different companies follow AcceleratedSAP as methodology when implementing SAP?
• Is different companies use different innovative ways to improve the process? Are there commonalities or diversion in this innovation?

Chapter 2

Literature Review

The purpose of this chapter is to present my theoretical framework. In this chapter first I will present different implementation framework models from some researchers and academician. Then select one model as my theoretical base.

Information Systems Development Methodology

Creation of an Information System is not a trivial matter, and must strive to fulfil four main goals; usefulness, usability, reliability and flexibility (Kruchten, 2000). To minimise risks of failure in any of these primary objectives there are a number of specialised development methodologies available, each with different strengths and weaknesses and suited to different project types:

The Classic Model

This model, often called the Waterfall model (figure 3), represents the "traditional" software lifecycle, and outlines an Information System project in clearly defined, partitioned phases that follow in sequential order (though the actual phases are not always the same) (Avgerou and Cornford, 1998). This approach has strengths when requirements are well known and unchanging, unfortunately problems with this approach are quickly identified. The main failings of this model stem from its linear nature, where each stage must be completed and the outputted deliverable passed to the next phase. This produces an inflexible model that is hard to step back to previous stages without changing everything (Avison and Fitzgerald, 2006). Due to this separated structure a gap of understanding can become present between users and developers, and as no deliverables are viewed until the end of the sequence unsatisfactory results can be delivered. It also typically suffers from long development times (which are certainly not available in this project) and as such is not usually practised in the formal fashion (Avgerou and Cornford, 1998).

This model alone is clearly unsuitable to the ERP implementation project as completion in a timely fashion is a key objective, and with this extra constraint risks will be extremely high. As such requirements capture/analysis will need to on-going throughout the entire process. With these points noted, a partially phased approach is attractive from a project management point of view, and an extensive initial requirements capture phase could greatly reduce project risks through understanding of the problem domain.

Business Process Reengineering Implementing Methodologies

One approach of information system development, which takes into account strategic aspects, is business process reengineering. It has presented organisation with the opportunity to rethink out dated procedures, rules, and assumptions underlying their business activities. This opportunity is usually enabled partly by the application of technology to outdated process (Avison and Fitzgerald, 2006).

The initial research of the subject starts with Business Process Reengineering which is achieved by the adoption of ERP as it streamline the organisation's processes by integrating the information flow into a single system. The term business process reengineering had its origin at MIT during 1984-1989 while MIT's enumerating management techniques for the 1990s. Business process reengineering simply means transformation from function based to process based. The radical redesign of a process is easily achieved by involving information technology (IT) in business processes and hence the prominence of IT in business process reengineering. IT is accepted not only as just a business process reengineering enabler (Hammer and Champy, 1993) but also as an essential enabler of business process reengineering (Davenport and Short, 1998). There exists a recursive relationship between business process reengineering and IT which can be utilised for thorough process change. In the modern times and due to rapid proliferation of computers in the business arena, business process reengineering through IT is getting a big boost. Business process reengineering using IT emanated from gradual progression in the use of computers from routine clerical job processing to IT-based decision making. Many corporations reaped benefits by re-engineering their processes at various stages of IT development. At the same time, re-engineering cannot be planned and achieved in small cautious steps for any corporation (Hammer, 1990). Some of the commonly used IT tools for re-engineering are ERP systems.

First we adopt the work of Kettinger al.'s (1997) for a literature review on business process reengineering implementing methodologies also chosen by Pellerin and Hadaya (2008). This implementation methodology proposes a generic stage-activity framework for conducting business process reengineering projects, because The technology is derived from the methodologies practiced by 25 leading reengineering consulting organisations and Unlike most business process reengineering studies, in which the unit of analysis is the organisation, Kettinger et al.'s (1997) work is cantered on the business process reengineering project, which is more relevant to Information System professionals.

Kettinger et al.'s (1997) framework comprises six stages, each containing the following activities (See Figure 4). The first stage, envision (S1), typically involves the business process reengineering project champion engendering the support of the top management. A task force, including senior executives and individuals knowledgeable about an organisation's processes, is authorised to target a business process for improvement based on a review of business strategy and IT opportunities in the hope of improving the organisations overall performance.

The second stage, initiate (S2), encompasses the assignment of a reengineering project team, setting of the performance goals, project planning and shareholder/employee notification and 'buy-in'. This is frequently achieved by developing a business case for reengineering via bench-marking, identifying external customer needs, and cost benefit analysis.

The third stage, diagnose (S3), is classified as the documentation of the current process and sub processes in terms of process attributes such as activities, resources, communication, roles, IT, and cost. In identifying process requirements and assigning customers value, root causes for the problems are surfaced, and non-value-adding activities are identified.

The fourth stage, redesign (S4), a new process design is developed. This is accomplished by devising process design alternatives through brainstorming and creativity techniques. The new design should meet strategic objective and fit with the human resource and IT architecture. Documentation and prototyping of the new process is typically conducted, and a design of new information system to support the new process is completed.

The fifth stage, reconstruct (S5), heavily relies on change management techniques to ensure smooth migration to new process responsibilities and human resources roles. During this stage, the IT platform and systems are implemented, and the users go through the training and transition.

The sixth and last stage, evaluate (S6), requires monitoring of the new process to determine if it met its goal and often involves linkage to an organisations total quality program.

This methodology was empirically derived from the methodologies practiced by 25 leading reengineering consulting firms which takes the management accounting perspective by attempting to reorganise business processes while using information as an enabler then it provides a set of tools and techniques to facilitate the reengineering effort and unlike most BPR studies, in which the unit of analysis is the organisation (Kettinger et al., 1997; Pellerin and Hadaya, 2008). This justifies the use of this methodology to build on the relation of further theories but just to compare and have further opinion let look at another business process reengineering implementation methodology.

A seven-step methodology, as shown in Figure 5, that shows the various steps in IT driven business process reengineering implementation (Davenport and Short, 1998; Armistead and Rowland, 1996). These steps are prioritising processes based on the comparative importance of objectives, identifying the processes to be redesigned, understanding and measuring/benchmarking the existing processes, identifying the appropriate IT tool, designing/building a process prototype, testing the reengineered process, and implementing the changed process.

The first step is to define the objectives of the process redesign which can be cost reduction, time reduction, improvement in output quality and/or improvement of quality of work life. Rarely, organisations become successful in meeting multiple objectives, concurrently. In the second step, selection of the processes to be redesigned is carried out. The two approaches, namely, exhaustive and high-impact approaches are available for the selection of the processes to be redesigned. Exhaustive approach ranks all processes to be redesigned based on the order of urgency prior to the identification of the process to be redesigned whereas the high-impact approach tries to identify only the most important processes which are in conflict with business vision and process objectives. The third step tries to measure the process before redesign in order to avoid repetition and to set a baseline for future improvements. In the fourth step, it is better to have a picture of all latest IT technologies available for redesign prior to the redesign and freezing of the redesigned process under study. The fifth step can be easily dealt with by using IT as a design tool in creating a more generic design of the process under study in arriving at a suitable organisational prototype. After generating the redesigned process prototype, implement the same in one of the units of the organisation to study the actual benefits before launching it on an organisation wide basis and the same is done in the sixth step. If the pilot launch is found successful in meeting the process objectives, launch the redesigned process throughout the organisation which is the seventh and last step in IT-based implementation of the redesigned process.

If both the implementation methodologies are compared there is not just the difference in number of steps between the two methodologies, there is also the difference in the approach in cut-overs where training of users are missing in second as well the pilots and rollouts are mentioned in the later methodology. This goes with Kettinger et al's (1997) findings that, while business process reengineering implementing methodologies may vary based on philosophical differences, there is enough commonality among the practiced approaches to generally describe a prototypical business process reengineering efforts.

Generic Enterprise Resource Planning Implementing Methodologies

In the past, companies used to decide how they wanted to do business and then made a decision about a software package that best supported their business processes. This was changed with ERP systems that required the business processes to be modified to fit the system (Davenport, 1998). Business Process Reengineering implementation exists ranging from technology enabled re-engineering to clean slate re-engineering. If ERP system is chosen first, then the re-engineering is driven by the chosen ERP system or re-engineering is technology enabled.

The reason why many companies chose to conduct ERP system development was to attempt to solve all their organisational problems without reengineering business processes first. Then the Costs involved with such re-engineering are very low as alteration done on the system is least or none. In clean slate re-engineering, design starts from scratch and ERP system software is highly customised to fit the processes of the enterprise in discussion. ERP implementation significantly impacts company culture, organisational structure, business processes, in addition to procedures and rules.

Furthermore, ERP applications integrate many best business practices and much knowledge that could be worthwhile if included as a part of BPR projects. By taking the best practices inherent in ERP applications, companies can change their processes simultaneously with technological change. As a result, many companies changed their business processes to fit the ERP system requirements, and the possibilities of ERP systems have been used to underpin Business Process Reengineering (Kooch, 2001, Chenn, 2001). As ERP systems have traditionally taken too long to implement, a dynamic and incremental implementation of ERP components is recommended as opposed to massive reengineering. Also pointed by Ahmed (1999) the focus of ERP implementations has shifted from matching business processes with the ERP system to developing "knowledge-workers" that can quickly understand and work with redesigned processes and realise the ERP-enabled benefits.

Boudreau and Robey (2005), suggest a vital importance to acceptance of ERP systems. They also note that if not successfully implemented, users may work around the system and otherwise doom the project to costly duplication of effort, or worse, system failure. A phased implementation approach is highlighted in Robey et al. (2002). It is important to have a structured approach, similar to systems development, for the implementation and maintenance of ERP systems.

Systems development theory uses the concept of a lifecycle and stages in the lifecycle to indicate development of information systems. The waterfall model, incremental model, RAD (rapid application development) model and spiral model are some of the systems development methods prevalent in the literature. Newer approaches to systems development address component-based development using off-the-shelf packages, agile development and the unified process for object-oriented software development (Pressman, 2005). The newer approaches have fewer stages in the development of systems. For example, the unified process which draws upon the best practices of conventional software process models has inception, elaboration, construction and transition phases. A common aspect of all these models is that they focus little attention on implementation and the post implementation of the system.

The literature review undertaken revealed a lack of research with regard to some critical factors of ERP implementation (eg client consultation, schedule and plans), and this could be due to the fact that these factors are related to any information system project, not particularly to ERP project implementation. However, and generally speaking, there has not yet been a common comprehensive or integrative approach to ERP implementation.

Successful ERP project implementation is a complex and difficult task. Implementing an ERP system package causes vast change that needs to be managed carefully to get the full advantages (Bingi et al, 1999; Sor, 1999). More importantly, it has been stressed by many that it is really a mistake to view ERP project implementation as merely an IT project (Davenport, 2000; Milford & Stewart, 2000; O'Leary, 2000).

A major difference between ERP systems and traditional information systems comes from the integrated nature of ERP applications. Implementing an ERP system causes dramatic changes that need to be carefully administrated to reap the advantages of an ERP solution. Holland and Light (1999) cite that the implementation of an ERP software package involves a mix of business process change and software configuration to align the software with the business processes. In that sense, it has become clear through the literature review, and studying the experiences of leading organisations, that the implementation of an ERP system is radically different from traditional systems development. In an ERP system implementation, the key focus has shifted from a heavy emphasis on technical analysis and programming towards business process design, business-focused software configuration (Kelly et al, 1999), and legacy data clean-up (Smethurst & Kawalek, 1999).

In essence, there are several critical and inter-related issues that must be carefully considered to ensure successful implementation of an ERP system project. The framework (Figure 6) presented in this report is the result a major research study undertaken to propose an integrative 'Critical Success Factors' view of ERP. ERP system implementation has been subdivided into three levels: strategic, tactical, and operational. Each level contains a number of critical factors. These levels of implementation, however, are not independent of each other, and each level should be used to derive the next level. Moreover, each level requires differing inputs; for example, there is a direct relationship between the implementation level at which a decision is being taken and the characteristics of the information required supporting decision making (Bocij et al, 2008).

Communication

Communication is one of most challenging and difficult tasks in any ERP implementation project (Welti, 1999). Slevin and Pinto (1987) define communication as the provision of an appropriate network and necessary data to all key factors in the project implementation. Communication has to cover the scope, objectives, and tasks of an ERP implementation project (Sumner, 1999). Failure to establish and manage the communication process with stakeholders can lead to a lack of support from stakeholders, disapproval of the deliverables and dissatisfaction.

ERP implementation levels

Strategic level

The decisions made at this level significantly change the manner in which business is being done (Bocij et al, 2008), and these decisions are the responsibility of top management (Schultheis & Sumner, 1995; Turban et al, 2000). This level can be considered as the process of establishing overall goals and of planning how to achieve those goals. Kelly et al (1999) suggested that the strategic level is the premeditated plan for transforming the organisation, enabling it to operate in the new style environment.

Current legacy system evaluation: This includes the existing IT (hardware and software), business processes, organisation structure, and culture. Holland and Light (1999) argue that the nature and scale of problems that are likely to be encountered can be defined by evaluating the existing legacy system (by asking what the status of the enterprise's legacy system is and how it will affect the transition to ERP and common business processes). It is clear that ERP implementation involves a complex transition from legacy information systems and business processes to an integrated IT infrastructure and common business process throughout the organisation (Gibson et al, 1999).

Project vision and objective: It is very important that the organisation has a clear sense of whom and what it is before implementing an ERP project (Davenport, 2000). A global survey showed that an understanding of business objectives and clear vision are key success factors (Cooke & Peterson, 1998). Slevin and Pinto (1987) define project vision as the initial clarity of goals and general direction. Welti (1999) advises on determining the project vision in the planning phase, particularly within the project scope, where the project scope includes the project definition, objectives, and strategy. He argues that all these components of the project scope are compulsory to create a clear project vision. At this stage in the ERP project, the vision should provide a direction and general objective, and no details are required.

ERP implementation strategy: This will be reviewed in this level to determine the impact of ERP system implementation on the enterprise. Trepper (1999) argues that the organisation's executive managers must understand how ERP system implementation will impact on the organisation to ensure a smooth transition. Holland and Light (1999) suggest that the propensity of an organisation for change should influence the choice of ERP implementation project strategy. There are two main technical options to implement an ERP system: modify the ERP system package to suit an organisation's requirements or the implementation of a standard package with minimum deviation from the standard settings. Companies that do not select the second option are liable to face major difficulties (Bancroft et al, 1998; Martin, 1998; Gibson et al, 1999).

Hiring consultants: Due to the complexities of implementing an ERP system, most companies choose to hire consultants to help them select, configure, and implement the system. Welti (1999) argues that the success of a project depends on the capabilities of the consultants, because they have in-depth knowledge of the software. Somers and Nelson (2001) point out those consultants may be involved in different stages of the ERP project implementation. There are hundreds of companies that provide such ERP services. Since it is a critical success factor, it has to be managed and monitored very carefully.

Benchmarking: Al-Mashari and Zairi (2000) argue that benchmarking works essentially at capturing both external and internal best practices related to all aspects of ERP system implementation, and enabling the transfer of knowledge across all levels of project implementation. They argue that benchmarking can play a significant role in shaping the strategic direction to be taken for change introduction using an ERP package.

Tactical level

At the tactical level, also termed managerial level, the medium-term planning of ERP specific organisational issues is largely concerned, where decisions are made by middle managers (Turban et al, 2000). In order to make sure that the enterprise is meeting its targets, objectives of top management are accomplished, and it is not wasting its resources, the tactical level provides middle-level managers with the information they need to monitor the performance of the organisation, control operations, and allocate resources and set policies effectively (Schultheis & Sumner, 1995; Bocij et al, 2008).

Client consultation: Slevin and Pinto (1987) define client consultation as the communication and consultation with, and active listening to all affected parties, mainly the client. It is essential for an organisation to keep its clients aware of its future project to avoid misconception. They also argued that the consultation with clients should occur early in the process; otherwise the chance of subsequent client acceptance will be lowered. In general, this factor has not been thoroughly discussed in the literature reviewed.

Business process change (BPC): As mentioned before, there are two main options to implement ERP systems: modify the package to suit the organisation's requirements, or implementation with minimum deviation from the standard settings (Holland & Light, 1999). Research has shown that even a best application package can meet only 70% of the organisational needs (Melymuka, 1998). Therefore, to take a full advantage of ERP software, business process change is seen as a prerequisite (Holland & Light, 1999; Somers & Nelson, 2001). Davenport (2000) points out that the organisational structure and culture, the behaviours of workers throughout the enterprise, and business strategy, all have to be restructured. To this end, Bingi et al (1999) point out that the need to change the organisation's business processes is seen as one of ERP's major benefits.

ERP software package selection: Selecting new ERP system software is one of the most risky decisions that most companies face. It is inappropriate if the selection of ERP software is being driven by the technology experts rather than by the operational experts in the company (Kuiper, 1998), as companies often fail to consider whether the system they are evaluating can match their overall business strategy (Davenport, 1998), not to mention the system's price tag that could run up into the hundreds of thousands of pounds. Several methodologies and approaches for software selection have been proposed by a number of researchers and practitioners (Kuiper, 1998; Butler, 1999).

Implementation approach: an organisation has to take a fundamental decision regarding the implementation approach, and clearly select a focused path. Welti (1999) cites three main implementation approaches: step-by-step, big bang, and roll-out. With the step-by-step approach, the modules are implemented continuously, while with the big bang approach all modules are simultaneously implemented across an entire company (Koch et al, 1999). The rollout approach, which may be implemented as step-by-step or big bang, creates a model implementation at one site, which is then rolled out to other sites. However, unlike large enterprises, small and medium size enterprises (SME) cannot afford to spend years on a software project. Therefore, vendors and consultants of ERP systems have responded with methods and tactics specifically designed to keep ERP system projects moving. Most enterprises now use a rapid implementation approach, example AcceleratedSAP(ASAP) (Callaway, 1999).

Operation level

Although installing ERP package is not as difficult as getting the enterprise soft elements in line with all the change imperatives, its critical role in yielding optimum outcomes from implementation cannot be over-emphasised (Al-Mashari & Zairi, 2000). For this phase, there are numerous tools used during an ERP package system implementation supported by several ERP package vendors. The following sections will discuss the steps at this level based on the literature review.

Business process modelling: In this step, the project team determines how the system will work, not in the technical sense, but in terms of the processes the company uses to accomplish different tasks, and how the business will operate after the ERP system package is in use (Callaway, 1999). The business process modelling is the complete description of how an enterprise will implement the ERP system package to support its business activities. It is a design document that serves in the next step, configuring the system, as a template for the realisation of the requirements of the enterprise in the ERP system package (Appelrath & Ritter, 2000).

Configuring system: Configuring an ERP system package is largely a matter of making compromises and of balancing the way the enterprise wants to work with the way the ERP package system lets it work (Davenport, 1998). Customisation, also called configuration, refers to the set-up and configuration of all usage options that are possible in an ERP software package to reflect organisational features, and modification refers to changing the ERP software package code to perform unique business processes (Brehm & Markus, 2000; Buck-Emden, 2000).

Final preparation: Before going live on an ERP system, all necessary adjustments, in order to prepare the system and business for production start-up, have to be made. The system must be tested to make sure that it works technically and the business process configurations are practical (Callaway, 1999; Davenport, 2000). At this stage, Welti (1999) suggests that it is important to assess the adequacy of the end user training programme.

Going live: This is the final step of the ERP package implementation; it is also referred to as 'going into production'. It has two major steps: activating the system, and transitioning from the old system to the new system (Callaway, 1999). The project team must accompany the productive operation until a sufficient stability of the ERP package has been completed (Appelrath & Ritter, 2000).

ERP Integration

There is no single software package that can cover all a company's requirements; therefore a company may have to seek other specific software products that are best in meeting its unique requirements (Bingi et al, 1999). In general, an ERP system package seldom stands alone, therefore the integration of an ERP system package from different vendors is one of the most vexing problems companies meet when they implement an ERP system package (Bancroft et al, 1998; Callaway, 1999).

As the literature suggest that implementing ERP is one of the options to of business process reengineering and the ERP implementation methodology by Bocij et al. (2008) have lots similarities with business process reengineering framework. The different steps mentioned in business process engineering framework are further categorised into further three interdependent levels along with the communication and integration as the core practice of this ERP implementation methodology. Further we look at more specific AcceleratedSAP Methodology which is recommended by SAP, one of the biggest ERP vendors, to implement SAP R/3 ERP system.

AcceleratedSAP - SAP R/3 ERP Implementation Methodology

Besides requiring process and organisation change activities, an ERP implementation requires the transformation of a larger number of business processes than in a BPR project. This wider scope justifies firms' decisions to choose a more rigorous, structured planning methodology when implementing ERP systems. Business software companies and integration partners have proposed a number of structured ERP implementation methodologies.

These methodologies differ mostly in terms of the tools used while conducting solution-specific activities. AcceleratedSAP is one of the most popular and well-documented methodologies (Brand 1998). It has proven to be effective when implementing the SAP R/3 ERP solution across industries and in different customer environments (Bancroft et al. 1998).

AcceleratedSAP consists of a methodology, known as the Roadmap, which is linked to the configuration tools in the R/3 System. It supports project managers and business process consultants with a wealth of checklists, spreadsheets, questionnaires, and documentation templates. It also includes guidebooks and special technical accelerators such as a cutover plan for the more technical aspects of SAP Software (mysap.com, 2000).

This approach provides a detailed description of work packages, activities and tasks associated with each phase of ERP implementation. From an academic point of view, the use of this methodology has significant value as it is aligned with industry standards and procedures. It is also associated with the implementation of SAP R/3, for which the underlying concepts are already taught in numerous university curricula.

They are designed to support an enterprise-wide and multiple-site implementation of ERP. Different business units can optimise operations for specific markets, yet all information can be consolidated for enterprise wide views. This category of methodologies supports an enterprise-wide, global implementation strategy that takes geographic, cultural, and time zone differences into account (Siau, 2004).

According to AcceleratedSAP Implementation Methodology Implementation of SAP R/3 ERP System covers the following five phases (see Figure 7) (SAP Help, 2010):

Project Preparation (P1): In this phase you plan your project and lay the foundations for successful implementation. It is at this stage that you make the strategic decisions crucial to your project: Define your project goals and objectives, Clarify the scope of your implementation, Define your project schedule, budget plan, and implementation sequence, Establish the project organisation and relevant committees and assign resources.

Business Blueprint (P2): In this phase you create a blueprint, which documents your enterprise's requirements and establishes how your business processes and organisational structure are to be represented in SAP software. You also refine the original project goals and objectives and revise the overall project schedule in this phase.

Realisation (P3): In this phase, you configure the requirements contained in the Business Blueprint. Baseline configuration (major scope) is followed by final configuration (remaining scope), which can consist of up to four cycles. Other key focal areas of this phase are conducting integration tests and drawing up end user documentation.

Final Preparation (P4): In this phase you complete your preparations, including testing, end user training, system management, and cutover activities. You also need to resolve all open issues in this phase. At this stage you need to ensure that all the prerequisites for your system to go live have been fulfilled.

Go Live & Support (P5): In this phase you move from a pre-production environment to the live system. The most important elements include setting up production support, monitoring system transactions, and optimising overall system performance.

After your system has gone live, you can use a separate Roadmap with six work packages, in order to optimise your R/3 System continuously. These phases are the main milestones for implementing SAP software. Each phase has:

• Work packages, which consist of activities, for which project teams are responsible.
• Activities, which consist of tasks, which are processed by one or more team members.
• Tasks, which are carried out by a project team member. You can also access the How-to sections and accelerators at this level.

AcceleratedSAP has reached a level of maturity and functional richness that it should be considered by every R/3 customer. More than 17,000 SAP or partner consultants have been trained in AcceleratedSAP. Whether consultants follow the entire Roadmap or just use certain accelerators, they save a considerable amount of time and improve the quality and repeatability of your implementation. There is no magic behind AcceleratedSAP but, as Aberdeen Group stated in a study of AcceleratedSAP customers, "No pain...no gain but AcceleratedSAP works" (Aberdeen Group, June 1998).

Another independent study conducted by the Institute of Information Management at the University Of St. Gallen Switzerland (IWI-HSG) investigated in detail several AcceleratedSAP projects in the midsize market. The feedback they received from AcceleratedSAP customers was also extremely positive (mysap.com, 2000).

This Methodology offers a structured set of rules and guidelines that projects can use and also delivers some tools called accelerators that speed up the implementation process. In order to promote the message that SAP can be implemented in shorter times, and in a more efficient manner, SAP developed TeamSAP, which is a commitment from SAP and its service partners to offer them the right kind of professional advice to implement SAP R/3, to guide them through the implementation process, and help them as their business changes. TeamSAP consists of SAP consulting partners, application partners, technology partners, and hardware vendors. AcceleratedSAP is the roadmap that TeamSAP uses to provide quick and predictable implementation options, with a typical implementation time between 6-9 months. Some large implementations, whose business complexity does not permit such implementation time frames could still capitalise on the AcceleratedSAP guidelines and shorten their implementation times (SAP Whitepaper, 2002).

Some implementation partners of SAP have developed their own versions of AcceleratedSAP, which are essentially variations or add-ons to the AcceleratedSAP guidelines, following the information gathered from years of SAP consulting and implementation experience. AcceleratedSAP contains three basic components.

First, the AcceleratedSAP Roadmap, which defines different phases of the implementation process supported by a project plan that splits the activities in each phase into discrete units of work. Second, AcceleratedSAP delivers a comprehensive set of Windows-based and R/3 resident tools that maybe used during the implementation process. Third, AcceleratedSAP offers a hotline service to its customers, in addition to the Online service system (OSS) connection that offer users post-sales support and this can be used by service partners on behalf of the users (Clients) (Ghosh, 1999). AcceleratedSAP also offers the methods of Information and knowledge transfer by providing the InfoDb or the information database, the SAPNet or the SAP Web site and a quality-check Audit process to ensure that AcceleratedSAP guidelines are indeed being followed in the implementation project.

The AcceleratedSAP methodology clearly shows some similarities with Kettinger et al.'s (1997), Davenport and Short (1998) and Bocij et al.'s (2008) framework, as all approaches initiate the transformation process with a strategic positioning exercise followed by the examination of current business processes. Similarly, mostly all approaches end with ongoing support and performance monitoring activities. On the other hand, the AcceleratedSAP methodology does not include, prior to configuration, specific activities to evaluate future processes.

The proposed framework presented in Figure 8 was constructed by aligning the AcceleratedSAP methodology with Kettinger et al.'s (1997) framework. This alignment was made possible by grouping similar activities in the two methodologies into four main phases: Project Preparation, Evaluation, Implementation, and Continuous Improvement. This shows the concurrent execution of BPR and ERP implementation activities within the entire frameworks discussed above.

In this alignment Envision and initiate comes under project preparation, business blueprint is same as diagnose and redesign, realisation and final preparation is reconstruct and evaluate we implement the process and make improvement just as we do that in go-live and support. Apart from comparing with Kettinger et al.'s framework, if we look at the Bocij et al's (2008) framework of ERP system project implementation and align it with AcceleratedSAP methodology, we can notice that AcceleratedSAP does not contain Strategic level and some part of Tactical level. But its Project preparation phase can be aligned with Tactical level of the Bocij et al's (2008) framework and rest of the phase of AcceleratedSAP Methodology with Operational level of the Bocij et al's (2008) framework.

"Large Groups of people are smarter than an elite few, no matter how brilliant - better at solving problems, fostering innovation, coming to wise decisions, even predicting the future" (Surowiecki, 2005). Surowiecki's (2005) highlights the potential of a new paradigm: Open Innovations. Traditionally, research and development departments are the main drivers of a company's innovations. Now, the tendency to open up to other resources of innovations becomes more and more important, e.g., employees, suppliers or universities.

SAP was already using this technique as they mentioned in their white paper (2005), stating "We would prefer to do everything ourselves. It's the best way to make sure your know-how stays under your own roof. Yet we seem to have external experts coming and going, just about all the time. Fact is, we don't have enough manpower, and neither can we be expected to know everything about everything".

SAP is not an expert in all aspects of every sector of industry. SAP is primarily an ERP System provider, not an organisational consultant. Therefore they work together with partners that specialise in specific industrial sectors and disciplines. Partners with an in-depth understanding of the business processes, customs and 'best practices' in specific markets, Partners who are able to support SAP continually in improving its software, by providing detailed reports on experiences gained with previous implementations. In this way a fine meshed picture emerges of the most specific needs and issues in a certain market, and a wealth of know-how and experience is created in the process (SAP white paper, 2002) this also aligns with the Ahmed (1999) argument of having "knowledge workers" discussed above in this chapter.

The Service Partner focuses on strategic consultancy, implementation, system integration, and the continual improvement of the SAP user's business processes. They operate at various levels, acting as boardroom advisers and project managers, functional specialists and ABAP programmers. In the UK there are more than twenty-five active SAP Service Partners (SAP UK, 2010). This number is sufficient to cater for the needs in key areas of specialisation, and to adequately fulfil the demand for capacity.

SAP selects its partners on the quality of their staff. How well are they trained, How much experience have they had with SAP projects, How do SAP customers perceive their performance, the annual customer satisfaction survey is an important aspect of the assessment. The partner must score well in these surveys. After all, it's the quality of the performance they deliver to SAP customers that proves what they're worth.

However, it is not strictly necessary that two different parties should be engaged in the exploration phase and the implementation phase. The essence is that project objectives and requirements are carefully analysed before starting with the actual implementation. Often the customer will have formulated technical objectives (functionality, reporting, etc.), but will not have indicated any strategic objectives, e.g. stocks reduction, profit and sales. It is important that the objectives and means of attaining them are described as accurately as possible. SAP offers a framework that can be consulted in each phase of the SAP project. This so-called Solution Map enables the mapping of processes that are typical for a certain company, and the SAP approach to handling those processes. Depending on the chosen implementation method the solution is then further developed. The framework even enables the evaluation of an operational SAP environment, and, in the process, exposing possible areas of contention or improvement. In addition, it has descriptions of a number of 'best practices', with a host of valuable practical advice for defining the required functionality (SAP whitepaper, 2002).

The AcceleratedSAP methodology provides very detailed guidelines for each phase of the project. The method uses roadmaps to describe which activities must be carried out, and when. It ensures, for instance, that a training plan is prepared in the correct stage of the project. And that the end users who must test the system are properly prepared. Central in this is the question and answer database, which collects essential process information and provides the blueprint for the project. The blueprint is directional in allocating roles within the project, setting tasks, and ensuring effective and efficient use of human resources.

Not all partners but most would choose to use the above AcceleratedSAP methodology. Likewise, not all AcceleratedSAP tools would be equally effective in every project. However, the AcceleratedSAP method is available to everyone, and all tools are conveniently supplied on a CD-ROM. Other methods are usually not SAP-specific, and often depend on the approach of the consulting agency. In the latter case, the SAP user's partner choice will be limited due to the lack of specific know-how and user rights (SAP White Paper, 2002).

In that sense, it has become clear through the literature review that if we look at various methodologies (Figure 9) from Information Systems development to Business process reengineering and then further towards ERP implementation methodology they have similarities. These all methodologies, discussed in this chapter, are commonly applied in the industry and are developed by widely held academic gurus in the field of Information system, business process reengineering and ERP's. There after we discussed AcceleratedSAP is one of the SAP R/3 ERP methodologies, which is supported by all these methodology and also been recommended by SAP itself to be used as the road map to implement their ERP system. But the literature entrench the integration of customers and service partners as one of the biggest resources for external innovations (Gassmann and Enkel, 2006; Wagner and Prasarnphanich, 2007) and Not all service partners choose to use the above AcceleratedSAP method. Likewise, not all AcceleratedSAP tools would be equally effective in every project. Which creates the gap and scope to do the research as mentioned in the subject. Although the Customer integration is a mode of value creation in which customers take part in both operational and innovation value creating activities, which used to be seen as the domain of the firm (Tseng and Piller, 2003; Piller and Walcher, 2006; Reichwald and Piller, 2006). The open innovation should use some standard Methods to improve on the implementation and stay as innovative as we have seen the standard methodology is very important for the implementation of ERP with low cost involved.

Consequently this study leads us to the lack of evidence about the application of AcceleratedSAP while implementing SAP and develops the key research questions that are the focus of this study are:

• To what extent different companies follow AcceleratedSAP as methodology when implementing SAP?
• Is different companies use different innovative ways to improve the process? Are there commonalities or diversion in this innovation?

Chapter 3

Research Methodology

This chapter should give the reader detailed and sufficient information in order to make an estimate of the reliability and validity of the methods used. I will explain and justify the choice of methodology approaches that I have adopted in order to answer the research question.

"Methodological insight gives an audience a better understanding of previously conducted research and how to proceed in future." (Gammelgaard, 2004, p. 480)

Research methods can be classified in different ways, the choice of approach affects the way the researcher is collecting data. The most comment distinction is between the quantitative and the qualitative approaches (Myers, 2007). Quantitative approaches were originally used while studying natural sciences like: laboratory experiments, survey methods and numerical methods. A qualitative study is used when the researcher wants to get a deeper understanding on a specific topic or situation. Myers (2007) states that the qualitative approach was developed in social sciences in order to support the researcher in studies including cultural and social phenomena. Sources included in the qualitative approach are interviews, questionnaires, observations, documents and the researcher's impression and reactions.

The chosen approach is qualitative and the motivation of the chosen approach will be discussed in the chapter below.

Qualitative Research Method

According to Yin (2008), the purpose of an academic study can be exploratory, descriptive, or explanatory.

Exploratory studies are practical if you wish to clarify your understanding of a problem (Saunders, Lewis & Thomhill, 2009). They also describe exploratory studies as a method of finding out "what is happening; to seek new insights; to ask questions and access phenomena in a new light."

Descriptive studies are appropriate when you wish to portray phenomenon such as event, situation or process. Furthermore, a descriptive is also appropriate when problem is clearly structured, but intention is not to conduct research about the connections between cause and symptoms.

Explanatory studies are useful when you wish to establish causal relationship between variables. The emphasis is this sort of study is to examine a situation or a problem in order to explain the relationship between variables (Saunders, Lewis & Thomhill, 2009).

Since the purpose of this study is to explore the application of ERP implementation methodology framework by different vendors when implementing ERP and to find commonalities or diversion in the ways of improvement by them so I am following explanatory because sometimes it examines a situation or a problem in order to explain the relationship between variables. The study is based on a qualitative theoretical research and the empirical finding consists of interviews performed in a qualitative way, this will be discussed further in the following chapters.

Collection of Data

Primary data: Collection cannot be a discreet step in the research process, particularly in the qualitative research, which requires prolonged investigation in the field. This being the case managing the interaction between the researcher and the data sources is vital issue (Thiétart, 2001). Primary data consists of interviews, observations, questionnaires and experiments (Arbnor & Bjerke, 1999). Throughout this study have observations and interviews been used to gather data.

Interviews

According to Yin (2008) no source of information is better than others. An interview is a purposeful discussion between two or more people. The interviews can help you to gather valid and reliable data that are relevant to your research questions and objectives (Saunders, Lewis & Thomhill, 2009). There are a number of different ways to execute an interview. By using a structured interview all questions are decided in advance. A semi structure interview has a decided subject but the questions are formulated during the interview. By using an unstructured interview the interview become more as a conversation between the interviewees and the interviewer. The interviews can be executed toward one person or a group.

Since we are looking answers to our research about the application of methodology in various organisations while implementation SAP R/3 ERP, which is based on particularly in the qualitative research. I have conducted eight semi-structured and in-depth (unstructured) interviews that provide me the opportunity to probe consultants, which include Vendor and Service partner both, and the client. Give them opportunity to explain their response. This gives interviewee the chance to use their words and idea in particular way to respond their experience in the implementation.

It was vital that the collected information was right and trustworthy so that a reliable thesis could be carried out and gives me the honest and impartial view of the interviewee. Therefore I have conducted one on one interview with six SAP R/3 consultants and one core team members from the client side. I have also conducted one group interview with three consultants simultaneously. All the interviews are taken through telephonic or internet-mediated modes and those interviews were recorded to ensure that your responses are documented accurately. This research methodology helped us get more innovative research data as interview has given chance to put their idea openly. It also led us to an area that is not considered in literature but which is significant to our understanding.

Observation

Observations can be executed in different ways. The observer can either participate in the researched activity or observe by watching from distance. The observation can be planned or can take place without the observed knows about it.

Two form of observation can be distinguished, in relation to the viewpoint the researcher takes towards the subject being observed (Jorgensen, 1989; Patton, 2002). The researcher may adopt either an internal viewpoint, using an approach based on participant observation, or an external viewpoint, by conducting non-participant observation. Between the two extremes, the researcher can also opt for intermediate solution.

This report have also used 5 samples of SAP implementation project data of the companies around the world to support our analysis, from Australia, Belgium, Germany and China respectively (mysap.com, 2002) (for details refer table 3). Which help author to support the literature and primary research findings by playing no participant observant role.

The secondary data: consists of various documentations. It is essential to use secondary data in order to get a wider sight. For a researcher it is important to see what other researcher has done and their results within the research field (Arbnor & Bjerke, 1999).

Literature Study

A literature study consists of researches from books, brochures or magazines. The literature study was based on the purpose of this report, which was to explore the application of ERP implementation methodology framework and its alignment with other popular theories and frameworks. To fulfil this purpose, I needed to find some background information about Business Process Reengineering implementing framework, ERP systems methodologies in general and also specific to SAP R/3. The benefit of making an extensive literature study is to find out what the theory claims about the topics in focus.

Choice of Theories

Throughout this study extensive literature study has been executed information system, Business process reengineering and ERP's. Basically ERP is one of the options for Business Process Reengineering so we have pick up the work of Kettinger et al (1997), A Staged Activity Framework for Business Process Reengineering, which is and popular among the implementation of Business Process Reengineering and then compared it with another Business Process Reengineering framework discussed by Davenport and Short (1998). Thereafter we moved more towards the specific topic and discussed one of the popular Generic ERP Implementation Framework by Bocij et al, 2008.

Subsequently, we have thoroughly described the theory of AcceleratedSAP, which is related to the topic of our research and compared them with former theories. Finally I discussed it application by the vendor along with the practice of open innovation and identified the gap which leads to our research question.

Besides these sources described above additional research has been carried out to verify or show differences about the collected information, which affects the reports validity.

Choice of ERP Product for research: SAP

Competition in the ERP software industry is very strong, with over 500 software producers fighting for their market share. Producers can be divided into two groups: (1) companies that offer an integrated suite of applications and (2) those that make innovative niche products and solutions for supply change management, customer relationship management, advanced demand planning software (APS) and e-business applications.

The major players in the first group are SAP AG, Oracle, PeopleSoft and J.D. Edwards (both companies PeopleSoft and J.D. Edwards were purchased by Oracle) While the second group consists of several leaders like Siebel Systems and Ariba. Table 4 provides a breakdown by company of ERP Vendors ranked by 2004 revenue, market share and estimated growth. (For more detailed ERP supplier comparison see appendix 1).

SAP is German based ERP vendor, Pioneered and leader in Enterprise Resource Planning packages, the largest installed base enterprise software. Its transparent and long term stra