ERP A ROUTE TOWARD SUCCESSFUL IMPLEMENTATION

(1)

The candidate confirms that the work submitted is their own and the appropriate credit has been given where reference has been made to the work of others.

I understand that failure to attribute material which is obtained from another source may be considered as plagiarism.

ERP – A R

OUTE

T

OWARD

S

UCCESSFUL

I

MPLEMENTATION

Sabrina Mary Ming-Ling Tsung BSc. (Hons) Information Systems with

Management Studies Session 2003/2004

(2)

Summary

“…failed ERP implementations are still far too common. Last year the Globe and Mail reported the failure rate at 66 percent.” – (Carlo, M., 2004)

This project will track the stages taken for the development of a framework for the successful implementation of ERP systems. Enterprise Resource Planning (ERP) is an extremely current issue that constantly requires further research as improvements to the field are being made continually. This report examines what ERP Systems are and why businesses are choosing to implement them. Reasons for why ERP fails and how it can be made successful have been investigated. This leads on to a more detailed evaluation of the areas that affect success. The issues that have been identified and explored are: Organisational Change Management (OCM), Project Management and Systems Implementation.

Analysis of published case studies, detailing companies that have already undertaken ERP implementation, provides the opportunity to corroborate background findings with ‘real-world’ examples.

The development of a framework for the successful implementation of ERP systems utilises all the information gained from the preceding research. Methods for dealing with the key issues, such as project management, change management and Business Process Reengineering (BPR) have been incorporated into this framework.

A case study provides a primary source of information. The information gained from the case study is used to theoretically evaluate the developed framework.

(3)

Acknowledgements

I would like to thank my project supervisor, Dr. Julika Matravers for her constant support, guidance and encouragement throughout this project. I would also like to thank my assessor, Dr. Karim Djemame for his advice from my mid-project report and mid-progress meeting.

A special thanks goes to Company X, especially the Financial Director who managed to take time out of his extremely busy schedule to answer my questions and provide guidance; the insight provided by him was invaluable.

I must thank my cousin and mum for having the patience to proof read my project and point out areas that required further attention.

Throughout this project the support of my friends has been priceless. I would especially like to thank Scott, Tom and Michael for helping to keep me sane!

Finally, thank you to my housemate Laura, for her support, patience and proof reading skills as the project was drawing to a close. All the people mentioned have made my project possible and a far more enjoyable experience.

(4)

Chapter1 Introduction

Many organisations make use of Enterprise Resource Planning (ERP) systems in the hope of streamlining the flow of information between departments. This multi million pound industry was in decline during the 90s, however it is the general consensus that it is now on the way back up. These systems on average take two years to implement, if not longer, and the cost of ownership runs into the millions (Koch, C., 1999). The rate at which organisations are choosing to switch to an ERP system gives the impression that usually they are successful; however, this is often not the case. A considerable amount of ERP implementations fail (Bingi, P. et al, 1999). This project will investigate why implementations of ERP systems are not successful and reveal what can be done to rectify this.

1.1 Aim and Objectives

The aim of this project is the development of a framework for the successful implementation of an ERP system, concentrating on issues of organisational change.

The objectives of this project are to:

Critically review literature available on ERP, systems implementation, deciding factors of success and failure for Information Technology projects and organisational change.

Analyse and evaluate published case studies on companies that have implemented ERP systems. Carry out an investigation into an external company so that I can personally apply knowledge

gained from research.

Use evaluated data from the case study and research to develop a framework of guidelines that can be followed in order to increase the level of success for implementation of ERP systems. Evaluate the framework.

1.2 Minimum Requirements

The minimum requirements are:

Background chapters on ERP, systems implementation and organisational change.

Investigate two case studies on ERP systems that have been implemented from published

sources.

A case study on one external business, through my own contacts. A framework of guidelines for the implementation of ERP systems. The possible extensions are:

Forming an applicable set of criteria for determining whether an ERP system has been a success or failure, which would have a separate section.

(8)

1.3 Project Schedule

At the start of this project, an initial project schedule was created to provide a guideline for the stages that needed to be completed (see Appendix B). The stages planned for can be seen in the table below.

Task Start Date Duration End Date

Formulate project aims and requirements 16/10/03 8 23/10/03

Initial investigation into literature available 30/10/03 20 18/11/03

Begin writing background chapters 15/11/03 14 27/11/03

Conduct further literature research 25/11/03 28 23/12/03

Write mid-project report 30/11/03 3 12/12/03

Continue writing background chapters 01/12/03 23 23/12/03

Review literature available on published case studies 01/01/04 29 29/01/04

External case study 14/02/04 16 02/03/04

Develop framework 03/03/04 28 31/03/04

Evaluate & submit project 07/04/04 21 28/04/04

1.4 Methodology

The primary methodology used for the background chapters is study and analysis of secondary source material available. This is done through literature searching of books and journals/periodicals in the library, online journals, online books and news alerts via email.

This literature review will uncover research that has been undertaken within the field. It will detail the development of ideas and combine concepts that have been proposed through empirical and theoretical research. The principle of grounded theory has been used with regard to the literature review. This means that the reading that has been completed has prompted the route for further literature searching. Creswell, J. W. (1998) describes grounded theory as a zigzag approach between data collection and analysis.

Following the investigation of literature available is the case study. An ‘interpretivist’ approach (Cornford, T. & Smithson, S., 1996) has been taken with regard to this. The case study will be undertaken to develop understanding and support claims made from the literature review. A framework of guidelines for the successful implementation of an ERP system is then developed; this is considered to be a constructive approach to research (Cornford, T. & Smithson, S., 1996).

Finally the framework and project will be evaluated. The framework will be evaluated against a list of critical success factors that I will formulate throughout the project and by applying it to the case study. The project will be evaluated against the aims, objectives and minimum requirements. The project process will also be evaluated against the methodologies that I have chosen to use. With regard to this project, all of the methods that are used are of a qualitative nature.

(9)

1.5 Outline of project

The aim of the project is to develop a framework for the successful implementation of an ERP system. To achieve this research has been conducted into a number of different areas. Each chapter tackles a different area; highlighting what implications this has on implementing an ERP system. A project outline follows; providing a summary of each chapter.

Chapter 2, Enterprise Resource Planning; this provides a general background for understanding what

Enterprise Resource Planning (ERP) is. This project will investigate what ERP is, its’ advantages and disadvantages, and reasons why organisations are choosing to use this type of system over other information systems. Following this will be an evaluation of the industry, detailing who the major competitors are, the condition of the industry in the past and present, and what is expected for the future. This will be the backbone of the project and will be the basis for further research. One of the disadvantages of adopting an ERP system is that it has a high risk of failure, therefore it is essential that the meaning of success and failure is understood. This issue will be investigated in the following chapter.

Chapter 3, Success and Failure; this chapter covers the issues of success and failure in relation to

information systems and then more specifically, ERP systems. Firms encounter a great number of problems during the process of implementing a new ERP system. As it is such a large industry it is important to understand why projects fail, what problems are encountered and how the level of success can be improved. A set of criteria for determining if implementation of an ERP system has been a success within the context of this project has been developed here. There is a large body of texts available which examine the factors that determine whether an Information Technology project has been a success or failure. Information gathered from these texts will be combined to form the applicable set of criteria. These criteria will be used to evaluate the framework.

Chapter 4, Organisational Change Management; through investigating what is meant by success and

failure, factors that can influence a project’s success has been established. One of the main issues that can be persistently seen throughout the literature available is the issue of change management; therefore this chapter will investigate this issue in further detail. Surveys carried out by the Standish Group (1995) clearly shows that the main reasons for success and/or failure of IT applications development is the extent of user involvement and management support. Organisational Change

Management (OCM) is an extensive subject that features in a range of disciplines; notably, information systems, management studies and sociology. Information regarding change management has been evaluated and combined from these three fields creating an argument for why it is such an important area of interest pertaining to the successful implementation of ERP systems. The chapter will begin by looking at what OCM is, its relevance to IT projects and the people issues involved. Theories to deal with organisational change are discussed, followed by why OCM is such a key issue

(10)

with regard to the implementation of ERP systems. This culminates in an overview of the Effective

Technical and Human Implementation of Computer-based Systems (ETHICS) approach, which is a framework that integrates OCM practices with a technical approach to implementation of computer-based systems. There are many different approaches that can be taken when implementing an

Information System (IS); these are investigated in more detail in the next chapter.

Chapter 5, ERP Implementation; this chapter is split into two distinct sections. The first section will

be a study into existing project management methodologies. The importance of these methodologies will be determined and the key methods will be highlighted, showing the implications this has on ERP implementation. The second section will examine existing software development and implementation methodologies. This will culminate in the analysis of the implications that these methodologies will have on the proposed framework. The best practices will be extracted so that they can be incorporated into the new framework.

Chapter 6, Evaluation of Published Case Studies; a critical review of published cases of ERP

implementations will be detailed here. Procedures that have been carried out well and inadequately have been highlighted, supporting findings from the background research. The main issues are summarised so that they can be incorporated into the framework.

Chapter 7, Proposed Framework; this chapter will integrate all the ideas that have been found from

the research into an implementation framework. From all the researched information, possible solutions for the key problem areas are proposed. In particular, the issue of change management and the problems that arise due to this is covered in depth. Existing best practices and improvements that have been formed as a result of this project are incorporated into a framework for the successful implementation of an ERP system. The proposed framework will then need to be evaluated. This evaluation is conducted in the next chapter.

Chapter 8, Evaluation; this chapter has been broken down into two sections. The first section

focuses on evaluating the framework. Applying the framework to a case study of a company that has already implemented an ERP system is the first stage of the first section. This will be a hypothetical approach and therefore cannot be quantified. The framework will also be measured against the success criteria that were developed in Chapter 3. The second section of this chapter will evaluate the project as a whole. This will be evaluated against the aim, objectives and minimum requirements set out at the beginning of the project. Evaluation of the methodologies will also be carried out here. Following the evaluation will be the project conclusion.

Chapter 9, Conclusion; all the knowledge gained throughout the project will be pulled together and

(11)

Chapter 2 Enterprise Resource Planning

Enterprise Resource Planning (ERP) is a system that aims to integrate the main business functions across all the departments within an organisation (Laudon, K.C. & Laudon, J.P., 2002). If implemented correctly, there should be one system that allows information to flow freely and easily from one department to the other. ERP concentrates on “…integrating all enterprise transaction

processing activities” (Turban, E., et al, 2002). It also includes internal and external suppliers and

customers. The system is based on client/server architecture (see Appendix C).

ERP developed from Materials Requirements Planning (MRP). MRP first emerged in the 1960s; it is a system that aids companies in their volume and timing calculations, for production and sales. This was done using known forecast sales (Laudon, K.C. & Laudon, J.P., 2002). During the 1980s and 1990s, MRP evolved into MRPII (Materials Resource Planning). This allows forecasting of financial and production issues if demand changes. It aims to integrate more processes that may be located outside of the firm. From developing MRPII, ERP evolved.

Its aim is to have one single software program that fulfils the requirements of all the users, from people in finance to human resources and the warehouse(Koch, C., 1999). This software program will run off a single database allowing straightforward sharing of information and effortless communication. Generally ERP systems are implemented in large to medium sized enterprises. At the heart of ERP is the integration of old legacy systems with the new system. This can be a very difficult task and is often the reason why the implementation of these systems can be time consuming and costly. Off-the-shelf ERP packages are available; these packages can then be customised to suit the particular requirements of the organisation. Most organisations opt to use an off-the-shelf package when implementing ERP systems.

Demand for more advanced processing capabilities has resulted in ERP II systems. “Many

businesses are looking to improve and extend processes, offering customers, suppliers and other trading partners access to integrated processing. This is done through concepts like self-service functionality, and aims to deliver more efficient and effective processes with reduced costs”

(Sirsalewala, M., 2003). An example of self-service functionality would be a Web front end that would allow a customer to change their account information and check the status of their orders (Verma, G. & Hollowell, T., 2002). This integrates the customers’ processes into the ERP system, avoiding unnecessary duplication of data, reducing the time intensive process of data entry for staff. There are two types of self-service functionality; manager and employee self-services. Fig. 1 illustrates the different processes that each type of service offers.

(12)

Fig 1; Self Service Functions

Manager Self Service Employee Self Service

Strategic Enterprise

Management Financial Analytics Workforce Analytics Organisation Analytics

Financial Accounting Management Accounting Corporate Governance Financial Supply Chain

Management Employee Relationship

Management

Employee Life-Cycle Management Employee Transaction

Management Purchase Order Management Industry Management Production Execution Projects Management Maintenance Quality Management

Distribution Sales Order Management

Travel Management Environment, Health &

Safety

Incentives & Communication

Corporate Real Estate

People Integration Information Integration Process Integration Application Platforms

(SAP, 2004)

ERP software packages are modular. Each module satisfies a separate function for example there may be a financial module, human resource module, production module, sales module and so on.

2.1 The advantages and disadvantages of ERP

There are a plethora of advantages and disadvantages associated with ERP systems. Some advantages are as follows (Curtis, G. & Cobham, D., 2002, Brown, C. & Vessey, I., 2000):

• ‘Only one software vendor to deal with.’

• ‘Reduced maintenance and other costs.’

• ‘Comparability between systems within the organisation.’

• ‘A more unifying strategy for the organisation.’

• ‘New ways of doing business.’

• ‘IT cost reduction.’

• ‘Flexibility/agility.’

Some disadvantages of ERP systems described by Curtis G. & Cobham D (2002) are “The high initial cost of purchase and subsequent maintenance…The need sometimes for business to align itself

with the off-the-shelf package…The lack of flexibility of the system when business needs change”.

Forrester research (Uknown (a), 2004) conducted a software usability study (part of a larger report that evaluates companies that sell ERP applications), the report states that “several applications

(13)

required ‘inordinate patience and expertise’ to complete the tasks, and many fell short on overall usability” (Gilbert, A., 2003).

Another problem that occurs is that often these systems are not wholly utilised by the firm. According to a survey carried out by IBM, “Chief financial officers do not make full use of their

enterprise resource planning (ERP) systems” (Frauenheim, E., 2003). It is a common strategy for

firms to use pre-built ERP packages developed by vendors such as SAP. Although this helps to reduce costs and risks that would otherwise be associated with a bespoke system, it can also limit the ability for an organisation to innovate (Davenport, T., 1998; Prahalad, C. & Krishnan, M., 1999). From the advantages it is clear to see why firms would want to implement an ERP system. However, the sheer numbers of disadvantages associated with these types of system make it a risky choice. Therefore, one of the aims of the framework will be to mitigate the level of risk involved. As mentioned in Chapter 1, the ERP industry was in decline in the 90s, however it is now thought to be getting stronger. The following section will look at the state of the ERP industry.

2.2 Industry Evaluation

Currently there are three major players in the supply of ERP systems; they are Oracle, SAP and PeopleSoft. These organisations dominate the industry; with most large companies opting for a software package designed by one of the top three (see fig. 2, p.9). It is important to understand the state of the industry as this will determine what software provider an organisation opts to use for their enterprise system. Also, a strong industry will increase the likelihood of organisations that have not yet implemented an ERP system to do so in the future. Increased competition will open up new choices for firms leading to improvements in the current service available. Furthermore, companies with existing ERP systems will be looking for greater functionality and integration. ERP vendors are beginning to offer integration of current ERP systems with Customer Relationship Management (CRM) modules and mobile working functionality. A brief description of the top three vendors follows.

SAP is a German company that was founded in 1972. The largest inter-enterprise software company and the third-largest software supplier, SAP is the recognized leader in e-business solutions for all types of industry (SAP, 2003; Turban, E. et al, 2002).

Oracle began business in 1977.

“Today Oracle (Nasdaq: ORCL) is still at the head of the pack. Oracle technology can be found in nearly every industry around the world and in the offices of 98 of the Fortune 100 companies. Oracle is the first software company to develop and deploy 100 percent internet-enabled enterprise software across its entire product line: database, business applications, and application

(14)

development and decision support tools. Oracle is the world's leading supplier of software for

information management, and the world's second largest independent software company.” (Oracle,

2003).

PeopleSoft are the youngest company out of the three major competitors. It started up in the 1980s, founded by Dave Duffield and Ken Morris.

“Today, PeopleSoft is the world's second largest enterprise application provider, with $2.8 billion in annual revenues, 13,000 employees, and more than 11,000 customers in 150 countries. And the visionary innovation that made PeopleSoft an industry leader continues to fuel its expansion into

new technologies, new markets, and new industries.” (PeopleSoft, 2003).

In July 2003 PeopleSoft acquired JD Edwards, creating the second largest enterprise application software company in the world. However, currently Oracle is trying to carry out a hostile takeover of PeopleSoft. If this goes ahead; the European market will be left with only two main competitors. These three companies were all around to utilize the growth of ERP systems during the 1980s and were all able to emerge from the slump in business during the 1990s. Each of these businesses will have their own guidelines on how their software should be implemented.

However, although these three companies dominate the industry, a META GROUP study (May 2003) entitled “Deriving Value from 21st_{Century ERP Applications” concluded that a provider} called QAD Inc. “…offers the lowest cost of ownership, highest return on investment and fastest time

to implement compared with other ERP software vendors offering manufacturing solutions.” (QAD,

2004). Surveys like this show that it is not necessarily wise for firms to automatically opt for the bigger brands when deciding upon an ERP software package.

Fig. 2 (next page) shows the number of different vendors used for ERP packages from a survey carried out by IT Toolbox. Over 375 participants were used for the online survey. The participants consisted of IT and business professionals. The graph clearly shows that SAP, PeopleSoft and Oracle are the top vendors for ERP packages, followed closely by a company called SSA Global/BaaN. This illustrates that the major brands still dominate the market.

(15)

Fig. 2 Vendors used for ERP packages1

Vendors Used For ERP Packages

0 5 10 15 20 25 30 35 40

SAP PeopleSoft/J.D. Edwards Oracle SSA Global/BaaN Microsoft Great Plains QAD Lawson SYSPRO Other Ve n d o r % of sample

As mentioned earlier, many of the top ERP providers were able to emerge from the slump in business. However, it would be naïve for them to believe that their problems are behind them. Many of the top ERP providers will have a list of consultants/integrators such as Deloitte Consulting or Accenture, which they will recommend prospective clients use. In the USA, there is an emerging trend for organisations to file lawsuits against the software companies and the systems’ integrators when their ERP systems go wrong. For example, in 1999 a company called W.L. Gore & Associates filed a lawsuit against Deloitte Consulting, citing breach of contract, fraud, and negligence for a failed implementation of a Human Resources software package (Osterland, A., 2000). They also identify PeopleSoft, the maker of the software, who recommended Deloitte Consulting, for certifying an incompetent third party (Osterland, A., 2000). If this trend becomes commonplace, it could be the beginning of the end for many ERP providers, or it will mean that the providers and integrators need to clean up their act by delivering a top-class service every time.

As many implementations of these software packages ‘fail’, it is essential to understand what is meant by success and failure of these systems. The following chapter will investigate the issues pertaining to the success and failure of information systems, which will then be linked specifically to ERP systems.

(16)

Chapter 3 Success and Failure

To develop a methodology for the successful implementation of an ERP system it is vital that there is a clear understanding of what is meant by success and failure with regard to these systems. As ERP is an information system, success and failure needs to be analysed in this more generic context first. Once this is understood, these factors can then be related specifically to ERP systems. “The old computing was about what computers could do; the new computing is about what users can do. Successful technologies are those that are in harmony with users' needs. They must support

relationships and activities that enrich the users' experiences.” (Shneiderman, B., 2002). This

statement makes it clear that success and failure of an information system does not solely lie with the technology; users also play a major role in the outcome. This will especially be true of ERP as it is an extremely people-orientated system (Mohamed, M., 2002).

3.1 What is success?

There is no one defining factor that can be used as a measure of success of an information system. Generally success is measured against a series of factors, which depending upon circumstances, do not all have to be fulfilled. Oddly, there is more literature available defining what makes a system a failure, as opposed to what makes a system a success. DeLone and McLean (1992) detail a series of success factors that should be considered. These factors link with the issues presented by Kendall (1997). The success factors are combined from both studies and can be seen below (DeLone & McLean, 1992);

System quality– does the IS work? Information quality

System use– do the end-users use the system as it was intended; are the capabilities of the system utilised?

User satisfaction– is it easy to use?

Individual impact– is it a good fit with the users’ motivations? Organisational impact – is it a good fit with the organisation?

Cockman et al (1999) present four factors of successful implementation; they are Ownership,

Leadership, Capability and Organisation. Ownership refers to how committed the people

responsible for change implementations are, and the degree to which they own the system (Cockman et al, 1999). Leadership refers to how committed senior manages are to change. Capability is concerned with the skill levels of the implementers and the organisation factor is interested in the organisation of the implementation phase (Cockman et al, 1999).

From the success factors it can be seen that technical and non-technical issues have an equally important role in deciding if an information system has been a success or not. It can be difficult to

(17)

determine success, as many of the benefits gained from an ERP system are intangible such as increased flexibility and a higher level of information transparency amongst other things.

3.2 What is failure?

There is a great deal of literature available defining what is meant by the failure of an information system. Unlike success, only one ‘failure factor’ need be present for the information system to be deemed a failure. Ewusi-Mensah & Przanyski (1995) discuss three types of failure; these are, total abandonment, substantial abandonment and partial abandonment. Total abandonment refers to when a project is totally discarded; substantial abandonment is when the system becomes radically different prior to implementation and partial abandonment is a reduction in the scope of the information system without significant change to the specification.

Lyytinen & Hirschheim (1987) divide failure up into four distinct categories:

1. Correspondence failure – doesn’t meet objectives.

2. Process failure – no workable system or project is over-budget in terms of time/cost.

3. Interaction failure – low use or is difficult to use.

4. Expectation failure – stakeholders perceive their needs not to have been met.

One of the main problems with information systems projects is that once they start to fail, the situation can quickly become irretrievable – this is referred to as escalation.

Cockman et al (1999) highlight capability as being an important reason for failure. Capability encompasses knowledge, behaviour and feelings, and is the ability to do something well. This links with interaction failure as if the system is difficult to use, the level of capability will be low. Although these problems can stem from a technical issue, the problem lies with how the users of the system feel. This is a difficult issue to deal with and is discussed further in the following chapter. Like the success factors, reasons for failure can be technical and non-technical. However, unlike success factors, there appears to be more reasons for failure on the non-technical side. It is likely that this would be especially true of ERP projects as they are typically more people orientated. Resolutions of these issues will need to be formulated and included in the eventual framework.

3.3 Guidelines relating to the success and failure of Information Systems

One important element of an Information Systems Success measure put forward by Garrity E. J. and Sanders G. L. (1998), is that there must be an ‘assessment of how the information system impacts the

worker and allows the worker to accomplish his or her tasks’. Garrity and Sanders also suggest two

influencing factors that will impact upon the success or failure of Information Systems; they consider these to be either endogenous or exogenous. “Endogenous factors of success are those which can be considered to be within the expertise and control of the actors at the respective levels and might

(18)

include, for example, user skills and the development process and methodology adapted. Exogenous factors are those which cannot be so considered, for example, political and economic factors.”

(Garrity, E.J. & Sanders, G.L., 1998).

DeLone and McLean (1992) revised model of IS success divides success into three stages; the technical development stage, the deployment to the user stage and the delivery of business benefits stage. This is called the 3-D model.

Sauer C. (1993) makes several recommendations with regard to preventing the failure of an information system, these are; recognise the politics of the organisation and take appropriate action,

‘manage the evaluation process’, make use of prior analysis of the IS process and use it as a

framework, keep track of and document problems and their resolution, ‘abandon hopeless projects’, and carry out post project reviews so that knowledge can be gained from experience.

3.4 Success and failure in relation to ERP systems

As a type of information system, ERP projects inherit many of the same success and failure factors. Failures can occur as a result of risks that have not yet been mitigated. There are a set of unique risks associated with ERP projects due to their sheer size and scope. Mary Sumner (2000) outlines these unique risks as being;

“Failure to…

redesign business processes; follow an enterprise – wide design which supports data integration; mix internal and external expertise effectively; adhere to standardised specifications which the software supports

Insufficient…

training and reskilling; internal expertise

Lack of…

business analysts with business and technology knowledge; integration

Attempting to build bridges to legacy applications”

These risks are unique to ERP systems due to the sheer size and scope of this type of project. Consolidation of data is a key factor, as information from across the whole organisation needs to be pulled together, often from differing legacy systems. Also, when adopting to use an off-the-shelf package, it is favourable to re-design business processes as opposed to customising the software. Implementation of non-ERP information systems, tend to be bespoke, therefore the issue of customisation is not relevant. Even when an off-the-shelf package is used, the system scope is not so wide; therefore customisation does not produce the same problems as it would for ERP systems.

(19)

Nah, Zuckweiler and Lau (2003) have summarised the critical success factors that apply to ERP systems. These can be seen (reproduced) in the following table:

Table 1: Review of Critical Success Factors for ERP Implementation

ERP Change Software Appropriate

Teamwork Management Top BPR with Business Monitoring and Development, Business & And Culture and Management Minimum Plan and Project Project Evaluation of Testing and IT Legacy Composition Program Support Customization Vision Management Champion Communication Performance Troubleshooting Systems

Bingi, Sharma, and Godla(1999) x x x x x

Buckhout, Frey, and Nemec

(1999) x x x

Falkowski, Pedigo, Smith, x x x x x x x

and Swanson (1998)

Holland, Light, and Gibson (1999) x x x x x x x x x x

Murray and Coffin (2001) x x x x x x x

Roberts and Barrar (1992) x x x x x x

Rosario (2000) x x x x x x x x x

Scheer and Habermann (2000) x

Shanks et al. (2000) x x x x x x x x

Stefanou (1999) x x

Sumner (1999) x x x x x x x x

Wee (2000) x x x x x x x x

Number of citations 9 9 8 8 7 7 6 6 6 6 2

Note. BPR = Business Process Reengineering; IT = Information Technology.

The table above details the main issues that affect success with regard to ERP implementation. From this it can be seen that the key factors that impact upon the likelihood of success are; the composition of the ERP team and the way that they work together, the change management culture and program, top management support and Business Process Reengineering (BPR) so that minimal customisation of the software is required. These issues should be tackled from the very beginning of the project; therefore it is critical that they are incorporated into the framework. Secondary to these Critical Success Factors (CSF) are; a clear business plan and vision, good project management, a project champion, clear communication, continuous monitoring and evaluation of performance, software development, testing and troubleshooting. The research also considers the issue of the use and replacement of appropriate business and IT legacy systems. Although this is considered to be critical to the success of an ERP implementation it is not universally acknowledged as a vitiating factor (as can be seen from the table above).

The CSFs outlined above can also be considered as a brief outline of the strategies that could be undertaken to control the risk factors associated with ERP projects. Alongside these CSFs, other strategies that should be used in order to mitigate risks are; recruitment and retention of specialist technical personnel, equipping the existing workforce with the new skills needed (through training), dedication to the use of project management methodologies and best practices recommended by the software vendor and continuous commitment of the users to their project management roles (Sumner, M., 2000).

(20)

3.5 Success criteria for the implementation of an ERP system

From the research undertaken for this section, the following list of criteria has been formulated and will be used in this project to determine whether an ERP system has been implemented successfully. This list contains the main points that appear to be recurring within the majority of the literature that is available on what determines the success of Information Systems/ERP systems.

Use of a change management program

ERP Teamwork and Composition

Top Management Support

BPR

Project Management

Business Plan and Vision

Does it meet requirements? – set out at the beginning of a project. System quality – does the IS work?

System use – do the end-users use the system as it was intended; are the capabilities of the system utilised?

Has it been implemented on time/budget? This is an important issue as “…40% of CFOs saying ERP rollouts took longer than expected and 55%, admitting it cost more than expected – although three quarters still rated it as a success (McCue, A., 2004).”

However, this will not be the most important factor determining success and will need to be considered within context.

From the criteria for success it can be seen that a good change management programme can positively influence the outcome of an ERP project. This is because it decreases the level of resistance to the new system, increasing the likelihood of user acceptance. For this reason it is essential for an organisation to understand the importance of change and utilise any methods available for dealing with this. Therefore the following chapter will look at the issue of organisational change, detailing how this relates to the adoption of ERP systems.

(21)

Chapter 4 Organisational Change Management

Organisational Change Management (OCM) is defined as the process of controlling changes to the infrastructure or any aspect of services in a controlled manner (Robbins, P., 2001). It is a methodology that is used to aid in the implementation of approved changes so that there is minimum disruption (Laudon & Laudon, 2002). When trying to manage organisational change, an impact and risk assessment of the effect of the change on the business should be the starting point Organisational change must be planned, monitored and controlled; it is a continuous, never-ending process.

Implementation of ERP systems requires a great deal of change management, as generally it affects the whole enterprise. As ERP endeavours to standardise business processes, it will be the duty of the OCM to ensure that any damages caused by the transformation can be avoided/minimised (Susanto, 2003). OCM is a continuous process required throughout ERP implementation due to the complexity of the system. Without making use of OCM, it is likely that the organisation will not be positioned to best use the new system.

4.1 What is OCM?

OCM is a crucial subject that affects all businesses today and in fact has a presence in every day life, as in life nothing stays the same therefore everything is always changing. As this is true on an individual level, and individuals are what make up organisations, it is also true of organisations.

“Industries go through periods of relatively minor change, these periods are punctuated by intervals of major disturbance, or disequilibrium, when whole product classes and virtually all companies in

the industry are affected.” (Nadler, D. et al, 1995). Consequently it is imperative that organisations

ensure that they make the issue of organisational change a priority. Organisations face constant competition. To be able to emerge from this competition unscathed requires firms to improve their products and/or services and processes. Improvement inevitably leads to change and although these changes are intended to improve upon the traditional they often cause various other problems that at first glance would not appear to be related. For example, improving machinery so that a process becomes quicker would initially appear to be a good investment. However, increasing the speed of a process, would lead to a greater workload that in turn could increase the levels of stress, which could have a negative impact upon staff turnover. Greater levels of staff turnover could then have a negative impact upon the speed of processes as staff will not be as experienced; therefore undoing the benefits from the new machinery. This tends to occur when peoples’ values, attitudes and psychological needs are neglected, causing a change situation to become unbalanced (Mumford, E., 1995). When this happens, the new system does not produce the desired efficiency and in fact operates more inefficiently than anticipated, resulting in the costs far outweighing any gains (Mumford, E., 1995).

(22)

4.2 OCM in relation to IT projects

Avgerou, C. (2002) divides change in relation to IT projects into two different groups; i) planned radical change and ii) emergent, situated change. Planned radical change is described as “… associating the development of technology – based information systems with radical organisational

restructuring.” (Avgerou, C., 2002). Business Process Re-engineering (BPR) would fall under this

category. BPR can be described as a radical re-design of business processes in order to eradicate repetitive and/or paper intensive tasks so as to decrease costs, increase quality and service and maximum utilisation of information technology in place (Laudon, K.C. & Laudon, J.P., 2002). It is argued that BPR enables organisational transformation, therefore aiding in organisational change (Lee, H.G., & Clark, T.H., 1996). In particular, BPR is an “…evolutionary way of exploiting the

capabilities of IT…” (Scott Morton, M.S., 1991).

One positive attribute of planned radical change is that innovative thinking is encouraged, reducing the likelihood of over-specialisation stagnating within the business (Avgerou, C., 2002). However, one of the criticisms of this approach is that it can ignore the principles that emphasize “…the social context of the organisation and aims at feasible, rather than radical, organisational changes…”

(Avgerou, C., 2002).

In contrast, emergent, situated change can be described as an ongoing process that requires continuous management (Avgerou, C., 2002). “Theoretically this perspective draws from the rich ideas of structuration theory and studies of the relationship between technology and society”

(Avgerou, C., 2002). Structuration theory is based on the “…structuring of social relations across

time and space, in virtue of the duality of structure” (Giddens, A., 1984). An emergent, situated

change approach highlights the belief that organisations should understand that changes will occur as their employees gain knowledge in how to best utilise the new technologies in place (Avgerou, C., 2002).

The implementation of ERP systems will encompass both ‘planned radical’ and ‘emergent, situated’ change. When an ERP system is first implemented, the change occurring will fall under the ‘planned radical change’ group. Often BPR will need to take place so as to better align current processes with the capabilities of the proposed new system. Once the system is in place, ‘emergent, situated change’ will take over as users get to grips with the new system and learn new ways of carrying out their day-to-day activities.

4.3 What are the people issues?

There are many people issues that must be considered when developing and implementing information systems. These issues are particularly prevalent with regard to the implementation of an ERP system. This is because ERP systems are people-orientated; which means the implementation

(23)

has a definite impact upon the people within the organisation as work processes, roles and responsibilities all undergo change (Pereira, B., 2004). Four issues that are centred on the user are usability, acceptance, support and involvement. Usability has been defined by ISO as “…the degree to which specific users can achieve specific goals within a particular environment; effectively,

efficiently and comfortably…” (Bennett, S. et al, 2002). A system is effective if a user is able to

complete the goals that they have set out to achieve using it. Efficiency relates to the time and resources consumed by the system in order to realise goals. Comfort and acceptance relates to how the user feels about their use of the system, their level of satisfaction. Therefore, the main issue here is how steep the learning curve is. A learning curve can be described as the rate at which new information is assimilated. Generally speaking, users will absorb new information quite slowly at first, making the curve quite flat however, this should then rise exponentially.

The three principles of usability are (Dix, A. et al, 1993):

1. Learnability – the amount of time and effort needed to achieve a specific level of

performance.

2. Flexibility – the number of ways users and the system are able to interact with each other. 3. Robustness – the level of support that is provided when things go wrong.

Learnability can also be associated with the organisation as a whole, not just individuals. An organisation with a learning culture can be described as one that is able to sustain internal innovation, which immediately results in improved quality, enhancing customer and/or supplier relationships, more effective execution of the business strategy and the ultimate objective of sustaining profitability (Quinn Mills, D. & Friesen, B., 1992). Argyis (1976, 1982) suggests that there are two types of learning; ‘adaptive learning’ and ‘double-loop’ learning. An adaptive attitude can be described as one where situations are handled as they occur; whereas a double-loop learning culture would be one where new ways of looking at the world are continually being sought and where challenging assumptions, goals and norms are encouraged (Lambert, R., & Peppard, J., 1995). “The essence of a learning organisation is that it is not just the top that does the thinking; rather it must occur at every

level” (Lambert, R. & Peppard, J., 1995). A learning organisation has also developed the ability to

adapt and change (Robbins, S.P., 2001).

Acceptance deals with issues of trust – are the users willing to use the system? In the case of ERP packages, the whole business will be utilising the new information system, which the employees must use in order to access data. Therefore it is essential that the employees accept the system in place.

Support issues are concerned with how users get support when they are having difficulties. Difficulties can occur when there is a lack of transparency in the GUI (Graphical User Interface).

(24)

Often programs have a help facility that the user can operate, however it is often the case that users will ask someone who is ‘IT literate’ to operate the help facility for them.

There are also many involvement issues that must be considered during the development of a system. It is universally acknowledged that there is a huge communication problem between system developers and the end users (Feraud, G., 1999). Generally end-users are not technically proficient, are resistant to change and can be confused between what they want and what they need. To deal with the people issues that arise due to the use of IS and change, there are a number of OCM theories that can be considered. This is investigated in the following section.

4.4 OCM theories

The basic underlying concept of change management is simple; ensure that every stakeholder is fully prepared for the way in which the project outcomes will affect him or her. The specific activities that should be undertaken when dealing with change depends on many variables, such as the type of project, the degree of change, the business of the organisation and the experience of stakeholders – amongst other things. The Island Consulting team describe a series of change management activities that they feel should be present when dealing with a project that brings on ‘reasonable’ change. These activities are; guaranteeing key executive support, detailed understanding of the project objectives, estimating corporate readiness and potential impacts, identifying all the stakeholders, formulating and implementing strategies and schedules for training and communication, building services for support and counselling, development and implementation of new business processes and organisational structures (Island Consulting, 2004). This links back to the CSFs for ERP discussed in the previous chapter, showing the particular importance of top management support; described by Island Consulting as ensuring support from key executives. A well-known theory by John Kotter (1996, 1999) suggests eight stages involved in the process of change. The stages are as follows (Kotter, J., 1999):

1. Establishing a sense of urgency

Examine, identify and discuss; the market, competition, (potential) crises and major opportunities.

2. Forming a powerful guiding coalition

Put together a team of people with enough power to lead the change. Encourage this group to work together as a team.

3. Creating a vision

Develop a coherent vision that will help direct the change effort, and develop strategies for achieving that vision.

4. Communicating the change vision

Communicate the new vision and strategies, ensuring that the guiding coalition teach the new behaviour expected of employees by example.

(25)

5. Empowering others to act on the vision

Discard any obstacles to change. Remove systems or structures that undermine the change vision and encourage risk taking in non-traditional ideas, activities and actions.

6. Generating short-term wins

Plan for and create visible improvements. Present these 'wins' and publicly recognise and reward those who made them possible.

7. Consolidating improvements and producing more change

Use credibility gained from early 'wins' to bring other structures and processes into alignment with the change vision. Utilise the people who can and will implement the new changes, and revive the process with new projects, themes and change agents.

8. Anchoring new approaches in the culture

Articulate the links between the new behaviour and organizational success. Develop ways to ensure further leadership development and succession.

These are a generic set of steps for dealing with change in any organisation. The following section will show how OCM relates to ERP systems.

4.5 OCM – a key issue in the implementation of ERP systems?

Implementation of ERP systems requires a great deal of change management as it affects the whole organisation and because it is people centred. From the research in this and the preceding chapter it is clear that one of the main reasons for failure of a project is the change management issue. Often, companies are not prepared to spend the amount of money needed to properly manage the smooth transition to a new system. “An organisation can buy the most expensive package on the market, and spend millions implementing it, but unless users are empowered and motivated to use the system properly, the company could simply end up with and ERP system that replicates the old process.”

(Ashford W., 2003). One method that can be used to tackle the issue of change when implementing a new Information System is the ETHICS approach (see Section 4.6). This approach combines the people issues discussed in Section 4.3. and the OCM theories discussed in Section 4.4. Compared with other information systems, ERP systems are a far more people-orientated and require a great deal more change management as it is enterprise wide, therefore the ETHICS approach will assist in dealing with these issues. The approach is outlined in the following section.

4.6 The ETHICS approach

The Effective Technical and Human Implementation of Computer-based Systems (ETHICS) approach is a systems design methodology proposed by Enid Mumford. The methodology is designed to “…assist managers to introduce new information systems easily and effectively”

(Mumford, E., 1995). This approach has three objectives that relate to managing change (Mumford, E., 1995):

(26)

systems at all organisational levels play a major part in the design of these systems.”

2. “…to enable groups concerned with the design of computer systems to set

specific job satisfaction objectives in addition to the usual technical and operational objectives.”

3. “…to ensure that any new technical system is surrounded by compatible, well –

functioning organisational system.”

This method takes a socio-technical approach. This means that it “…recognises the interaction of technology and people, and produces work systems which are both technically proficient, have social

characteristics which lead to high job satisfaction and create high quality products” (Mumford, E.,

1995). As this approach focuses on changes associated with people and how they interact with information systems, it will be a useful tool to consider with regard to implementing ERP systems. There are many implementation methodologies that can be used for information systems. These methodologies are investigated in the following chapter. The relevance of these methodologies to ERP implementation will be considered.

(27)

Chapter 5 ERP Implementation

“The most critical aspect of implementation is neither technical nor economic, but political.”

(Avgerou C. & Cornford T., 1993). The importance of politics during implementation and the role it plays in the level of success of an IS cannot be stressed enough. However, understanding politics and being able to ‘play the game’ is a skill that is difficult to teach but once developed will prove to be invaluable. An effective ‘weapon’ that can be utilised is the ability to communicate strategic ideas and knowledge. Project management methodologies endeavour to tackle this issue and are concerned with managing the whole project process surrounding implementation of a new system. These methodologies provide guidelines for when change management should be undertaken. Also, provisions are made for critical issues, such as top-level management support and composition of the project team as highlighted in Chapter 3. The negative aspect of these methodologies is that they provide less detail on the actual product/software implementation. Due to this, the second section of this chapter will look at the series of generic steps that can be followed during the implementation of a system. These steps are described in different ways in various implementation methodologies. It is important to understand the various systems implementation techniques that are used so that a new framework can incorporate the best practices from each and disregard the any methods that have a tendency to fail or cause problems. The chapter will conclude by bringing together the best practices from both project management and systems implementation methodologies.

5.1 Project Management

There are a variety of different project management methodologies available for use; some have been developed by consultancy firms and product vendors, whilst others are in the public domain. The implementation methodologies/frameworks discussed in the previous chapter did not effectively deal with the issue of OCM. Project management methodologies, although slightly less focused on the finer details of actual software implementation, the way a project is managed is covered in greater depth. Project management deals with such issues as top-management support, teamwork and change management; all influencing factors of success that are highlighted in Chapters 3 and 4. Some examples of project management frameworks are; PRIDE, Project Resource Organisation

Management & Planning Techniques (PROMPT), Scalable Methodology (developed by the US Project Management Institute) and PRrojects INControlled Environments (PRINCE) to name but a few. This chapter will look at the PRINCE2 project management methodology in further detail.

5.1.1 PRINCE2

PRINCE is the de facto standard that is used by the UK government. It is a set of structured methods that can be followed to effectively manage projects (Unknown (b), 2004). Although it was designed for the public sector, it is increasingly being used in the private sector. There is a great deal of

(28)

information available on the PRINCE and updated PRINCE2 methodologies. The main issues have been extracted and presented below.

The PRINCE2 methodology is based around three fundamentals that can be applied to each project and the stages within that project. The three fundamentals are; processes, components and techniques (Unknown (c), 2004). Fig. 2 illustrates the stages involved in the process fundamental. Fig. 2 Process Model

(Unknown (d), 2004)

The ‘components’ fundamental deals with the business case, organisation, controls, risk management, quality of the project environment, configuration management and change control and management. The last element corroborates the need for change to be managed as discussed in chapter 4. The ‘techniques’ fundamental covers product-based planning, change controls and quality reviews. Planning is an element that recurs throughout the three fundamentals. It focuses on continuous, estimating, planning and re-planning throughout any project process. PRINCE structures the preparation and maintenance of plans at different levels throughout a project life-cycle (Bentley, C., 1997). It also promotes the use of exception planning; so that contingency plans are in place should there be a divergence from original plans.

PRINCE distinguishes management, specialist and quality activities. It defines management activities as: planning, monitoring and reporting of the work undertaken within the project. In contrast, specialist activities are involved with describing the work necessary to produce the deliverables required by the project. These deliverables would have been identified and defined at the very beginning of the project by the project manger and then endorsed by the project board. Quality activities have the potential to be performed by anyone who has made a contribution to the final deliverable that is being reviewed. It is imperative that quality activities are planned at the

(29)

earliest stage of the project life. PRINCE has been designed so that it is compliant with ISO9000. ISO9000 is a certificate that can be obtained once a set of standards has been met. These generic standards are concerned with continually meeting all of your customer’s expectations and requirements, enhancing satisfaction and loyalty (Bennett, S. et al, 2002). Compliance with ISO9000 ensures that PRINCE2 is built upon a foundation of quality and effective modern project management (Unknown (e), 2004).

A unique feature of the PRINCE methodology is a process of continuous assurance. It recommends that a business assurance co-ordinator (BAC), technical assurance co-ordinator (TAC) and a user assurance co-ordinator (UAC) be put in place. It is the job of the BAC to monitor if the project is aligned with the business mission of the organisation and then reports back on findings at progress meetings (Allan, G., 2004). This ensures that the project stays working toward the best interests of the organisation. The TAC monitors the technical aspects of the project, assuring that technical difficulties do not arise (Allan, G., 2004). It is the function of the UAC to represent the needs of the end-user. These assurance activities are constantly carried out throughout the project and are not left until the end (Allan, G., 2004).

PRINCE2 focuses on; defining the organisation structure for the project management team, business justification and dividing the project into stages so that it can be more easily managed and controlled. It is also a flexible approach that can be tailored to the appropriate level of the project (Bentley, C., 1997).

5.2 Systems Implementation

There are many methods that can be used for systems implementation (Bennett, S. et al, 2002). Methodologies are required when there is an interest in the design of information systems, as a framework is needed to follow. Two popular styles of framework are soft systems methodology (SSM) and ‘hard’ systems thinking. When developing an intricate system, a systems thinking approach provides a set of concepts and principles that can be followed (Cropley, D.H. & Cook, S.C., 1999). The hard systems methodology has clear definable goals that need to be met. It takes a systematic approach to the design and implementation of systems. From the different solutions available, the one that most closely meets the requirements will be chosen. The hard system approach is technology orientated and makes use of formal system design methodologies. In contrast, the soft systems methodology is centred on people. The problem definition will be hard to define, so too will the goals and success criteria. This results in making it difficult to choose between solutions as the trade-off is challenging to quantify.

5.2.1 Soft Systems Methodology

Checkland et al developed Soft Systems Methodology (SSM) in the 1960s. It evolved in response to the difficulties that are encountered with the hard systems approach with regard to human activity

(30)

systems. The political issues are particularly prevalent when using this method, as are good interpersonal skills. When a problem is unclear, this methodology works well as it focuses on analysing and defining problems. SSM is a seven-stage methodology the stages are as follows:

1. Problem situation: unstructured; at this stage a set of perspectives should be taken into

account, they are (CATWOE):

Customer – the person who causes the study to occur. Actor – a person that carries out activities in the system.

Transformation process – main activity of the system, expressing the change of some input into some output (Checkland, P.B., 1981).

Weltanshauung – the perspective/inclination of the image or model of the world that the individual attempting to classify the system has. It is an epistemological

approach to systems. “Developing a view of something as a ‘system’ by

investigating whether the nature and origin of the knowledge relating to it maps to

the knowledge relating to ‘systems’ (MacKinnon, L. M., 2004)”.

Owner (of the system)

Environmental constraints – impositions taken by the system as given.

2. Problem situation: expressed; once the different perspectives of the problem have been taken

into account, it can then be defined (Checkland, P.B., 1981)

3. Root definitions of relevant systems; this defines what has been agreed and what still needs to

be considered. A “kind of hypothesis about the relevant system, and improvements to it, that might help the problem situation.” (Avison & Fitzgerald, 1995) is generated at this stage.

4. Conceptual models; a model of the activity system required to achieve the transformation

described in the root definition is created here (Checkland, P.B., 1981).

5. Comparing models with reality; at this stage rich pictures and conceptual models are

compared with the existing system and debated (Checkland, P.B., 1981).

6. Assessing feasible and desirable changes; analysis of proposed changes.

7. Action to improve the problem situation; this is equivalent to an implementation stage. At

this point changes in structure, procedures and attitudes are made. 5.2.1.1 Criticisms

SSM takes an extremely vague approach from the start and carries on like this for as long as possible. It also assumes that all the actors have equal choice, which is unrealistic, as in reality power is not divided equally in an organisation. This methodology requires a culture of openness and “niceness”, which is more suited to middle class academics as opposed to managers and workers.

5.2.1.2 Advantages

SSM works well for ill-structured situations. It is more suited to analysis of problems as opposed to design problems. Also, it is a good methodology to use for people centred design of information