Enterprise Resource Planning Systems

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 (ThiA©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 strategy is a factor that is crucial for it market dominance. The company specialises in providing enterprise resource planning packages to six industry sectors: process, discrete, consumer, service, financial services and public services. SAP offers the most advanced Service Oriented Architecture (SOA) based product that is first in enterprise resource planning solution in the market with one of the greatest innovation power (SAP Global, 2010). SAP is ranked the number one in all three enterprise software markets: enterprise resource planning (ERP), customer relationship management (CRM) and supply chain management (SCM). Strong market position enhances the company's brand image.

The table 1 shows SAP R/3 ERP is the largest installed ERP systems in the world (40%) and very popular ERP vendor among the most research. Therefore, the study is based on SAP R/3 as Enterprise Resource Planning product chosen for this dissertation.

Validity and Reliability

Validity, reliability and objectivity are three measurements connected to the quality of the study. The reliability is defined as the level of trustworthy in the measurement, like if the researcher should get the same result if the study were repeated. Validity and reliability have to be considered to reduce the risk of obtaining incorrect answers to research questions (Chisnall, 2005).

The validity throughout the study is increased by use of different reliable sources. By gathering information from different books, articles, Internet and interviews and do a comparison between findings from the sources a valid report could be carried out. The study's reliability is frequently high. Interviewing different persons at the department and asking the same or similar questions and reviewing the result could hold a good level of reliability.

hapter 4

Research Analysis

In this chapter acquired data will be presented and analysed with reference to the literature review discussed to find the answers to the research questions.

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 (SAP white paper, 2002). These partners are selected by SAP on consultant quality at par with the required quality qualifications standards. These partners' implements SAP in different industries for their client. This leads to the key research questions:

• 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?

AcceleratedSAP methodology Application

The literature review demonstrates the practice of implementation methodology irrespective of whether it is Information system development or Business process reengineering. SAP ERP is no different from the above mentioned Systems; all eight interview samples (six consultants, one Consultants Group and one Core user) unanimously replied that they use implementation methodology for implementing SAP. Even when referred the implementation project data sample from mysap.com (2002), entire 5 samples displays use of some methodology. All the interview and previous implementation data samples give us the indication that methodology is very important for any implementation and this also validates the construction of our theoretical framework to demonstrate the literature review about the various implementation methodologies.

Though above finding give us the indication about the use of methodology when implementing SAP R/3. They does not justifies the hypothesis that AcceleratedSAP is one of the most popular and well-documented methodologies used and it has proven to be effective when implementing the SAP R/3 ERP solution across industries and in different customer environments, which could be the answer to our first research question.

One consultant from the UK (7th January, 2010) said "Basically we have been using the AcceleratedSAP methodology as one of the best practices as SAP says. Following the roadmap and even the blueprint and then the realisation phase, all as per AcceleratedSAP methodology." This methodology contributes to successful implementation because, she continues, "you have the road map in front of you and you have your milestones map and you know what stage comes next and clients is prepared as well as you are prepared and you know where you heading to (7th January, 2010)." This specifies the use of AcceleratedSAP methodology in her organisation and she also accepted that the methodology contributes to the successful implementation of SAP by providing the awareness to not only consultants but also clients who are new to the implementation but also have the procedural knowledge of the organisation.

Another SAP Senior Consultant in US (4th January, 2010) said "most of the places that I have implemented we normally use the AcceleratedSAP Methodology, so that's what we use everywhere mostly." He also confirms in this statement that generally AcceleratedSAP is used to implement SAP but he also commented that for every client it is little different the way the methodology is used but overall it fits the category of AcceleratedSAP. On asking what ways the application of methodology is different, he replied, "basically it depends on how customer want it is more of the customer oriented methodology (4th January, 2010)." Further asking him if AcceleratedSAP methodology contributes to successful implementation he replied that "yes it does, it is good methodology (4th January, 2010)" he also said that they used this methodology in his organisation for the all the implementations they does for various clients, "so it is well known and good methodology is to be used for SAP implementation unless it's like, I mean if it is fresh implementation then AcceleratedSAP is good but if it is SAP upgrade or SAP support project then we have to use totally different methodology."

One of the consultants who worked in global SAP implementation projects by three different SAP consulting organisations said, "Methodology is not a personal call, I mean which just depends on a consultant or a team lead, it is dependent on the organisation you are working for (19th December, 2009)." He continued referring all different and well known organisations he worked for, "it depends on organisation which methodology they are following in the particular project, we mainly follow AcceleratedSAP methodology only, that is mainly, sometimes what happens in a project is apart from AcceleratedSAP methodology organisation's own steps or two in between the AcceleratedSAP methodology but primary focus is related to AcceleratedSAP only (19th December, 2009)."

In Additional to this I asked him that how different was the approach of the different company, he replied, "difference is only towards the approach, the goal every company has is the project should be successful, that is every company hopes for, they adopt different approaches depending on the individual meetings at senior management level and everything. Difference where it comes is for example in the current project we have been following AcceleratedSAP only but plus we have introduces our own step in the end, i.e. after realisation once the project goes live at that particular time my current organisation introduced a step of its own. That's a good step actually, I noticed it for the first time that this step is also required (19th December, 2009)."

When asked the same question about the use of methodology to the group of consultants who are working with one of the well-known France based consulting company they replied unanimously, "yes, we followed AcceleratedSAP, it not exactly AcceleratedSAP, it our organisation proprietary tool which is more similar to AcceleratedSAP and which we have actually rectified the gaps, in all it's a unified version of AcceleratedSAP (12th January 2010)."

Likewise if the implementation project data samples are observed, Acacia Resources Limited used RapidPath, implemented by the PriceWaterhouseCooper, 'Powered by AcceleratedSAP' approach because it offered the shortest interruption to the business a six month long implementation. The company decided to analyse the existing R/3 functionality and modify its business practices to SAP R/3 functionality. The benefits of RapidPath include a structured approach that adheres to AcceleratedSAP principles and provides the controls required for successful implementation.

Another client, Sumitomo Chemical selected Deloitte Consulting/ICS because the consulting company has a strong global presence and a very cost effective implementation solution. ICS successfully incorporated predefined SAP accelerators into its Fast Track methodology 'Powered by AcceleratedSAP' and is therefore certified worldwide. Using this methodology Sumitomo Chemical Belgium implemented R/3 in less than 4 months.

Third sample, Siemens is responsible for global implementation at UM Zinc Chemicals, the methodology provided by Siemens was live & go, which is preconfigured R/3 System for small and midsize companies in Belgium and Luxembourg. The methodology which is 'Powered by AcceleratedSAP', and help the team to concentrated on what was necessary to replace the existing solutions of UM Zinc Chemicals and to progress in a controlled manner. Other two samples in implementation data at Legend QDI Ltd, China and GA¼nther+Schramm GmbH & Co. KG, Germany were implemented by SAP's implementation partners, SAP China with Deloitte Consulting/ICS and ATOS respectively but both used AcceleratedSAP as the implementation methodology.

If we reflect back to the literature review compares all our research findings with it. As per literature review AcceleratedSAP methodology consists of a known as the Roadmap, which is linked to the configuration tools in the R/3 System. It supports project managers and business process consultants and clients with a wealth of checklists, documentation template and milestones of various phase of implementation project. This was supported by the research and findings where majority say that they are using AcceleratedSAP or their company patient methodology, which is powered by AcceleratedSAP or unified modal of AcceleratedSAP.

There was only one exception in this finding were one of the Principal and practice leader for SAP HCM Practice with more than 20 years of experience said, "within our organisation we have our own methodology, and that is our 'DeliverSAP' Methodology. Which is in line with a systems development methodology that has been tailored to a package enabled solution. So instead of having all the system development, instead of having their capabilities you have configuration effort. Further there system analysis system methodology but we have gather your requirement we do system development and then we deliver it (2nd January 2010)." This gives us little different picture of what has been presented before in our finding as most of them were having AcceleratedSAP as a base framework but the literature review and the theoretical framework supports this statement that AcceleratedSAP is in line with the Information System Development Waterfall model by Kruchten (2004). Concurrently, literature also a show the implementation of an ERP system is radically different from traditional systems development and that is the reason interviewee have mentioned about having their capabilities of configuration effort instead of traditional development effort. Therefore we can draw an conjecture with this discussion that interviewee discussion about the 'DeliverSAP' methodology is in line with methodology mentioned in the literature review.

He also has difference of opinion when majority of sample also agrees that these methodologies contribute to successful implementation. He argues, "Any methodology will not contribute to a successful implementation. It would not be reason why it is successful. The methodology provides structure; it is the people that make the implementation successful. The level of the timing level, the commitment of the project team, the interaction, the contribution of the customer is the one thing that makes the project successful. Methodology is just the vehicle which you have to drive to get there (2nd January, 2010)."

He also mentions, "AcceleratedSAP is a cookbook, if you look at the cookbook there is lot of dishes lot product you can do with a cookbook. The problem with the methodology is you follow every step you never finish a delivery. You should be smart enough to know which steps you have to execute and which step you do not have to execute depending on the business means depending on the functions that you are delivering (2nd January, 2010)."

These statements give more practical opinion about an implementation process because When placing the same argument in front of another senior consultant, he replied, "for a person who is starting off this is definitely a guideline but for a person who is been in the industry for a good amount of time, I guess, his entire skill are being streamline in such a way that invariably he end up following the methodology. However if you are a fresher or novice then it is recommended and it is the best practice that u follow the process and it will help in streamlining the entire process (7th January 2010)."

That is the reason it is contrary from the majority of sample who agree that these methodologies contributes to successful implementation but this also gives indications that it is successful just as a road map which guides consultants and client to have structured approach to implement. Nevertheless consultants need to be smart enough to know what have to be executed next depending on the business means depending on the functions that needs to be delivered depending on the client's requirement and also duration of delivery.

Simultaneously, it has been supported by the findings above, where most of the consultants in an interview had stated that the application of this methodology is not same and it is differs from project to project depending on the client's needs. In the literature review it has also been indicates by Hammer (1990) that the application may not be same and cannot be planned during BPR and therefore it need to performed in short steps and the wealth of know-how and experience and also Ahmed's point to developing "knowledge-workers" that can quickly understand and work with redesigned processes.

Therefore, the findings from the research and their analysis with support of the literature give us an answer to our first research question that AcceleratedSAP is most commonly used by different companies while implementing SAP. These companies are either directly using AcceleratedSAP methodology or their patent methodologies which are powered by AcceleratedSAP. But the application of this methodology while implementing may vary depending on the client's requirement and project duration.

Improvement in AcceleratedSAP

The responses to the first research question enhance the essence of second research question to know more about different innovative ways applied by different companies to improve the implementation process and are there commonalities or diversion in this innovation, since the above research analysis demonstrated that AcceleratedSAP methodology is most used but there are some differences in the application of methodology during the project. Now this can be one of the reasons for innovative changes or there might be another reason where organisation find need of improvement and therefore apply some changes. This is the hypothesis which needs to be researched in this section and then referred with the literature to look for the answer to the research question.

When asked if consultants want to make any changes to the methodology one of the senior consultant replied, "It is an accepted approach that up till business blueprint phase is AcceleratedSAP is followed. However when we move on to the unit testing, the integration testing and go-live phase depending on the work pressure and kind of time lines you have they might skip certain process or they might have couple of process being run in parallel. This might be based on the factors that how well the project is going and how tight the time lines are (7th January 2010)." So he suggested that till blueprint there can't be any changes but as we discussed above that after blueprint it depends upon the project status and this may lead to make few changes. This theory also goes with our literature review and discussion in our findings of first research questions where application of methodology is based on requirement.

Further he also stated, "I guess there can be couple of things I think you can do to improve the entire process lifecycle of the implementation. The one is, it is better you spend more time in understanding the existing process of you client or the concerned company where the implementation need to be done. Second thing is you need to figure out first whether what you implementing is what the customer wants. It is very important that you spend enough time in as-is and to-be phase so that the alignment of the process is done to what you have in SAP. Second thing is whatever discussion you have with customer; you need to make them understand that you accept SAP as and the SAP as best practice that are available in the industry. If you go and deviate a lot from the standard SAP practice it's going to increase the project time, it's going to increase the complexity and eventually the efficiency of the entire process would not be as good as it had been. So spending time on customer requirement and then making customer realise that accepting standard SAP processes would be much better way of going about the entire implementation. This I would suggest each company should do. (7th January 2010)."

Here he mentions the importance of blueprint phase which according to the literature suggest that this is the documentation phase where your enterprise's requirements is documented and establishes how your business processes and organisational structure are to be represented in SAP software. This is also called documentation of AS-IS and TO-BE. According this consultant this phase is the cornerstone of this methodology and ample amount of time should be given to this phase so that future dependent phases are executed smoothly and can also be modified according to the further situation and status of the project.

Simultaneously same response came from most consultants who want to improve the methodology, one of our consultant working in the UK said, "yes there is definitely some scope of improvement, there are some places where too much documentation to be done, that can be cut down and it can be made more process oriented so it covers most process, may be not too much of improvement but yes some minor point can be improved (7th January, 2010)." Mostly the documentation is done in Blueprint phase and is mention to be one of the corner stone of the implementation project by the consultants above, so it was confirmed if blueprint should be reduces, on that query, she replied, "blueprint forms the basis of the project, all the requirement are gathers properly in the blueprint phase, if the requirement is not properly captured and process is not mapped properly from AS-IS to TO-BE then there will be lot of implications on the project and it will affect the project deadline. (7th January, 2010)." She also stated that blueprint is important but that extra effort to document unnecessary documentation is something to be avoided. This was further confirmed how this can be done, she replied, "SAP has provided template to fill the documentation so one needs to follow just one standard SAP template that solves the purpose instead using different template for every client to client and company to company. (7th January, 2010)."

One another consultant gave us the live example where he has to join project in the mid of implementation and he noticed that the blueprint document was not up to date and lots of information was missing so he has to personally sat with the client to update and do kind of redo the blueprint phase, which was really hard job to do and effected the schedule. One of the consultants in US also mentioned the importance of blueprint in implementation.

When referred back to the literature and look at AcceleratedSAP and other implementation methodologies mentioned, all these theory shows the importance of blueprint phase or requirement gathering or diagnosed phase in various methodologies mentioned in the literature. Therefore this discussion doesn't give us any improvement in methodology but give us precautionary importance of the phase which should be well applied and documented in the implementation. One of the consultant also stated, "I would think that entire methodology is perfect in its nature. I would suggest that what you can do is involve the process level users who are actually running the legacy system before the business blueprint is finished. Because they know what are the real time issues they have faced or they are facing in the current legacy system. What would happen is eventually this would help us to plug those loop hole in the system we are configuring, normally this is not done because the interaction is at management level, those are not actual people who are using the system but these are those people who make strategic decisions but they do not know the ground level difficulties that are being faced by the people who are actually using the system. I think there involvement before the business blueprint is finished would be helpful (7th January 2010)."

This statement not only shows the importance of blueprint phase but also tell us specific core user involvement in this phase which can be our second finding for this research question. This finding gives us logical reasoning that process level user involvement would give consultants the tacit knowledge which helps them map system more accurately. This should certainly help the system run more smoothly and was also supported by Ahmed (1999) point which shows 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.

Ahmed's work also lead us to the third finding for this research question where client plays the important role and they need to quickly understand the new system and for that they need to be given proper training before they can test the system. In support of this argument one of our consultant said, "we have introduces our own step in the end, i.e. after realisation once the project goes live at that particular time my current organisation introduced a step of its own. That's a good step actually; I noticed it for the first time that this step is also required. It's a kind of a hand shake, it's a kind of extended support and client feels that he is comfortable using SAP and they will be using it whole and solely for business. This makes client comfortable and this is actually a good step according to me (19th December, 2009)." Another consultant from the UK also supported the argument by adding "after realisation phase, when user does testing the training is not being talked about. How would you expect User to conduct the test when he is not trained? So the training should fall before the testing phase. So that user is prepared to conduct the test when the build is ready. Now what happen is, it is the hand help kind of practice which we help the client to do because they don't know the system and they are scared of the system and they don't know what they will touch and where they will break the system. So the training should be one aspect of methodology but it si not discussed anywhere (7th January 2010)."

As per literature review in the Kettinger et al.'s (1997) framework model, user training phase come between implementation and evaluation of the process. So user is trained before they evaluated the process but in AcceleratedSAP methodology the User training phase is a part of final preparation phase and it comes after user testing phase. So the involvement of client is important to make them comfortable on the system. Therefore this research analysis shows the gap in the methodology practices as stated by both the consultants above. They suggest that training should be performed just after realisation and before user testing so that user is comfortable on the system while testing the scenarios but also tests them accurately. This will also make project functionally more smooth and under budget.

The fourth and last finding to this research question is also discussed by our consultants above, where they argue the use of standard SAP functionalities and templates, which is also recommended by SAP and supports the literature that the these are tried and tested functionalities and templates and if implemented they will reduce the effort and time and implementation will be more smooth. Nevertheless developing totally new functionality requires more efforts as in terms of development and testing and also requires more consultant involvement during post go-live support.

The research analysis and findings in this section as suggested by the consultants and further supported by the literature, give us four different innovative and practical ways which either improve the AcceleratedSAP Methodology or make the implementation process more smother. These four ways are

• In the blueprint phase the AS-IS and TO-BE should be well documented and properly mapped.
• Involvement of process level user during the blueprint phase to map system more accurately by using their practical and tacit knowledge.
• User training to be conducted before testing instead of after testing phase to make user more comfortable during the testing phase and to get better testing results.
• Use of standard functionalities and templates gives us more smooth and quick implementation.

These suggestions came from different consultants and give the ideas that these improvements are mostly common among the different organisations best practices.

There were also few exceptions in this research as when interviewed the group they replied that they were quite satisfied with the methodology and did not wanted to challenge the tried and tested methodology but they wanted to build more improved and common practices templates called global templates. These templates are improved version of standard template and were built upon the vast experience by the companies consulting for long time.

Emergent Finding

The above argument proceeds to the hypotheses that use of this methodology helps prepare any knowledge management or knowledgebase to get more projects or get into more market.

One of the consultants supported this argument by saying, "Yes we have a knowledge repository where in you have such matter expert who are people spent lot of time in the industry, there is also knowledge base which hold uploaded data from previous projects and it can be used. But these things are confidential and only used within our organisation (7th January)."

Another consultant added to this argument by saying that his organisation has the knowledge base which has been prepared by following these methodology templates. And this has helped them develop Best practice products for Petroleum and defence industry in partnership with SAP. In turn this helps them get more industry specific client. One more consultant echoed that same by saying that this methodology helps them reuse the functionalities and this in turn save time and effort. When discussed with the group they most of the time mostly talked about improvising the standard and generation of the global template, which can be used and implemented with minute customising as these templates are more generic templates which intern saves time and efforts.

This is most common practice among the SAP implementing partners who develop their knowledge base to use their experience in industry for long time. They collect all this knowledge from various project and creates the common practice functionalities or templates which can be reused and help them get into different market or bid for more projects successfully. This was also discussed in the literature that SAP is not an expert in all aspects of every sector of industry. 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.

Chapter 5

Conclusion

The conclusion is the last part of this dissertation. It consists of reflections of the result from the literature review and research analysis.

The purpose of the study 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. In order to fulfil this purpose two research question were supposed to be answered, To what extent different companies follow AcceleratedSAP as methodology when implementing SAP and Is different companies use different innovative ways to improve the process, are there commonalities or diversion in this innovation. To do this research, literature was discussed in detail and was compared with the qualitative primary research findings.

Literature review presented the theoretical framework of implementation methodology, starting with the discussion of Information System development Classic Waterfall model which represents the "traditional" software lifecycle, and outlines an Information System project in clearly defined, partitioned phases that follow in sequential order. This model alone is clearly unsuitable to the ERP implemention project as completion in a timely fashion is a key objective, and with this extra constraint risks will be extremely high.

So next topic was more specific Business Process Reengineering Implementing Methodologies, one of the approaches of information system development Kettinger et al.'s (1997) framework comprises six stages, each containing the following activities was initially discussed in in this section and then it was compared with a seven-step methodology in IT driven business process reengineering implementation by Davenport and Short, 1998, as choice of methodology depends on project specification.

Since ERP is one of the options of business process reengineering, a generic framework of Enterprise Resource Planning Implementation methodology was discussed in detail where all aspects of the implementation were discussed on strategic, tactical and operation level and the importance of communication in all level and also integration of all level were discussed. Being the market leader in ERP product market SAP was chosen as the research product. Therefore, all these methodologies were compared with the well explained AcceleratedSAP Methodology used to implement SAP R/3 ERP System and the similarities and diversion were discussed between all above methodologies and the AcceleratedSAP methodology, which was used as my theoretical base.

The research conducted was based on qualitative one on one interview with six SAP R/3 consultants and one core team members from the client side. One group interview with simultaneously three consultants was also conducted. Because this research methodology helped us get more innovative research data as interview has given chance to put their idea openly. This also led to an area that is not considered in literature but which is significant to our understanding. 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. Which help author to support the literature and primary research findings by playing no participant observant role.

In the next chapter the research data from interview and observation was analysed and compared with the other research finding as well as literature not only gives us the indication about the use of Methodology when implementing SAP R/3 ERP system but also concurred that AcceleratedSAP is most commonly used by different companies while implementing SAP. These companies are either directly using AcceleratedSAP methodology or their patent methodologies which are powered by AcceleratedSAP. But the application of this methodology may vary depending on the client's requirement and project duration.

Further research analysis gave us four different innovative and practical ways which either improves the AcceleratedSAP Methodology or make the implementation process more smother. These four ways are:

• In the blueprint phase the AS-IS and TO-BE is well documented and properly mapped.
• Involvement of process level user to provide us tacit knowledge during the blueprint phase to map system more accurately
• User testing to be conducted before testing instead of after testing phase to make user more comfortable during the testing phase and to get better testing results.
• Use of standard functionalities and templates gives us more smooth and quick implementation.

This suggestion came from different consultants and provided us the ideas that these improvements were mostly common among the different organisations best practices.

We concluded this report with emergent finding that most of the SAP implementing partners has common practice and skill set to develop their knowledge base to use their experience in industry for long time because of more structured implementation approach with help of AcceleratedSAP methodology. They can collect all this knowledge from various projects and creates the common practice functionalities or templates which can be reused to save time and effort. This also helps them get into different market or bid for more projects successfully by using this knowledge.

Cite this page