DEFINITION AND ANALYSIS OF CRITICAL SUCCESS FACTORS …• A CSF unified model for ERP...

DEFINITION AND ANALYSIS OF CRITICAL SUCCESS FACTORS FOR ERP

IMPLEMENTATION PROJECTS

José Manuel Esteves de Sousa Universitat Politècnica de Catalunya

Barcelona, Spain

Advisors: Joan Antoni Pastor

Josep Casanovas A thesis submitted in partial fulfillment of the requirements for the degree of Doctor of

Philosophy in the Llenguatges i Sistemes Informàtics of the Universitat Politècnica de Catalunya, Barcelona, Spain.

ACKNOWLEDGEMENTS

Throughout this doctoral research project, there are many people that I would like to

acknowledge for continuing support and kind help that they have been offered to me. Foremost, I would like to thank my advisor Joan Pastor for his guidance and support over the

past six years. I can only feel flattered for the confidence he has shown in me. Fortunately, I have benefited from his extraordinary motivation, great intuition, and technical insight. I just hope my thinking and working attitudes have been shaped according to such outstanding qualities.

I wish to thank my co-advisor, Josep Casanovas, for his guidance and support over the last two years. He has always show confidence in me.

My thanks also extend to João Álvaro for he guided my first steps in the academic world and lately as a Ph.D. student and with whom I have had the pleasure of working in some studies. I want to thank him for the advices and support he has always given to me. Thanks for John Gunson for his cooperation and wise advices. I would also like to express thanks to my ERP research colleagues for the questions, comments and discussions we had during and after the conferences.

Special thanks to my friends and family who have been a beacon of strength. Thank you for understanding when I needed a break and when I needed solitude.

During my research I had the financial support of two institutions that made possible this long journey. First, the Agencia Española de Cooperación Internacional (AECI) who awarded me with a Mutis fellowship helping me in the early stages of my doctoral studies and then, the Fundação para a Ciencia e Tecnologia (FCT) who awarded me with a fellowship for the development of the doctoral research project.

Last, but not least, I would like to thank my mother, Ana, to whom this thesis is dedicated and my whole family for their unconditionally love and support along this journey.

ABSTRACT

ERP is one the latest technologies that many organizations have undertaken. Typically, Enterprise Resource Planning (ERP) systems are software packages composed of several modules, such as human resources, sales, finance and production, providing cross-organizational integration of transaction-based data management throughout imbedded business processes support. These software packages can be customized up to a certain limit to the specific needs of each organization. ERP was characterized as the most important development in the corporate use of technology in the 1990s. Unfortunately, many ERP projects have not been effective enough and hence have been unable to achieve all the results envisaged. As the cost of an ERP implementation project is very high, it is critical for an organization to make the project a success and start obtaining benefits out of it as fast as possible. But what is it that makes an ERP implementation project successful?

To address this issue we propose the use of a Critical Success Factors (CSF) approach to manage ERP implementation projects. After an extensive literature review on ERP research and ERP implementation project studies, we have studied and have proposed results along the following issues:

• The identification and definition of a comprehensive list of CSF. • The relevance of CSF along the typical ERP implementation phases. • The definition of Key Performance Indicators (KPI) for CSF. • The analysis of CSF management in some organizational contexts.

A theoretical framework was developed in order to aid the process of answering the implied

research questions. In order to accomplish the research aims of this research, we have proposed an interpretive research approach and a “multimethod” research framework that combines various research methods, both quantitative and qualitative, with predominance of qualitative ones.

• An annotated bibliography on ERP research. • A CSF unified model for ERP implementation projects. • A CSF relevance schema along the typical ERP implementation phases. • A new criticality indicator for Process Quality management (PQM) method. • A tentative set of KPI for some CSF and a systematic approach to develop the rest of KPI. • An ERP implementation model. • A CSF management analysis in two organizational contexts: a small and midsized

enterprise and a public higher education institution.

With regard to the two cases studies conducted, the first was a pilot case study of an ERP implementation in a Portuguese small and midsized enterprise. The second one was an in-depth case study of an ERP implementation in a big Spanish public higher education institution. The different organizational contexts provided valuable insights in CSF management as well as implications from the emergence of patterns of communality between both case studies. The research results evidence that:

• Most of the problems that arise in ERP implementation projects are associated with the activities identified as CSF in this research,

• The main concerns are organizational rather than technological. • The management of CSF is influenced by the context and, • When managers have taken into account the CSF identified, some of project problems have

been avoided or their impact significantly reduced in ERP implementation projects, and the organization is more likely to use more effectively the ERP system after its implementation.

• A CSF approach is also helpful to avoid problems on the long term since most of the CSF identified are strategic.

It is hoped that future ERP research and ERP implementations can draw upon and learn from

this thesis.

LIST OF ABREVIATIONS

ASAP BPR CSF ERP IS IT GQM GT HEI KPI MCP MRP MRPII PQM ROI SME UPC WS

Accelerated SAP Methodology Business Process Reengineering Critical Success Factors Enterprise Resource Planning Information System Information Technology Goals/Questions/Metrics Grounded Theory Higher Education Institution Key Performance Indicators Most Critical Processes Material Requirements Planning Manufacturing Resource Planning Process Quality Management Return On Investment Small and Midsized Enterprise Universitat Politècnica de Catalunya Web Survey

INDEX

Chapter 1 Introduction.............................................................................................. 15

1.1 ERP Overview............................................................................................................ 15 1.1.1 ERP Historical Account ................................................................................................... 17 1.1.2 ERP Functional Modules ................................................................................................. 17 1.1.3 ERP Product Lifecycle and Market.................................................................................. 18 1.1.4 ERP Importance ............................................................................................................... 19 1.1.5 Motivation and Benefits for adoption of ERP.................................................................. 20

1.2 Objectives of the Research........................................................................................ 21 1.3 Thesis Contributions ................................................................................................. 22 1.4 Organization of the Thesis........................................................................................ 23 1.5 References .................................................................................................................. 26

Chapter 2 Theoretical Background and Literature Review .................................... 28 2.1 Information Systems Implementation Review........................................................ 29

2.1.1 IS Implementation Research Diversity............................................................................. 30 2.1.2 ERP System as a Special Information System ................................................................. 31

2.2 ERP Lifecycle Framework ....................................................................................... 33 2.2.1 Phases of the ERP Lifecycle ............................................................................................ 33 2.2.2 Dimensions of the ERP Lifecycle .................................................................................... 34 2.2.3 The ERP Implementation Phase....................................................................................... 35 2.2.4 ERP Implementation Approaches .................................................................................... 36 2.2.5 ERP Implementation Success........................................................................................... 37

2.3 An Annotated bibliography on ERP Research ....................................................... 38 2.4 ERP Implementation Phase Bibliography .............................................................. 40

2.4.1 Implementation Approaches ............................................................................................ 41 2.4.2 Implementation Success................................................................................................... 42 2.4.3 Other Issues...................................................................................................................... 43 2.4.4 Case Studies ..................................................................................................................... 43 2.4.5 Main Topics Researched .................................................................................................. 45 2.4.6 Topics for Further Research............................................................................................. 45

2.5 Critical Success Factors Approach .......................................................................... 46 2.5.1 CSF Approach Usage....................................................................................................... 47 2.5.2 A Conceptual CSF Identification Framework.................................................................. 48 2.5.3 Techniques for CSF Identification ................................................................................... 52

2.5.4 Benefits of CSF for Managers.......................................................................................... 53 2.5.5 Key Performance Indicators............................................................................................. 53

2.6 Conclusions ................................................................................................................ 55 2.7 References .................................................................................................................. 55

Chapter 3 Research Design....................................................................................... 64 3.1 Conceptual Framework ............................................................................................ 65 3.2 IS Research Paradigms and Methods...................................................................... 65

3.2.1 Quantitative, Qualitative, and Multimethod Research ..................................................... 67 3.3 Research Strategy...................................................................................................... 71

3.3.1 Research Questions .......................................................................................................... 71 3.3.2 Research Goals................................................................................................................. 71 3.3.3 Motivation........................................................................................................................ 71 3.3.4 Research Paradigm........................................................................................................... 72 3.3.5 Research Design............................................................................................................... 72 3.3.6 Multimethod Design Followed......................................................................................... 74

3.4 Trustworthiness of the Research.............................................................................. 79 3.4.1 Credibility ........................................................................................................................ 79 3.4.2 Transferability .................................................................................................................. 80 3.4.3 Dependability ................................................................................................................... 80 3.4.4 Confirmability .................................................................................................................. 81

3.5 References .................................................................................................................. 81 Chapter 4 Unified Model of Critical Success Factors ............................................. 84

4.1 Background on CSF for ERP Implementations ..................................................... 85 4.1.1 Research Approach .......................................................................................................... 86 4.1.2 CSF Unified Model Proposal ........................................................................................... 87 4.1.3 Organizational Perspective............................................................................................... 91 4.1.4 Technological Perspective................................................................................................ 93

4.2 Comparison of ERP projects with other Projects .................................................. 94 4.3 CSF as Perceived ERP Risk Factors........................................................................ 95 4.4 Clarifying Project Champion Role CSF.................................................................. 96

4.4.1 Project Champions ........................................................................................................... 96 4.4.2 Project Sponsors............................................................................................................... 98 4.4.3 Project Managers.............................................................................................................. 99 4.4.4 Hypothesis Development ................................................................................................. 99 4.4.5 Research Methodology................................................................................................... 101 4.4.6 Web Survey Analysis ..................................................................................................... 103 4.4.7 Proposed Definitions...................................................................................................... 107 4.4.8 ERP Project Structure Typologies.................................................................................. 107

4.4.9 Discussion ...................................................................................................................... 108 4.5 Comparison with Further ERP CSF Models ........................................................ 109 4.6 Our Extended CSF Unified Model......................................................................... 111 4.7 Conclusions .............................................................................................................. 111 4.8 References ................................................................................................................ 112

Chapter 5 Critical Success Factors Relevance....................................................... 116 5.1 Software Project Overview..................................................................................... 117

5.1.1 Software Project Structure ............................................................................................. 117 5.2 CSF Relevance Overview........................................................................................ 119

5.2.1 CSF Relevance in ERP context ...................................................................................... 119 5.3 Process Quality Management Method Overview ................................................. 121

5.3.1 Building the PQM Matrix of CSF vs. Business Processes ............................................. 121 5.3.2 PQM Matrix Detail Section............................................................................................ 122 5.3.3 PQM Matrix Analysis Section ....................................................................................... 123 5.3.4 Establishing the Most Critical Processes........................................................................ 123

5.4 SAP Implementation Methodologies ..................................................................... 124 5.4.1 ASAP Implementation Methodology............................................................................. 124 5.4.2 Other SAP Methodologies ............................................................................................. 124

5.5 Research Methodology............................................................................................ 126 5.5.1 Validation....................................................................................................................... 127

5.6 Critical Success Factors Relevance Schema.......................................................... 129 5.6.1 Organizational Perspective............................................................................................. 130 5.6.2 Technological Perspective.............................................................................................. 131 5.6.3 Strategic and Tactical Factors along the ERP implementation Phases........................... 133 5.6.4 Organizational and Technological Factors along the ERP implementation Phases ....... 135

5.7 Identification of the Most Critical Work Packages.............................................. 138 5.7.1 Work Package Criticality Indicator................................................................................ 138 5.7.2 An Example.................................................................................................................... 138 5.7.3 Critical Work Packages per Phase.................................................................................. 139 5.7.4 Overall SAP Work Packages Criticality......................................................................... 141

5.8 Conclusions .............................................................................................................. 144 5.9 References ................................................................................................................ 144

Chapter 6 Pilot Case Study ..................................................................................... 147 6.1 Introduction ............................................................................................................. 148 6.2 Research Methodology............................................................................................ 148

6.2.1 Data Collection............................................................................................................... 148 6.2.2 Data Analysis ................................................................................................................. 149

6.3 Case Study Context ................................................................................................. 151 6.3.1 ERP Implementation Phases .......................................................................................... 151

6.4 A Grounded Model of ERP Implementations....................................................... 152 6.4.1 Phenomenon................................................................................................................... 152 6.4.2 Causal Conditions .......................................................................................................... 153 6.4.3 Environmental Context .................................................................................................. 153 6.4.4 Organizational Context .................................................................................................. 155 6.4.5 Information Technology Context ................................................................................... 156 6.4.6 Intervening Conditions................................................................................................... 156 6.4.7 Action/ Interaction Strategies......................................................................................... 157 6.4.8 Consequences................................................................................................................. 164

6.5 References ................................................................................................................ 165 Chapter 7 Key Performance Indicators for CSF ................................................... 167

7.1 Introduction ............................................................................................................. 168 7.2 Research Methodology............................................................................................ 169 7.3 A GQM Preliminary Plan on ERP Implementations........................................... 169

7.3.1 GQM Method Overview ................................................................................................ 169 7.4 ERP Business Process Reengineering.................................................................... 170

7.4.1 BPR and ERP ................................................................................................................. 171 7.4.2 Towards a BPR Strategic View for ERP Implementations ............................................ 172 7.4.3 Measurement Goal of the GQM Preliminary Plan ......................................................... 174 7.4.4 Questions........................................................................................................................ 174 7.4.5 Description of Metrics.................................................................................................... 174 7.4.6 Interpretation of BPR Metrics ........................................................................................ 176

7.5 ERP Sustained Management Support ................................................................... 176 7.5.1 Management Support ..................................................................................................... 177 7.5.2 Management Commitment............................................................................................. 177 7.5.3 Measurement Goals of the GQM Preliminary Plan........................................................ 179 7.5.4 Questions........................................................................................................................ 180 7.5.5 Description of Metrics.................................................................................................... 180 7.5.6 Interpretation of Metrics................................................................................................. 181

7.6 ERP Adequate Training Program ......................................................................... 182 7.6.1 Training Methods ........................................................................................................... 183 7.6.2 Training Schedule .......................................................................................................... 183 7.6.3 Training Curriculum....................................................................................................... 184 7.6.4 Training Evaluation........................................................................................................ 184 7.6.5 An ERP Training Framework Proposal.......................................................................... 185 7.6.6 Training as a Continuous Process .................................................................................. 186 7.6.7 Goals of the GQM Preliminary Plan .............................................................................. 187 7.6.8 Questions........................................................................................................................ 187

7.6.9 Description of Metrics.................................................................................................... 187 7.7 ERP User Involvement and Participation............................................................. 188

7.7.1 User Involvement ........................................................................................................... 189 7.7.2 User Participation........................................................................................................... 190 7.7.3 User Involvement/Participation in the ERP Implementation Context............................ 191 7.7.4 A Framework for Monitoring User Involvement and Participation Proposal ................ 193 7.7.5 Goals of the GQM Preliminary Plan .............................................................................. 194 7.7.6 Questions and Metrics.................................................................................................... 195 7.7.7 Description of Metrics.................................................................................................... 197 7.7.8 Interpretation of Metrics................................................................................................. 198

7.8 Towards a Framework to Develop KPI................................................................. 199 7.9 Considerations ......................................................................................................... 199 7.10 References ............................................................................................................ 200

Chapter 8 Confirmatory Case Study....................................................................... 204 8.1 Introduction ............................................................................................................. 205 8.2 ERP in Higher Education Institutions: Literature review .................................. 205 8.3 Case Study Context ................................................................................................. 206

8.3.1 ERP Implementation Phases .......................................................................................... 207 8.4 Research Methodology............................................................................................ 208

8.4.1 Data Collection............................................................................................................... 208 8.4.2 Data Analysis ................................................................................................................. 209

8.5 A Grounded Theory Model for ERP Implementations ....................................... 210 8.5.1 Phenomenon................................................................................................................... 210 8.5.2 Causal Conditions .......................................................................................................... 211 8.5.3 Environmental Context .................................................................................................. 211 8.5.4 Organizational Context .................................................................................................. 211 8.5.5 Information Technology Context ................................................................................... 212 8.5.6 Intervening Conditions................................................................................................... 212 8.5.7 Action/ Interaction Strategies......................................................................................... 212 8.5.8 Consequences................................................................................................................. 229

8.6 Comparison with the Pilot Case Study.................................................................. 231 8.6.1 Causal conditions ........................................................................................................... 231 8.6.2 Organizational Factors ................................................................................................... 231 8.6.3 Technological Factors .................................................................................................... 244 8.6.4 Consequences................................................................................................................. 250

8.7 SHEI-CSF Relevance .............................................................................................. 252 8.8 Key Performance Indicators .................................................................................. 255 8.9 Conclusions .............................................................................................................. 255

8.10 References ............................................................................................................ 256 Chapter 9 Contributions and Further Research.................................................... 260

9.1 Research Questions Addressed .............................................................................. 261 9.2 Methodological Contributions................................................................................ 262 9.3 Trustworthiness ....................................................................................................... 263 9.4 Limitations of this Research ................................................................................... 264 9.5 Implications.............................................................................................................. 265

9.5.1 Implications for Further Research.................................................................................. 265 9.5.2 Implications for Practitioners ......................................................................................... 267

9.6 Summary of Contributions..................................................................................... 269 9.7 References ................................................................................................................ 270

Appendix A: SAP System Overview Appendix B: Summary of Research Topics along the ERP lifecycle. Appendix C: An Overview of the major IS Research paradigms. Appendix D: PQM matrix for each SAP Implementation Phase.

LIST OF TABLES Table 1. IS research representation by organizational topic (source Vessey et al. 2002). ..................... 31 Table 2. IS events and journals surveyed................................................................................................ 38 Table 3. ERP publications at selected international IS conferences 1997-2000 .................................... 39 Table 4. Most common used research methods....................................................................................... 52 Table 5. Characteristics of multimethod designs (source: Morse 2003). ............................................... 69 Table 6. Three worlds relevant to research methods (source: Mingers 2001). ...................................... 70 Table 7. Multimethod research framework proposal.............................................................................. 74 Table 8. CSF studies found in the literature review................................................................................ 86 Table 9. The coding table for adequate training program CSF.............................................................. 87 Table 10. The list of CSF and the respective citations.............................................................................. 88 Table 11. The CSF categorization using the CSF framework................................................................... 89 Table 12. Unified critical success factors model. ..................................................................................... 89 Table 13. CSF literature relevance by perspective. .................................................................................. 90 Table 14. Pinto and Slevin CSF model and Standish Group model.......................................................... 94 Table 15. Comparison between risk factors and CSF in ERP projects..................................................... 95 Table 16. Some champion definitions found in literature (source Roure 1999). ...................................... 97 Table 17. Words count for project champion definitions.......................................................................... 98 Table 18. Categories of answers (%) for project champion role choice................................................. 104 Table 19. Identification of project champion by respondent type. .......................................................... 104 Table 20. Identification of the most critical figure in an ERP implementation by respondent type........ 106 Table 21. Comparison with further CSF models..................................................................................... 109 Table 22. The extended unified critical success factors ERP model. ...................................................... 111 Table 23. Example of the matrix CSF versus ASAP work packages for project preparation phase. ...... 122 Table 24. Comparing conventional and SAP methodologies (source: Khan 2002)................................ 125 Table 25. CSF relevance along the SAP implementation phases............................................................ 129 Table 26. Strategic and tactical perspectives along ERP implementation phases.................................. 134 Table 27. Organizational and technological perspectives along ERP implementation phases. ............. 136 Table 28. Formal definition of criticality indicator. ............................................................................... 138 Table 29. Work packages criticality by ASAP phase. ............................................................................. 140 Table 30. Information technology evolution in Photopics ...................................................................... 151 Table 31. ERP implementation phases in Photopics............................................................................... 151 Table 32. Cultural dimensions suggested by Hofstede (1991) with score and mean for Portugal. ........ 154 Table 33. Main issues in a BPR approach during an ERP implementation project. .............................. 173 Table 34. Goal for comprehensive business process reengineering CSF. .............................................. 174 Table 35. The definition of questions related with business process reengineering CSF. ...................... 174 Table 36. The definition of metrics for BPR and their relationship with questions. ............................... 175 Table 37. Goals for top management support CSF................................................................................. 179 Table 38. The definition of questions for top management CSF. ............................................................ 180

Table 39. The definition of metrics for top management and their relationship with questions. ............ 181 Table 40. ASAP Training activities of ASAP implementation methodology. .......................................... 186 Table 41. Goal for adequate training program CSF. ............................................................................. 187 Table 42. The definition of questions for adequate training program CSF. ........................................... 187 Table 43. The definition of metrics for training and their relationship with questions........................... 188 Table 44. Roles used along a SAP implementation project. ................................................................... 193 Table 45. Goals for user involvement and participation CSF. ............................................................... 195 Table 46. The definition of questions for user involvement measurement goal. ..................................... 195 Table 47. The definition of questions for user participation measurement goal..................................... 195 Table 48. The set of metrics for user participation goal. ........................................................................ 197 Table 49. The relationship between questions and metrics for user involvement. .................................. 197 Table 50. Information technology evolution in SHEI. ............................................................................ 207 Table 51. ERP implementation phases in SHEI...................................................................................... 207 Table 52. SHEI-CSF relevance along the ERP implementation phases. ................................................ 252 Table 53. Pilot case study trustworthiness.............................................................................................. 263 Table 54. Confirmatory case study trustworthiness................................................................................ 264

LIST OF FIGURES

Figure 1. ERP characteristics (source: Uwizeyemungu and Raymond 2004).......................................... 16 Figure 2. Thesis roadmap followed. ......................................................................................................... 23 Figure 3. Factor research view (source: Sarker 2000). ........................................................................... 29 Figure 4. Process research view (source: Sarker 2000)........................................................................... 30 Figure 5. Socio-technical research view. ................................................................................................. 30 Figure 6. An ERP lifecycle framework proposal. ..................................................................................... 33 Figure 7. Number of ERP Publications by category. ............................................................................... 40 Figure 8. Number of ERP publications related with each topic of implementation phase. ...................... 41 Figure 9. The ERP decision-making implementation framework. ............................................................ 47 Figure 10. A CSF conceptual framework. .................................................................................................. 48 Figure 11. Conceptual research framework. .............................................................................................. 65 Figure 12. Multimethod research framework Proposal. ............................................................................ 73 Figure 13. Types of respondents in our web survey. ................................................................................ 102 Figure 14. Identification of project champion figure. .............................................................................. 103 Figure 15. Identification of the most critical figure in an ERP implementation....................................... 105 Figure 16. A typical implementation project structure............................................................................. 118 Figure 17. CSF relevance research framework followed. ........................................................................ 127 Figure 18. Most relevant CSF model proposal for a typical SAP implementation project. ..................... 133 Figure 19. Strategic and tactical perspectives along ERP implementation phases.................................. 134 Figure 20. Organizational and technological perspectives along ERP implementation phases. ............. 136 Figure 21. Most critical work packages in project preparation phase..................................................... 139 Figure 22. Analysis of organizational versus technological SAP work packages. ................................... 142 Figure 23. Criticality analysis along SAP implementation phases........................................................... 143 Figure 24. An exploratory model for ERP implementation projects. ....................................................... 152 Figure 25. The ERP implementation project structure............................................................................. 158 Figure 26. BPR concerns in the ERP context. .......................................................................................... 172 Figure 27. Graphical representation of the GQM plan for BPR. ............................................................. 175 Figure 28. Top Management concerns in the ERP context. ..................................................................... 179 Figure 29. Graphical representation of the GQM plan for sustained management support. ................... 181 Figure 30. A proposed ERP training framework...................................................................................... 186 Figure 31. Graphical representation of the GQM plan for training. ....................................................... 188 Figure 32. Constructs proposed by different authors for user involvement and participation................. 191 Figure 33. A framework for monitoring user involvement and participation in ERP projects................. 194 Figure 34. A framework to develop KPI for ERP implementations.......................................................... 199 Figure 35. ERP project duration in SHEI. ............................................................................................... 208 Figure 36. A model for ERP implementation projects.............................................................................. 210

Chapter 1 – Introduction 15

Chapter 1

Introduction

Chapter Summary: This chapter introduces the doctoral research project that has been undertaken, giving an outline of why such research has been done, placing the research in context and demonstratingits importance. This chapter first describes an overview of ERP systems, analyzing the differentmeanings for them, their historical account, typical functional modules, product lifecycle,motivations for their adoption and benefits achieved. Then, the research questions are outlined andan overview of the chapters within this thesis is presented.

The focus of this dissertation is on the definition and analysis of Critical Success Factors (CSF)

in Enterprise Resource Planning (ERP) systems projects. The interest of studying CSF for ERP implementation projects is because the Information Systems (IS) implementation literature, while acknowledging adaptation as one phase in the process, offers little theory to address the problems faced during implementation of packaged application software (Holland and Light 1999, Volkoff 1999, Esteves and Pastor 2001). Furthermore, there is the personal motivation and curiosity to know why it is difficult to adopt an IS even if it follows (from a technology and conceptual perspective) the needs of an organization. Many organizations have tried ERP implementations and it is obvious these implementations are difficult and that success is not guaranteed.

1.1 ERP Overview

ERP stands for Enterprise Resource Planning. Other common names used are: Enterprise Information Systems (EIS), Enterprise Wide Systems (EWS) or Enterprise Systems (ES). Enterprise systems are “commercial software packages that enable the integration of transaction-oriented data and business process throughout an organization” (Markus and Tanis, 2000, p. 176). Typically, ERP systems are software packages composed of several modules, such as human resources, sales, finance and production, providing cross-organization integration of transaction-based data throughout embedded business processes. These software packages can be customized to the specific needs of each organization up to certain limits (Esteves and Pastor 1999, Pastor and Esteves 1999). As Klaus et al. (2000) state, in the IS literature we observe some dissent among academics on the nature and definition of ERP. Some authors (Davenport 2000, Laudon and Laudon 2000) advise against the use of the term ERP and suggest alternatives; others (e.g. Pawlowski et al. 1999) state that ERP is not a term referring to a distinct object but rather a category (“umbrella term”), signifying a range of similar products. Yet others explain the ERP


concept in terms of its historical evolution, relating it with manufacturing and supply chain management. It is unlikely that a broadly agreed upon definition can be achieved.

In the literature there is a consensus that ERP are indeed expected to support the enterprise's operations and provide its various levels of management with information in a highly integrated manner. When integrated beyond the confines of the individual enterprise with the systems of its business partners, such extended ERP systems engender a vision of a network of value-creating processes cutting across organizational boundaries. ERP can form a fundamental platform for the informational infrastructure of an enterprise. Based in literature review, Uwizeyemungu and Raymond (2004) have attempted to identify the characteristics generally attributed to ERP systems (see figure 1).

Technical

Organizational

Informational

Adaptability

Integration

Transversality

Openness

Completeness

Homogenization

Best practices

Real time

Simulation

ERP

Figure 1. ERP characteristics (source: Uwizeyemungu and Raymond 2004).

Nowadays, new terms have been proposed, such as ERP II, and Enterprise Resource Management (ERM). The term ERP II was created by Gartner Group and it is defined as “a business strategy and a set of industry-domain-specific applications that build customer and shareholder value by enabling and optimizing enterprise and inter-enterprise, collaborative operational and financial processes” (Bond et al. 2000).

There are over 1000 ERP vendors and solutions to from which to choose (Anderegg 2000). “However, most of them are very small and escape the detection of companies looking for new ERP systems” (Anderegg 2000, p. 9). As Oliver and Oliver (2002, p. 508) mention the extent to which ERP systems are shaping the IT industry are captured in the following comparison: “Twelve years ago, IT people identified their organizations as IBM or Digital shops, says Bruce


Richardson, VP of research at AMR research inc. They are now more likely to be SAP or Peoplesoft” (Sweat 1998).

1.1.1 ERP Historical Account

The roots of ERP systems can be traced back to the Material Requirements Planning systems (MRP) in the 70’s. These systems evolved to the Manufacturing Resource Planning systems (MRPII). (Shankarnarayanan 1999) identifies four phases in the ERP systems history:

• The 1960’s - Most of the software packages (then usually bespoke developed) were designed to handle inventory based on traditional inventory concepts.

• The 1970’s - The focus shifted to MRP systems which translated the master schedule built for the end items into time-phased net requirements for the sub-assemblies, components and raw materials planning and procurement.

• The 1980’s - The concept of MRP-II systems evolved, as an extension of MRP to shop floor and distribution management activities.

• The early 1990’s - MRP-II was further extended to cover areas like engineering, finance, human resources, project management, i.e. the almost complete gamut of activities within any business enterprise. Hence, the term ERP (enterprise resource planning) was coined.

Hoy (1996) mentions that ERP systems follow the trend of its predecessors: MRP-II systems

that consisted in a change from a materials emphasis to a holistic view of the manufacturing environment. Additionally, ERP systems add technology aspects to the overall system requirements. These include features such as a client/server-distributed architecture, and Object-Oriented Programming (OOP) development practices. Both of these factors help with the scalability task. This scalability and their evolution towards including supply chain and customer relationship management operations provide the extension into customer and supplier environments.

1.1.2 ERP Functional Modules

The ERP functional capabilities are generally grouped into functional modules. This perspective gives the organization implementing an ERP system the possibility to choose only the modules that serve the interest of its business. The functionality may be expanded in the future by implementing additional modules. In chapter 5, the pilot case study chapter, we explain in detail the SAP system functional modules. We would like to mention that each vendor has its own way of thinking the composition of the ERP functional modules.

In other cases, these functional capabilities are spread across different modules. According to Anderegg (2000, p. 43), “in many cases ERP vendors use terminology specific to their own product in describing a particular ERP functional module…be careful in comparing ERP systems based on terminology, for it is better to compare them based on functional capabilities”.


1.1.3 ERP Product Lifecycle and Market

One of the main issues within ERP area is to know how long an ERP product may remain in the market, i.e. the ERP product lifecycle. Usually, to study this issue the Boston Matrix technique is used. The theory underlying the Boston Matrix is the Product lifecycle concept, which states that business opportunities move through 'lifecycle' phases of introduction, growth, maturity and decline. The Boston Matrix focus is based in the market growth versus market share. These are the two axes that define four quadrants which define the product categories: cash cows, stars, dogs, and babies. Janstal (2002) evaluated different ERP packages and he mapped them in a Boston Matrix which is available in http://www.dpu.se/boston_e.html. Janstal (2002) alerts that “ideal is to find mature “STARS” in the evaluation and selection of packages. STARS are often subject to development, the vendor makes lots of profit, the remaining life time for the package is satisfactory long and most of the bugs are gone. But very few systems are for the moment found in this section of the Boston Matrix”. According to his account, “an ill performed business application or ERP package can be sold and maintained at most in 15-20 years. In late stage the package has old architecture and contains of ‘spaghetti code’. It is hard (sometimes impossibly) to make changed in the program code without hazardous damage the systems stability” (Janstal 2002).

According to Janstal (2002), SAP AG is still the market leader for ERP systems. The company is the largest vendor of ERP systems. Their global market share is 12%. SAP has done a powerful redesign in order to integrate SAP R/3 with CRM, e-Business, SCM, APS and other new extended ERP applications. An overview of SAP system is provided in appendix A.

Regarding the ERP market, mostly of the studies are published by consulting companies. For instance, a survey from AMR research confirmed that ERP will remain the biggest segment of large and mid-size company IT applications budgets through 2004 (Seewald 2002). The only academic study we found about ERP market is the one conducted by Everdingen et al. (2000). They studied the ERP adoption by European midsize companies using a European multi-country/multi- industry survey conducted in mid-1998. Although the study is not recent, it shows that the penetration of ERP vendors was growing considerably during the period 1998-2000. According to their findings and from the viewpoint of clients, the fit with business processes was the most important selection criterion for a new ERP system. “At the same time companies within the mid-market rate a low price and short implementation times as highly important” (Everdingen et al. 2000, p. 31). At that time, some of the ERP vendors Ire attempting to satisfy these requirements by offering “accelerated” implementation methods. Roughly 11% of companies had an ERP implemented.

1.1.3.1 ERP Market in Spain

According to a study conducted by Grupo Penteo an IESE business school (Grupo Penteo 2002), 70% of the Spanish companies implemented an ERP system. However, the study also shows that only 13% of these companies fully use the functionality of their ERP systems. SAP system is the most implemented ERP system (62 %), followed by JD Edwards (8%), Movex (7%), and BAAN (5%). According to the study the main reasons for SAP system choice are: the high


functionality offered, and its innovative vision of corporate applications. Next, we briefly describe the SAP system.

1.1.4 ERP Importance

The importance of ERP was already evidenced by several studies such as: • Approximately $300 billion has been invested in ERP worldwide in the last decade

(Carlino et al. 2000). • More than 60% of Fortune 1,000 companies had implemented core ERP applications

manufacturing, financials, and human resources (Stein 1999). ITtoolbox (http://ittoolbox.com) conducted its 2004 ITtoolbox ERP Implementation Survey

from March 17 to March 19, 2004. Over 375 IT and business professionals from around the world participated in this online survey. Participants were recruited directly from the ITtoolbox network. The 2004 ITtoolbox ERP Implementation worldwide survey reveals that the IT professionals surveyed:

• 52% anticipate budget increases for new ERP implementations/new modules deployments in 2004.

• SAP and PeopleSoft/J.D. Edwards were cited as the most popular ERP packages for new implementations and replacements.

• 65% are considering adding new modules to their existing ERP packages. • 46% indicated that the main challenge to successful ERP implementations was

inadequate definition of requirements and resistance to change. Davenport (1998, p. 122) characterized ERP as “the most important development in the

corporate use of technology in the 1990s”. By utilizing packaged ERP software like those offered by companies such as SAP, BAAN, PeopleSoft and Oracle, companies seek to integrate the flow of information between different segments of their business while improving efficiency and reducing costs. Theoretically, these integrated systems provide broad functionality while reducing problems associated with data flow when interfacing between different software systems. According to (O'Leary 2000, p. 3) “ERP are a corporate marvel, with a huge impact on both the business and information technology worlds, including each of the following dimensions:

• ERP affects most major corporations in the world. • ERP affects many Small and Medium Enterprises. • ERP affects competitor's behavior. • ERP affects business partner requirements. • ERP has changed the nature of consulting firms. • ERP provides one of the primary tools for reengineering. • ERP has diffused many “best practices”. • ERP gave client server computing its first enterprise product. • ERP has changed the nature of the information system functions. • ERP has changed the nature of jobs in all functional areas. • ERP costs are high. • ERP has experienced huge market growth”.


1.1.5 Motivation and Benefits for adoption of ERP

According to Ross and Vitale (1998) the six common motivations to ERP implementations are: The need for a common platform, process improvement, data visibility, operating cost reductions, increased customer responsiveness, and improved strategic decision making. Another study by Deloitte Consulting (1998) of selected individuals from 62 organizations found that motivations for an ERP implementation fell into two broad categories: a solution of technological problems and a vehicle for solving operational problems such as uncompetitive business performance and ineffective business processes. Markus and Tanis (2000) presented reasons why organizations implement ERP systems and discuss issues related to ERP systems success (see chapter 3 for an analysis about this topic). A number of points raised in their discussion can usefully be applied to analyze the question of how to assess the benefits of ERP implementation.

Prior research has reported mixed results with regard to the effect of ERP systems adoption on a firm’s long-term financial performance (Nicolaou 2004). The media are plenty of articles about ERP benefits and costs rates. For instance, in 1997 Appleton (1997) estimated that half of the ERP implementations failed to meet expectations. Other recent studies show that more than 70% of ERP implementations fail to achieve their estimated benefits (Al-Mashari 2000). Other survey from (Themistocleous et al. 2001) shows that organizations acquire benefits such as an increase in suppliers’ and customers’ satisfaction and an increase in productivity but the level of the Return On Investment (ROI) is rather low.

Lately, different ERP benefits and costs models have been published such as: Shang and Seddon (2000), Gattiker and Goodhue (2000), Esteves et al. (2001), Stefanou (2001), Murphy and Simon (2002). The most cited study is the one of Shang and Seddon (2000). They present a list of business benefits categorized in five dimensions. However, lately this study has been criticized. The two main reasons for the criticisms are the lack of relationship between benefits and ERP goals and the timeframe to realize these benefits. Markus and Tanis (2000, p. 186) note that the benefits of ERP systems implementation should be assessed in relation to the organization’s unique goals for the system. They also state that the measures of ERP success (the benefits attained) are relative to the period of time during which they are assessed. Davenport (2000) states that there are different types of benefits and that some types are likely to arise before others e.g. benefits from improved transactional processes and common data appear to precede benefits associated with improvements in management and decision-making. Therefore, according to O’Grady (2002), “a framework for assessing the benefits of ERP systems should therefore reflect both the objectives for implementing the system and the timing differences for the realization of each type of benefit”. For an extended reading on the potential benefits of ERP systems see O’Grady (2002).


1.2 Objectives of the Research

Since there were only a few research studies about CSF in ERP implementation projects reported in the literature when this research was initiated, the need and opportunity to conduct a doctoral research study in this area became rather obvious. A doctoral research study that would explain CSF in ERP implementations would benefit both academics and practitioners. This thesis is centered on a specific phase of the ERP lifecycle, the ERP implementation phase. After an extensive literature review on the ERP research, we detected a lack of this thesis focuses on the identification and management of critical success factors for ERP implementation projects. The general research questions of the doctoral research study are the following:

• What are the CSF for an ERP implementation project? CSF should be analyzed with respect to organizational and technological perspectives, at least.

• What is the relevance of each CSF along the typical implementation project phases?

• How these CSF are managed and influence ERP implementation projects?

• What are the key performance indicators related to the above CSF? These key performance indicators help in the control and monitoring of CSF.

The main research goal of this study is to gain an understanding of project management

practices in the realm of ERP implementation by focusing on the analysis of CSF and the generation of KPI. Therefore, the project aims to contribute to the monitoring of the implementation phase, to help managers in the task of project management. We attempt to achieve the following goals:

• Definition of CSF needed for a successful ERP implementation. All the studies related with CSF and ERP implementations are based on case studies so, first, we attempted to unify these CSF in a unique model.

• Understand how these CSF are managed in ERP implementations. • Generation of a set of KPI to help with the monitoring of CSF. Usually, once CSF

are established, each process and department is encouraged to identify indicators that can be used to measure its contribution. KPI can be used to monitor the ERP implementations and, help in CSF analysis, thus helping managers in the decision making process related to the ERP implementation phase.

According to Kulik (1997) the importance of understanding why projects succeed is because

“repeating what worked on successful projects is a powerful strategy to ensure the success of future projects”.


1.3 Thesis Contributions

The thesis contributes with: • An annotated bibliography which is a reference for researchers interested in the

implementation of ERP systems. • A new CSF unified model for ERP implementation projects which combines previous

research CSF studies. It extends previous research by providing a definition for each CSF and categorizing them in four perspectives: organizational, technological, strategic and tactical.

• A CSF relevance schema along the ERP implementation phases. • A new criticality indicator for defining the most critical processes using PQM method. • The definition of the most critical processes on SAP implementations based on ASAP

implementation methodology. • A set of KPI for some CSF and a systematic approach to develop the rest of KPI. • A CSF management analysis in two organizational contexts: a small and midsized

enterprise and a public higher education institution. • A novel grounded theory model for ERP implementation projects.


1.4 Organization of the Thesis

This thesis is structured to guide the reader through the different phases of the doctoral project. Figure 2 presents the thesis ‘roadmap’, which includes the multimethod research approach followed.

ERP Literature Review

Thesis Introduction

Thesis Contributions

Research Design

5 - Goals/Questions/Metrics

6 - Case Study7 - Grounded Theory8 - Stakeholder Analysis

CSFs Management(4 – Pilot Case Study)

CSFs Relevance( 2- Process Quality

Management3- Survey)

CSFsIdentification

( 1- coding procedure)

CSFsIdentification


Key Performance Indicators

Confirmatory Case Study

ERP Context

1

3

2

7

4

6

5

9

8

Figure 2. Thesis roadmap followed.


Once the above overview on ERP systems has been provided, we present below a brief outline of the topics addressed in this thesis. This doctoral thesis is organized in nine chapters plus appendices. The initial three chapters deal with general concepts – thesis introduction, literature review, and research methodology. Then, the next chapters deal with the initial phase of the multimethod research approach that we have followed. Finally, the contributions chapter is presented.

In Chapter 2 the literature review on ERP research and CSF is presented. This literature review shows that ERP researchers have mainly concentrated on issues related to the implementation phase of the ERP lifecycle. Until now, the other phases have been 'almost forgotten'. One of the main reasons is that the majority of organizations are in the implementation phase. Also, in some phases, namely acquisition and implementation phases, there is a strong intervention of consultants, which makes very difficult the access to information. ERP systems offer many potential areas for research, several of which were discussed in this literature review. Due to their pervasive nature, ERP systems are of interest for a wide range of professional and scholarly communities (from software engineering to accounting), apart from the IS field. This suggests that ERP-related research could or should be interdisciplinary. The literature review on CSF approach reveals that this approach has been widely used in different disciplines, especially in IS. Based on the literature review, a CSF identification framework is proposed.

In Chapter 3 the research methodology undertaken in this doctoral research is described. Therefore, the purpose of this chapter is to present the thesis conceptual framework, the research paradigm, expound the research strategy, including the research methods and techniques adopted. The chapter reports on the multimethod research focus that this doctoral research project has taken. The doctoral research framework presents the different phases of the research study, with the different research methods mapped and linked in each phase. Considering the research questions and the research context, we rationally selected those research methods that could be useful to address our research questions as well as their combination. Finally, we propose the principles for evaluation of interpretive research in IS research.

In Chapter 4 a unified CSF model for ERP implementations is defined. This model was developed through the application of open coding procedure from grounded theory method and based in a set of previous CSF lists. We also compare the CSF for ERP implementations with CSF for other IS implementation projects. We present an analysis of ERP CSF as perceived risk factors for ERP implementations and we compare the CSF unified model with the list of risk factors for ERP implementations. This comparison shows that most of the CSF may be perceived as risk factors. Finally, we present a study that we carried out to clarify project champion CSF since during the literature review we found some misunderstandings regarding this figure. The findings show that the project champion is associated to the project sponsor role and that project sponsor and project manager are both identified as CSF for ERP implementation projects. Therefore, the CSF unified model was extended to incorporate these CSF.

In Chapter 5 the analysis of the CSF relevance along the typical ERP implementation phases using the Process Quality Management (PQM) method is presented. By applying PQM method and using the ASAP implementation methodology as a reference for the SAP implementation processes, we defined the CSF relevance for each CSF along the SAP implementation phases. Then we extrapolated our findings to other ERP studies by comparing our relevance schema with others proposed by other colleagues. One of the limitations of PQM is that the process structure of


the PQM method is too simple since it only provides one level of process analysis. Since most cases imply project process structures that are more complex, such as ERP implementation processes structure, here we propose the improvement of the PQM analysis section to provide more depth to complex project structures. We propose an extension to the standard PQM method, where we provide a new criticality indicator for complex implementation project process structures. This criticality indicator was used to define and analyze the most critical SAP implementation processes.

In Chapter 6 a pilot case study of an ERP implementation in a Portuguese SME is described. We focused on the identification of organizational factors that affected the ERP implementation project. The pilot case study helped to test the research framework and the preparation of the in-depth case study, especially the interview questions. As outcomes, there was a preliminary list of findings regarding CSF management, and a grounded theory ERP implementation model. We also analyze the ERP implementation project from a national cultural perspective using Geert Hofstede’s dimensions. These dimensions are used to explain some of the attitudes and behaviors during the ERP implementation project. Our findings enforce that some of the problems in ERP implementation projects are not of technological nature but may be attributed to organizational factors while some issues are related to national culture. Finally, we also discuss the issue of defining ERP implementation success as solely on time, on budget and providing the required functionality. The findings show that even when the project is not on time and within budgets, managers still thinking that it was a success since most of the times the initial project duration and budget predictions may be unrealistic or not update along the ERP implementation phases.

In Chapter 7 a set of Key Performance Indicators (KPI) for some CSF were developed using the Goals/Questions/Metrics (GQM) method. The GQM method is a mechanism for defining and interpreting operational, measurable goals. Because of its intuitive nature the approach has gained widespread appeal. As a result, we propose a GQM preliminary plan with different metrics to monitor and control CSF while implementing an ERP system. Due to the extensive number of CSF we will focused on the most frequently cited CSF and the ones we had some working experience in the past. Thus, we propose set of metrics using GQM for: sustained management support, business process reengineering, adequate training program, and user involvement and participation. The idea of this work is not to present an exhaustive list of KPI. Instead, we attempt to present a form to develop these metrics in future ERP implementation projects and provided the first set of metrics that should be extended and adapted according to the specific needs of ERP implementation projects. Therefore, we present a general framework to develop KPI for the rest of CSF.

In Chapter 8 an in-depth case study of an ERP selection and implementation in a public HEI is described. This case study helped to validate the theory developed and the research propositions defined in previous chapters. Special attention has been paid to contextual influence and to organizational factors. Furthermore, this case study helped to validate the theory developed and the research propositions defined in previous chapters. We also compare the findings of this case study with the pilot case study. Finally, we present an analysis of the CSF relevance along the ERP implementation phases of this case study.

In Chapter 9 the thesis contributions and how we believe that this research contributes to the current body of knowledge on ERP are presented. Each research question is revisited and discussed. The additional contributions and key findings of the study, along with limitations of the


study are also presented. Then, we describe the implications for practitioners and for ERP/IS research. Finally, we evaluate the trustworthiness of this doctoral research.

We added some appendices to provide greater depth of understanding of some aspects discussed in the thesis. The appendices are:

A: SAP system overview. B: Summary of Research Topics along the ERP lifecycle. C: An Overview of the major IS Research paradigms. D: PQM matrix for each SAP implementation phase.

1.5 References

Al-Mashari M. 2000. “Constructs of process change management in ERP context: a focus on SAP R/3”, Sixth Americas Conference on Information Systems, pp 977-980.

Anderegg T. 2000. “ERP: A-Z Implementer’s Guide for Success”, Resource Publishing, USA. Appleton E. 1997. “How to survive ERP”, Datamation 43, pp. 50–53. Bond B., Genovese Y., Miklovic D., Wood N., Zrimsek B., Rayner N. 2000. “ERP is Dead – Long

Live ERPII”, Research Note SPA-12-0420, Gartner Inc., October 2000. Carlino J., Nelson S., Smith N. 2000. “AMR research predicts enterprise applications market will

reach $78 billion by 2004”, AMR research, Boston 2000. Davenport T. 1998. “Putting the Enterprise into the Enterprise System”, Harvard Business Review,

July-August, 1998, pp. 121-131. Davenport T. 2000. “Mission Critical: Realizing the Promise of Enterprise Systems”, Boston,

Harvard Business School Press. Deloitte Consulting 1998. “ERP’s Second Wave, Maximizing the Value of ERP-enabled

Processes”, Deloitte Touche Tohmatsu, http://www.dc.com Esteves J., Pastor J. 1999. “An ERP Lifecycle-based Research Agenda”, Proceedings of 1st

International Workshop on Enterprise Management and Resource Planning: Methods, Tools and Architectures - EMRPS'99, pp 359-371.

Esteves J., Pastor J. 2001. “Enterprise Resource Planning Systems Research: An Annotated Bibliography”, Communications of the Association for Information Systems (CAIS), 7(8).

Esteves J., Carvalho J., Santos A. 2001. “Towards an ERP Lifecycle Costs Model”, Information Resources Management Association (IRMA) International Conference, Toronto (Canada), pp. 431-435.

Everdingen Y., Hillegersberg J., Waarts E. 2000. “ERP Adoption by European Midsize Companies”, Communications of the ACM, 43(4), pp. 27-31.

Gattiker T., Goodhue D. 2000. “Understanding the Plant Level Costs and Benefits of ERP: Will the Ugly Duckling Always Turn into a Swan?”, Hawaii International Conference on System Sciences, vol. 7.

Grupo Penteo 2002. “Aplicaciones Corporativas: situación en España y tendencies futures”, Grupo Penteo report, 2002.

Holland C., Light B. 1999. “A Critical Success Factors Model for ERP Implementations”, Focus, IEEE Software May/June 1999, pp 30-36.

Hoy P. 1996. “The Changing Role of MRP II”, APICS Magazine, 6(6), June 1996.


Janstal S. 2002. “Lifecycles for Business Applications and ERP Systems”, Data Research DPU for Evaluation of Information Technology, white paper, 2002, http://www.dpu.se/boston_e.html

Klaus H., Rosemann M., Gable G. 2000. “What is ERP?”, Information Systems Frontiers, 2(2), pp. 155-176.

Kulik P. 1997. “Software Project Success Factors”, white paper, February 1997. Laudon K., Laudon J. 2000. “Management Information Systems: Organization and Technology in

the Networked Enterprise”, Upper Saddle River, Prentice Hall. Markus M., Tanis C. 2000. “The Enterprise Systems Experience- From Adoption to Success”, In

Framing the Domains of IT Research Glimpsing the Future Through the Past, R. W. Zmud (Ed.), Pinnaflex Educational Resources, Cincinnati, OH.

Murphy K., Simon S. “Intangible Benefits Valuation in ERP Projects”, Information Systems Journal, 12(4), pp. 301-320.

Nicolaou A. 2004. “Firm Performance Effects in Relation to the Implementation & Use of ERP Systems”, America Accounting Association Mid-Year conference, Florida (USA).

O’Grady W. 2002. “Assessing Benefits from ERP Systems Use”, The Accounting and Finance Association of Australia and New Zealand conference, 2002.

O'Leary D. 2000. “Enterprise Resource Planning Systems: systems, lifecycle, electronic commerce, and risk”, Cambridge University Press, 2000.

Oliver D., Oliver L. 2002. “ERP Adoption: Selling the System”, IFIP TC8/W.G. 8.2 conference, Barcelona (Spain), pp. 507- 520.

Pastor J., Esteves J. 1999. “The ERP lifecycle”, Datamation Magazine, Spanish version, December 1999.

Pawlowski S., Boudreau M. 1999. “Constraints and Flexibility in Enterprise Systems: A Dialectic of System and Job”, Americas Conference on Information Systems.

Pinto J., Slevin D. 1987. “Critical Factors in Successful Project Implementation”, IEEE Transactions on Engineering Management, 34(1), pp. 22-27.

Ross J., Vitale M. 1998. “The ERP Revolution: Surviving Versus Thriving”, Research paper, Center for Information Systems research, Sloan School of Management, M.I.T.

Seewald N. 2002. “Enterprise Resource Planning Tops Manufacturers’ IT Budgets”, chemical week, 34, September 2002.

Shang S., Seddon P. 2000. “A Comprehensive Framework for Classifying the Benefits of ERP Systems”, Americas Conference on Information Systems (AMCIS), 2000.

Shankarnarayanan S. 1999. “Using IT to gain a competitive advantage”, Baan Infosystems. http://www.expressindia.com/newads/bsl/advant.htm (April 1999).

Stefanou C. 2001. “A framework for the ex-ante evaluation of ERP software”, European Journal of Information Systems, vol. 10, pp. 204–215.

Stein T. 1999. “Enterprise Apps, Big Strides for ERP”, InformationWeek, January 1999, http://www.informationweek.com/715/15iuerp.htm

Sweat J. 1998. “ERP: The Corporate Ecosystem”, Information Week online, 1998. Themistocleous M., Irani Z., O’Keefe R. 2001. “ERP and applications integration, Exploratory

survey”, Business Process Management Journal 7, pp. 195–204. Uwizeyemungu S., Raymond L. 2004. “Integration, Flexibility and Transversality: Essential

characteristics of ERP Systems”, International Conference on Enterprise Information Systems (ICEIS), 1, pp. 70-76.

Volkoff O. 1999. “Using the Structurational Model of Technology to Analyze an ERP implementation”, Americas Conference on Information Systems, August 1999.

Chapter 2 – Theoretical Background and Literature Review 28

Chapter 2

Theoretical Background and Literature Review

Chapter Summary: This chapter presents the literature review on ERP research and CSF which shows that ERP researchers have mainly concentrated on issues related to the implementation phase of theERP lifecycle. Until now, the other phases have been 'almost forgotten'. One of the main reasons isthat the majority of organizations have just passed in the implementation phase. Also, in somephases, namely acquisition and implementation phases, there is a strong intervention ofconsultants, which makes very difficult the access to information. ERP systems offer many potential areas for research, several of which are discussed in this literature review. Due to theirpervasive nature, ERP systems are of interest for a wide range of professional and scholarlycommunities (from software engineering to accounting), apart from the IS field. This suggests that ERP-related research could or should be interdisciplinary. The literature review on CSF approachreveals that this approach has been widely used in different disciplines, especially in IS. Based onthe literature review, we propose a CSF identification framework.


Thesis Introduction


Research Design






CSFsIdentification


CSFsIdentification




ERP Context

2


2.1 Information Systems Implementation Review

ERP systems are integrated IS designed to create a seamless software applications link between all the processes of an organization (Hendrickson 2000) and they support many, even most, aspects of a organization’s information needs (Davenport 2000). Due to its business oriented vision, ERP systems are categorized as business applications. Technically, they are categorized as Commercial Off-The-Shelf (COTS) products. Thus, the existent IS implementation research is a valuable knowledge to ERP arena. As the ERP annotated bibliography presented in the next section shows, most of the IS implementation research findings have been applied to ERP area. IS implementation has been a topic of considerable interest to practitioners as well as academic researchers for over two decades (Sarker 2000). Kwon and Zmud (1987) stated that a better understanding of the IS implementation process and the factors contributing to this process would enable organizations to develop a more effective implementation strategy. This view supports the earlier argument by Ginzberg (1979), who suggested that the better the handling of the implementation process, the greater the chances of successful implementation.

Based in a literature review on IS implementation research, Sarker (2000) defines three main waves of research. The initial studies (e.g. Lucas 1975, Schultz et al. 1984) on IS implementation focused on identifying a broad range of factors that affect the implementation outcome. This research perspective is named factor research (see figure 3).

Individual Variables

Organizational Variables

Situational Variables

Technological Variables

IS ImplementationOutcome(Success)

Figure 3. Factor research view (source: Sarker 2000).

The understanding of the roles of different factors lead to the realization that implementation was not a static phenomenon as previous research had implicitly assumed. The next wave of research took a technical process perspective (see figure 4). Thus, studies (Ginzberg 1979, Galbraith 1979) on IS implementation focused this activity as being either a basically technical process, where system requirements were problematically identified and met, or a technical process with behavioral consequences (Hirschheim et al. 1991).


Process of Implementation Post Implementation Stateof the Organization

Initial Stateof the Organization

Moderating Conditions

Figure 4. Process research view (source: Sarker 2000).

Recently, the IS implementation research has evolved from a technical process perspective to a social-technical perspective (see figure 5). Within this perspective, the organization is implicitly conceptualized as a “diamond,” a model originally proposed by Leavitt (1965), consisting of interacting components: people, tasks, technology, and structure. Introduction of an IS involves changing the organization’s technology component which automatically triggers changes in the other components of the organization.

Organizational Structure

People

Task Technology

Organization

Figure 5. Socio-technical research view.

2.1.1 IS Implementation Research Diversity

A study conducted by Vessey et al. (2002) examined the IS research diversity by analyzing the publications on Top IS journals over a five year period, from 1995-1999. The findings show that organizational concepts is the category that accounts for 65.6 percent of publications in IS top journals. Vessey et al. (2002) divided this category in eleven sub categories (see table 1).


Table 1. IS research representation by organizational topic (source Vessey et al. 2002). Sub-categories Representation (%)

Usage/Operations 24.4 Technology transfer 19.4 IT impact 15.3 Management of computing function 11.6 Organization alignment 6.9 Strategy 6.6 Organization structure 5.0 Learning 4.4 Knowledge management 3.4 Legal and so on change management 1.8 IT implementation 1.5

The findings show that IT implementation topics account for only 1.5 percent of the

publications on top journals while IT/IS usage/operations was the highest topic across all the journals. A similar study conducted by Claver et al. (2000) examined IS research in two top journals information and management and MISQ between 1981-1997, and it shows that IS implementation topic accounts for 5.3 percent of the publications on these two top IS journals. Furthermore, their findings show that topics focusing especially on the IS lifecycle (development and implementation, etc.) despite their global importance, have shown to decrease with the passage of time.

2.1.2 ERP System as a Special Information System

Lucas et al (1988) have stated that implementation of a package differs from that of a custom system in three different ways:

• The user may have to change or add to the programs in the package to fit business requirements.

• The user may have to change business procedures in order to work with the package. • The user develops dependence on the package vendor for assistance and for updates with

the package. One might question the value of studying ERP as a special IS and not treat them as a typical IS.

Sandoe et al. (2001, p. 11) describe the reasons why ERP systems are special IS: • ERP systems by their very design have the broadest reach of all organizational IS and

package software – they are used by every major functional area and at all levels of the organization.

• ERP systems represent a shift in the way most organizations use IS. ERP systems are a broad phenomenon; no longer are they being deployed solely in extremely large organizations, nor are they being used just in certain industries.

• Because of their high degree of complexity and the fact that organizations are increasingly dependent on smooth operation of these systems for their success, the sophisticated skills needed to implement and manage ERP systems are among the most sought after among computing professionals today.


Skok and Legge (2001, p. 189) mention that ERP systems are often viewed as a new paradigm for IS development, because of the following differentiating factors:

• The number and variety of stakeholders in any implementation project. • The high cost of implementation and consultancy. • The integration of business functions. • The consequent configuration of software representing core processes. • The management of change and political issues associated with BPR projects. • The enhanced training and familiarization requirement.

Furthermore, Skok and Legge (2001, p. 189) mention that “historically, software package was

seen to fulfill specific functional roles in an organization. Although current packaged applications, in the form of ERP systems, consist of standard multi-functional, multi-language, multi-legislative software modules, and can offer integration across an entire organization”. With regard to the implementation process, there is also the issue of implementing these complexes and functionally diverse IS in a specific period, with little knowledge about them.

The current IS implementation research does not provide enough findings for these issues. We think that the existent IS implementation is a strong, rigorous and relevant basis to research in ERP field. Thus, we expect that the findings of this thesis may contribute to extend the knowledge on ERP implementations and IS implementations in general.


2.2 ERP Lifecycle Framework

During the literature review phase, we found that there was no consensus regarding the ERP lifecycle phases (see section 2.3 - ERP implementation phase, for a detailed discussion of the topic). Therefore, we (Esteves and Pastor 1999) proposed a framework to study ERP systems. The framework is presented in figure 6. Other authors have proposed models for ERP systems but focusing in the ERP implementation phase. However there is a misunderstood in relation to the concept of implementation. Later, we describe in detail this phase and the related models.

Change ManagementChange Management

PeoplePeople

ProcessProcess

ProductProduct

ImplementationImplementationAcquisitionAcquisition Use &Use &MaintenanceMaintenance EvolutionEvolution RetirementRetirementDecisionDecision

PlanningPlanning

Figure 6. An ERP lifecycle framework proposal.

The framework is structured in phases and dimensions. Phases are the different stages of an ERP system lifecycle within an organization and dimensions are the different viewpoints by which the phases could be analyzed. We describe the dimensions and phases in the following sections. The dimensional vision of the framework presents a set of related issues. For instance, the change management dimension embodies cultural issues, organizational structures, roles and skills, management of strategic change and business process re-engineering. This framework is useful for identifying the origins and impacts of change, and thus provides a way of identifying and characterizing research issues in ERP systems.

2.2.1 Phases of the ERP Lifecycle

The phases of the ERP lifecycle consist in the several stages that an ERP system goes through during its whole life within the hosting organization. They are the following: adoption decision phase, acquisition phase, implementation phase, use and maintenance phase, evolution phase and retirement phase. Next, we describe each phase. 1. Adoption decision phase - This phase is the one during which managers must question the

need for a new ERP system while selecting the general information system approach that will


best address the critical business challenges and improve the organizational strategy. This decision phase includes the definition of system requirements, its goals and benefits, and an analysis of the impact of adoption at a business and organizational level.

2. Acquisition phase - This phase consists of the product selection that best fits the requirements of the organization. Thus, minimizing the need for customization. A consulting company is also selected to help in the next phases of the ERP lifecycle especially in the implementation phase. Factors such as price, training and maintenance services are analyzed and, the contractual agreement is defined. In this phase, it is also important to make an analysis of the return on investment of the selected product.

3. Implementation phase - This phase consists of the customization or parameterization and adaptation of the ERP package acquired according to the needs of the organization. Usually this task is made with the help of consultants who provide implementation methodologies, know-how and training.

4. Use and maintenance phase - This phase consists of the use of the product in a way that returns expected benefits and minimizes disruption. During this phase, one must be aware of the aspects related to functionality, usability and adequacy to the organizational and business processes. Once a system is implemented, it must be maintained, because malfunctions have to be corrected, special optimization requests have to be met, and general systems improvements have to be made.

5. Evolution phase - This phase corresponds to the integration of more capabilities into the ERP system, providing new benefits, such as advanced planning and scheduling, supply-chain management, customer relationship management, workflow, and expanding the frontiers to external collaboration with other partners.

6. Retirement phase - This phase corresponds to the stage when with the appearance of new technologies or the inadequacy of the ERP system or approach to the business needs, managers decide if they will substitute the ERP software with other information system approach more adequate to the organizational needs of the moment.

2.2.2 Dimensions of the ERP Lifecycle

We defined four areas of concern or viewpoints by which the different phases of the lifecycle should be analyzed: product, process, people and change management: 1. Product - This dimension focuses on aspects related to the particular ERP product in

consideration, such as functionality, and on related technical aspects, such as hardware and base software needs. A thorough understanding of the software tool’s capabilities must exist in order to make an alignment with the business strategy in order to determine whether the software is being used effectively, in accordance with the needs of the organization, and how it can best be applied to further the goals of the organization.

2. Process. Each organization has its own core capabilities and functionality that must be supported by an ERP system. Also, an ERP system must help the decision-making required to manage the resources and functions of the organization. Usually, the main ERP investment focus is on re-engineering processes to enable the organization to adapt to the new business models and functional requirements of the ERP system in order to achieve better performance.


3. People. This dimension refers to the human resources and their skills and roles in an ERP system lifecycle. These skills and roles must be developed to minimize the impact of the introduction and diffusion of an ERP system, in order to reduce risk and manage complexity, while facilitating organizational change. Dealing with contingencies, changing practices, and adapting to a new organizational structure and culture are some aspects that must be learned.

4. Change management. This dimension refers to the body of knowledge that is used to ensure that a complex change, like that associated with a big system, gets the right results, in the right timeframe, at the right costs (Holland and Davis 1998). The change management approach tries to ensure the acceptance and readiness of the new system, allowing the organization to get the benefits of its use.

2.2.3 The ERP Implementation Phase

There is no agreement between researchers about the definition and duration of implementation phase. Walsham (1995, p. 210) mentions that the term implementation “is sometimes used to mean technical implementation, namely ensuring that system development is completed and that the system functions adequately in a technical sense. At other times, it is used to refer to the human and social aspects of implementation, such as that the system is used frequently by organizational members or that it is considered valuable to them in their personal work activities or coordination with others”.

These two streams of thought have been used in ERP research. In ERP field the term implementation is used sometimes to refer to the implementation phase exclusively or to represent to whole ERP lifecycle. For instance, Somers and Nelson (2001) referred to the whole process of adopting, selecting, implementing and using the ERP system. Somers and Nelson (2001) and other researchers like Rajagopal (2002) have used Kwon and Zmud ’s innovation-diffusion stage model as their ERP implementation stage model (Kwon and Zmud 1987) which follows six stages or phases: initiation, adoption, acceptance, routinization and infusion. Another example is the implementation lifecycle model proposed by Harwood (2003). He proposes an ERP implementation lifecycle where implementation term refers to the whole process of identifying, selecting, implementing and improving the ERP systems, and then he used the term implementation project or stage to refer to specific part of customization of the ERP according to the organization needs.

We think that this diversity on ERP implementation term has originated some misunderstandings on ERP research field and maybe it is one of the explanations for some contradictory findings. In some cases it may affect the evaluation of a successful or a failed ERP implementation since in most cases researchers use indistinctly implementation word to refer to ERP implementation project and product and/or ERP usage.

Krammergaard and Moller (2000, p. 200) mention that the definition of ‘ERP implementation’ is different according to consultants and vendor’s view or organizations’ view. They state that “in the world of ERP systems, the implementation is often used as a term to describe a well-defined project spanning from the choice of the systems through the configuration and the training until going live, where the system is becoming operative. In the companies’ view implementation means a continuous learning cycle where the organizational processes supported by the ERP systems are gradually aligned with the business objectives. Concurrently the business objectives


are taken even further, driven by the market dynamics but also by the new internal opportunities.” Krammergaard and Moller (2000, p. 205). For Krammergaard and Moller (2000, p. 206), ERP implementation is “an ongoing process of integration and transformation of the business using an ERP system”. Al-Mudimigh et al. (2001, p. 216) define ‘ERP implementation’ as “a socio-technical challenge that requires a fundamentally different outlook from technologically-driven innovation, and will depend on a balanced perspective where the organization as a total system is considered”.

In this doctoral thesis we focus in ERP implementation as the phase that consists of the customization or configuration and adaptation of the ERP package acquired according to the needs of the organization, as we defined earlier. Our concept of ERP implementation focuses on the ERP system and when it is ready to be used by the organization according to its needs. This stream of thought follows the first perspective proposed by Walsham (1995), the consultant’s and vendor’s view according to Krammergaard and Moller (2000), and the socio-technological perspective mention by Al-Mudimigh et al. (2001). We think the ERP implementation definition provided by Krammergaard and Moller (2000) is not exclusive since the only divergence is the period when the organization adapts its business to the ERP system. However, the organization should have a business vision aligned with the ERP system characteristics at the beginning of the ERP implementation. It is only a question of when realized it. Some authors think that it must be before the ERP implementation, others during and finally some others after the ERP go live.

2.2.4 ERP Implementation Approaches

The typical (and most common) categorization of ERP implementation approaches is based in two factors: scope and function. Davenport (2000) proposes a matrix of ERP implementation approaches based on these factors with two extremes: the incremental and big-bang approaches. The incremental approach “implements the system and associated business change in small pieces; a big-bang approach involves implementing everything at once” (Davenport 2000, p. 173).

Parr and Shanks (2000a) argue that the concept of ERP implementation is not a generic concept. Therefore, they developed a taxonomy of ERP implementation approaches that consists in ERP categories and characteristics. They defined three main categories of ERP implementations: comprehensive, middle-road and vanilla. They also defined the following ERP characteristics: physical scope, BPR scope, technical scope, module implementation strategy and, resource allocation. Each of these characteristics has a range of values which represent fundamental decisions which are made in the implementation process, and each of them has consequences for the implementation. Combinations of these characteristics serve to place an implementation within one of the categories. More than one combination of characteristics might result in the same category (Parr and Shanks 2000a).

Finally, software vendors and implementation consultants generally formalize their prior experience into an approach, or methodology that serves as the framework for an ERP implementation. Kale (2000), mentions that such methodology may not be the most efficient one but it ensures success under optimal conditions. Nowadays, there are so much ERP implementation methodologies as consultants.


2.2.5 ERP Implementation Success

Through the implementation of ERP systems, organizations can reap enormous benefits but the project can also be disastrous for organizations that fail to manage the implementation process (Davenport 1998, Holland et al. 1999c). The first thing to ask is: what characteristics define a successful ERP implementation? What factors contribute to the success or failure of ERP implementations?

Nowadays, in the emerging ERP research area, the definition and measurement of ERP implementation success is a thorny issue. However, as Truex (2001) mentions, “in general, the literature views success in a limited fashion, that is, these articles do not study larger aspects of organizational and institutional change coinciding with the implementation of ERP systems”. Some authors (e.g. Markus and Tanis 2000, Harwood 2003) state that success means different things depending of who defines it. Thus, for instance, project managers and implementation consultants “often define success in terms of completing the project on time and within budget. But people whose job is to adopt ERP systems and use them to achieve business results tend to emphasize having a smooth transition to stable operations with the new system, achieving intended business improvements like inventory reductions, and gaining improved decision support capabilities” (Markus and Tanis 2000, p.2). This relative point of view for success can also be applied to failure, and people may also qualify an implementation as a failure according to their goals. As Harwood (2003, p. 94) explains “a project that goes on time and within budget can be construed as a success from a project manager’s viewpoint but if the benefits fail to materialize and there are subsequent problems, then, from a business manager’s viewpoint, the implementation is a failure”.

According to Markus and Tanis (2000), optimal success refers “to the best outcomes the organization could possibly achieve with enterprise systems, given its business situation, measured against a portfolio of project, early operational, and longer term business results metrics”. In this research we adopt Markus and Tanis viewpoint. Markus and Tanis (2000) argued that a minimum set of success metrics includes project metrics, early operational metrics, and long-term business results. In this doctoral thesis we focused on ERP implementation success from the ERP implementation project perspective. De Wit (1998) distinguished between project success (measuring against the objectives of a project) and project management success (measured against the traditional measures of performance against cost, time and quality).

A second distinction is also important it is the difference between success criteria (measures by which success of a project will judge) and Critical Success Factors (CSF). A detailed explanation of CSF and its definition is presented on the next section. Our research focuses on the definition and support of CSF in ERP implementations. Pinto and Slevin (1987) defined a model of a project implementation success as ( )xxx n

fS ,......,,21

= where S is project success and xi the CSFi.

Thus, we attempt to define a model of this nature for an ERP implementation project. Thus, our first task is to define each xi . Next, we describe the usage of CSF approach in general, and second we focus only on literature related to ERP implementation success and CSF.


2.3 An Annotated bibliography on ERP Research

In order to research into ERP systems, a thorough literature review has been conducted. We started this literature review on early 1999 by searching on Internet. Mostly of the articles found were from business literature (also named grey literature). Search strategies were compiled to address various topics of ERP systems to ensure that would obtain the most number of papers possible. In early 1999 we had access to a few number of scientific databases and mostly of the academic papers were obtained by emailing the respective authors. At the end of 1999, we published a research agenda for ERP field basically based on the business literature (Esteves and Pastor 1999). Then, after 1999, the university progressively extended the access to several scientific databases. Thus, we decided to create an annotated bibliography of ERP research (see Esteves and Pastor 2001).

The annotated bibliography contains publications published in the main IS conferences and journals during the period 1997-2000, categorizing them through an ERP lifecycle based framework that is structured in phases. Here, we only describe the literature review related with ERP implementation phase since it is the phase associated to our research study. For a complete description of the annotated bibliography please see Esteves and Pastor (2001a). In order to develop an overview of academic activity relating to ERP systems, key IS conferences and journals were scanned for the period 1997-2000. Table 2 shows the IS events and journal surveyed. Table 2. IS events and journals surveyed.

Academic events Journals ACIS - Australasian Conference on Information Systems AMCIS - Americas Conference on Information Systems ECIS - European Conference on Information Systems EMRPS - Enterprise Management and Resource Planning: Methods, Tools and Architectures HICSS - Hawaii International Conference on Systems Science ICIS - International Conference on Information Systems IRIS - Information Systems Research Seminar In Scandinavia PACIS - Pacific Asia Conference on Information Systems

ACM - Association for Computing Machinery CAIS - Communications of the Association for Information Systems DSS - Decision Support Systems Journal EJIS - European Journal of Information Systems HBR - Harvard Business Review IJIM - International Journal of Information Management ISJ - Information Systems Journal ISR - Information Systems Research JGIM - Journal of Global Information ManagementJIT - Journal of Information Technology MISQ - Management Information Systems Quarterly

The search was made through the use of keywords such as enterprise resource planning,

enterprise wide systems, enterprise systems or software packages and the main ERP vendors such as: SAP, Oracle, Baan, Peoplesoft, JD Edwards. Publications during the period 1997-2000 were analyzed. Table 3 lists the number of publications identified from conferences and IS journals. We also included relevant publications from other scientific publications we found during the collection process. During 1999 and 2000, nearly all the IS conferences mentioned in table 2 dedicated panels to the subject, AMCIS (Panel 1999a), ECIS (Panel1999b), ACIS (Panel 1998b) as well as the ICIS (Panel 1998a).


Table 3. ERP publications at selected international IS conferences 1997-2000 IS Events/Journals 1997 1998 1999 2000 ∑

ACIS - 2 1 1 4 AMCIS 1 2 32 29 64 ECIS - 2 4 5 11 EMRPS - - 29 - 29 HICSS - - 3 3 6 ICIS 1 4 4 7 16 PACIS 1 - - 3 4 Others 1 5 9 9 24 IS journals - 2 3 16 21 Others 1 2 4 3 10 Total 5 19 89 76 189

After we collected all the publications, they were analyzed and categorized using a simplified

version of the ERP lifecycle framework described in section 2.2. One of the ways to analyze qualitative data is the utilization of a classification system that includes a quest for regularity and standards, as well as topics encompassed by the data and that must then be summarized by means of words or phrases (Bogdan and Biklen 1982). We used that process to analyze and categorize our data, in this case the publications found. The ERP lifecycle represents the various phases through which a project of an ERP system passes in an organization. The ERP lifecycle is structured in dimensions and phases, generic enough to permit the classification of publications and comprehensive enough to give a general vision. Publications that did not fall into a specific phase of the ERP lifecycle were included in an ERP general directions section.

The number of publications that are related to the implementation phase is greater than the number related to other phases (see figure 7). This corresponds to the focus on ERP systems given by the trade press, which also deals predominantly with implementation problems. Due to the great number of papers related to education, we created a section dedicated to that subject. We reviewed 189 publications, most of them from AMCIS and EMRPS. So far, EMRPS is the only academic event dedicated exclusively to ERP systems.


38

7 11

78

1712

0

26

0102030405060708090

Genera

l

Adopti

on

Acquis

ition

Imple

mentat

ion Usage

Evolut

ion

Retirem

ent

Educat

ion

Nº.

artic

les

Figure 7. Number of ERP Publications by category.

In appendix B, we present a brief description of the ERP topics researched and further research

in each section. Next, we describe in detail the ERP implementation phase since it is the focus of this doctoral research.

2.4 ERP Implementation Phase Bibliography

The publications related with the implementation phase were categorized in five main topics: implementation approaches, implementation success, other implementation issues and implementation case studies (see figure 8). Next, we describe each topic.


10

25

10

33

0

5

10

15

20

25

30

35

ImplementationApproaches

ImplementationSuccess

Other Issues Case studies

Implementation Phase

Nº.

Arti

cles

Figure 8. Number of ERP publications related with each topic of implementation phase.

2.4.1 Implementation Approaches

This topic focuses on how to deal with an ERP implementation project. It covers aspects such as: taxonomies of ERP implementations, implementation methods and techniques, and comparisons with other software implementation projects.

• Davenport (1996, 1998) says that the package implementation process is equally distinct and roles, responsibilities and the necessary skill set have changed substantively from those associated with a more traditional custom implementation.

• Gibson et al. (1999) argue that ERP software implementation requires a different approach that places less emphasis on the technical aspects of software implementation and instead seeks to balance the business process design, software configuration and project management aspects of information technology implementation with the overall strategy and structure of the firm.

• Milford and Stewart (2000) describe the design of a qualitative research project that seeks to determine if ERP implementations are qualitatively different from other large system implementations.

• Somers et al. (2000) propose an integrative framework and taxonomy derived from the socio-technical view of organizations and other extant theories that illustrates the multifaceted nature of ERP implementations.

• Rebstock and Selig (2000) present a framework of three strategies to implement ERP in international companies. They also report case studies that allow the comparison of these strategies.

• Parr and Shanks (2000a) argue that the concept of an ERP implementation is not a generic concept, and they present taxonomy of ERP implementation categories. They


further argue that understanding the differences between the different categories is crucial to future research in ERP implementations.

• Hazebrouck and Frerichs (1999) analyze and describe the usage of ASAP methodology.

• Fichtenbauer (1999) treats the problems, experiences and solutions of the organization of processes in combination with SAP-projects. The author used an ARIS approach.

• Scheer and Habermann (2000) explain the benefits of using business process models to achieve positive results.

2.4.2 Implementation Success

Implementation success deals with the issues of how to succeed through an ERP implementation. It covers aspects such as: ERP project success and failure definitions, problems and outcomes, critical success factors and risk management.

• Some publications (Gibson and Mann 1997; Bancroft et al. 1998; Holland et al. 1999c; Holland and Light 1999e; Parr et al. 1999; Stefanou 1999; Sumner 1999a; Sumner 1999b; Vikram et al. 1999) attempt to identify critical success factors on ERP implementations.

• Esteves and Pastor (2000) unified these works in a unified model of critical success factors.

• Parr and Shanks (2000b) present a project phase model of ERP projects and analyze the critical success factors in each phase.

• Shanks et al. (2000) define a set of critical success factors and analyze which of them are important in which ERP process model phase, based in two case studies: one in Australia and the other in China. They also analyze the differences between them using national cultural characteristics.

• Sumner (2000) identifies the risk factors in ERP projects that are unique to these projects.

• Markus et al. (2000) describe the results of a study of problems and outcomes in ERP projects.

• Bingi et al. (1999) discuss the critical issues affecting an ERP implementation. • Brown and Vessey (1998) have started the identification of ERP implementation

variables that may be critical to a successful implementation. These variables are then incorporated into a preliminary contingency framework.

• Dong (2000) proposes a conceptual model exploring impacts of top management on enterprise systems implementation effectiveness.

• Stewart et al. (2000) describe a research program being undertaken to identify the variables that inhibit an ERP implementation.

• Southwick and Sawyer (1999) argue the importance of analyzing managerial and social issues surrounding ERP implementation by applying critical social theory.

• Bunker (2000) analyzes the ERP contextual skills issues need to be addressed in order to facilitate the successful transfer and implementation of these IS into varied organizational contexts.


• Willcocks and Sykes (2000) analyze the role of the Chief Information Officer (CIO) and IT function in an ERP implementation, providing three scenarios of this role.

• Densley (1999) sets out the key issues to enable successful ERP implementations. • Gable and Stewart (1999) analyze the ERP issues in small and medium enterprises. • Rosemann and Wiese (1999) adapt the balanced scorecard approach to evaluate the

implementation and usage of ERP systems. • Soh et al. (2000) survey the different misfits observed, i.e. the gap between the

functionality offered by the package and the functionality required by the adopting organization. They also analyze the strategies employed, and the related impacts on organizations.

2.4.3 Other Issues

This topic encompasses other issues not covered in the rest of topics such as: role of consultants, applied theories to specific ERP issues, general conclusions and organizational change management in ERP projects.

• Adam and O'Doherty (2000) analyze 14 ERP implementation projects in Ireland and draw some conclusions.

• Markus et al. (2000) examine the variety of multi-site structures and the configuration and implementation associated with them.

• Krumbholz et al. (2000) describe the usage of some social sciences theories of culture to model and predict the impact of culture on ERP implementations.

• Umar and Missier (1999) develop a knowledge-based decision support workbench with the goal of reducing the integration and migration effort.

• Westrup and Knight (2000) analyze how the mediation by consultants is of importance in ERP implementations.

• Daneva (1999) suggests an approach to deal with the identification and measurement of reuse in requirements conceptualization phase of the SAP R/3 component configuration cycle.

• Decision making under the aspect of whether to implement ERP with or without BPR has been surveyed and analyzed by Bernroider and Koch (1999).

• Theoretical considerations have focused on global business processes (Basu and Palvia 1999) and information technology architecture options (Chan 1999).

• Lindvall (2000) discusses the changes before, and just after, the implementation of a SAP/R3-system. He puts attention to changes in the implementing organization, especially focusing on the effects of the finance function.

2.4.4 Case Studies

We found several case studies that document specific ERP implementations. They cover different perspectives in particular situations such as:

• ERP impacts, organizational change management, business process reengineering, people roles and decision-making.


• To analyze the ERP impacts based in a benefit/costs analysis (Gattiker and Goodhue 2000).

• To describe the impact of ERP on job characteristics (Pawlowski et al. 1999) and on organizational knowledge (Baskerville et al. 2000).

• To test the role of three key social enablers in ERP implementations: strong and committed leadership, open and honest communication, and a balanced and empowered implementation teams (Sarker and Lee 2000).

• To make recommendations on how to maximize the benefits from ERP (Niehus et al. 1998) or how to avoid ERP project failures (Scott 1999a).

• To demonstrate how myth-making served to construct an ERP system as an 'ideal' system and the legacy system as a 'dying system' (Alvarez 2000).

• To analyze the key decisions of the development team and critical success factors (Clemons 1998).

• To decide onto an ERP adoption and implementation (Hirt and Swanson, 1998; Hirt and Swanson, 1999).

• To analyze ERP implementations from a knowledge transfers perspective (Lee and Lee 2000).

• To demonstrate tradeoffs between Big Bang versus slower ERP implementation approaches that allow time for organizational learning (Brown and Vessey 2000).

• To describe the journey of Geneva pharmaceuticals through the first two of three phases of SAP R/3 implementation project (Bhattacherjee 2000).

• To compare the best of breed strategy with the single vendor ERP alternative (Light et al. 2000).

• To identify the critical elements of business processes and ERP systems alignment (Smethurst and Kawalek 1999; Volkoff 1999).

• To define business process requirements for large-scale public sector ERP implementations (Blick et al. 2000).

• To explore strategic options open to firms beyond the implementation of common business systems (Holland et al. 1999d).

• To describe the implementation of a SAP system in a multi-cultural organization (Gulla and Mollan 1999).

• To standardize ERP templates within the different ERP systems of an organization (Huber et al. 2000).

• Business Process Reengineering (Slooten and Yap 1999; Ross 1998; Ross 1999) and change management (Perez et al. 1999; Amin et al. 1999).

• To know the causes and nature of changing requirements in user's requirement definition (Rugg and Hooper 1999).

• To analyze the special challenges of ERP implementations outside the business world (Hanseth and Braa 1998; Sieber and Nah 1999; Sieber et al. 1999; Holland et al. 1998; Holland and Light 1999a).

• To describe global supply chain management (Chatfield and Andersen 1998). • To examine a model that proposes various antecedents to successful e-business change

management in ERP environments (Ash 2000).


2.4.5 Main Topics Researched

Some authors have studied implementation approaches and they have proposed some new ones. However, we detected that 'implementation' does not mean the same to everyone, and each author has his own model of implementation phases/stages. Although some studies on critical success factors research have been published, some of them do not provide a precise definition of the critical success factors found and some of them are based in only one case study. Therefore, more effort should be put in their definition and subsequent validation. There is only one study that focuses on ERP success definition (Markus et al. 2000). Some studies have focused on ERP impacts at organizational, technological and business level, business process reengineering and organizational change management issues. The few studies developed are not enough to create a body of knowledge on the area.

Case studies constituted the largest category of publications. However, we detected that in some of them, there is a lack of research methodology explanation, lack of enough data to interpret some of the presented results, and most of them lack assumptions or hypotheses (in theoretical terms) for further studies.

2.4.6 Topics for Further Research

Adequate ERP implementation methodologies have been pointed as one of the critical success factors. However, there is a lack of studies regarding the definition, usage and adequacy of these methodologies and their value in ERP projects.

As we mentioned above, critical success factors are quite well studied. However, we noted that their operationalization is not. There is the need to develop approaches to put in practice and manage the critical success factors identified in some studies. The development of techniques and approaches for the control and monitoring of ERP implementation projects is an area to be improved. It is also important to relate critical success factors with implementation methodologies. There is the need of more in-depth case studies that document ERP implementations. It would be useful to analyze knowledge transfer and knowledge management during ERP implementations. User involvement and satisfaction have not been studied in depth. Some studies have shown that implementing ERP systems is far more likely to succeed when user involvement is high and when users have realistic expectations relating to the scope of the project and system functionality (Bonner 2000). Also, there is the need to understand the different stakeholders (such as steering committee, project members, consultants, vendors) in ERP implementation projects.


2.5 Critical Success Factors Approach

Using ideas from Daniel (1961), Rockart (1979) proposed the CSF method to help CEOs specify their own needs for information about issues that were critical to the organization so that systems could be developed to meet those needs. CSF are “the limited number of areas in which results, if they are satisfactory, will ensure successful competitive performance for the organization” (Rockart 1979, p. 85). Rockart further defines these factors as areas where things must go right and as key areas where favorable results are absolutely necessary if management goals are to be reached. Rockart (1979, p. 85) stated that “the critical success factors are areas of activity that should receive constant and careful attention from management”. Information about their status must be made available in a timely fashion at the appropriate levels. Thierauf (1982) stated that if the results in these areas are not adequate, the organization’s efforts for the period will be less than desired.

As the name implies, the purpose of any CSF approach is “the determination of the set of factors that the manager considers critical for his or her success. Once identified, these factors are stated as his or her objectives and the information required to monitor their performance is then identified” (Dadashzadeh 1989).

According to Leidecker and Bruno (1984), CSF are “those characteristics, conditions or variables that, when properly sustained, maintained, or managed, can have a significant impact on the success of a firm competing in particular industry”. Pinto and Slevin (1987) defined critical success factors as “factors which, if addressed, [would] significantly improve project implementation chances” (Pinto and Slevin 1987, p. 22). These two definitions avoid the optimal concept provided by Rockart (1979). Rockart’s concept of CSF is clearly inspired by the issue of optimum match between environmental conditions and business characteristics, i.e., the core of business strategy. According to Rockart, no organization can afford to develop a strategy which fails to provide adequate attention to the principal factors which underlie success in the industry. This provides the rationale for making them the basis of an IS. Rockart used the concept of CSF to help the implementation of strategy. Eisenhardt and Zbaraki (1992, p. 18) demonstrated that the CSF method requires that “actors enter decision situations with known objectives. These objectives determine the value of the possible consequences of an action. The actors gather information, and develop a set of alternative actions. They then select the optima alternative”.

In strategic management field, a similar concept to CSF is used: Key Success Factors (KSF). According to Grunert and Ellegard (1993), the term has been used in basically four different ways: as a (necessary) ingredient in a management information system; as a unique characteristic of a company; as a heuristic tool for managers to sharpen their thinking; and as a description of the major skills and resources required to have a successful performance in a given market. Grunert and Ellegard (1993) have approached the last view of KSF and they defined KSF as a skill or resource that a business can invest in, which, on the market the business is operating on, explains a major part of the observable differences in perceived value and/or relative costs. The terms KSF and CSF have been used interchangeably in the literature.


2.5.1 CSF Approach Usage

The CSF approach has been popularized by Rockart and other researchers and is now being increasingly used by IS departments, and by consultants, as an aid to IS strategic planning. According to (Peffers et al. 2003, p. 55), “senior managers have found CSF to be appealing for IS planning because they help justify the development of strategically important new systems, the benefits of which may be hard to quantify”. Some examples are: CSF use in the context of IS planning and implementation (Jarvenpaa et al. 1985), executive IS development (Rockart and DeLong 1988), information requirements determination (Cooper 1988). The CSF approach was applied in case studies carried out in the UK universities (Pellow and Wilson 1993) to determine the organizational information needs of heads of departments. According to Williams and Ramaprasad (1998), “there is a great deal of attention devoted to the concept in the IS literature as many argue that the use of CSF can have a major impact on the design, development, and implementation of IS”.

However, a CSF analysis has some limitations. A CSF analysis is a useful concept to identify performance objectives to be satisfied by new strategic IT investments, but it suffers from limitations that affect its value. It often lacks a theoretical basis, there is no accepted procedure for its application, and ad-hoc applications may result in incomplete and biased results (Peffers and Gengler 1998). Other important aspect is that most of the analyses made are descriptive. The CSF must be directly related to strategic and business plan objectives and goals. For each CSF there must be one or more associated Key Performance Indicators (KPI) that provide the measure, and a standard of performance or allowable variance from planned performance. The most effective KPI are those designed into the process in such a way as to provide a readily available or continuous reading of performance. Figure 9 represents the use of the CSF approach in a decision-making process, in this case an ERP implementation project.

Critical Success Factors


Implementation Phase

ProjectManagement

Figure 9. The ERP decision-making implementation framework.


2.5.2 A Conceptual CSF Identification Framework

Based in the literature review on CSF approach, we propose a CSF conceptual framework for CSF approach use (see figure 10). Since our aim is to identify CSF for ERP implementation projects, in the next chapter we describe the use of this framework within our research context. Next, we explain this framework.

Project Life Cycle

CSFs Relevance

StrategyImplementation

StrategyFormulation

Internal/External

Ongoing/Temporal

Building/Monitoring

Strategic/Tactics

CSFsOrganizational/Technological

Perceived CSFs Actual CSFs

Sources of CSFs

Individual StrategyEnvironmental Temporal Industry

Sources of CSFs

Individual StrategyEnvironmental Temporal Industry

Figure 10. A CSF conceptual framework.

2.5.2.1 CSF Sources

Bullen and Rockart (1986) distinguished between five sources of CSF: the industry where the organization operates, the competitive strategy and industry position pursued by the organization, the environmental factors surrounding the organization, temporal factors facing the organization and, CSF that are specific to each manager and their role in the organization. Other authors such as Leidecker and Bruno 1984 have added other potential sources such as CSF related to the analysis of main competitors (especially industry leaders) and the evolution of their business.


2.5.2.2 Relationship between Strategy and CSF

Different perspectives on CSF and their relationship with strategy are presented in the literature. Dirks and Wijn (2002) analyzed two of these perspectives: strategy formulation, strategy implementation. They noted that the initial definition and use of CSF is based on strategy implementation. According to Rockart (1979), and Boyton and Zmud (1984), the strategy determines the CSF. They claim that CSF are meant to determine which information is of importance for the management control system. “Various strategies call for different information, and, to that end, the management control process starts with the identification of CSF. In general the chosen strategy determines the CSF, and the subsequently form the basis for the design and functioning of the management control systems. Therefore the most important role of management control systems is to support the implementation of strategies” (Dirks and Wijn 2002).

Another vision is that CSF can be used for strategy formulation by supporting the strategic planning process. “The CSF follow from the vision and mission of the organization and from a strategic evaluation of the market” (Dirks and Wijn 2002). From this viewpoint, CSF can be regarded as ‘order-winning criteria’ – for instance, quality and lead-time (Wijn et al. 1996). Wijn et al. (1996) provided a CSF definition based in a market-oriented approach. They defined CSF as “the factors on which a company can distinguish itself from competitors, and thus build a stable, positive relation with the market” (Wijn et al. 1996). This market-oriented approach to CSF is especially interesting for companies surrounded by strategic uncertainties that relate to customer preferences (Dirks and Wijn 2002).

Another issue is the relationship between CSF and strategy. In the CSF approach of strategic control, the CSF are derived from the market, and are not automatically manageable and controllable. The CSF method of strategic control relates the CSF to critical business processes, and proceeds from these business processes to KPI. Hardaker and Ward (1987) developed the Process Quality Management (PQM) based on this perspective of CSF. We agree with Ward (1990) in that CSF are not, in themselves, directly manageable. Rather than the CSF, it is the processes that define what a management team 'Do', processes that can be owned, defined, measured and managed.

2.5.2.3 CSF Dimensions

Different CSF dimensions or categories have been proposed in the literature. Next, we review the most common dimensions used.

Hierarchy/Group of CSF

Studies have shown that CSF can be synthesized (while each manager in an organization may have different, individual CSF, the whole organization may have its own, aggregated set of organizational CSF). This argument has been extended to include CSF for a group of organizations belonging to an industry (industry CSF), or for a group of managers in a particular role belonging to different organizations (occupational CSF), giving rise to the concept of group of CSF. Thus, there could be generic CSF for ERP implementation projects managers, CSF for ERP implementation projects, or CSF for ERP implementation projects in higher education.


Temporal/Ongoing CSF

CSF can either be ongoing, or they can be temporal (Khandewal and Ferguson 1999). Project champion role is an example of an ongoing CSF because the project champion is constantly involved in the ERP implementation project and along its phases. On the other hand, definition of project scope is an example of a temporal CSF the proper management of which is essential for the success of the ERP project for a period after which it will cease to be critical. Because of the changing circumstances a manager’s priorities may change from time to time. What is critical for him today may in time be accomplished and thus cease to be critical. Conversely what is commonplace today may become critical in the future. Khandewal and Ferguson (1999) assert notwithstanding the earlier statement that the CSF can either be ongoing, or temporal that all CSF can be defined in a way that they are temporal. For example, formal plan and schedule for the ERP implementation project can be defined as a temporal CSF. This CSF will then be considered having been achieved as soon as a project plan is developed. The assumption is that once the project plan is developed the ongoing updating of this plan would be an integral part of the project plan. This CSF can be considered having been achieved as soon as a project plan is developed. The assumption is that once the project plan is developed the ongoing updating of this plan would be an integral part of the project plan. All CSF would thus belong to a point in time, although they may differ in their degree of temporality. Therefore, it is important to know these points in time were CSF are more relevant.

Internal/External CSF

CSF can be characterized by the extent to which they are internal (endogenous) or external (exogenous) to the organization or the unit they are applied. According to Flynn and Arce (1997, p. 312), “an internal CSF has related actions taken within the organization, while an external CSF has related actions performed outside the organization”. Internal CSF related to situations or issues within managers control while external CSF may not be controlled. This dimension is very important in order to collect the information from the proper sources of information (Rockart 1979).

Building/Monitoring/Benchmarking CSF

Building/monitoring CSF refer that part of it over which the manager has control, and, consequently, whether they refer to something which must be monitored or built. Eberhagen and Naseroladl (1992) refer that “if he is concerned a lot with the performance of his department and puts a great amount of effort in guiding and measuring that performance the manager is monitoring and thus have CSF related to monitoring. On the other hand, a manager who is much concerned about future planning and changes is then building/adapting. Thus, being concerned with CSF related to building/adapting”.

According to Flynn and Arce (1997, p. 312), “a monitoring CSF is concerned only with monitoring an existing organization situation...a building CSF is concerned with changing the organization or with future planning”. For example, maintenance of technological leadership would be a source of CSF which the business can build, while changing consumer demographics would be a force that can be monitored, but not controlled. Bullen and Rockart (1986) differentiated between building CSF which are used to achieve specific objectives or implement changes in practices or performance and monitoring CSF which are used in the long term


monitoring of key issues. This later perspective is quite similar to strategic and tactical CSF dimension.

Strategic/Tactical CSF

This dimension is related with the type of planning: strategic and tactical planning. The IS strategic plan details what is to be achieved while the IS tactical plan describes how goals will be met and when. Strategic factors require long-term planning and it is carry out by senior management. These are uncertain and risky as they are based on opportunities, often looking to the future. Tactical factors require short or medium-term planning and are based on resources available to meet the objectives defined at strategic level. Tactical decisions are made frequently by middle management and are concerned with the utilization of resources.

Kelly et al (1999) suggested that the strategic level is the premeditated plan for transforming the organization, enabling it to operate in the new style environment. At the tactical level, also termed managerial level, medium-term planning is largely concerned. According to Ward (1990, p. 117), “there will normally be a mixture of tactical and strategic CSF. If they are all strategic, the business might founder in the short term while everybody concentrates on the blue skies ahead. Equally, if all CSF are tactical, the business might burn out like a super-nova”.

Perceived versus Actual CSF

Grunert and Ellegard (1993) proposed the concept of perceived versus actual CSF. They mention that the knowledge about discrepancies between actual and perceived CSF would have a number of useful practical implications such as: providing decision-makers feedback about possible discrepancies will contribute to better strategy formulation and implementation; this knowledge could be applied in designing better information systems; finally, if we could knew to which extent or under which circumstances decision-makers can be expected to perceive the causes of success correctly, this would give researchers valuable information on when an interview with a decision-maker would be sufficient to uncover the major driving forces in an industry.

Measuring “actual” CSF is however, an aim which can be approached, but not attained. What can be attained is a confrontation of decision-makers’ own perceptions of the causes of success with estimates of the causes of success which have higher degree of objectivity (Dess and Robinson 1984). The identification of CSF in one organization does not mean that these CSF will be the same in all other organizations. These CSF should be as perceived CSF by managers in terms of their projects. Each organization must redefine their CSF according to their own needs and goals. In the future the actual CSF for a specific project within an organization may be perceived as CSF for other similar projects.

CSF Relevance

In 1988, Pinto and Prescott (1988, p. 5), claimed that “the majority of the studies in the critical success factor research stream have been theoretical and have assumed a static view of the importance of various factors over the life of a project. In other words, a critical success factor was assumed to have the same degree of importance throughout the life of the project”. Therefore, Pinto and Prescott (1988) examined changes in the criticality of project CSF over the lifecycle of a project. They concluded that the criticality of CSF is subject to change at different phases of the project lifecycle. They stated that “this finding implies that future use of critical success factor


analysis and implementation, regardless of the area to be examined, may be contingent on other organizational phenomena, such as project (or organizational) lifecycle” (Pinto and Prescott, p. 17).

Subsequent studies on CSF approach have addressed not solely the identification of CSF but also their relevance along the project lifecycle. However, the number of these types of studies stills very limited with most studies only focusing on CSF identification. The assumption of CSF criticality is slightly different from some studies that try to define CSF for each phase of the project lifecycle. Pinto and Prescott (1988) use the same set of CSF and examined their criticality along the project phases while some studies define different sets of CSF for each project phase. These approaches are different although some researchers are empirically using the same assumption stated by Pinto and Prescott (1988) since they are providing what they call “the most critical” or “most relevant” or “the top” CSF which means they are only defining the most relevant CSF but probably they are always using as a reference the same set of CSF.

To study CSF relevance, researchers have used surveys and case studies using interviews. The typical procedure is to ask participants to rank the most CSF in each project phase and then create a list of the top relevant CSF in each project phase or, ask participants to evaluate CSF relevance using a likert scale like low, normal and high relevance. Some authors have studied CSF along different IS lifecycles: information centers (Magal et al. 1988), implementation projects (Pinto and Slevin 1988), Cooper and Zmud (1990), Activity based costs implementation (Anderson 1995), ERP lifecycle (Somers and Nelson 2001, Nah et al. 2001).

2.5.3 Techniques for CSF Identification

There are many techniques to identify CSF. Table 4 summarizes some studies that we found in the literature and the research methods applied. Each of these methods has its respective strengths and weaknesses, see Khandewal and Ferguson (1999) for a brief explanation of the different techniques. Based on a literature review of CSF, Shah and Siddiqui (2002) concluded that the survey method is the most commonly used method to identify CSF. Table 4. Most common used research methods.

Research method Reference Action-research Kock et al. 1999 Case studies Holland et al. 1999, Sumner 1999 Combination of methods Khandewal and Ferguson 1999, Parr et al. 1999 Delphi technique McCarthy and Atthirawong 2001, Brancheau et al. 1996 Focus groups Lawley et al. 2001 Group interviewing Khandewal and Miller 1992 Literature review Esteves and Pastor 2000, Umble and Umble 2001 Multivariate analysis Tishler et al. 1996 Scenario analysis Barat 1992 Structured interviewing Bullen and Rockart 1986


2.5.4 Benefits of CSF for Managers

Rockart (1979, p. 87) defined the following benefits for managers when applying CSF method: • “The process helps the manager to determine those factors on which he or she should

focus management attention. It also helps to ensure that those significant factors will receive careful and continuous management scrutiny.

• The process forces the manager to develop good measures for those factors and to seek reports on each of the measures.

• The identification of CSF allows a clear definition of the amount of information that must be collected by the organization and limits the costly collection of more data than necessary.

• The identification of CSF moves an organization away from the trap of building its reporting and information system primarily around data that are “easy to collect”. Rather, it focuses attention on those data that might otherwise not be collected but are significant for the success of the particular management level involved.

• The process acknowledges that some factors are temporal and that CSF are manager specific. This suggests that the IS should be in constant flux with the new reports being developed as needed to accommodate changes in the organization’s strategy, environment, or organization structure. Rather than changes in an IS being looked on as an indication of “inadequate design”, they must be viewed as an inevitable and productive part of IS development”.

• The CSF concept itself is useful for more than IS design. Current studies suggest several additional areas of assistance to the management process.

2.5.5 Key Performance Indicators

According to Baker (1995, p. 10), Key Performance Indicators (KPI) “represent a set of measures focusing on the aspects of organizational performance that are most critical for the current and future success of the organization”. These performance variables are especially critical in achieving a desired set of outcomes. Key performance indicators (or factors) are normally linked to core products and services and associated customer expectations (Harbour 1997). The focus of KPI, therefore is either on the aspects of organizational performance that require improvement or on the aspects that must be kept within a specified level to ensure the success of the organization, or in our case, the success of and ERP implementation project. Although the term KPI is widely used, it should be noted that different concepts such as critical success measures, or ‘performance metrics’ or ‘performance measures’ are used to mean the same thing. KPI, are considered a special type of metrics, in this case performance metrics.

Performance measures or sometimes called performance indicators are one of the multiple types of measures that exist (for a detailed overview of metrics please see: Esteves and Pastor 2001b). According to O'Hara (2000), “metrics in this category emphasize performance to show the ability to deliver products and services with the qualities, timeliness, and costs that customers require”. According to Birch (2000, p. 5), a performance measure “is composed of a number and a unit of measure. The number gives us a magnitude (how much) and the unit gives the number a meaning (what). Performance measures are always tied to a goal or an objective”. According to


Harbour (1997, p. 7) a performance measurement “is the process of measuring work accomplishments and output, as well as measuring in-process parameters that affect work output and accomplishments”.

According to Baker (1995, p. 43), “the major contribution of KPI at the team level is that they generate ownership of the improvement process. When a team of employees have established their own KPI, within the broad context provided by the CSF, they have declared what they believe is important”. In addition to this benefit, KPI help employees:

• To clarify their team's objectives • Set team goals or targets • Provide a basis upon which to share roles and responsibilities within the team • Focus on key processes for potential improvement • Identify problem areas and determine improvement priorities • Measure the success of their actions • Provide a basis for recognizing and celebrating team achievements.

2.5.5.1 What Should Be Measured?

The typical dilemma confronting anyone introducing KPI is determining what should be measured. In essence, effective KPI target the critical issues confronting an organization and provide information that can be used to improve processes and performance. Too many KPI - or conflicting indicators - can actually inhibit performance improvement. According to Baker (1995), “before you can begin to select what should be measured by KPI, you must be clear on what aspects of your organization's performance are critical for success in the context of the vision”.

An important aspect is to keep things simple an easy to understand. Pfleeger (1993) mentions that people who collects the metrics need to know the relationship between the measurements they are collecting and the problems to be solved, “the greater the distance from measurement to problem, the less likely developers are to use the measurement” (Pfleeger 1993, p. 73). She also refers that if a problem can be understood with one piece of data instead of several, so much the better. An important guideline that Baker (1995) gives is that we must promote KPI that measure key processes and outcomes. This guideline encompasses the idea of measuring outcomes as well as performance in key processes that the project team impacts. As recommend by Baker (1995), when developing outcome indicators, it is best to measure KPI of a total process that overlaps individual departments or functions. Finally, Baker (1995) mentioned there is no perfect number of KPI. What we need to consider is (Baker 1995, p. 165):

• Have we introduced KPI that cover all these CSF? • Can we easily sustain the number of KPI we are proposing to use? • Is each particular KPI in fact providing useful information that the team can use to

analyze and improve the key processes for which they are responsible? Baker (1995) also provides a set of guidelines to develop KPI such as:

• Resource the process. • Encourage a balance in team KPI. • Promote KPI that measure processes and outcomes. • Permit KPI to evolve, practicality, not perfection.


• Never lose sight of ownership. • A limited, manageable number of KPI. • Build the integrated system of KPI from the ground up.

2.6 Conclusions

Publications within the IS community on ERP systems appear small compared to the business that they have generated. The publications identified during the literature review are originated from a small number of sources and only recently. All major IS conferences in year 2000 dedicated at least a track or mini-track to ERP systems. This literature review shows that ERP researchers have mainly concentrated on issues related to the implementation phase of the ERP lifecycle. Until now, the other phases have been 'almost forgotten'. One of the main reasons is that the majority of organizations are in the implementation phase. Another reason to the existence of more research in the implementation phase is that in some phases, namely acquisition and implementation phases, there is a strong intervention of consultants, which makes very difficult the access to information. Although there are several ERP systems in the market, the majority of case studies analyzed are related with SAP systems.

There is the evidence of lack of studies and research generalization of findings to other ERP systems. ERP systems offer many potential areas for research, several of which were discussed in this literature review. Due to their pervasive nature, ERP systems are of interest for a wide range of professional and scholarly communities (from software engineering to accounting), apart from the IS field. This suggests that ERP-related research could or should be interdisciplinary.

The CSF approach has been popularized by John Rockart and other researchers and it is now being increasingly used within IS community. Based in a literature review on CSF approach, we propose a CSF identification framework.

2.7 References

Adam F., O'Doherty, P. 2000. “Lessons from Enterprise Resource Planning Implementation in Ireland - Towards Smaller and Shorter ERP Projects”. Journal of Information Technology, 15(4), pp. 305-316.

Alvarez R. 2000. “Examining an ERP implementation through Myths: A Case Study of a Large Public Organization”. Americas Conference on Information Systems, USA.

Al-Mudimigh A., Zairi1 M., Al-Mashari M. 2001. “ERP software implementation: an integrative framework”, European Journal of Information Systems, 10, pp. 216–226.

Amin N., Hinton M., Hall P., Newton M., Kayae R. 1999. “A Study of Strategic and Decision-Making Issues in Adoption of ERP Systems Resulting from a Merger in the Financial Services Sector”. 1º International Workshop on Enterprise Management Resource and Planning Systems, Venice (Italy), pp. 173-181.

Anderson S. 1995. “A Framework for assessing cost management system changes: The Case of Activity-based Costing Implementation at General Motors, 1986-1993”. Journal of Management Accounting Research, 7, pp. 1-51.


Ash, C. 2000. “E-Business Change and Personnel Performance: A Case Study of an ERP Enabled Organisation”. 10th Annual BIT conference, Manchester (UK).

Baker T. 1995. “Key Performance Indicators”, AusIndustry Enterprise Improvement Inc. Bancroft N., Seip H., Sprengel A. 1998. “Implementing SAP R/3”. 2nd ed., Manning Publications. Barat J. 1992. “Scenario Playing for Critical Success Factor Analysis”, Journal of Information

Technology, 7, pp. 12-19. Baskerville R., Pawlowski S., McLean E. 2000. “Enterprise Resource Planning and Organizational

Knowledge: Patterns of Convergence and Divergence”. International Conference on Information Systems, Brisbane, Australia.

Bernroider E., Koch S. 1999. “Decision Making for ERP-Investments from the Perspective of Organizational Impact - Preliminary Results from an Empirical Study”. Americas Conference on Information Systems, Milwaukee, USA.

Bhattacherjee A. 2000. “Beginning SAP R/3 Implementation at Geneva Pharmaceuticals”. Communications of AIS, 4(2).

Bingi P., Sharma M., Godla J. 1999. “Critical Issues Affecting an ERP Implementation”. Information Systems Management, 16 (3), pp. 7-8.

Birch C. 2000. “Future Success: A Balanced Approach to measuring and improving success in your organization”, Prentice Hall.

Blick G., Gulledge T., Sommer R. 2000. “Defining Business Process Requirements for Large-Scale Public Sector ERP Implementations: A Case Study”. 8th European Conference on Information Systems ECIS, Vienna (Austria).

Bogdan R., Biklen S. 1982. “Qualitative Research for Education: an Introduction to Theory and Methods”. Allyn and Bacon, Boston.

Boynton A., Zmud R. 1984. “An Assessment of Critical Success Factors”, Sloan Management Review, 25(4), pp. 17-27.

Brancheau J., Janz B., Wetherbe J. 1996. “Key Issues in Information Systems Management: 1994-95 SIM Delphi Result”, MIS Quarterly, 20(2), pp. 225-242.

Brown C., Vessey I. 1999. “ERP Implementation Approaches: Toward a Contingency Framework”. International Conference on Information Systems ICIS, Charlotte (USA).

Brown C., Vessey I. 2000. “NIBCO's Big Bang”. International Conference on Information Systems ICIS, Brisbane (Australia).

Bunker D. 2000. “Enterprise Resource Planning ERP System Tools: the Context of their Creation and Use within the Technology Transfer Process”. Americas Conference on Information Systems.

Bullen C., Rockart J. 1986. “A Primer on Critical Success Factors”, in Rockart and Van Bullen, the Rise of Management Computing, Dow Jones Irwin, Illinois (USA).

Chan S. 1999. “Architecture Choices for ERP Systems”. Americas Conference on Information Systems, Milwaukee (USA).

Chatfield A., Andersen K. 1998. “Playing with LEGO: IT, Coordination and Global Supply Management in a World Leader Toy Manufacturing Enterprise”. European Conference on Information Systems, Aix-en-Provence (France).

Claver E., Gonzalez R., Llopis J. 2000. “An analysis of research in information systems (1981-1997)”, Information & Management, 37, pp. 181-195.

Clemons C. 1998. “Successful Implementation of an Enterprise System: a Case Study”. Americas conference on Information systems, Baltimore (USA).


Cooke-Davies T. 2002. “The ‘Real’ Success Factors of Projects”, International Journal of Project Management, 20.

Cooper R., Zmud R. 1990. “Information Technology Implementation Research: A Technological Diffusion Approach”. Management Science, 36(2), pp. 123-139.

Dadashzadeh M. 1989. “Teaching MIS Concepts to MBA students: A Critical Success Factor Approach”, Journal of Information Systems Education, 1(4).

Daneva M. 1999. “Measuring Reuse of SAP Requirements: a Model-based Approach”. Proceedings of the fifth symposium on software reusability, pp. 141-150.

Daniel 1961. “Management Information Crisis”, Harvard business review, pp. 111-116. Davenport T. 1996. “Holistic management of mega-packaging change: the case of SAP”.

Americas Conference on Information Systems, Phoenix (USA). Davenport T. 1998. “Putting the Enterprise into the Enterprise System”. Harvard Business Review,

Jul- Aug, pp. 121-131. Davenport T. 2000. “Mission Critical: Realizing the Promise of Enterprise Systems”, Boston,

Harvard Business School Press. Densley B. 1999. “The Magnificent 7, getting the Biggest Bang from the ERP Buck”. 1º

International Workshop on Enterprise Management Resource and Planning Systems EMRPS, Venice (Italy), pp. 59-65.

De Wit A. 1988. “Measurement of Project Success”, International journal of project management, 6.

Dess G., Robinson R. 1984. “Measuring Organizational performance in the absence of objective measures”, strategic management journal, 5, pp. 265-285.

Dirks P., Wijn M. 2002. “Strategic Control: Meshing Critical success Factors with the Balanced Scorecard”, Long Range Planning, 35, pp. 407-427.

Dong L. 2000. “A Model for Enterprise Systems Implementation: Top Management Influences on Implementation Effectiveness”. Americas Conference on Information Systems AMCIS, USA.

Eberhagen, N., Naseroladl, M. 1992. “Critical Success Factors; a survey”, Working paper within the Information System Science’s project, ISV-WP-7, Department of Mathematics, Statistics and Computer Science, Växjö University, Sweden.

Esteves J., Pastor J. 1999. “An ERP lifecycle-based Research Agenda”. 1º International Workshop on Enterprise Management Resource and Planning Systems EMRPS, Venice (Italy), pp. 359-371.

Esteves J., Pastor J. 2000. “Towards the Unification of Critical Success Factors for ERP Implementations”, 10th Annual BIT conference, Manchester (UK).

Esteves J., Pastor J. 2001a. “Enterprise Resource Planning Systems Research: An Annotated Bibliography”, Communications of the Association for Information Systems (CAIS), 7(8).

Esteves J., Pastor J. 2001b. “Goals/Questions/Metrics Method and SAP Implementation Projects”, technical research report, LSI-01-49-R, Universidad Politécnica de Catalunya.

Fichtenbauer C. 1999. “BPR including SAP-projects with ARIS-Toolset Problems, experiences and solutions”. 1º International Workshop on Enterprise Management Resource and Planning Systems EMRPS, Venice (Italy), pp. 71-75

Flynn D., Arce E. 1997. “A CASE Tool to support critical success factors analysis in IT planning and requirements determination”, Information and Software Technology, 39, pp. 311-321.

Gable G., Stewart G. 1999. “SAP R/3 Implementation Issues for Small to Medium Enterprises”. Americas Conference on Information Systems AMCIS, Milwaukee, USA.


Galbraith J. 1979. “A change process for the introduction of MIS: a successful case”, TIMS Studies in Management Science, 13, pp. 219-233.

Gattiker T., Goodhue D. 2000. “Understanding the Plant Level Costs and Benefits of ERP: Will the Ugly Duckling Always Turn into a Swan?”, 33rd Hawaii International Conference on Science Systems, Hawaii.

Gibson N., Holland C., Light B. 1999. “Enterprise Resource Planning: A Business Approach to systems Development”. 32nd Hawaii International Conference on Science Systems, Hawaii (USA).

Gibson J., Mann S. 1997. “A qualitative examination of SAP R/3 Implementations in the Western Cape”, an empirical research report presented to the department of information systems, University of Cape Town.

Ginzberg M. 1979. “A Study of the Implementation Process”, TIMS Studies in the Management Sciences, 13, North-Holland Publishing Company, pp. 85-102.

Grunert K., Ellegard C. 1993. “The Concept of Key Success Factors: theory and method”, in M. Baker (eds.), Perspectives on marketing management, 3, Chichester: Wiley, pp. 245-274.

Gulla J., Mollan R. 1999. “Implementing SAP R/3 in a Multi-cultural Organization”. 1º International Workshop on Enterprise Management Resource and Planning Systems, Venice (Italy), pp. 127-134.

Hanseth O., Braa K. 1998. “Technology as Traitor: Emergent SAP Infrastructure in a Global Organization”. International Conference on Information Systems, Helsinki (Finland).

Hardaker M., Ward B. 1987. “How to make a team Work”, Harvard Business Review, 65(6), pp. 112-120.

Harwood S. 2003. “ERP: The Implementation Cycle”, Butterwoth-Heinemann publishing, Burlington (MA).

Hazebrouck P., Frerichs P. 1999. “Use and Enhancement of Accelerated SAP: An Example”. 1º International Workshop on Enterprise Management Resource and Planning Systems, Venice (Italy), pp. 153-171.

Hendrickson A. 2000. “ERP: Enabling Technology for the 21st Century’s Supply Chain”, Transportation Trends, 2(3), pp. 1-7.

Hirschheim R., Newman 1991. “Symbolism and Information Systems Development: Myth, Metaphor and Magic”, Information Systems Research, 2(1), pp.1-34.

Hirt G., Swanson E. 1998. “Adopting SAP at Siemens Power Corporation”. Information Conference on Information Systems ICIS, Helsinki, Finland.

Hirt G., Swanson E. 1999. “Adopting SAP at Siemens Power Corporation”. Journal of Information Technology, 14(3), pp. 243-251.

Holland C., Light B., Gibson N. 1998. “Global Enterprise Resource Planning Implementation”. Americas Conference on Information Systems, Baltimore (USA).

Holland C., Light B. 1999a. “Global Enterprise Resource Planning Implementation”. 32nd Hawaii International Conference on Science Systems, Hawaii.

Holland C., Light B., Gibson N. 1999c. “A Critical Success Factors Model for Enterprise Resource Planning Implementation”, European Conference on Information Systems (ECIS), Copenhagen (Denmark).

Holland C., Light B., Kawalek P. 1999d. “Beyond Enterprise Resource Planning Projects”. 7th European Conference on Information Systems (ECIS), Copenhagen (Denmark).

Holland C., Light B. 1999e. “Critical Success Factors Model for ERP Implementation”. IEEE Software, May/June, pp. 1630-1636.


Huber T., Alt R., Österle H. 2000. “Templates - Instruments for Standardizing ERP Systems”, Hawaii International Conference on Science Systems, Hawaii.

Khandewal V., Miller J. 1992. “Information System Study”, Opportunity Management Program, IBM Corporation, New York.

Khandewal V., Ferguson J. 1999. “Critical Success Factors (CSF) and the Growth of IT in Selected Geographic Regions”, Hawaii International Conference on System Sciences (HICSS).

Kelly S., Holland C., Light B. 1999 “Enterprise Resource Planning: A Business Approach to Systems Development”. Americas Conference on Information Systems (AMICS).

Kock N., Jenkins A., Wellington R. 1999. “A Field Study of Success and Failure Factors in Asynchronous Groupware Supported Process Improvement Groups”, Business Process Management Journal, 5(3), pp. 238-253.

Krammergaard P., Moller C. 2000. “A Research Framework for Studying the Implementation of enterprise resource planning systems”, 23rd information systems Research seminar in Scandinavia, Sweden, pp. 139-162.

Krumbholz M., Galliers J., Coulianos N., Maiden N. 2000. “Implementing enterprise Resource Planning Packages in different Corporate and National Cultures”. Journal of Information Technology, 15(4), pp. 267-280.

Kwon T., Zmud R. 1987. “Unifying the fragmented models of Information Systems Implementation”, in Critical Issues in Information Systems Research, Boland R.J. and Hirschheim, R.A. (eds.), John Willey & Sons Ltd., pp. 227-251.

Jarvenpaa S., Dickson G., DeSanctis G. 1985. “Methodological Issues in Experimental IS Research: Experiences and Recommendations”, MIS Quarterly, 9(2), pp. 141-156.

Leavitt H. 1965. “Applied organizational change in industry: structural, technical and humanistic approaches”, in March J. (ed.), Handbook of Organizations, pp. 1144-1170.

Lee Z., Lee J. 2000. “An ERP Implementation Case Study from a Knowledge Transfer Perspective”. Journal of Information Technology, 15(4), pp. 281-288.

Leidecker J., Bruno A. 1984. “Identifying and Using Critical Success Factors”, Long Range Planning, 17(1), pp. 23-32.

Light B., Holland C., Kelly S. 2000. “Best of Breed IT Strategy: An Alternative to Enterprise Resource Planning Systems”. European Conference on Information Systems (ECIS), Vienna (Austria).

Lindvall J. 2000. “SAP/R3. Support or Straitjacket for the Global Company?”, EAA Conference, Munich (Germany).

Lucas H. 1975. “Why Information Systems Fail”, New York: Columbia University press. Lucas H., Walton E., Ginzberg, M. 1988. “Implementing Packaged Software,” MIS Quarterly, pp.

537-549. McCarthy B., Atthirawong W. 2001. “Critical Factors in International Location Decisions: A

Delphi Study”, 12th Annual Conference of the Production and Operations Management Society, Orlando (USA).

Magal S., Carr H., Watson H. 1988. “Critical Success Factors for Information Centers”, MIS Quarterly, 1988, pp. 413-424.

Markus M., Tanis C. 2000. “The Enterprise Systems Experience- From Adoption to Success”, In Framing the Domains of IT Research Glimpsing the Future Through the Past, R. W. Zmud (Ed.), Pinnaflex Educational Resources, Cincinnati, OH.


Markus M., Axline S., Petrie D., Tanis C. 2000. “Learning from Adopters' Experiences with ERP: problems encountered and success achieved”. Journal of Information Technology, 15(4), pp. 245-266.

Milford M., Stewart G. 2000. “Are ERP Implementations Qualitatively Different from Other Large Systems Implementations?”, Americas Conference on Information Systems (AMCIS), USA.

Nah F., Lau L., Kuang J. 2001. “Critical Factors for Successful Implementation of Enterprise Systems”, Business Process Management Journal, 7(3), pp. 285-296.

O'Hara S. 2000. “Using Metrics to Demonstrate the Value of Project Management”, Project Management Institute Annual Seminars & Symposium, Houston (USA).

Panel 1998a. “Acquiring and Implementing ERP: the view from business to academia”. Chair: Ton Veth, International Conference on Information Systems (ICIS), Helsinki (Finland).

Panel 1998b. “Panel Discussion”. Gable Guy panel chair. Australasian Conference on Information Systems, Sydney (Australia).

Panel 1999a. “ERP in the MIS Curriculum: a Triperspective”, Americas Conference on Information Systems, Milwaukee (USA).

Panel 1999b. “ERP software: characteristics and consequences”. Chair: Michael Rosemann, European Conference on Information Systems (ECIS), Copenhagen (Denmark).

Parr A., Shanks G., Darke P. 1999. “Identification of Necessary Factors for successful Implementation of ERP Systems”. New information technologies in organizational processes - field studies and theoretical reflections on the future of work, Kluwer academic publishers, chapter 8, pp. 99-119.

Parr A., Shanks G. 2000a. “A Taxonomy of ERP Implementation Approaches”, Hawaii International Conference on Science Systems (HICSS), Maui (USA).

Parr A., Shanks G. 2000b. “A Model of ERP Project Implementation”. Journal of Information Technology, 15(4), pp. 289-304.

Pawlowski S., Boudreau M., Baskerville R. 1999. “Constraints and Flexibility in Enterprise Systems: Dialectic of System and Job”. Americas Conference on Information Systems (AMCIS), Milwaukee (USA).

Peffers K., Gengler C., Tuunanen T. 2003. “Extending Critical Success Factors Methodology to Facilitate Broadly Participative Information Systems Planning”, Journal of Management Information Systems, 20(1), pp. 51-85.

Pellow A., Wilson T. 1993. “The Management Information Requirements of Heads of University Departments: a Critical Success Factors Approach”, Journal of Information Science, 19, pp. 425-437.

Perez M., Rojas T., Padron J. 1999. “SAP, Change Management and Process Development Effectiveness II: Case Study”. Americas Conference on Information Systems, Milwaukee (USA).

Pfleeger S. 1993. “Lessons Learned in Building a Corporate Metrics Program”, IEEE Software, May 1993, pp. 67-74.

Pinto J., Prescott J. 1988. “Variations in Critical Success Factors Over the Stages in the Project Lifecycle”, Journal of Management, 14(1), pp. 5-18.


Pinto J., Slevin D. 1988. “Critical success factors across the project lifecycle”, Project Management Journal, 19 (3), pp. 67–75.


Rebstock M., Selig J. 2000. “Development and Implementation Strategies for International ERP Software Projects”, European Conference on Information Systems, Vienna (Austria), pp. 932-936.

Robey D., Ross J., Boudreau M. 2002. “Learning to Implement Enterprise Systems: An Exploratory Study of the Dialectics of Change”, Journal of Management Information Systems, 19(1), pp. 17-46.

Rockart J. 1979. “Chief executives define their own information needs”. Harvard Business Review, March - April 1979, pp. 81-92.

Rockart J., DeLong D. 1988. “Executive Support Systems”, Homewood, IL: Business One Irwin. Rosemann M., Wiese J. 1999. “Measuring the Performance of ERP software - a Balanced

Scorecard Approach”, Australasian Conference on Information Systems (ACIS), Wellington (New Zealand).

Ross J. 1998. “Dow Corning Corporation: Reengineering Global Processes”. International Conference on Information Systems (ICIS), Helsinki (Finland).

Ross J. 1999. “Dow Cornings Corporation: Business processes and information technology”. Journal of Information Technology, 14(3), pp. 253-266.

Rugg G., Hooper S. 1999. “Knowing the Unknowable: The Causes and Nature of changing Requirements”. 1º International Workshop on Enterprise Management Resource and Planning Systems (EMRPS), Venice (Italy), pp. 183-192.

Sandoe K., Corbitt G., Boykin R. 2001. “Enterprise Integration”, John Wiley & Sons, New York. Sarker S. 2000. “Toward a Methodology for Managing Information Systems Implementation: A

Social Constructivist Perspective”, Informing Science, 3(4), pp. 195-205. Sarker S., Lee A. 2000. “Using a Case Study to Test the Role of Three Key Social Enablers in

ERP Implementations”. International Conference on Information Systems, Brisbane (Australia).

Scheer A., Habermann F. 2000. “Making ERP a Success”. Communications of the ACM, 43(4), pp. 57-61.

Scott J. 1999a. “The FoxMeyer Drug's Bankruptcy: Was It a failure of ERP?”. Americas Conference on Information Systems, Milwaukee (USA).

Shah M., Siddiqui F. 2002. “A Survey of Research Methods used to Investigate Critical Factors”, European Conference on Research Methodology for Business and Management Studies, Reading (UK), pp. 353-361.

Shanks G., Parr A., Hu B., Corbitt B., Thanasankit T., Seddon P. 2000. “Differences in Critical Success Factors in ERP Systems Implementation in Australia and China: A Cultural Analysis”. European Conference on Information Systems (ECIS), Vienna (Austria).

Schultz R., Ginzberg M., Lucas H. 1984. “A structural model of implementation”, Management Science Implementation – Applications of Management Science, Supplement 1, 55-87.

Sieber M., Nah F. 1999. “A Recurring Improvisational Methodology for Change Management in ERP Implementation”. Americas Conference on Information Systems, Milwaukee (USA).

Sieber T., Siau K., Nah F., Sieber M. 1999. “Implementing SAP R/3 at the University of Nebraska”. International Conference on Information Systems, Charlotte (USA).

Skok W., Legge M. 2001. “Evaluating Enterprise Resource planning (ERP) Systems using an Interpretive Approach”, SIGCPR2001 Conference on 'The IT Personnel Crisis: Finding and Retaining the Skilled Workforce'. San Diego (USA).

Slooten K., Yap L. 1999. “Implementing ERP Information Systems using SAP”. Americas Conference on Information Systems (AMCIS), Milwaukee (USA).


Smethurst J., Kawalek P. 1999. “Structured Methodology Usage in ERP Implementation Projects: An Empirical Investigation”. Americas Conference on Information Systems (AMCIS), Milwaukee (USA).

Soh C., Kien S., Tay-Yap J. 2000. “Cultural Fits and Misfits: is ERP a Universal Solution?”. Communications of the ACM, 43(4), pp. 47-51.

Somers T., Nelson K., Ragowsky A. 2000. “Enterprise Resource Planning ERP for the Next Millennium: Development of an Integrative Framework and Implications for Research”. Americas Conference on Information Systems (AMCIS), USA.

Somers T., Nelson K. 2001. “The Impact of Critical Success Factors across the Stages of Enterprise Resource Planning Implementations”. Hawaii International Conference on System Sciences.

Southwick R., Sawyer S. 1999. “Critical Views of organization, management, and information technology: applying critical social theory to information system research”. Americas Conference on Information Systems (AMCIS), Milwaukee (USA).

Stefanou C. 1999. “Supply Chain Management SCM and Organizational Key Factors for Successful Implementation of Enterprise Resource Planning ERP Systems”. Americas Conference on Information Systems (AMCIS), Milwaukee (USA).

Stewart G., Milford M., Jewels T., Hunter, T., Hunter B. 2000. “Organisational Readiness for ERP Implementation”. Americas Conference on Information Systems (AMCIS), USA.

Sumner M. 1999a. “Critical Success Factors in Enterprise Wide Information Management Systems Projects”. Americas Conference on Information Systems (AMCIS), Milwaukee (USA).

Sumner M. 1999b. “Critical Success Factors in Enterprise Wide Information Management Systems Projects”. ACM SIGCPR conference on Computer Research, New Orleans (USA).

Sumner M. 2000. “Risk Factors in Enterprise-Wide/ERP Projects”. Journal of Information Technology, 15(4), pp. 317-328.

Thierauf R. 1982. “Decision Support Systems for Effective Planning and Control: A Case study Approach”. Prentice-Hall, Englewood Cliffs USA).

Tishler A., Dvir D., Shenhar A., Lipovetsky S. 1996. “Identifying Critical Success Factors in Defense Development Projects: A Multivariate Analysis”, Technological Forecasting and Social Change, 51(2), pp. 151-171.

Umar A., Missier P. 1999. “A Knowledge-based Decision Support Workbench for Enterprise Resource Integration and Migration”. 1º International Workshop on Enterprise Management Resource and Planning Systems (EMRPS), Venice (Italy), pp. 53-58.

Umble E., Umble M. 2001. “Enterprise Resource Planning Systems: A Review of Implementation Issues and Critical Success Factors”, 32nd Decision Sciences Institute Annual Meeting, San Francisco (USA).

Vessey I., Ramesh V., Glass R. 2002. “Research in Information Systems: An Empirical Study of Diversity in the Discipline and its Journal”, Journal of Management Information Systems. 19(2), pp. 129-174.

Vikram S., Vijay S., David M., Chitti G. 1999. “An Examination of Success factors for SAP Implementation”. Americas Conference on Information Systems (AMCIS), Milwaukee (USA).

Volkoff O. 1999. “Using the Structurational Model of Technology to Analyze an ERP Implementation”. Americas Conference on Information Systems (AMCIS), Milwaukee (USA).


Walsham G. 1995. “The Emergence of Interpretivism in IS Research”, Information Systems Research, 6(4), pp. 376-394.

Ward, B. 1990. “Planning for Profit”. Chapter 5, in “Managing Information Systems for Profit. Edited by T. J. Lincoln, John Wiles & Sons Ltd., pp. 103-146.

Westrup C., Knight F. 2000. “Consultants and Enterprise Resource Planning ERP Systems”. European Conference on Information Systems (ECIS), Vienna (Austria).

Wijn M., Hofenk W., Hoekstra R., Hengeveld M. 1996. “Ktitieke Success Factoren: Een Kritische Beschounwing”, Bedrijskunde, 3, pp. 8-17.

Willcocks L., Sykes R. 2000. “The Role of the IT Function”. Communications of the ACM, 43(4), pp. 32-38.

Williams J., Ramaprasad 1998. “The Utilization of Critical Success Factors: A Profile”, Decision Sciences Institute, 29th Annual Meeting, Las Vegas, Nevada.

Chapter 3 – Research Design 64

Chapter 3

Research Design

Chapter Summary: This chapter describes the research methodology undertaken in this doctoral research.Therefore, the purpose of this chapter is to present the thesis conceptual framework, the researchparadigm, and the research strategy, including the research methods and techniques adopted andused. The chapter reports on the multimethod research focus that this doctoral research project has taken. The doctoral research framework presents the different phases of the research study, withthe different research methods mapped and linked in each phase. Considering the researchquestions and the research context, we rationally selected those research methods that could be useful to address our research questions as well as their combination. Finally, we propose theprinciples for evaluation of interpretive research in IS research.


Thesis Introduction


Research Design






CSFsIdentification


CSFsIdentification




ERP Context

3


3.1 Conceptual Framework

This section describes the conceptual framework related with ERP systems implementation phase, namely with the CSF associated to ERP implementations. As we stated in chapter two, the ERP implementation phase consists of the customization or parameterization and adaptation of the ERP package acquired according to the needs of the organization. Usually this task is made with the help of consultants who provide implementation methodologies, know-how and training.

The thesis conceptual framework diagram is represented in figure 11. The research area is ERP systems and aspects such as: overview, importance, project management, issues and ERP lifecycle were studied (see chapter 2 – Theoretical Background and Literature Review). The thesis specific context was the ERP implementation phase, and its success or failure. The support to ERP implementation through CSF and related KPI was studied. We attempted also to understand the management of these CSF and KPI.

Lifecycle

ERPs

IssuesOverview

Importance

ERPImplementation

ProjectManagement

CSFsManagement

KeyPerformance

Indicators

Critical SuccessFactors

ImplementationSuccess

Figure 11. Conceptual research framework.

3.2 IS Research Paradigms and Methods

The set of activities a research community considers appropriate to the production of understanding (knowledge) are its research paradigms, methods and techniques. In the past two decades, research paradigms have multiplied to a point at which researchers have many choices.


Thus, a review on these paradigms is suitable before propose a research framework (Creswell 2003).

Implicitly, all research presupposes a worldview, a collection of fundamental objects, natural laws and above all definitions of what research is. This is like an immortal soul for Socrates: the framework of what science already knows. Where the natural sciences differ from less developed sciences such as economics or psychology is precisely the presence of such strict rules. These often appear obvious to us. Thomas Kuhn (1970) called these world-views “paradigms”. Immature sciences and complex multidisciplinary research areas are characterized by not having established any paradigms yet. Therefore every researcher has to invent the foundation of his research on his own. Research becomes a random collection of observations that cannot be structured into a whole, since there is no framework to put them in. There is some consensus that the term paradigm has the following key characteristics (Khazanchi and Munkvold 2002):

• Ontology, i.e., the theory or study of existence (being). For example, ontological assumptions in the conduct of inquiry within a paradigm might specifically characterize the nature of reality;

• Epistemology, i.e., a theory of knowledge that deals with the nature of knowledge, its scope, and provides a set of criteria for evaluating knowledge claims and establishing whether such claims are warranted; and

• Methodology, i.e., a procedure by which knowledge is to be generated. The most used classification of IS research paradigms divides them into positivist,

interpretative, and critical research (Orlikwoski and Baroudi 1991, Klein and Myers 1999). Khazanchi and Munkvold (2002) made an overview and comparison of these paradigms (see appendix C).

Positivists generally assume that reality is objectively given and can be described by measurable properties which are independent of the observer (researcher) and his or her instruments. Positivist studies generally attempt to test theory, in an attempt to increase the predictive understanding of phenomena. In line with this Orlikowski and Baroudi (1991, p.5) classified IS research as positivist if there was evidence of formal propositions, quantifiable measures of variables, hypothesis testing, and the drawing of inferences about a phenomenon from the sample to a stated population.

Walsham (1995) describes interpretative paradigm in IS research in the following way: “interpretive methods of research adopt the position that our knowledge of reality is a social construction by human actors. In this view, value-free data cannot be obtained, since the enquirer uses his or her preconceptions in order to guide the process of enquiry, and furthermore the research interacts with the human subjects of the enquiry, changing the preconceptions of both parties”.

Critical researchers assume that social reality is historically constituted and that it is produced and reproduced by people. Although people can consciously act to change their social and economic circumstances, critical researchers recognize that their ability to do so is constrained by various forms of social, cultural and political domination. The main task of critical research is seen as being one of social critique, whereby the restrictive and alienating conditions of the status quo are brought to light. Critical research focuses on the oppositions, conflicts and contradictions in


contemporary society, and seeks to be emancipatory i.e. it should help to eliminate the causes of alienation and domination.

In post-modern thinking there is an idea that many different paradigms can coexist and knowledge is seen as a set of perspectives (Heylighen 1999). As more and more concepts, theories and models are developed it becomes impossible for any one scientist to remain informed about all of them. Researchers are forced to focus on smaller and smaller domains, becoming ever more specialized.

3.2.1 Quantitative, Qualitative, and Multimethod Research

Research methods can be classified in various ways. However one of the most common distinctions is between qualitative and quantitative research methods:

• Quantitative research methods were originally developed in the natural sciences to study natural phenomena. Examples of quantitative methods now well accepted include survey methods, laboratory experiments, formal methods (e.g. econometrics) and numerical methods such as mathematical modeling.

• Qualitative research methods were developed in the social sciences to enable researchers to study social and cultural phenomena. Examples of qualitative methods are action research, case study research and ethnography. Qualitative data sources include observation and participant observation (fieldwork), interviews and questionnaires, documents and texts, and the researcher’s impressions and reactions.

Although most researchers do either quantitative or qualitative research work, some researchers

have suggested combining one or more research methods in the one study. This type of research is denominated mixed and multimethod research. Qualitative and quantitative methods have different strengths and logics and are often best used to address different questions and purposes.

3.2.1.1 Quantitative Methods

According to Creswell (2003, p. 19) the use of quantitative methods is recommended when the researcher:

• Tests or verifies theories or explanations. • Identifies variables to study. • Relates variables questions or hypotheses. • Uses standards of validity and reliability. • Observes and measures information numerically. • Uses unbiased approaches. • Employs statistical procedures.

3.2.1.2 Qualitative Methods

Morse (1991) says that the characteristics of a qualitative research problem are: • The concept is immature due to a conspicuous lack of theory and previous research. • A notion that the available theory may be inaccurate, inappropriate, incorrect, or biased.


• A need exists to explore and describe the phenomena and to develop theory. • The nature of the phenomenon may not be suited to quantitative measures.

Maxwell (1996, p. 17) defined five particular research purposes for which qualitative studies

are especially suited: 1. Understanding the meaning, for participants in the study, of the events, situations, and

actions they are involved with and of the accounts that they give of their lives and experiences.

2. Understanding the particular context within which the participants act, and the influence that this context has on their actions.

3. Identifying unanticipated phenomena and influences and generating new grounded theories about the latter.

4. Understanding the process by which events and actions take place. 5. Developing causal explanations.

3.2.1.3 Multimethod Research

In the related literature it is common to find the terms ‘mixed method’ design , ‘multimethod’ design and ‘multiple method’ design that are very often used interchangeably. However, it is important to distinguish these terms. Tashakkori and Teddlie (2003, p. 11) define multiple method as “research in which more than one method or more than one worldview is used”. They define at least three broad categories of these multiple methods: multimethod research, mixed method research, and mixed model research. From the analysis of Tashakkori and Teddlie (2003) we evidence that the distinction among these terms is related to the research stage of the study (definition of research questions, research methods, data collection and analysis, and the inference process) where the mix of methods is used. Morse (2003, p. 190) provides the following definitions for multimethod and mixed method designs:

• Mixed methods design – this is the incorporation of various qualitative and quantitative strategies within a single project that may have either a qualitative or quantitative theoretical drive. The “imported” strategies are supplemental to the major or core method and serve to enlighten or provide clues that are followed up within the core method.

• Multimethod design – this is the conduct of two or more research methods, each conducted rigorously and complete in itself, in one project. The results are then triangulated to form a complete whole.

Morse (2003) uses the term research project to refer to a research study focusing in one

research question, while research program refers to a cluster of research projects. According to Morse (2003), the major difference between multimethod and mixed method design is that in multimethod design all projects are complete in themselves. Tashakkori and Teddlie (2003) propose the term mixed model research to represent the mixed combination of methods in many or all the stages of the study. Regarding multimethod design, Morse (2003) describes three main principles:

• Principle 1: identify the theoretical drive of the research project. • Principle 2: develop overt awareness of the dominance of each project.


• Principle 3: respect methodological integrity. The first principle analyses the importance of the theoretical drive definition. The theoretical

drive may be inductive (for discovery) or deductive (for testing). The second principle is related with the awareness of working inductively or deductively at any given time which will ensure that the assumption of each method is not violated. Morse (2003) defines two types of multimethod designs that may be applied: simultaneous and sequential designs. Using a categorization of qualitative and quantitative methods and the two main types of multimethod design, Morse (2003) proposes eight combinations of multimethod designs (see table 5). According to Morse’s naming convention indicates, awareness of the theoretical drive by using uppercase/lowercase notations indicating that the major methods (a plus [+] sign indicating that the methods are used simultaneously or an arrow [ ] indicating directions), with uppercase representing dominance and lowercase representing the supplemental projects.

Morse (2003) mentions that research projects may have complex designs containing combinations of the above (table 5), depending on the scope and complexity of the research program. The third principle emphasizes the need to keep the integrity of each research method. “It is important not to violate the assumptions, sampling (appropriateness and adequacy of data), and so forth” (Morse 2003, p. 199). Hunter and Brewer (2003, p. 578) mention that the multimethod approach “is a strategy for overcoming each method’s weaknesses and limitations by deliberately combining different types of methods within the same investigations”. Table 5. Characteristics of multimethod designs (source: Morse 2003). Design type Combination Simultaneous QUAL+qual indicates a qualitatively-driven, qualitative simultaneous design.

QUAN+quan indicates a quantitatively-driven, quantitative simultaneous design. QUAL+quan indicates a qualitatively-driven, qualitative and quantitative simultaneous design. QUAN+qual indicates a quantitatively-driven, quantitative and qualitative simultaneous design.

Sequential QUAL qual indicates a qualitative-driven project followed by a second qualitative project. QUAN quan indicates a quantitative-driven project followed by a second quantitative project. QUAL quan indicates a qualitative-driven project followed by a second quantitative project. QUAN qual indicates a quantitative –driven project followed by a second qualitative project.

Mingers (2001) proposes a framework for mapping the research methods in a multimethod

design approach. This framework is based in two important features for multimethod research: its multidimensionality and the different types of activity that need to be undertaken within the phases of research. “By combining these two factors, a grid is produced that can be used to map the characteristics of different research methods to help in linking them together” (Mingers and Brocklesby 1997).

Regarding multidimensionality and based on Habermas’s theory, Mingers (2001) says that we can categorize research methods in terms of their relationship to the three worlds – the material world, the social world, and the personal world. The definitions of these worlds are included in table 6.


Table 6. Three worlds relevant to research methods (source: Mingers 2001). World Characteristics

The Material World

It is outside and independent of human beings. It existed before us and would exist whether or not we did. We can shape it through actions, but are subject to constraints. Our relationship to this world is one of observation, but such observations are always theory and subject dependent. We can characterize this world as objective in the sense that it is independent of the observer, although clearly our observations and descriptions of it are not.

The Personal World

It is the world of our own individual thoughts, emotions, experiences, and belief. We do not observe it, but experience it. This world is subjective in that it is generated by, and only accessible to, the individual subject. We can aim to express our subjectivity to others and, in turn, appreciate theirs.

The Social World

It is the world that we share and participate in. Our relation to it is one of intersubjectivity because it is, on the one hand, a human construction, and on the other, it goes beyond and preexists any particular individual. It consists of a complex multilayering of language, meaning, social practices, rules, and resources that both enables and constraints our actions and is reproduced through them. One of its primary dimensions is that of power.

For the second dimension of multimethod research framework – the phases of the research

process, Mingers (2001, p. 245) identifies four phases: • Appreciation of the research situation as experienced by the researchers involved,

expressed by any actors in the situation, and prior literature and theories. This will involve the identification of the experience or phenomena to be explained, initial conceptualization and design of the study, and the production of basic data using methods such as observation, interviews, experiments, surveys, or qualitative approaches.

• Analysis of the data produced so as to understand the history that has generated it, and the particular structure of relations and constraints that maintain it. This will involve analysis methods appropriate to the methodology of the study and the data produced in the first stage.

• Assessment of the postulated explanation(s) in terms of other predicted effects, alternative possible explanations, and, within action research, consideration of ways in which the situation could be other than it is. The assessment phase also involves interpretation of the results, and inherence to other situations.

• Action to report on and disseminate the research results and, if necessary or desired, to bring about change to the situation.


3.3 Research Strategy

In this section we outline the doctoral research proposal. First, we define the research questions. Second, we present the goals to be achieved. The motivation aspects are then presented. Next, we present the expected contributions of the doctoral research study. Finally, we describe the research plan.

3.3.1 Research Questions

The general research questions of the doctoral research study are the following: • What are the CSF for an ERP implementation project? CSF should be analyzed with respect to

organizational and technological perspectives. • What is the relevance of each CSF along the implementation project stages? • How these CSF are managed and influence ERP implementation projects? • What are the KPI related to the above CSF? These KPI help in the control and monitor of CSF.

3.3.2 Research Goals

The main research goal of this study is to gain an understanding of project management practices in the realm of ERP implementation by focusing on the analysis of CSF and the generation of KPI. Therefore, the project aims to contribute to the monitoring of the implementation phase, to help managers in the task of project management. The definition of goals was done accordingly to the decision-making structure presented in figure 10. We attempt to achieve the following goals:

• Definition of CSF needed for a successful ERP implementation. All the studies related with CSF and ERP implementations are based on case studies so, first, we attempt to unify these CSF in a unique model.

• Understand how CSF are managed in ERP implementations. • Generation of a tentative set of KPI to help with the monitoring of CSF. Usually, once

CSF are established, each process and department is encouraged to identify indicators that can be used to measure its contribution. KPI can be used to monitor the ERP implementations and, help in CSF analysis, thus helping managers in the decision making process related to the ERP implementation phase (see figure 11).

3.3.3 Motivation

The main motivations to do this doctoral research study were: • The first reason to research in ERP area was a scientific reason. The IS implementation

literature, while acknowledging adaptation as one phase in the process, offered little theory to address the problems faced during implementation of packaged application software (Holland et al. 1999, Volkoff 1999, Esteves and Pastor 2001).

• Furthermore, there was the personal motivation and curiosity to know why it is difficult to adopt an IS even if it follows (from a technology and conceptual perspective) the needs of


an organization. Many organizations have tried ERP implementations and it is obvious that ERP implementations are difficult and that success is not guaranteed.

3.3.4 Research Paradigm

In order to develop this doctoral research project we decided to adopt the interpretive research paradigm. Interpretive paradigm assumes that “our knowledge of reality is gained only through social constructions such as languages, consciousness, shared meanings, documents, tools, and other artifacts” (Klein and Myers 1999, p. 69). Interpretive research does not predefine dependent or independent variables and it attempts to explain phenomena through the meanings that people assign to them (Orlikowski and Baroudi 1991, Klein and Myers 1999). According to Walsham (1993) the purpose of the interpretive approach in IS is to produce an understanding of the context of IS and the process whereby IS influences and is influenced by the context. The interpretive approach accords with the significance of context in the research, which is not considered as “given” and external to human agency, rather, actors are constantly making the context used for the “interpretive act” (Boland 1993). Interpretive research approach gives the researcher greater scope to address issues of influence and impact, and to ask questions such as “why” and “how” particular technological trajectories are created (Orlikowski and Baroudi 1991).

Aladwani (2001, p. 267) states that “past ERP implementation research may be described as factor research, which involves identifying the factors or variables that are critical for implementing ERP successfully. Although factor research is valuable for advancing our understanding of ERP implementation success, it adopts a static view, which limits its adequacy in explaining the dynamics of the implementation process”. Aladwani (2001) and Robey et al. (2002) suggest a process research approach or a combination of factor and process approaches, in order to improve research in ERP topics. Using a process approach, ERP implementation may be conceived as sequences of discrete events that lead to outcomes of particular interest. Another perspective is that an ERP implementation may be conceived as a sequence of stages, in which related activities occur (Robey et al. 2002). Our aim is to use both factor and process approaches in order to study CSF for ERP implementation projects.

3.3.5 Research Design

We agree with Robey (1996, p. 406) when he says that “theoretical foundations for research and specific research methods are justified by research aims, or purposes. They should not be chosen because they conform to a dominant paradigm or because the researcher believes in their intrinsic value. Rather theory and method are justified on pragmatic grounds as appropriate tools for accomplishing research aims”. Therefore, in order to accomplish the research aims of this research, we propose a research framework (see figure 2) that combines various research methods, both quantitative and qualitative, with predominance of qualitative ones. This type of research is defined as “multimethod” research by Mingers (2001). There is a move in the IS field toward combining qualitative and quantitative methods (Mingers 2001). These methods need not to be viewed as polar opposites (Van Maanen 1983) since their combination introduces both testability and context into the research (Kaplan and Duchon 1988). Collecting different kinds of data by different methods from different sources provides a wider range of coverage that may result in a


fuller picture of the unit under study than would have been achieved otherwise (Bonoma 1985). The use of multiple methods increases the robustness of results because findings can be strengthened through triangulation – the cross-validation achieved when different kinds and sources of data converge and are found congruent (Kaplan and Duchon 1988).

The doctoral research framework (see figure 12) presents the different phases of the research study, and with the different research methods mapped and linked in each phase. Considering the research questions and the research context, we asked ourselves which research methods could be useful to address those questions. These are the research methods that we believe are appropriate for this research study. At the beginning we accepted that some research methods could change accordingly to the outcomes that we would obtain in each research phase.







CSFsIdentification


CSFsIdentification




ERP Context

Figure 12. Multimethod research framework Proposal.

Next, we describe each research phase that we carried out using the multimethod approach.


3.3.6 Multimethod Design Followed

In order to accomplish the research aims of this research, we proposed a multimethod research framework (see table 7) that combined various research methods, both quantitative and qualitative, with predominance of qualitative ones. The use of multiple methods increases the robustness of results because findings can be strengthened through triangulation – the cross-validation achieved when different kinds and sources of data converge and are found congruent (Kaplan and Duchon 1988). Taking into account the research questions and the research context, we asked ourselves which research methods could be useful to address those questions. These are the research methods that we believe are appropriate for this research study. At the beginning we accepted that some research methods could change accordingly to the outcomes that we would obtain in each research phase. Mainly, our approach follows the QUAL qual and the QUAL quan design type according to Morse (2003) typology. We would like to emphasize that our model is quite complex with some combinations proposed by Morse (2003). Next, we briefly describe each research phase and the respective research methods used. Table 7. Multimethod research framework proposal.

Research methods used

Research Phase Type

Lite

ratu

re r

evie

w

Cod

ing

proc

edur

e

Cas

e st

udy

Proc

ess q

ualit

y m

anag

emen

t

Surv

ey

Web

surv

ey

Stat

istic

al a

naly

sis

Gro

unde

d th

eory

Goa

ls/q

uest

ions

/met

rics

Stak

ehol

der

anal

ysis

ERP implementation review QUAL CSF identification QUAL quan CSF relevance QUAL qual CSF management QUAL qual KPI identification QUAL quan Confirmatory case study QUAL qual

3.3.6.1 ERP implementation projects

The first phase of this research framework consisted in an extensive literature review on the ERP topic. Based on this literature review, we provided an annotated bibliography of the ERP publications published in the main Information Systems conferences and journals with which we reviewed the state of art in this area (Esteves and Pastor 1999, Esteves and Pastor 2001). The surveyed publications were categorized through a typical ERP lifecycle. Furthermore, the survey included proposed topics for further research in each phase. One of these topics was CSF for ERP implementation projects.


3.3.6.2 CSF identification

The purpose of this phase was to identify and define the CSF for ERP implementation projects. We developed a unified model of CSF based on prior research with partial CSF lists through the application of the Open Coding procedure from the Grounded Theory method (Glaser and Strauss 1967). The number of CSF is large but they are divided in four perspectives: strategic and tactical perspectives, and organizational and technological perspectives. We also compared the CSF for ERP implementations with CSF for other IS implementation projects. Finally, we carried out specific research to clarify the project champion role CSF since during the literature review we found some misunderstandings regarding this figure, for which we used the web survey method to collect the data. This data was analyzed through qualitative procedures and by using some statistical analysis. The findings show that the project champion is associated to the project sponsor role and that project sponsor and project manager are both identified as CSF for ERP implementation projects. This clarification was used to refine our prior CSF unified model.

3.3.6.3 CSF relevance

The purpose of this phase was to analyze the CSF relevance along the typical ERP implementation phases using the Process Quality Management (PQM) method. The PQM developed by IBM is “designed to assist the management team reach consensus on the most critical business activities, i.e. those whose performance will have the biggest impact on the success or failure of the enterprise” (Hardaker and Ward 1987, Ward 1990, p. 105). The PQM method uses the concept of CSF (Rockart 1979) to encourage management teams to focus their attention on the critical issues of the business, and then to base the IT strategy on these. This is a novel way of studying CSF relevance since until now researchers have used case studies or surveys. By applying PQM and using the ASAP implementation methodology as a reference for the SAP implementation processes, we defined the CSF relevance for each CSF along the SAP implementation phases. We used SAP as the ERP system because SAP is the most implemented ERP systems worldwide and because the documentation of SAP implementation is more accurate and accessible. Next, we contacted two professional experts on SAP implementations and we asked them to verify the relationships between CSF and SAP implementation processes that we had previously established. We asked them to provide an argumentation for each change. Overall, their opinion was that our analysis was very accurate and rigorous.

Next, we extrapolated our findings to other ERP studies by comparing our relevance schema with others proposed by other colleagues. One of the limitations of PQM is that the process structure of the PQM is too simple since it only provides one level of process analysis. Since the structure of ERP implementation processes implies project process structures that are more complex, we proposed the improvement of the PQM analysis section to provide more depth to these complex project structures. We then extended the standard PQM method, with a new criticality indicator for complex implementation project process structures. This criticality indicator was used to define and analyze the most critical SAP implementation processes. Finally, we analyze the relevance of knowledge types along the SAP implementation phases. Our research model helped to provide some exploratory insights on knowledge types needed for the


management of CSF and also to analyze the relevance of these knowledge types along the SAP implementation phases.

3.3.6.4 CSF Management

To study the management of CSF we opted for using the case study method. A case study is “an empirical enquiry that investigates a contemporary phenomenon within its real-life context, especially when the boundaries between phenomenon and context are not clearly evident and it relies on multiple sources of evidence” (Yin 1994, p. 13). We conducted a pilot case study of an ERP implementation in a Portuguese Small and Midsized enterprise (SME). This SME was selected because we detected a lack of studies on ERP implementations on SME, and the geographic location. Since Portugal is the country of the doctoral student, the language spoken and the knowledge of Portuguese society were an advantage, and the SME is located near the home residence which helped to keep contact with interviewers. Finally, the SME managers were open to provide access to all the project documentation. All these reasons are point out by Yin (1994) as valid reason to select a pilot case study.

The pilot case study helped to validate the research framework and the preparation of the in-depth case study (see confirmatory case study phase below). Yin (1994) states that the case study approach “allows an investigation to return the holistic and meaningful characteristics of real life events - such as individual lifecycles, organizational and managerial processes...and the maturation of industries”. As Stewart and Gable (1999) comment:

• This approach is appropriate to understanding ERP implementation issues because the research objective is to characterize the organizational and managerial processes constraining such implementations,

• It provides useful skills to researchers, • It is most appropriate to understanding the interactions between the issues (as theoretical

construct) and the context within which these issues are operating. According to Yin (1994, p. 77), “the pilot case study helps investigators to refine their data

collection plans with respect to both the content of the data and the procedures to be followed. The pilot case is used more formatively, assisting an investigator to develop relevant lines of questions – possibly even providing some conceptual clarification for the research design as well”. The pilot case study serves as a preparation for the in depth case study. Since there were no studies related with this topic, the pilot case study also served as an exploratory case study.

The data collected in our pilot case study was analyzed using Grounded Theory (GT) method. GT method is a general methodology for developing theory that is grounded in data systematically gathered and analyzed. The methodology was presented initially by Glaser and Strauss in The Discovery of Grounded Theory (1967). Strauss and Corbin (1990, p. 23) explain that by using GT “a theory is inductively derived from the study of the phenomenon it represents. That is, it is discovered, developed, and provisionally verified through systematic data collection, analysis, and theory stand in reciprocal relationship with each other. One does not begin with a theory, and then prove it. Rather, one begins with an area of study and what is relevant to that area is allowed to emerge”. GT differs from other qualitative approaches. Traditional qualitative approaches collect the data first before commencing the analysis and long after they have left the research site. In


contrast, grounded theorists use their emerging theoretical categories to shape the data collection while doing the fieldwork. The concept of theory deserves a clarification. According to Strauss and Corbin (1990, p. 15), a theory is “a set of well-developed concepts related through statements of relationship, which together constitute an integrated framework that can be used to explain or predict phenomena”. We will refer a theory concept as Strauss and Corbin (1990) stated before.

Lately, GT method has gained importance in the IS field (for a review on GT method in IS field see Smit and Bryant 2000). Myers (1998) suggests that this can be attributed to the fact that the method is useful for developing context-based, process-oriented descriptions and explanations of phenomena. GT method seems particularly useful for this doctoral research since there is a lack of theoretical foundation in ERP implementation topics (Robey et al. 2000, Esteves and Pastor 2001); we decided to analyze the data collected through case studies with GT method. Another important characteristic of GT method is that it facilitates “the generation of theories of process, sequence, and change pertaining to organizations, positions, and social interactions “(Glaser and Strauss 1967, p. 114). This seems particularly useful in our research since the literature reveals that organizational perspective has a strong influence on ERP implementations.

The three phases of GT method are: open coding, axial coding and selective coding. In order to establish relationships among the concepts that will emerge in the open coding phase, we will use the paradigm model proposed by Strauss and Corbin (1990). The paradigm model is “an analytical tool devised to help analysts integrate structure with process” (Strauss and Corbin 1990, p. 123). Briefly, the paradigm model encompasses the following elements: causal conditions, the phenomenon, the context, the intervening conditions, strategies and actions, and finally the consequences.

3.3.6.5 KPI Identification

In this phase we developed a set of Key Performance Indicators (KPI) for each CSF in order to improve the management, control and monitoring of the CSF defined previously. We used the Goals/Questions/Metrics (GQM) method. The GQM approach is a mechanism for defining and interpreting operational, measurable goals. It was developed at the University of Maryland as a mechanism for formalizing the tasks of characterization, planning, construction, analysis, learning and feedback. GQM does not provide specific goals but rather a framework for stating measurement goals and refining them into questions to provide a specification for the data needed to help achieve the goals (Basili et al. 1994). The GQM top-down approach assists managers and developers not only in knowing what data to collect but also in understanding the type of analysis needed when the data is in hand (Pfleeger et al. 1997). Because of its intuitive nature the approach has gained widespread appeal. As a result, we proposed a GQM preliminary plan with different metrics to monitor and control CSF while implementing an ERP system.

3.3.6.6 Confirmatory Case Study

To validate all our previous research we conducted an in-depth case study combined with the GT method of an ERP implementation in a big Spanish university. This case study may be considered a critical case (Yin 1994). This ERP implementation was selected because the authors maintain a very close relationship with that university, thus, we can understand better the ERP


implementation context, and second, this ERP implementation was the first to implement a specific ERP, in a Spanish Higher Education Institution (HEI) with the public sector module. Nowadays, this last aspect also makes it a unique case study in Spain. Different research techniques have been used to collect data and to increase credibility and validity to the case study (Yin 1994).

Again, the data collected was analyzed through the GT method. In this doctoral research program we adopt Strauss viewpoint of GT method rather the one by Glaser. The key distinction relates to the position the researcher takes in relation to the data. Glaser (1992, p. 4) states that a GT can only be grounded in the data and would otherwise be a preconceived conceptual description of the phenomenon under investigation. Glaser (1992, p. 22) states that a preconceived research problem will necessarily obstruct the researcher’s view of the data while Strauss and Corbin (1990) suggest several sources of research problems including suggested or assigned (for example by a professor to a graduate student), technical literature, and personal and professional experience. They believe that “the research question in a grounded theory study is a statement that identifies the phenomenon to be studied” (Strauss and Corbin 1990, p. 38). For Glaser (1992, p. 22) the researcher begins his or her study “with the abstract wonderment of what is going on that is an issue and how it is handled”. The second main divergence concerns theory generation versus theory verification. Strauss and Corbin (1990) emphasize on verification and validation of theory and hypotheses “throughout the course of a research project” (Strauss and Corbin, 1994, p. 274). In Glaser's opinion, verification falls outside the parameters of grounded theory which instead should be directed at the discovery of hypotheses or theory. Glaser reminds the reader that the verificational model was “exactly what we had tried to get away from” (Glaser and Strauss 1967, p. 67). Finally, Strauss and Corbin (1994) version of GT method allows for the potential of prior theory, literature, and personal and professional experiences to help researchers gain insight into the data.

This choice has implications for the research design and the research outcomes. We acknowledge these differences. However, our idea in using the GT method is not to provide a grounded theory of ERP implementations as stated by Glaser (1992) but we instead combine the GT method with the case study method to provide a theory that is grounded in data collected from the case studies. Our main purpose for using the GT method is to serve as a research method to analyze the data collected in our case studies.


3.4 Trustworthiness of the Research

In qualitative research the requirements of validity and reliability are under enthusiastic discussion. There are interpretations that these traditional measures of reliability are not applicable at all in qualitative research because of the nature of the methods and epistemological assumptions of the research, which promote the uniqueness of the research. On the other hand, there are also demands for using the same criteria for qualitative and quantitative research when evaluating the trustworthiness of the research. Between these poles are many different variations for justifying the results of the research. However, the issue of trustworthiness cannot be avoided whatever the epistemological approach of the research (Gibbs 2002, p. 13).

Lincoln and Guba (1985) describe the criteria that are frequently cited for evaluating qualitative studies. They address the criticisms leveled at naturalistic research and determine that quality rests in trustworthiness of the study and its findings. They agree with others that conventional criteria are inappropriate for qualitative studies and they proposed: (1) credibility, (2) transferability, (3) dependability, and (4) confirmability, as the alternative the criteria. Next, we describe each research evaluation component.

3.4.1 Credibility

Credibility refers to the accuracy or credibility of the findings, or it can be described as a “truth formulating process” between the researcher and the informants (Lincoln and Guba, 1985). The goal is to demonstrate that inquiry was conducted in a way which ensures the subject was accurately described. To maximize credibility, Lincoln and Guba (1985) suggest a number of techniques:

• Increase the likelihood that credible findings and interpretations are produced through prolonged engagement, persistent observation, and triangulation.

• Use peer (stakeholder) debriefing to provide an external check on the inquiry process. • Use negative case analysis to refine the emerging results. • Make a direct test of findings and interpretations by checking them with participants.

A common technique used is the stakeholder check. Stakeholder checks might involve

opportunities for people with a specific interest in the research, such as participants, service providers, funding agencies, to comment on categories or the interpretations made (Erlandson et al. 1993, p. 142). With regard to triangulation, Patton (1987) discusses four types of triangulation in doing evaluations, that is, the triangulation:

• of data sources (data triangulation), • among different evaluators (investigator triangulation), • of perspectives on the same data set (theory triangulation) and • Of methods (methodological triangulation).

Yin (1994) provides a list of data sources that can be used during data source triangulation such

as interviews, analysis of documents and direct observation. Bratthall and Jorgensen (2002) extended Yin’s (1994) work by adding some practical guidelines for use during data source


triangulation. The triangulation among evaluators will be made by contrasting perspectives among the doctoral student and the doctoral supervisor.

3.4.2 Transferability

An alternative concept to the logical positivist's generalizability construct (or external validity) is Lincoln and Guba's (1985) transferability. In Lincoln and Guba's (1985) use of the term, “transferability” implies generalizability of the findings and results of the study to other settings, situations, populations, circumstances, etc. The idea beyond generalizability on qualitative studies usually is based, “not on explicit sampling of some defined population to which the results can be extended, but on the development of a theory that can be extended to other cases” (Maxwell 1996, p. 97). Transferability is relative and depends entirely on the degree to which salient conditions overlap or match. This is mostly verified through “thick” description. The researcher does not provide the confidence limits of the study, but instead provides as complete a data base as possible in order to facilitate transferability judgments on the part of others.

With regard to case study method generalization, Yin (1994, p. 30) noted that another way of thinking about case research is that its results should be generalized to a theory, named analytic generalization in contrast with statistical generalization. “In statistical generalization an inference is made about a population (or universe) on the basis of empirical data collected about a sample” Yin (1994, p. 30) while “in the analytical generalization, the researcher is striving to generalize a particular set of results to some broader theory” (Yin 1994, p. 36).

One of the procedures that may be available to establish transferability, applicable to all but the most exploratory of qualitative studies, is to see whether a given theory or model that the qualitative researcher claims to be testing or applying has, in fact, been accurately interpreted and used in the research. This may be interpreted as a check of 'content accuracy.'

Finally, perhaps the most defensible indicator of transferability is to look for evidence of multimethod procedures in the design and/or analysis of the qualitative study. By applying such different methods and procedures and then triangulating or comparing the different 'paths' or results to see if they 'converge' upon the same findings and results, serve to enhance the believability and robustness of the results - more so than if a single method were used.

3.4.3 Dependability

This is concerned with the stability of the data over time. Dependability requires accounting for dynamic changes in the phenomenon of study, design, or methodology as appropriate (Lincoln and Guba 1985). Therefore, there is the need to be able to demonstrate any changes or shifts in the way in which the inquiry was conducted. In order to assess the degree of dependability, Lincoln and Guba (1985) advise us to look for accurate and adequate documentation of changes, surprise occurrences, and the like, in the phenomena being studied. If change is to be expected, has it been thoroughly described? Similarly, have any unexpected but material occurrences which might affect our variables of study been identified and documented with adequate detail?

Lincoln and Guba (1985) point out that dependability is difficult to predict in a changing social world. In establishing dependability, the researcher attempts to account for changing conditions in


the phenomenon chosen for study as well as changes in the design created by increasingly refined understanding of the setting.

3.4.4 Confirmability

This quality, according to Lincoln and Guba (1985), is synonymous with objectivity. Need to show that data, interpretations and outcomes inquires are rooted in contexts and persons apart from the evaluator and are not simply figments of the evaluator’s imagination. All data needs to be able to be tracked to its source and that the logic used to assemble the interpretations into structurally coherent and corroborating wholes is both explicit and implicit in the narrative of the case study. Evidence for this quality may be established in two ways:

• Via our more traditional notions of credibility: is there a smooth logical progression, as evidenced in the research report. This one, then, depends on the 'internal logic' of the study and particularly how thoroughly and skillfully it is substantiated in the narrative of the research report. Is there a 'natural flow,' or a 'Grand Canyon leap of faith?!' Does it “feel real?!”

• Via some evidence of lack of the researcher's own bias: such as, for instance, doing 'member checks' and running his/her findings and conclusions past third parties, “key informants” from the same or similar field setting as the original study, etc. Perhaps this one is 'established in reverse:' that is, do you see anything in the research report to indicate to you a potential bias on the researcher's part? Premature closure regarding the findings? Unwillingness to thoroughly search out and account for potential 'disconfirming' evidence? And so forth.

This doctoral research project is found to follow the trustworthiness components described

above and thus the research will be evaluated against them. The thesis evaluation is done in the chapter 9 – Contributions and further work.

3.5 References

Aladwani A. 2001. “Change Management Strategies for Successful ERP Implementation”, Business Process Management Journal, 7(3), pp. 266-275.

Basili V., Caldera C., Rombach H. 1994. “Goal Question Metric Paradigm”, Encyclopedia of Software Engineering (Marciniak, J.J. editor), vol. 1, John Wiley & Sons, pp. 528-532.

Bergeron F., Begin C. 1989. “The Use of Critical Success Factors in Evaluation of Information Systems: A Case Study”, Journal of Management Information Systems, 5(4), pp. 111-124.

Boland R. 1993. “Accounting and the Interpretive Act”, Accounting Organizations and Society, 18(2/3), pp. 125-146.

Bonoma T. 1985. “Case Research in Marketing: Opportunities, Problems and a Process”, Journal of Marketing Research, 2(2), pp. 199-208.

Bratthall L., Jorgensen M. 2002. “Can You Trust a Single Data Source Exploratory Software Engineering Case Study?”, Empirical software engineering, 7, pp. 9-26.


Cavaye A. 1996. “Case Study Research: A multi-faceted research approach for IS”, Information Systems Journal, 6, pp. 227-242.

Creswell J. 2003. “Research Design: qualitative, Quantitative, and mixed methods approaches”, second edition, Sage publications.

Erlandson D., Harris E., Skipper B., Allen S. 1993. “Doing naturalistic enquiry: A guide to methods”, Newbury Park, CA: Sage.

Esteves J., Pastor J. 1999. “An ERP Lifecycle-based Research Agenda”, Proceedings of 1st International Workshop on Enterprise Management and Resource Planning: Methods, Tools and Architectures - EMRPS'99, pp 359-371.

Esteves J., Pastor J. 2001. “Enterprise Resource Planning Systems Research: An Annotated Bibliography”, Communications of the Association for Information Systems (CAIS), vol. 7, article 8, August 2001.

Gibbs G. 2002. “Qualitative analysis with Nvivo”, Open University Press, Buckingham. Glaser B., Strauss A. 1967. “The Discovery of Grounded Theory”. Chicago: Aldine. Glaser B. 1992. “Basics of Grounded Theory Analysis: Emergence vs. Forcing”. Mill Valley, CA:

Sociology Press. Hardaker M., Ward B. 1987. “Getting Things done: How to Make a Team Work”, Harvard

Business Review, Nov/Dec 1987, pp. 112-119. Holland C., Light B., Gibson N. 1999. “A Critical Success Factors Model for Enterprise Resource

Planning Implementation”. European Conference on Information Systems. Hunter, A., Brewer, J. (2003) “Multimethod Research in sociology” in Tashakkori and Teddlie

(2003), pp. 577-594. Kaplan B., Duchon D. 1988. “Combining Qualitative and Quantitative Methods in Information

Systems Research: A Case Study”, MIS Quarterly, December 1988, pp. 571-586. Khanzanchi D., Munkvold B. 2002. “On the rhetoric and relevance of IS research paradigms: A

conceptual framework and some propositions”, 36th Hawaii international conference on system sciences (HICSS).

Klein H., Myers M. 1999. “A Set of Principles for Conducting and Evaluating Interpretive Field Studies in Information Systems”, MIS Quarterly, 23(1), pp. 67-94.

Kuhn T. 1970. “The Structure of Scientific Revolutions”, the University of Chicago Press, Chicago.

Lincoln Y., Guba, E. 1985. “Naturalistic inquiry”. Beverly Hills, CA: Sage. Maxwell, J. 1996. “Qualitative Research: an Interactive Approach”. Thousand Oaks, CA: Sage. Mingers J. 2001. “Combining Research Methods: Towards a Pluralistic Methodology”,

Information Systems Research, 12(3), pp. 240-259. Mingers J., Brocklesby J. 1997. “Multimethodology: Towards a Framework for mixing

Methodologies”, Omega, 25(5), pp. 489-509. Morse J. 1991. “Approaches to qualitative-quantitative methodological triangulation”, nursing

research, 40(1), pp. 120-123. Morse, J. (2003) “Principles of mixed methods and multimethod research design” in Tashakkori

and Teddlie (2003), pp. 189-208. Myers M. 1998. “Qualitative Research in Information Systems”, University of Auckland.

Available: http://www.auckland.ac.nz/msis/isworld/index.html. Orlikowski W., Baroudi 1991. “Studying Information Technology in Organizations: Research

Approaches and Assumptions”, Information Systems Research, 2(1), pp. 1-28.


Patton M. 1987. “How to Use Qualitative methods in evaluation”, SAGE publications, Newbury Park (CA).

Pfleeger S., Jeffery R., Curtis B., Kitchenham B. 1997. “Status Report on Software Measurement”, IEEE Software, March/April 1997, pp. 33-43.

Rockart J. 1979. “Chief Executives Define Their Own Information Needs”, Harvard Business Review, pp. 81-92.

Robey D. 1996. “Diversity in Information Systems Research: Threat, Promise and Responsibility”, Information Systems Research, 7(4), pp. 400-408.

Robey D., Ross J., Boudreau M. 2002. “Learning to Implement Enterprise Systems: An Exploratory Study of the Dialectics of Change,” Journal of Management Information Systems, 19(1), pp. 17-46.

Smit K., Bryant A. 2000. “Grounded Theory Method in IS Research: Glaser vs. Strauss”, research in progress papers, 7, http://www.lmu.ac.uk/ies/im/Research/2000-7.pdf

Stewart G., Gable G. 1999. “Applying the Case Study and Action Research Methods to Post-graduate Studies of Enterprise Processing System Implementations”, 3rd annual SAP ASIA Pacific forum.

Strauss, A and Corbin, J. 1990. “Basics of Qualitative Research: Grounded Theory Procedures and Techniques”, Sage Publications, Newbury Park, CA.

Strauss, A and Corbin, J. 1994. “Grounded Theory Methodology: An Overview”, in Handbook of Qualitative Research, N. Denzin and Lincoln (Ed.), Thousand Oaks: Sage Publications.

Tashakkori A., Teddlie C. 2003. “Handbook of Mixed Methods in social & behavioural research”, SAGE publications.

Van Maanen J. 1983. “Reclaiming Qualitative Methods for Organizational Research”, in Qualitative Methodology, Van Maanen (ed.), Sage Publications, Beverly Hills, CA, pp. 9-18.

Volkoff O. 1999. “Using the Structurational Model of Technology to Analyse an ERP implementation”, Americas Conference on Information Systems.

Walsham G. 1993. “Interpreting Information Systems in Organizations”, John Wiley & Sons, New York (USA).

Walsham G. 1995. “The Emergence of Interpretivism in IS Research”, Information Systems Research, 6(4), pp. 376-394.

Ward B. 1990. “Planning for Profit”, chapter 5, in “Managing Information Systems for Profit”, edited by T. J. Lincoln, John Wiles & Sons Ltd.

Yin R. 1994. “Case Study Research: Design and Methods”, 2nd edition, USA: SAGE publications.

Chapter 4 - Unified Model of Critical Success Factors 84

Chapter 4

Unified Model of Critical Success Factors

Chapter Summary: This chapter defines a unified CSF model for ERP implementations. This model was developed through the application of open coding procedure from grounded theory method andbased in a set of previous CSF lists. We also compare the CSF for ERP implementations with CSFfor other IS implementation projects. We present an analysis of ERP CSF as perceived risk factorsfor ERP implementations and we compare the CSF unified model with the list of risk factors for ERP implementations. This comparison shows that most of the CSF may be perceived as riskfactors. Finally, we present a study that we carried out to clarify project champion CSF sinceduring the literature review we found some misunderstandings regarding this figure. The findings show that the project champion is associated to the project sponsor role and that project sponsorand project manager are both identified as CSF for ERP implementation projects. Therefore, theCSF unified model was extended to incorporate these CSF.


Thesis Introduction


Research Design






CSFsIdentification


CSFsIdentification




ERP Context4


4.1 Background on CSF for ERP Implementations

We can evidence a lack of research studies in the area of ERP implementation success and failure (Esteves and Pastor 2001, Robey et al. 2002). According to Parr et al. (1999), “the systems are relatively new and a tradition of academic scrutiny and evaluation takes time to develop”. We tracked the academic and trade literature to find research in this field (see chapter 2 – Theoretical background and literature review). In the trade press there are some studies of this nature based on one or two ERP implementation case studies, such as Barranco (1998). Also, some consultants have developed CSF from their accumulated expertise (e.g. Deloitte Consulting 1998; Godwin 1998). Other studies are more a set of advises where some CSF are proposed rather than a CSF analysis done. Until 2000 some relevant papers in the academic press were published:

• Bancroft et al. (1998) provided nine CSF for ERP implementations based in interviews and researchers' experience on ERP implementations.

• Brown and Vessey (1999) defined the variables that appear to be critical to successful ERP implementations, based in a trade and academic literature review.

• Clemons (1998) defined three CSF based in a case study. • De Bruin (1997) analyzed a study of benchmarking partners where the consultancy firm

surveyed over 270 SAP implementations in the United States. • Dolmetsch et al. (1998) identified 5 CSF based on 4 case studies. • Gibson and Mann (1997) analyzed the implementation phase of nine companies and,

based in interviews, they created a list of 6 CSF. • Jarrar et al. (2000) conducted a literature review to understand CSF in successful ERP

implementations and they defined for main categories of CSF. • Kale (2000) presented 13 CSF based on his experience on ERP implementations. • Parr et al. (1999) identified ten CSF based in interviews with ten senior members of

multiple ERP implementation teams. • Stefanou (1999) identified three CSF by analyzing a large number of cases that were

published during the last few years in respected periodicals or reported by leading IT and management consulting firms.

• Sumner (1999a, 1999b) presented four lists of CSF, each one representing a specific case study and the related CSF found.

• The most extensive study whose subject is the definition of CSF in ERP implementations is the Holland and Light model (Holland and Light 1999; Holland et al. 1999). They conducted some case studies, across a range of industries, looking in particular at organizations implementing ERP software. Holland and Light proposed a CSF research framework based on a review of literature and the experiences of the organizations in their study. The model groups the CSF into strategic and tactical factors.

Table 8 summarizes the CSF studies we found during the literature review. We also present the

number of CSF each study identified and the research method used.


Table 8. CSF studies found in the literature review Author CSF Research method

Bancroft et al. (1998) 9 Experience Brown and Vessey (1999) 3 Literature review Clemons (1998) 3 Single case study De Bruin (1997); 11 Survey Dolmetsch et al. (1998) 5 Multi-case studies Holland et al. (1999) 12 Literature review, Multi-case studies Gibson and Mann (1997) 6 Multi-case studies Jarrar et al. 2000 4 Literature review Kale (2000) 13 Experience Parr et al. (1999) 10 Survey Stefanou (1999) 3 Literature review Sumner (1999a) 12 Multi-case studies According to Reimers (2003) the use of CSF in ERP implementations implies that managers

control these factors, i.e. they can change them at will, and that these factors are causally linked with a ‘successful’ project outcome (as stated by Rockart 1979).

4.1.1 Research Approach

The research process was composed of the following phases: • The first phase (research design phase) had two steps. The first step was the definition of

the research subject and scope. Through the analysis of articles related with ERP systems, we detected a shortage of knowledge about the implementation of ERP in organizations. Therefore, the goal of this study was to analyze (identify and define) the CSF of ERP implementations. The second step consisted in the collection and analysis of specialized literature.

• In phase two (data collection phase) we located 11 papers related with CSF models that became the primary research documents (see section 4.1 – Background on CSF for ERP implementations).

• Phase three (data analysis phase) represents the operations where data are divided, conceptualized, and organized in new ways. The research technique used was open coding process from Grounded Theory method, proposed by Glaser and Strauss (1967). “Coding represents the operations by which data are broken down, conceptualized, and put back together in new ways. It is the central process by which theories are built from data.” (Strauss and Corbin 1990, p.57). To increase validity and reliability of the resulting CSF unified model, the several sources of information where triangulated and inconsistencies where clarified with additional documentation (namely with documents published in the trade press).

• The last phase (comparison phase) was a comparative analysis of the resulting model with other studies related with the subject.


An example of the coding process is represented in table 9, in this case adequate training program. First, we collected all the CSF related with training and we grouped them in a category called ‘adequate training program’. Then, based in their definitions and names, we defined this category: “the training plan should take into consideration both technical staff and end-users, and its scope will depend on the type of implementation approach selected (see bellow). Some organizations use an in-house training approach while others prefer using training consultants”. For a detailed description of all the coding process for the rest of CSF please see Esteves and Pastor (2000). In the next section, we present the CSF unified and the definition of each CSF. Table 9. The coding table for adequate training program CSF.

Author Title Definition (and/or justification) Bancroft et al. (1998) Train everyone “A new system inevitably means new ways of operating. In

Battco, the requirements of the client/server SAP R/3 environment have initiated a project to reengineer the business process. Users must be informed as to the business needs for such change as well as 'which keys to press when.'“ (p. 138)

Brown and Vessey (1999) Clemons (1998) De Bruin (1997) Training “As with any system implementation, users need to receive

training in the use of R/3. Key to this is timing - some organizations embark upon training programs several months before R/3 goes live, by which time users have forgotten their training. The content of training also needs to be aimed at the specific users' needs (in particular they need to be taught how to perform particular business processes rather than training in how to use a particular R/3 module).” (p. 8)

Dolmetsch et al. (1998) Gibson and Mann (1997) User training No definition provided Holland and Light (1999) Kale (2000) Training of user

members, Training of SAP team members

“All training needs for all the members of the team should be identified and corporate training programs should be arranged, either on site or members should be nominated for external training programs.” (p. 110) “Training plans should not only have training programs, but should also budget refresher courses for all members.” (p. 111)

Parr et al. (1999) Stefanou (1999) Sumner (1999a) Training and re-

skilling Emphasize user-training

“Invest in training, re-skilling, and professional development of the IT workforce.”

4.1.2 CSF Unified Model Proposal

Table 10 represents the list of CSF and the respective citations. Given the cross-functional nature and large budget of a typical ERP implementation, the extent of sustained management support appears to be the most important factor.


Table 10. The list of CSF and the respective citations.

Sust

aine

d m

anag

emen

t sup

port

Effe

ctiv

e O

rgan

izat

iona

l cha

nge

man

agem

ent

Goo

d pr

ojec

t sco

pe m

anag

emen

t

Ade

quat

e pr

ojec

t tea

m c

ompo

sitio

n

Mea

ning

ful b

usin

ess p

roce

ss re

engi

neer

ing

Use

r inv

olve

men

t and

par

ticip

atio

n

Ade

quat

e pr

ojec

t cha

mpi

on ro

le

Trus

t bet

wee

n pa

rtner

s

Ded

icat

ed st

aff a

nd c

onsu

ltant

s

Stro

ng c

omm

unic

atio

n in

war

ds a

nd o

utw

ards

Form

aliz

ed p

roje

ct p

lan/

sche

dule

Ade

quat

e tra

inin

g pr

ogra

m

Prev

entiv

e tro

uble

shoo

ting

Usa

ge o

f app

ropr

iate

con

sulta

nts

Empo

wer

ed d

ecis

ion-

mak

ers

Ade

quat

e ER

P im

plem

enta

tion

stra

tegy

Avo

id E

RP

cust

omiz

atio

n

Ade

quat

e ER

P ve

rsio

n

Ade

quat

e in

fras

truct

ures

and

inte

rfac

es

Ade

quat

e le

gacy

syst

ems

know

ledg

e

Bancroft et al. 1998 Brown and Vessey 1999

Clemons 1998 De Bruin 1997 Dolmetsch et al. 1998 Gibson and Mann 1997 Holland and Light 1999

Kale 2000 Parr et al. 1999 Stefanou 1999 Sumner 1999 Total number citations: 10 7 6 5 4 3 3 3 6 7 6 5 4 3 3 4 5 1 1 1

The final step consisted in mapping the CSF (see table 11) in the CSF dimensions proposed in

the CSF identification framework of chapter 2 – Theoretical Background and Literature Review.


Table 11. The CSF categorization using the CSF framework.

Critical Success Factors

Stra

tegi

c

Tac

tical

Org

aniz

atio

nal

Tec

hnol

ogic

al

Ong

oing

Tem

pora

l

Bui

ldin

g

Mon

itori

ng

Inte

rnal

Ext

erna

l

Sustained management support Effective organizational change management Adequate project team composition Good project scope management Comprehensive business process reengineering Adequate project champion role Trust between partners User involvement and participation Dedicated staff and consultants Appropriate usage of consultants Empowered decision-makers Adequate training program Strong communication inwards and outwards Formalized project plan/schedule Preventive troubleshooting Avoid ERP customization Adequate ERP implementation strategy Adequate ERP version Adequate Infrastructure and interfaces Adequate legacy systems knowledge

Since the most used CSF dimensions in ERP research are strategic, tactical, organizational and

technological, we present the CSF unified model using these four main dimensions (see table 12). Table 12. Unified critical success factors model. Strategic Tactical

Org

aniz

atio

nal • Sustained management support

• Effective organizational change management • Good project scope management • Adequate project team composition • Comprehensive business process reengineering • Adequate project champion role • User involvement and participation • Trust between partners

• Dedicated staff and consultants • Strong communication inwards and outwards • Formalized project plan/schedule • Adequate training program • Preventive trouble shooting • Appropriate usage of consultants • Empowered decision-makers

Tec

hnol

ogic

al • Adequate ERP implementation strategy

• Avoid ERP customization • Adequate ERP version

• Adequate infrastructure and interfaces • Adequate legacy systems knowledge


In our view, the nature of the ERP implementation problems includes strategic, tactical, organizational and technological perspectives. Therefore, we propose that the CSF unified model should have these four perspectives. The organizational perspective is related with concerns like organizational structure and culture and, business processes. The technological perspective focuses on aspects related to the particular ERP product in consideration and on other related technical aspects, such as hardware and base software needs. The strategic perspective is related with core competencies accomplishing the organization's mission and long-term goals, while the tactical perspective affects the business activities with short-term objectives. The CSF were ordered according to the number of citations in the research studies and the related perspectives (see table 13). This figure shows that organizational aspects are considered to be more important than technological ones. Given the cross-functional nature and large budget of a typical ERP implementation, the extent of sustained management support appears to be the most important factor. Table 13. CSF literature relevance by perspective.

Perspectives Critical Success Factors Relevance Sustained management support 10 Effective organizational change management 7 Good project scope management 6 Adequate project team composition 5 Comprehensive business process reengineering 4 User involvement and participation 3 Adequate project champion role 3

Strategic

Trust between partners 3 Dedicated staff and consultants 6 Strong communication inwards and outwards 7 Formalized project plan/schedule 6 Adequate training program 5 Preventive trouble shooting 4 Appropriate usage of consultants 3

Org

aniz

atio

nal

Tactical

Empowered decision-makers 3 Adequate ERP implementation strategy 4 Avoid ERP customization 5

Strategic

Adequate ERP version 1 Adequate infrastructures and interfaces 1

Tech

nolo

gica

l

Tactical Adequate legacy systems knowledge 1

Wherever necessary, we have provided a common name for the same concept named

differently by the various authors. In the sequel, we provide a detailed description of the several CSF, classified according to their respective perspective.


4.1.3 Organizational Perspective

4.1.3.1 Strategic Factors

Sustained management support. Sustained management commitment, both at top and middle levels during the implementation, in terms of their own involvement and the willingness to allocate valuable organizational resources (Holland et al. 1999). Management support is important for accomplishing project goals and objectives and aligning these with strategic business goals (Sumner 1999a).

Effective organizational change management. Organizational change refers to the body of knowledge that is used to ensure that a complex change, like that associated with a new big information system, gets the right results, in the right timeframe, at the right costs. The change management approach will try to ensure the acceptance and readiness of the new system, allowing the organization to get the benefits of its use. A successful organizational change approach relies in a proper integration of people, process and technology.

Good project scope management. This factor is related with concerns of project goals clarification and their congruence with the organizational mission and strategic goals. This includes both scope definition and subsequent scope control. Some components of this factor are: scope of business processes and business units involved, ERP functionality implemented, technology to be replaced/upgraded/integrated, and exchange of data.

Adequate project team composition. A project team should incorporate all competences and skills that are expected to be necessary during the project. This might imply that the project team is composed by people with various education backgrounds, skills and professional experience. ERP projects typically require some combination of business, information technology, vendor, and consulting support. The structure of the project team has a strong impact in the implementation process. Two important factors are the integration of third-party consultants within the team and the retention within the organization of the relevant ERP knowledge.

Comprehensive business process reengineering. This is related with the alignment between business processes and the ERP business model and related best practices. This process will allow the improvement of the software functionality according to the current and future organization needs. Managers have to decide if they do business process reengineering before, during or after ERP implementation.

Adequate project champion role. The main reason why this person is considered to be central to successful implementations is that s/he has both the position and the skills that are critical for handle organizational change (Parr et al. 1999). The role of the project champion is very important for marketing the project throughout the organization (Sumner 1999a).

User involvement and participation. User participation refers to the behavior and activities that users perform in the system implementation process. User involvement refers to a psychological state of the individual, and is defined as the importance and personal relevance of a system to a user (Hartwick and Barki 1994). User involvement and participation will result in a better fit of user requirements achieving better system quality, use and acceptance.


Trust between partners. During the implementation phase there are different partners involved such as consultants and software and hardware vendors. An adequate partnership between them will ease the achievement of the defined goals.

4.1.3.2 Tactical Factors

Dedicated staff and consultants. Usually, an implementation project is carried out simultaneously with other activities. It is also important to ensure that the staff believes in the project success. Consultants should be involved in a way that helps the implementation process while also sharing their expertise with the internal staff involved. This is related with the recruitment and motivation of staff and consultants.

Strong communication inwards and outwards. Communication should be of two kinds: 'inwards' the project team and 'outwards' to the whole organization. This means not only sharing information between the project team but also communicating to the whole organization the results and the goals in each implementation stage. The communication effort should be done in a regular basis during the implementation phase.

Formalized project plan/schedule. This means to have a well-defined plan/schedule for all the activities involved in the ERP implementation, with an appropriate allocation of budget and resources for these activities. Evidence shows that the majority of projects fail to finish the activities on time and within budget. To ensure the project completion according with the plan/schedule, close monitoring and controlling of time and costs should be done, as well as implementation project scope and plan/schedule review, whenever justified.

Adequate training program. The training plan should take into consideration both technical staff and end-users, and its scope will depend on the type of implementation approach selected (see bellow). Some organizations use an in-house training approach while others prefer using training consultants.

Preventive trouble shooting. This factor is related with the “ability to handle unexpected crises and deviations from plan” (Pinto and Slevin 1 989, p. 67). A preventive trouble shooting strategy involves a risk management approach. Trouble-shooting mechanisms should be included in the implementation plan. Two important aspects are the adaptation and transfer of old data and the 'go live' moment. The time and effort involved in the transfer of data from previous systems should not be underestimated.

Appropriate usage of consultants. This factor is related to determine the number, how, and when to use external consultants appropriate to the ERP implementation needs. The usage of external consultants will depend on the internal know-how that the organization has at the moment.

Empowered decision-makers. Project team members must be empowered to make prompt decisions so project delays can be prevented (Parr et. al, 1999). Organizations should attempt to make decisions as rapidly as possible, as even small delays can have an impact on such a long-term project (De Bruin, 1997).


4.1.4 Technological Perspective

4.1.4.1 Strategic Factors

Adequate ERP implementation strategy. This includes management decisions concerning how the software package is to be implemented (Holland et al. 1999). There are different approaches to ERP implementation strategy ranging from 'skeleton' to 'big-bang' implementations (Gibson et al. 1997). While 'skeleton' implementations are phased and provide usable functionality incrementally, 'big-bang' ones offer full functionality all at once at implementation end. The advantages and disadvantages of these extreme approaches should be measured, especially at a functionality level.

Avoid ERP customization. Wherever and as far as possible, the ERP-hosting organization should try to adopt the processes and options built into the ERP, rather than seek to modify the ERP to fit the particular business practices (Parr et al. 1999). Thus, it is recommended that customization adheres to the standardized specifications that the software supports (Sumner 1999a). In this sense, a good business vision is helpful because it reduces the effort of capturing the functionality of the ERP business model and therefore minimizes the customization effort.

Adequate ERP version. An organization needs to determine which ERP version it will implement. Frequent upgrades can cause problems. This is particularly relevant when the organization has to wait for a future release that includes the functionality required (De Bruin 1997). There are both advantages and disadvantages of new versions for customers of ERP software. The advantages include accessibility of new features and the elimination of previous bugs. The disadvantages include potential conflicts between different versions of the software and the costs of upgrading (O'Leary 2000).

4.1.4.2 Tactical Factors

Adequate infrastructure and interfaces. Managers must ensure that “adequate infrastructure is planned for in a way that it becomes reliably available well in time (both for the pre-implementation and the post-implementation stages)” (Rao 2000, p. 83). Usually, ERP systems do not provide all the functional requirements of an organization. Therefore ERP vendors have a complete program of interfacing with third-party products to leverage organizations with special expertise and products (Kale 2000). There is the need to configure the interfaces according to the user's needs. Nowadays, there are some modeling tools that can help in all these tasks. Interfacing the different systems should be scheduled in such a way that the interfaces are operational when the ERP goes life. Before going life, validation tests should be applied.

Adequate legacy systems knowledge. Legacy systems are the business and IT systems prior to the ERP that encapsulate the existing business processes, organization structure, culture and information technology (Holland et al. 1999). They are a good source of information for ERP implementations and the possible problems that can be found during the implementation. When implementing an ERP it is necessary to decide which legacy systems will be replaced and the need to interface with those legacy systems for which the ERP does not provide an adequate replacement.


4.2 Comparison of ERP projects with other Projects

We also analyzed which of the CSF found for ERP implementation projects are unique to those projects compared with CSF for other IS implementation projects. We found two studies related with CSF that are usually referenced in the literature, Pinto and Slevin (1987) study and the report provided by Standish Group (1995). Table 14 shows the CSF identified by each study.

Pinto and Slevin (1987) developed a 10-CSF model for implementation projects in general which form the basis for Pinto and Slevin’s Project Implementation Profile (PIP) model. This instrument was developed in an attempt to create an empirical method of assessing the status of any project (Pinto and Slevin 1987). They found CSF for projects to be “inherently more ‘organizational and behavioral’ than technical” (Pinto and Slevin 1987, p. 22) and focused the project manager as the person charged with intuitively recognizing when a project is not going well either technically or organizationally.

While Pinto and Slevin did not intend to determine the strength with which the CSF affect project success, the Standish Group’s report, named ‘Chaos’ did just that (Standish Group 1995). Based in a survey to 365 IT professionals, the Standish Group identified and weight ten CSF. Like Pinto and Slevin (1987) findings, many of the CSF reported are not technical in nature. Table 14. Pinto and Slevin CSF model and Standish Group model. Pinto and Slevin CSF model Standish Group CSF model 1. Project mission 2. Top management support 3. Project schedule or plan 4. Client consultation 5. Personnel 6. Technical tasks 7. Client acceptance 8. Monitoring and feedback 9. Communications 10. Troubleshooting

1. User involvement 2. Executive management support 3. Clear statement of requirements 4. Proper planning 5. Realistic expectations 6. Smaller project milestones 7. Competent staff 8. Ownership 9. Clear vision and objectives 10. Hard-working, focused staff

As the comparison evidences, most of the CSF are not unique to ERP implementation projects.

However, and due to the specific characteristics of an ERP implementation project, they gain importance. According to Sumner (1999b, p. 303), “without question, the effective management of these huge projects is a new and unique challenge which requires the use of project management and control methods that have not been used extensively in the past. The sheer size of these projects requires centralized control, strict discipline, and extensive monitoring of project outcomes. Compared with traditional MIS projects, less emphasis is placed upon defining user requirements and organizing system processes to support these needs”.


4.3 CSF as Perceived ERP Risk Factors

Sumner (2000) studied the major risks associated with ERP projects. Based in some case studies, she developed a list of these risks (see table 15). The case studies were developed using structured interviews with the senior project managers responsible for planning and implementing ERP systems within their respective organizations. Table 15. Comparison between risk factors and CSF in ERP projects.

Risk Factors (Sumner 2000) CSF Failure to redesign business processes Comprehensive business process reengineering Lack of senior management support Sustained management support Insufficient training and reskilling Adequate training program Lack of ability to recruit and retain qualified ERP systems developers

Adequate team composition

Insufficient training of end-users Adequate training program Inability to obtain full-time commitment of ‘customers’ to project management and project activities

User involvement and participation

Lack of integration Lack of a proper management structure Adequate team composition Insufficient internal expertise Adequate team composition Lack of a champion Adequate project champion role Lack of ‘business’ analysts Appropriate usage of consultants Failure to mix internal and external personnel Adequate team composition Failure to emphasize reporting, including custom report development

Adequate training program

Insufficient discipline and standardization Avoid ERP customization Ineffective communications Strong communication inwards and outwards Avoid technological bottlenecks Adequate ERP strategy, preventive trouble shooting Attempting to build bridges to legacy applications Adequate infrastructures and interfaces

If we associated these risk factors with the CSF (see table 15), the findings suggest that most of

the CSF identified are in fact perceived as risk factors by ERP managers. Some of the risk factors identified by Sumner (2000) are related with more than one CSF such as ‘failure to redesign business processes’ which is related with ‘comprehensive business process redesign’ but also with ‘adequate organizational change management’.

We think that for future ERP implementation projects, the CSF unified model may be a good starting point to a risk factors analysis at the beginning of any ERP implementation project.


4.4 Clarifying Project Champion Role CSF

Several authors have acknowledged the importance of strong project leadership in the form of project champions, executive sponsors, project managers and steering committees (e.g., Beath 1991, Morris 1996). The terms of Chief Project Officer (CPO), project champion, project sponsor, project leader and project manager are commonly used in Enterprise Resource Planning (ERP) implementation projects and there is still confusion about their similarities and differences. Typically, ERP systems are software packages composed of several modules, such as human resources, sales, finance and production, providing cross-organization integration of transaction-based data throughout imbedded business processes. Researchers such as Sumner (1999b) and Parr et al. (1999) have identified the project champion role as a CSF in ERP implementations, while Bancroft et al (1998) defined as a CSF that the competence of the project manager. According to the CSF approach, the CSF identified must be accomplished in order to achieve success. Therefore, we think that in order to accomplish the CSF ‘adequate project champion role” it is important to define who is this person (or persons) and what is his/her role.

In an ERP implementation project, the figure of project champion does not usually exist officially. The term “champion” or “leader” is used most of the times interchangeably, and applied to the project sponsor or project manager figures, which are indeed the figures that are officially represented in a project structure. Brown and Vessey (1999) mentioned that project champion may or may not be a formal member of the project team, but can play a key role in change management efforts. They also referred that in some organizations, the sponsor also serves as the business champion for the project; in other situations, a champion emerges from among key business leaders. This section tries to clarify the concepts around ERP project championship and to analyze their criticality in an ERP implementation. We followed a qualitative research approach to address the arising research questions. Next, we present the results of the literature review that we made in order to clarify and analyze our research focus in relation to project champion, project sponsor and project manager roles.

4.4.1 Project Champions

Although the term “project champion” is widely used in research articles, it is often studied without a clear definition and rigorous identification process. Innovation literature relates champions with organizational change events (Beath 1991). According to Humphrey (1989), a champion agent is someone who maintains focus on the goal, strives to overcome obstacles, and refuses to give up when the going gets rough. Technology champions or leaders are often cited as CSF in the literature on innovation adoption. “The technology champion is a manager who lobbies for project acceptance and for access to resources needed for implementation. The activities of a successful technology champion reduce employee resistance tot he innovation and obtain access to resources”(Linton 2002). Roure (1999) made a literature review (see table 16) related with project champion definitions.


Table 16. Some champion definitions found in literature (source Roure 1999). Authors Definition Beath (1991, p. 355) “Information technology champions are managers who actively and

vigorously promote their personal vision for using information technology, pushing the project over or around approval and implementation hurdles.”

Chakrabarti and Hauschildt (1989, p. 166)

“The Champion (process promoter) acts as a linkage. He has the knowledge of the organization and knows who should be concerned with the innovation, thus connecting the sponsor with the expert. His strength is the ability to translate the technical language of the innovation into one which is commonly used in the organization. By becoming a salesman of the new idea, the champion is able to develop a plan of action. His diplomatic talents provide access to different people within the organization”.

Day (1994, p.149) “The agent who helps the venture navigates the socio-political environment inside the corporation”.

Ettlie et al. (1984, p.687) “A person advocating” for the project. Fischer et al. (1986, p. 13) “The key characteristic of the product champion is the tension between the

individual and what the organization wants”. Howell and Higgins (1990, p. 40)

Champions “make a decisive contribution to the innovation process by actively and enthusiastically promoting the innovation, building support, overcoming resistance and ensuring that the innovation is implemented”.

Rothwell et al. (1974, p. 291)

“Any individual who made a decisive contribution to the innovation by actively and enthusiastically promoting its progress through critical stages”.

Maidique (1980, p. 64) “A member of an organization who creates, defines or adopts an idea for a new technological innovation and who is willing to risk his or her position and prestige to make possible the innovation's successful implementation”.

Markham et al. (1991, p. 219) “A role where individuals are strong advocates for a project and generate positive behavioral support for an innovation during its development or work on behalf of the project in the face of organizational neutrality or opposition”.

Smith et al. (1984, p. 25) “Sells idea to obtain resources. The major salesman to management for accelerating progress toward commercialization”.

Shane (1994, p. 29) “An advocate whose goal is to promote the innovation”. Roberts and Fusfeld (1981, p. 186)

“Recognizing, proposing, pushing and demonstrating a new (his or her own or someone else's) technical idea, approach or procedure for formal management approval”.

Schon (1963, p. 84)

“Essentially the champion must be a man willing to put himself on the line for an idea of doubtful success. He is willing to fail. But he is capable of using any and every means of informal sales and pressure in order to succeed”.

Roure (1999) discovered that definitions of a project champion found in the literature reveal

wide variations among researchers. Based on the literature review, Roure (1999, p. 4) defined a project champion as “any individual who made a decisive contribution to the innovation by actively and enthusiastically promoting its progress through critical stages in order to obtain resources and/or active support from top management”. None of these researchers mention clearly who represents the figure of the project champion: the project sponsor or the project manager. On the organization literature, champions are distinguished from sponsors. Sponsors have the funds and authority to accomplish their goals (e.g. Vitale and Ives 1988), but champions, in spite of having less than the requisite authority or resources, bring about change in their organizations by using a variety of other influence processes (see Beath 1991).


4.4.1.1 Project Champion Definition Content Analysis

Based in all the definitions we collected for project champion role, we performed a content analysis on all the definitions. Table 17 shows the word frequency. Table 17. Words count for project champion definitions. Frequency Words 11 Innovation 5 Idea, organization 4 Actively, individual, management, resources, technology 3 Access, contribution, decisive, enthusiastically, implementation, new, obtain, process, product,

progress, promoting, support, willing This enables the following definition to be constructed: “Any individual adopts an idea for a new (technological) innovation and who makes a decisive

contribution to the innovation by actively and enthusiastically promoting its implementation and progress through critical stages in order to obtain resources and/or active support from top management”.

4.4.2 Project Sponsors

A project sponsor could also be a called product sponsor, product manager, product director, account manager or business unit manager (Whitten 1999, p. 12). According to Kale (2000, p. 230), “the sponsor point is a senior executive champion of change who by his or her actions and communications helps in maintaining project credibility, momentum, and committed support throughout the company”. The author defines the figure of chief project officer as “a member of the project's steering committee that has enough responsibility and authority to manage day-to-day operational project-related issues and meet all project-related resource requirements”. This figure is the project sponsor. Parr et al. (1999) evidence the confusion between project sponsor and project manager, when they write that “although they did not distinguish champions from sponsors, interviewees agreed that the presence of a champion had facilitated many successful projects. This person was the one who was unswerving in promoting the benefits of the new system, even when users lauded (as they frequently did) the advantages of the old system”.

Instead of referring to the project sponsor figure, Welti (1999) explains the role of the steering committee chairman. The characteristics of this chairman are: ownership and leadership of the steering committee respected and accepted authority, identification with the project and full support demonstration and close cooperation with the project manager. Rosario (2000) mentions that project sponsor commitment is critical to drive consensus and to oversee the entire lifecycle of implementation. Whitten (1999, p. 12) refers that “it is important for every project or product to have a sponsor who will champion its cause from a business perspective, and help remove obstacles that might harm its overall success”.


4.4.3 Project Managers

Bancroft et al. (1998, p. 137) mention that “the successful project manager integrates concerns that would otherwise fall between the cracks, and communicates with all those involved. These apolitical issues require sensitivity to the three perspectives - technical, business, and change management. Unless the project leader is sensitive to the impact of each of these elements on the project as a whole, he or she is likely to get caught by the sometimes conflicting requirements”. In their work these authors relate project manager with the project leader figure. Jurison (1999, p. 22) quotes that project manager’s “responsibility is to direct and coordinate all activities to meet the objectives of the project within budget and schedule”. Some authors (Thamhain 1991, Pettersen 1991, Einsiedel 1987) show that, apart from generic project management skills and knowledge, project managers, to be effective, need knowledge and understanding of: the technology of the project, the project application area, the organization or organizations in which the project is located and the market in which the organization or organizations are operating. Welti (1999) mentions that the project manager is the overall leader of the project: “their main task is managing, leading and coaching. They have to make the implementation as easy as possible, and create a pleasant atmosphere and environment for the project members to work in”. According to Welti (1999) the skills of a good project manager are: leadership, business management know-how, coaching, flexibility, acceptance, analytical abilities and stress resistance. The project manager reports directly to the steering committee the project status and seeks advice from the committee on a variety of project issues including direction, scope and funding (Purba et al. 1995).

4.4.4 Hypothesis Development

The literature suggests that almost all internal innovation processes have at least one champion, and most have two or more (e.g. Rothwell et al. 1974). However, even when there are multiple champions, one champion typically stands out as the principal champion (Day 1994). Our research focuses on the identification of this [principal] champion on ERP implementation projects.

Different championing functions require different power bases. Day (1974, p. 150) defines three types of championing:

• The bottom-up championing - It related with ventures that require a principal champion who has the appropriate knowledge and expertise and is close enough to the necessary sources of information to help the venture achieve innovative results: a champion from lower levels of the firm.

• The top-down championing – It is associated to the ventures that cannot remain invisible and require a corporate top manager as their principal champion to give them the resources and legitimacy they need to face the challenges they will encounter.

• The dual-role champion - Someone who possesses both the relevant expertise and information and the appropriate hierarchical power and control over resources so that he or she can make and implement better decisions in the face of significant uncertainties.

Within the organization theory literature, champions are distinguished from sponsors. Sponsors

have the funds and authority to accomplish their goals (e.g. Vitale and Ives 1988), but champions, in spite of having less than the required authority or resources, bring about change in their


organizations by using a variety of other influence processes (see Beath 1991). Other studies show that champions affect three areas: level of investment, budgets, and project termination decisions; levels of support (Markham et al. 1991); and levels of new product development process integration and strategy innovativeness (Markham and Griffin 1998). Beath (1991) mentions that project champions operate using three types of resources: information to evaluate, choose and sell an innovation; material resources to obtain the necessary information and to test and make transitions; and political support to guarantee both the availability of the material resources and, eventually the rewards for successful innovations. Day (1994, p. 154) says that “if the principal champion performs functions of both the organizational sponsor and the product champion, then he or she should have better insight and understanding when making decisions, as well as sufficient hierarchical power to grant legitimacy and provide the appropriate funding to readily implement those decisions”. Furthermore, Day (1994, p. 163) points out that for one champion to have both roles, “it is best when decisions are highly uncertain and speed is important, as with some radical innovations”.

The ERP literature evidences that the project champion corresponds to this dual-role champion. For instance Whitten (1999, p. 12) says that “it is important for every project or product to have a sponsor who will champion its cause from a business perspective, and help remove obstacles that might harm its overall success”. Due to the investment and the organizational issues associated, the ERP adoption decision is usually made not based in one person but at top management level. Therefore, the project champion must have the adequate organizational power to influence top management to adopt the ERP system. Falkowski et al. (1998) indicated that the project champion should be a high-level executive sponsor who has the power to set goals and legitimize change. Furthermore, Charkrabarti and Hauschildt (1989) reinforced the need of project champion knowledge of the organization and the people related with the innovation project. These arguments lead to the following research hypothesis:

Hypothesis 1: due to his or her influence, the ERP project sponsor should also act as the ERP project champion, thus as a dual-role ERP champion.

Second, people play different roles in an ERP implementation projects such as: project sponsor,

project manager, team members, consultants, key-users, and end-users. Thus, we state that: Hypothesis 2: There is a relationship between the person role and the project champion figure

identification with team members associated it the project manager figure and the rest of ERP roles to the project sponsor figure.

In an ERP implementation project, the figure of project champion does not usually exist

officially. The term “champion” or “leader” is used most of the times interchangeably, and applied to the project sponsor or project manager figures, which are indeed the figures that are officially represented in a project structure. Some researchers like Parr et al. (1999) noted that sometimes the identification of ERP project champion as a CSF involved some misunderstandings related with project sponsor and project manager figure. Thus, instead of defining ERP project champion as a CSF, we state:

Hypothesis 3: Both, the project sponsor and project manager roles are critical for ERP implementation projects.


4.4.5 Research Methodology

This study attempts to answer the following research questions: a) Who is the project champion in an ERP implementation, the project sponsor or the

project manager? b) Who is more critical in an ERP implementation project, the project sponsor, the project

manager or both? Thus, we also attempt to clarify the above functions and roles in an ERP implementation

project. We followed a qualitative research approach to answer these questions. This kind of research provides the understanding of a problem through research instruments that are oriented towards searching/determining/finding/analyzing the facts in a temporal and geographic mark, giving significance to the context and usage. The reason to choose qualitative research is due to the fact that the main concerns of this research are organizational rather than technological. We started the research by reviewing the related literature and then we created a Web Survey (WS) based in the research questions and our preliminary analysis. We used the technique of identifying champions through peer nomination, which has been shown to be a highly reliable, valid technique and predictive ability (Kane and Lawler 1978, McEvoy et al. 1988, Higgins 1990, Cho and Schunn 2003). In the organizational context, research on appraisal sources has emphasized the peer perspective (Latham et al. 1973). Peer ratings are especially useful for purposes of feedback on leaders and managers in organizations (DeNisi and Mitchell 1978, Kane and Lawler 1978).

4.4.5.1 Web Survey Technique

We started the research by reviewing the related literature and then we created a WS based in the research questions and literature review on the topic. The reasons for using a WS were the fact that it was the easiest way for us to access experts in the field and gather responses fast and the low cost of this technique. Regarding the sample selection method, we opted by a convenience sample and a closed web page survey. The idea was to target Internet users related with ERP implementations. A number of Internet links for ERP mailing lists, groups and forums were collected and evaluated. This evaluation focused on the relevance of these links to the research topic, and the level of apparent activity of the mailing lists, groups and forums.

4.4.5.2 Web Survey Design and Advertisement

The WS was designed using the Microsoft FrontPage tool. First we explained the WS objectives. Then, five questions were presented:

1. Who do you think is the ERP project champion: the project sponsor or the project manager, both or other figure? And why? This was an open-ended question.

2. Who do you think is more critical: project sponsor, project manager, both, don't know? This question was an option selection question.

3. Please, can you justify your option? This was an open-ended question in order to justify the above selection.


4. What is your function: project sponsor, project manager, team member, consultant, other? This was an option selection question.

5. Your ERP professional experience? This was an open-ended question. We also presented a box for comments and information about the author in case he would like

to receive a copy of the WS findings. Following Dillman and Bowker’s (2001) recommendations, we designed the WS as simple as possible. The WS was answered on-line, and the responses were sent to our e-mail address. The WS was spread in all the main forums and mailing lists related with ERP systems that we considered relevant. The types of respondents (see figure 1) were: project sponsors, project managers, team members, implementation consultants and others.

4.4.5.3 Web Survey Publicizing

A number of Internet links for ERP mailing lists, groups and forums were collected and evaluated. Then, the WS was spread in all the main forums and mailing lists related with ERP systems that we considered relevant. The WS was answered on-line, and the responses were sent to our email.

4.4.5.4 Web Survey Sampling

In terms of sampling, we opted by a convenience sample in terms of subject and we tried to obtain a maximum-variation sampling in relation to the role of respondents. The types of respondents are shown in figure 13. The number of respondents was 164, with implementation consultants as the most significant. We think the main reason for this relies in the fact that implementation consultants use more forums and mailing lists to share information.

9

32

5846

19

0

15

30

45

60

75

Project sponsor Project manager Implementationconsultant

Team member Other

Figure 13. Types of respondents in our web survey.


4.4.6 Web Survey Analysis

In this section we analyze the two WS questions in detail. Note that we did not provide any definition of project sponsor or project manager before the questions, to avoid conditioning the opinions of respondents. Next, we describe the findings for each research hypothesis.

4.4.6.1 Project Champion Role

P1 - Who do you think is the ERP project champion, the project sponsor or the project manager, both or other figure? And why?

Most of the respondents answered that the project sponsor is the champion (see figure 14). The main reasons for that choice were:

• Because usually s/he has authority to bring the required resources to the project. Most of the respondents focused on financial resources.

• To control costs and time of the project rather than to manage them. • To convey the right message to the organization and choose the right people to run the

system after the implementers have left. • Because s/he is in a position to influence the people and business processes.

83

58

22

10

15

304560

7590

Projectsponsor

Projectmanager

Both Neither

Figure 14. Identification of project champion figure.

Regarding this question, we opted by code the answers using ‘open coding’. Four categories of

reasons emerged: Economical – related with obtain the resources and funds necessary for the ERP project. Managerial – related with the typical management activities of a project. Strategic – related with the ERP project vision, its definition and control. Organizational – related with the organizational factors of an organization and the

underlying issues of structure, culture, power and influence within an organization.


In the same answer respondents gave more than one reason in most of the cases, within different categories (see table 18). Table 18. Categories of answers (%) for project champion role choice.

Category Project Sponsor Project Manager Both Neither Economical 22.2 - 25 - Managerial - 71.4 50 - Strategic 44.4 14.3 50 50 Organizational 44.4 42.9 - 50

Table 18 shows that strategic and organizational categories are the most expressed by

respondents to argue project sponsor choice while managerial category is the most expresses to argue project manager choice. Regarding both choices, the most used categories are strategic and managerial concerns. We analyzed the answers by respondent type (see table 19) and all types confirmed that the project champion is the project sponsor, except for project team members that opted by the project manager figure. In our opinion, this is because the operational leader of the project team is in fact the project manager, the figure that is in permanent contact with team members and helps and controls their work. One of the consultants answered that neither project sponsor nor manager are the figure of project champion. His comments were: “the project champion is an operational manager, responsible for ´championing´ the project at senior management level”. Table 19. Identification of project champion by respondent type.

Project champion figure Respondent type Project

sponsor Project manager Both Neither Total

Project sponsor 9 - - - 9 Project manager 19 7 6 - 32 Consultant 29 12 16 1 58 Team member 15 31 - - 46 Other 11 8 - - 19 Total 83 58 22 - 164

Most of respondents that answered both roles as the project champion, related project

champion role and the project timeline. Thus, they mentioned that project sponsor acts as the project champion in the initial phases of the ERP project and at the end, while the project manager is the champion on the middle phases. They share the championing in the last phase of the ERP project, the go live phase.

Pearson’s chi-square (X2) tests were performed to assess the second research hypothesis. We performed X2 to the contingency table presented in table 4. However, in the case of project champion figure variable we only defined two options: project sponsor and project manager. The X2 (X2=28.079, df=4, p=0.05) reveals that as hypothesized, the different types of respondents tended to identify different project champions figures. More of the project sponsors, project managers and consultants identified the project sponsor as the project champion figure while more team members opted for the project manager as the project champion figure.


4.4.6.2 Critical Success Factors

P2- Who do you think is more critical, project sponsor, project manager, or both? To this question, 90 respondents mentioned that both functions are critical to the ERP

implementation project success (see figure 15).

34 37

90

0153045607590

105

Project sponsor Project manager Both

Figure 15. Identification of the most critical figure in an ERP implementation.

The second most mentioned was the project manager figure. The argumentation for project sponsor choice was that:

• The project sponsor is the critical link in the whole process. The seriousness of the management or the business is required at all times and s/he must make sure all are involved.

• The project sponsor always has more authority and power. Typically s/he is the CEO. • The project sponsor is the one that has the financial responsibility and the project

ownership. The reasons for project manager choice were:

• The project manager has the responsibility to perform the commission of the sponsor and to report to the sponsor those key factors, which keep the project alive. It is not the responsibility of the project manager to make decisions on whether or not a project is completed but to report concerns of the project and cost performances that are necessary for the fiscal intermediary (sponsor) to base their decisions on.

• Operational management of the project is critical to its success; a project cannot succeed with a poor manager, while it can succeed with a poor sponsor.

• The project manager must have a complete understanding of the entire ERP package and the business processes within the company. S/he must look at the entire organization in order to make sure that all business processes can be accounted for. The project sponsor only needs to be able to discuss the advantages of the ERP project on an extremely high level.


• Project manager conducts effective planning along the ERP project lifecycle. The reasons for the choice of both roles as equally critical were:

• A good project manager brings all the pieces of the implementation together in a timely, effective manner, which builds and keeps team company morale high on the new system. A good project sponsor keeps the company and its managers focused on the new system, keep distractions out of the way, and lead the company into the new system. Both complement and may help each other. Both are key to a successful system. Each person separately can be successful but will not deliver a fully useful system. During the implementation you definitely need project sponsor support. The sponsor has the authority to allocate resources to the project. The project manager assigns tasks to those resources based on the project plan.

• The project manager is critical because of his/her responsibilities mentioned above. The sponsor has the resources or can provide the resources, like people or money and something very important which is the motivation for everyone else.

The X2 (X2=28.211, df=8, p=0.05) test reveals that as hypothesized both project sponsor and

project manager are critical success factors. The X2 test supports the relationship between respondent type and the identification of project sponsor and project manager as CSF. The analysis of answers by respondent type (see table 20) shows that not all types agreed who is more critical in an ERP implementation project. Most of the project sponsors mentioned their role as the most critical. We think there is some bias in this result due to the importance that each individual gives to his role. Most of project managers defined that both roles as critical and in second (and expected) their role. Consultants, which we think, represent the most neutral type in this answer, opted for both roles. Finally, project team members are divided between project managers and both roles. As we mentioned before, project team members have direct contact with the project managers. Therefore, it seems obvious that project managers are more critical. Another aspect that we think can explain their option is the type of typology of the ERP project (see project structure typology section below). In some ERP projects the figure of project sponsor is not present, at least officially and in some cases it is represented by the president of the company. Table 20. Identification of the most critical figure in an ERP implementation by respondent type.

Most critical figure Respondent type Project sponsor Project manager Both Total Project sponsor 6 1 2 9 Project manager 5 11 16 32 Consultant 11 6 41 58 Team member 6 16 24 46 Other 6 4 9 19 Total 34 37 90 164


4.4.7 Proposed Definitions

Based in the literature review and the WS answers, we propose a definition for both the project sponsor and the project manager figure:

• The ERP project sponsor is the person devoted to promote the ERP project, who has the ownership and responsibility of obtain the project resources. He must actively encourage the ERP project by promoting the new ERP system, overcoming resistance and involve everyone in the innovative business and organizational changes. He must control and monitor the project, helping remove obstacles in order to facilitate the success of the ERP project. Usually this figure is a senior executive of the company.

• The ERP project manager is the person devoted to plan, lead and control the project on the run in its several tasks. He is also responsible for ensuring the scope is properly and realistically defined, and communicating it to the whole company. One of his/her most important tasks is to promote good working relationships across the project. He is the person that puts in practice the strategic vision of top management for the new ERP project. Therefore, he acts as the intermediary between top management and the project team members and consultants.

4.4.8 ERP Project Structure Typologies

Based on the comments of respondents and the literature review, we identified different types of project structure typologies. These typologies are only related with the project sponsor and project manager roles. An important aspect of the typologies is if the ERP project is single or multi site. We categorized the types of typologies using this distinction. Thus single site typologies are:

One project sponsor and one project manager. One project manager and top management usually represented by the president or

organization owner. One project sponsor and two project managers: functional and technical project managers. One project sponsor and a project manager for each functional area.

Regards multi-site ERP projects we found that in terms of project sponsor role there are two

ERP project structure typologies: a global project sponsor, or the more common typology is a global project sponsor an a local project sponsor for each site. In terms of project managers, we found all the possible combinations but all have at least one project manager for each site.

Although we did not ask for the type of ERP project structure typology, we do not have statistics related with the relationship between this dimension and definition of project champion. However, we analyzed qualitatively the answers of some respondents that mentioned the ERP projects structure typology. We evidenced that when there is a figure of a project role in the typology (especially on multi-site typologies), people see him as the project champion. Regards which is more critical, if project sponsor and project managers or both, they answers were for both.


4.4.9 Discussion

The results suggest that project champions are associated with project sponsor figure. The results of testing hypothesis 1 provided the first evidence that project champions in ERP implementation projects should act as dual-role champions, both project sponsor and project champion. The dual-role champion is not unusual as the findings may suggest. Some studies (e.g. Day 1994) have shown that they make up for more than 36% of champions.

We think that these findings help to clarify the concepts of project champion, project sponsor and project manager roles in an ERP project. Until now, in many cases this distinction is not clear and allows to some misunderstandings in terms of findings. Researchers must be aware of the differences when they describe and use these roles in their research studies. We agree with Day (1994, p. 168) when she mentions that “given that dual-role champions have been largely ignored in previous research yet they make up 36% of the champions in this and other studies, more research needs to be done on these champions”.

One of the limitations of this study is that we do not categorize the respondents by the type of ERP project, if single or multi site, and the type of organization, big, medium or small organization. We think that this distinction can give new insights in terms of the comprehension of project champion and most critical role selection in an ERP project. We only analyzed the typology in terms of number of ERP project sites. In the future we attempt to analyze these typologies and the type of organizations. The evidence shows that in the case of small and medium enterprises, usually there is no steering committee, and the figure of project sponsor is in most cases the organization president or owner. Research is needed in order to understand the relationship between project sponsor and project manager, and to analyze how this relationship affects the ERP project success. Some respondents focused the issue of collaboration versus competition. Conflicts between both roles are mainly expressed in terms of lack of commitment, experience and contention for resources, and personal reasons in terms of career promotion and rewards.


4.5 Comparison with Further ERP CSF Models

After the publication of our unified model (Esteves and Pastor 2000), some lists of CSF have been published. Two studies deserve special attention for their rigor and contribution to this topic, the study published by Nah et al. (2001) and the study published by Somers and Nelson (2001). Table 21 shows a comparison between our CSF model and the other CSF models.

Based on a review of the ERP literature, Nah et al. (2001) identified 11 CSF. The authors did not use our unified model in their literature review. The list of CSF presented by Nah et al. (2001) is quite similar to our unified model. Their number of CSF is smaller due to the difference in the literature sample, and also because Nah et al. (2001) included more than one CSF in the same statement like business process reengineering and minimum customization, or project management which aggregates different CSF. The main difference resides in project management CSF. The definition of Nah et al. (2001) for project management focuses on project manager role but mainly on project scope definition and management and a formalized project plan and schedule. Overall, we evidence that our model encompasses the 11 CSF suggested by Nah et al. (2001). Table 21. Comparison with further CSF models.

Critical Success Factors Nah et al. (2001 Somers and Nelson (2001)

Sustained management support Effective organizational change management Good project scope management Adequate project team composition Comprehensive business process reengineering User involvement and participation Adequate project champion role Trust between partners Dedicated staff and consultants Strong communication inwards and outwards Formalized project Plan/schedule Adequate training program Preventive trouble shooting Appropriate usage of consultants Empowered decision-makers Adequate ERP implementation strategy Avoid ERP customization Adequate ERP version Adequate infrastructures and interfaces Adequate legacy systems knowledge

We evidenced the main discrepancies in the Somers and Nelson (2001) list of CSF. Their

model of CSF covers the whole ERP lifecycle while our model focuses only on ERP implementation phase. Thus, we do not consider as CSF: management of expectations, data analysis and conversion, and the selection of the appropriate package. Some of their CSF have different names or are integrated in some of our CSF. For instance, according to the definitions they provide, their steering committee CSF is part of our sustained management support CSF, interdepartmental cooperation CSF is part of trust between partners, communication outwards and user involvement and participation CSF. They define project management CSF which is a mix of


some of our CSF like project scope and project plan management. Project management also is associated with project manager role which is not defined as a CSF. Later we will discuss this topic in depth. Somers and Nelson (2001) refined some CSF such as trust between partners where they focus more on partnership with the ERP vendor and vendor support.

Three of our CSF, namely: user involvement and participation, empowered decision-makers, and adequate ERP version were not explicitly defined neither by Somers and Nelson (2001) or Nah et al. (2001). There are two CSF that our model did not identify, testing (Nah et al. 2001) and data analysis and conversion (Somers and Nelson 2001). However, we should point out that both topics are important issues that we discussed concerning reducing troubleshooting and adequate infrastructures and interfaces. Due to the recommendations by these two studies, we think it is necessary to extend our model to include these CSF. Therefore, we propose two new CSF:

• Formalized testing plan – “The test plan prescribes the scope, approach, resources, and schedule of the testing activities. It identifies the items to be tested, the features to be tested, the testing tasks to be performed, the personnel responsible for each task, and the risks associated with the plan” (IEEE 1998). The testing plan should cover functional and technical testing, data flow between the ERP system and other applications and user testing. Testing requires support by all those involved in the implementation process. Furthermore, having adequate testing capabilities is a critical tool for ensuring that the ERP system accomplishes the business requirements defined at the beginning of the project.

• Adequate data migration process – Accurate data must be available and on time before the system going life (Somers and Nelson 2001). Data Migration would involve moving the existing data, performing an integrity check and then transporting it to the ERP system that has been implemented. First, there is the need to find the proper data to load into the system and migrate it to the ERP system. Sometimes data arises from different sources. Therefore there is the need to convert the data into a unique format. There are diverse tools available to reduce the effort on migration process. In some occasions, there is the need to introduce manually the data into the system. Due to this effort, the migration process must be planned at the beginning of the ERP project in order to avoid delays.


4.6 Our Extended CSF Unified Model

Based on the study we carried out on project manager, project sponsor and project champion, we suggest the inclusion of adequate project manager role and adequate project sponsor role as two new CSF for ERP implementation projects. Finally, the studies carried out by Nah et al. (2001) and Somers and Nelson (2001) suggest two new CSF not identified in our previous analysis: formalized testing plan, and adequate data migration process. Therefore, we included these two new CSF in our unified model. The extended unified CSF model is shown in table 22. In the next chapter we will use this model as the reference CSF model. Table 22. The extended unified critical success factors ERP model. Strategic Tactical

Org

aniz

atio

nal

• Sustained management support • Effective organizational change management • Good project scope management • Adequate project team composition • Comprehensive business process reengineering • Adequate project sponsor role • Adequate project manager role • User involvement and participation • Trust between partners

• Dedicated staff and consultants • Strong communication inwards and outwards • Formalized project plan/schedule • Adequate training program • Preventive trouble shooting • Appropriate usage of consultants • Empowered decision-makers

Tec

hnol

ogic

al • Adequate ERP implementation strategy

• Avoid ERP customization • Adequate ERP version

• Adequate infrastructure and interfaces • Adequate legacy systems knowledge • Formalized testing plan • Adequate data migration process

4.7 Conclusions

This chapter defines a unified CSF model for ERP implementations. This model was developed through the application of open coding procedure from grounded theory method and based in a set of previous CSF lists. The number of CSF is large but they are divided in four perspectives: strategic and tactical perspectives, and organizational and technological perspectives. An important aspect is that most of the factors found can be considered “classics” since they are not specific to ERP implementations. Nonetheless, given the complexity of these projects, each factor “takes on greater significance” (Bancroft et al 1998, p. 67). The analysis of the CSF literature shows that management support is the most important factor in an ERP implementation followed by organizational change management. These CSF have almost nothing to do with technology and almost everything to do with people and process, due to the effort that has to be undertaken by the whole organization in a project of this nature. We also compare the CSF for ERP implementations with CSF for other implementation projects published by Slevin and Pinto (1987) and the list of CSF provided by Standish Group (1995). We present an analysis of ERP CSF as perceived risk factors for ERP implementations and we compare the CSF unified model with the list of risk factors for ERP implementations published by Sumner (2000). This comparison shows that most


of the CSF may be perceived as risk factors. Next, we present a study we carried out to clarify project champion CSF since during the literature review we found some misunderstandings regarding this figure. The findings show that the project champion is associated to the project sponsor role and that project sponsor and project manager are both identified as CSF for ERP implementation projects. Therefore, the CSF unified model must be extended to incorporate these CSF. Finally, we compare our CSF unified model with two relevant studies published on 2001. The comparison revealed the need to extend our model with two new CSF: formalized testing plan and, adequate data migration process.

4.8 References

Bancroft N., Seip H., Sprengel A. 1998. “Implementing SAP R/3”, 2nd ed., Manning Publications. Beath C. 1991. “Supporting the Information Technology Champion”. MIS Quarterly, 15(3), pp.

355-371. Brown C., Vessey I. 1999. “ERP Implementation Approaches: Toward a Contingency

Framework”, International Conference on Information Systems, Charlotte, North Carolina (USA).

Chakrabarti A., Hauschildt J. 1989. “The Division of Labour in Innovation Management”. R&D Management, 19(2), pp. 161-171.

Cho K., Schunn C. 2003. “Validity and Reliability of Peer Assessments with a Missing Data Estimation Technique”, ED-Media 2003 conference, Hawaii, USA.

Clemons C. 1998. “Successful Implementation of an Enterprise System: A Case Study”, Americas Conference on Information Systems (AMCIS), Baltimore (USA).

Day D. 1994. “Raising Radicals: Different Processes for Championing Innovative Corporate Ventures”, Organization Science, 5(2), pp. 148-172.

De Bruin P. 1997. “Unpublished 1997 Sapphire Conference Notes” in Gibson and Mann 1997. DeNisi A., Mitchell J. 1978. “An analysis of peer rating as predictors and criterion measures and

proposed new application”, Academy of management review, 3, pp. 369-374. Dillman D., Bowker D. 2001. “The Web questionnaire challenge to survey methodologists”, in U.

Reips and M. Bosnjak (Eds.), Dimensions of Internet Science, Lengerich (Germany): Pabst Science Publishers, 159-178.

Dolmetsch R., Huber T., Fleisch E. Österle H. 1998. “Accelerated SAP - 4 Case Studies”, University of St. Gallen, ISBN 3-906559-02-5.

Einsiedel A. 1987. “Profile of Effective Project Managers”. Project Management Journal, 24(5), pp. 51-56.

Esteves J., Pastor J. 2000. “Applying Grounded Theory to Create a Unified Critical Success Factors Model for ERP Implementations”, technical research report, LSI-00-58-R, Universidad Politécnica de Catalunya, October 2000

Esteves J., Pastor J. 2001. “Enterprise Resource Planning Systems Research: An Annotated Bibliography”, Communications of the Association for Information Systems (CAIS), vol. 7, article 8, August 2001.

Ettlie J., Bridges W., O'Keefe R. 1984. “Organization strategy and structural differences for radical versus incremental innovation”, Management Science, 1984, 30(6), pp. 682-695.


Falkowski G., Pedigo P., Smith B., Swanson D. 1998. “A recipe for ERP success”, Beyond Computing, pp. 44–45.

Fischer W., Hamilton W, Mc Laughin C., Zmud R. 1986. “The Elusive Product Champion”. Research Management, 29(3), pp. 13-16.

Gibson J., Mann S. 1997. “A Qualitative Examination of SAP R/3 Implementations in the Western Cape”, research report, department of information systems, University of Cape Town.

Glaser B., Strauss A. 1967. “The Discovery of Grounded Theory”. Chicago: Aldine. Hartwick J., Barki 1994. “Explaining the Role of User Participation in Information System Use,”

Management Science, 40(4), pp. 440-465 Harwood S. 2003. “ERP: The Implementation Cycle”, Butterwoth-Heinemann publishing,

Burlington (MA). Holland C., Light B. 1999. “Critical Success Factors Model for ERP Implementation”. IEEE

Software, May/June, pp. 1630-1636. Holland C., Light B., Gibson N. 1999. “A Critical Success Factors Model for Enterprise Resource

Planning Implementation”, European Conference on Information Systems. Howell J., Higgins C. 1990. “Champions of Technological Innovations”. Administrative Science

Quarterly, 35(2), pp. 317-341 Humphrey W. 1989. “Managing the Software Process”, Addison-Wesley, Reading MA, 1989. IEEE 1998. “IEEE Standard for Software Test Documentation”, IEEE Std 829-1998, IEEE

Computer Society. Jarrar Y., Al-Mudimigh Z. 2000. “ERP Implementation Critical Success Factors – The Role and

Impact of Business Process Management”, ICMIT , pp. 122-127. Jurison J. 1999. “Software Project Management: The Manager's View”, Communications of the

Association for Information Systems, 2(17). Kale V. 2000. “Implementing SAP R/3: The Guide for Business and Technology Managers”,

SAMS, Indiana (USA). Latham G., Skarlicki D., Irvine D and Siegel J. 1993. “The increasing importance of performance

appraisals to employee effectiveness in organizational settings in North America”, International review of industrial and organizational psychology, 8, pp. 87-132.

Lawley M., Summers J., Koronios A., Gardiner M. 2001. “Critical Success Factors for Regional community Portals: A Preliminary Model”, Australian and New Zealand Marketing Academy Conference.

Linton J. 2002. “Implementation Research: State of the Art and Future Directions”, Technovation, nº. 22, pp. 65-79.

Maidique M. 1980. “Entrepreneurs, Champions and Technological Innovation”, Sloan Management Review, 21(2), pp. 59-76.

Markham S., Green S., Raja B. 1991. “Champions and Antagonists: Relationships with R&D Project Characteristics and Management”, Journal of Engineering and Technology Management, 8, pp. 217-242.

Markham S., Griffin A. 1998. “The Breakfast of champions: Associations between champions and product development environments, practices, and performance”, Journal of product innovation management.

Markus M., Tanis C. 2000. “The Enterprise Systems Experience- From Adoption to Success”, In Framing the Domains of IT Research Glimpsing the Future Through the Past, R. W. Zmud (Ed.), Pinnaflex Educational Resources, Cincinnati, OH.


McEvoy G., Buller P., Roghaar S. 1988. “A jury of one’s peers”, Personnel Administrator, 33, pp. 94-101.


O'Leary D. 2000. “Enterprise Resource Planning Systems: Systems, Lifecycle, Electronic Commerce, and Risk”, Cambridge University Press.

Parr A., Shanks G., Darke P. 1999. “Identification of Necessary Factors for Successful Implementation of ERP Systems”, New information technologies in organizational processes, field studies and theoretical reflections on the future work, Kluwer academic publishers, pp. 99-119.

Pettersen N. 1991. “What do We Know about the Effective Project Manager?”, International Journal of Project Management, 9(2), pp.99-104.


Pinto J., Slevin D. 1989. “Critical Success Factors across the Project Lifecycle”, Project Management Journal, pp. 67-75.

Purba S., Sawh D., Shah B. 1995. “How to Manage a Successful Software Project”, John Wiley & Sons.

Rao S. 2000. “Enterprise Resource Planning: Business Needs and Technologies”, Industrial Management & Data Systems, 100(2), pp. 81-88.

Reimers K. 2003. “Implementing ERP Systems in China”, Communications of the Association for Information Systems, 11, pp. 335-356.

Roberts E., Fusfeld A. 1981. “Critical Functions: Needed Roles in the Innovation Process”, in Ralph Katz editor, Career issues in Human Resource Management. Prentice-Hall Inc. Englewood Cliffs. New Jersey.

Robey D., Ross J., Boudreau M. 2002. “Learning to Implement Enterprise Systems: An Exploratory Study of the Dialectics of Change,” Journal of Management Information Systems, 19(1), pp. 17-46.

Rockart J. 1979. “Chief Executives Define Their Own Information Needs”, Harvard Business Review, pp. 81-92.

Rosario J. 2000. “On the Leading Edge: Critical Success Factors in ERP Implementation Projects”, BusinessWorld, Philippines.

Rothwell R., Freeman C., Horlsey A., Jervis V., Robertson A., Townsend J. 1974. “Sappho updated - Project SAPPHO Phase II”, Research Policy, 3, pp. 258-291.

Roure L. 1999. “Cultural Differences in Product Champions Characteristics: A comparison of France and Germany”. Centre de Recherche DMSP, cahier nº. 268.

Schon D. 1963. “Champions for Radical New Inventions”. Harvard Business Review, 1963, 41(2), pp. 77-86.

Shane S., Venkataraman S., MacMillan I. 1995. “Cultural Differences in Innovation Championing Strategies”. Journal of Management, 21(5), 1995, pp. 931-952.

Smith J., Mc Keon J., Hoy K., Boysen R., Schechter L., Roberts E. 1984. “Lessons from 10 Case Studies in Innovation”. Research Management, 27(5), pp. 23-27.

Somers T., Nelson K. 2001. “The Impact of Critical Success Factors across the Stages of Enterprise Resource Planning Implementations”, 34th Hawaii International Conference on System Sciences, 2001.


Stefanou C. J. 1999. “Supply Chain Management (SCM) and Organizational Key Factors for Successful Implementation of Enterprise Resource Planning (ERP) Systems”, Americas Conference on Information Systems, Wisconsin (USA).

Standish Group 1995. “Chaos”, available: http://www.standishgroup.com/visitor/chaos.htm Strauss A., Corbin J. 1990. Basics of qualitative research: grounded theory procedures and

techniques. Newbury Park, CA: Sage Publications. Sumner M. 1999a. “Critical Success Factors in Enterprise Wide Information Management Systems

Projects”, Americas Conference on Information Systems, Wisconsin (USA). Sumner M. 1999b. “Critical Success Factors in Enterprise Wide Information Management Systems

Projects”, SIGCPR’99, New Orleans (USA), pp. 297-303. Sumner M. 2000. “Risk Factors in Enterprise-wide/ERP Projects”, Journal of Information

Technology, 15, pp. 317-327. Thamhain H. 1991. “Developing Project Management Skills”. Project Management Journal, 22(3),

1991. Truex D. 2001. “The Impact of ERP Systems as Facilitating or Confounding factors in Canadian

Telecommunications Mergers?”, Systemes d'Information et Management journal, 1(6), pp. 7-21.

Vitale M., Ives B. 1988. “Finding and Fostering Innovative Applications of Information Technology: the US Perspective”, Working paper, International Center for Information Technologies, Washington USA).

Welti N. 1999. “Successful SAP R/3 Implementation - Practical Management of ERP Projects”, Addison-Wesley.

Whitten N. 1999. “The Enterprize Organization: Organizing Software Projects for Accountability and Success”, Project Management Institute.

Chapter 5 - Critical Success Factors Relevance 116

Chapter 5

Critical Success Factors Relevance

Chapter Summary: This chapter describes the analysis of the CSF relevance along the ERP implementationphases using Process Quality Management (PQM) method. By applying PQM method and usingthe ASAP implementation methodology as a reference for the SAP implementation processes, wedefined the CSF relevance for each CSF along the SAP implementation phases. Then weextrapolated our findings to other ERP studies by comparing our relevance schema with othersproposed by other colleagues. One of the limitations of PQM is that the process structure of the PQM method is too simple since it only provides one level of process analysis. Since most casesimply project process structures that are more complex, such as ERP implementation processesstructure, here we propose the improvement of the PQM analysis section to provide more depth to complex project structures. We propose an extension to the standard PQM method, where weprovide a new criticality indicator for complex implementation project process structures. Thiscriticality indicator was used to define and analyze the most critical SAP implementationprocesses.


Thesis Introduction


Research Design






CSFsIdentification


CSFsIdentification




ERP Context

5


5.1 Software Project Overview

In order to achieve success in a software project, it is important to define and analyze the most critical processes within the project. If organizations had unlimited resources, each process within the project could have equal attention for resources and management focus. But in practice, the time and resources of project managers are always limited. Therefore, it is important to pinpoint those activities that warrant the most attention (Hardaker and Ward 1987).

We may define a project as “a unique set of coordinated activities, with definite starting and finishing points, undertaken by an individual or organization to meet specific objectives within defined time, cost and performance parameters” (Association of Project Management 2000) that “it is only completed when the deliverable has been produced to the satisfaction of the customer” (Shenhar and Wideman 2000).

A software project is “the set of all project functions, activities, and tasks, both technical and managerial, required to satisfy the terms and conditions of the project agreement. A software project should have specific starting and ending dates, well-defined objectives and constraints, established responsibilities, and a budget and schedule. A software project may be self-contained or may be part of a larger project. A software project may span only a portion of the software product lifecycle” (IEEE 1998). According to Savolainen (1991), a software project is successful if the implementation of the resulting IS supports effectively the business goals defined by management, and fulfils the users' requirements, if the users are satisfied with the system, if the system is implemented within the given time and budget, and if the system maintenance is flexible.

A common approach to define most critical processes is the Process Quality Management (PQM) method developed by IBM (Hardaker and Ward 1987, Ward 1990). This method is based upon the CSF approach. We have used this method to define the CSF relevance and the most critical SAP implementation processes.

The chapter is organized in the following way. First, we present a software project structure overview. Next, we describe the PQM method and its analysis and detail sections. Then, we described the SAP implementation methodologies. We define the research methodology followed. Then we present the CSF relevance schema. Next, we present our extended analysis framework for more complex critical processes. We apply this framework to the case of SAP implementation projects and analyze the results found. Finally, we present some conclusions.

5.1.1 Software Project Structure

The structure of project processes is the basis for their planning, monitoring, control and success. According to the Project Management Body of Knowledge (Duncan 1996), a project process is a “series of actions bringing about a result”. According to the IEEE standard for software lifecycle processes (IEEE 1996) a software process is “a set of interrelated activities, which transforms inputs into outputs”.

One of the steps in project planning is determining the sequence in which the processes will be performed. Most project process structures have more than one level (see figure 16).


Work package n

Work package 2

Work package 1

Phase n........Phase 2Phase 1

Work package n

Work package 2

Work package 1


- Activity 1- Task 1- Task 2...- Task n

- Activity 2...- Activity n

Work package n

Work package 2

Work package 1


Work package n

Work package 2

Work package 1


- Activity 1- Task 1- Task 2...- Task n

- Activity 2...- Activity n

Figure 16. A typical implementation project structure.

Most common project processes are structured in phases (in our case implementation phase),

work packages, work activities and work tasks (quotations from IEEE 1998, p. 3): • A project phase (in our case project implementation phase) is a collection of logically

related project activities, usually culminating in the completion of a major deliverable (Duncan 1996).

• A work package “is a specification of the work that must be accomplished to complete a work task. A work package should have a unique name and identifier, preconditions for initiating the work, staffing requirements, other needed resources, work products to be generated, estimated duration, risk factors, predecessor and successor work tasks, any considerations for the work, and the completion criteria for the work package – including quality criteria for the work products to be generated”. A work product is “any tangible item produced during the process of developing or modifying software”.

• A work activity is a “collection of work tasks spanning a fixed duration within the schedule of a software project. Work activities may contain other work activities, as in a work breakdown structure. Typical work activities include project planning, requirements specification, software design, implementation, and testing”.

• A work task is the “smallest unit of work subject to management accountability. A work task must be small enough to allow adequate planning and control of a software project, but large enough to avoid micro-management. The specification of work to be accomplished in completing a work task should be documented in a work package. Related work tasks should be grouped to form supporting processes and work activities”.

During the project, work package units are the basic element of project management in terms of

planning, control and monitoring (Fairley 1999). Therefore, we focus our analysis in the definition of criticality for this unit.


5.2 CSF Relevance Overview

In 1988, Pinto and Prescott (1988, p. 5), claimed that “the majority of the studies in the critical success factor research stream have been theoretical and have assumed a static view of the importance of various factors over the life of a project. In other words, a critical success factor was assumed to have the same degree of importance throughout the life of the project”. Therefore, Pinto and Prescott (1988) examined changes in the criticality of project CSF over the lifecycle of a project. They concluded that the criticality of CSF is subject to change at different phases of the project lifecycle. They stated that “this finding implies that future use of critical success factor analysis and implementation, regardless of the area to be examined, may be contingent on other organizational phenomena, such as project (or organizational) lifecycle” (Pinto and Prescott, p. 17).

Subsequent studies on CSF approach have addressed not solely the identification of CSF but also their relevance along the project lifecycle. However, the number of these types of studies stills very limited with most studies only focusing on CSF identification. The assumption of CSF criticality is slightly different from some studies that try to define CSF for each phase of the project lifecycle. Pinto and Prescott (1988) use the same set of CSF and examined their criticality along the project phases while some studies define different sets of CSF for each project phase. These approaches are different although some researchers are empirically using the same assumption stated by Pinto and Prescott (1988) since they are providing what they call “the most critical” or “most relevant” or “the top” CSF which means they are only defining the most relevant CSF but probably they are always using as a reference the same set of CSF.

To study CSF relevance, researchers have used surveys and case studies using interviews. The typical procedure is to ask participants to rank the most CSF in each project phase and then create a list of the top relevant CSF in each project phase or, ask participants to evaluate CSF relevance using a likert scale like low, normal and high relevance. Some authors have studied CSF along different IS lifecycles: information centers (Magal et al. 1988), implementation projects (Pinto and Slevin 1988), Cooper and Zmud (1990), Activity based costs implementation (Anderson 1995), ERP lifecycle (Somers and Nelson 2001, Nah et al. 2001).

5.2.1 CSF Relevance in ERP context

In order to study the relevance of CSF along an ERP lifecycle we made a literature review and we found four studies (Bergamaschi and Reinhard 2000, Parr and Shanks 2000, Nah et al. 2001, Somers and Nelson 2001). Parr and Shanks (2000) studied CSF relevance based in two case studies of ERP implementation. However, only one of the case studies was considered a successful ERP implementation. Somers and Nelson (2001) described the impact of CSF across the stages of a typical ERP implementation project based in a survey to 86 organizations. Bergamaschi and Reinhard (2000) analyzed the relevance of CSF along the ERP lifecycle phases based in a survey to 43 organizations in Brazil. The study of Nah et al. (2001) defines in which phase of the ERP lifecycle each CSF may come into play but authors include implementation stages in a unique phase denominated project phase. Our study extends the analysis of Nah et al. (2001) for the ERP lifecycle phases by focusing on implementation phase.


We found three main discrepancies in these studies: the first is related with the ERP lifecycle used while the second is related with the CSF considered. With regard to the ERP lifecycle, in all cases it is based in the particular researchers’ definition and none of the studies tried to directly analyze the lifecycle of the branded implementation methodologies used in ERP implementation projects. All the implementation methodologies have as basis an ERP lifecycle. The adoption of an ERP implementation methodology is considered a CSF (Esteves and Pastor 2000).

Second, the expression ‘implementation’ is used in one case (Somers and Nelson 2001) as referred to the whole process of adopting, selecting, implementing and using the ERP system. For us, the implementation phase consists of “the customization or parameterization and adaptation of the ERP package acquired according to the needs of the organization” (see chapter 4 – Unified Model of Critical Success Factors). In relation to the definition of CSF, each study used a different list of CSF, some CSF are the same but with different names, or different definitions encompass the same CSF. We opted by using our unified model of CSF for ERP implementation projects (see chapter 4 – Unified Model of Critical Success Factors).

Finally, all the studies used senior executives, project managers and/or project team members’ perspective. This perspective is relative first, because these actors do not participate in all the tasks associated to an ERP implementation project because each one plays a different role. Therefore the CSF relevance findings should be analyzed according to these actors viewpoint. Second, in none of the studies was explained if the actors have followed the ERP implementation best practices or the implementation processes that each ERP vendor and consulting companies propose which are based in hundreds or thousands of implementations. In our case we opted to analyze CSF relevance taking into account the ERP implementation processes underlying an ERP implementation project which are detailed in all the ERP implementation methodologies.

We agree with Ward (1990) in that CSF are not, in themselves, directly manageable. Rather than the CSF, it is the processes that define what a management team 'Do', processes that can be owned, defined, measured and managed. Therefore, it is necessary to relate the CSF to the ERP project implementation processes to provide an overall view of the importance of each process to the management of the CSF in ERP implementation projects. These ERP implementation project processes are described in the ERP implementation methodologies used. Broadly, an ERP implementation methodology covers the following: modeling business processes, mapping business processes onto the processes supported by the ERP system, perform the gap analysis, customizing the ERP system and finally, testing the customized ERP system before go live. Some ERP methodologies have specific modules to knowledge management and change management.

Both perspectives are valid but a comparative analysis should be made in order to improve the knowledge on this topic.


5.3 Process Quality Management Method Overview

The Process Quality Management (PQM) method developed by IBM is “designed to assist the management team reach consensus on the most critical business activities, i.e. those whose performance will have the biggest impact on the success or failure of the enterprise” (Ward 1990, p. 105). PQM uses the concept of CSF (Rockart 1979) to encourage management teams to focus their attention on the critical issues of the business, and then to base the IT strategy on these. PQM is essentially a top-down, business-lead approach. According to Ward (1990), the purpose of PQM is to enable the management team to:

• Identify the key requirements for improving the overall business performance of the enterprise;

• Conduct an audit on the current investment in IT-based applications and services; • Identify the principal opportunities and priorities for future investments in IT-based

applications and services; • Review the relevance of current quality improvement projects (if a quality program

exists). The PQM method has the following steps: • First step - to define the mission. According to Ward (1990), “the word 'mission' is used

in PQM very simply to mean the reason why the particular management team exists; what they are collectively being paid to do. The mission statement is the vision and guiding light for the team, and all those managed/influenced by them.”

• Second step - to identify CSF. Hardaker and Ward (1987) refer that in IBM they define CSF (applied to PQM) as “what the team must accomplish to achieve its mission”.

• Third step - to define the business processes. In this step the relationships between the CSF and the business processes are established. Therefore, we will have a list of the most critical processes (MCPs). This is made through the creation of a matrix of CSF versus business processes like the one shown in figure 2.

• Fourth step - to review the IT applications based in the knowledge of the matrix developed.

5.3.1 Building the PQM Matrix of CSF vs. Business Processes

In the third step, with PQM we generate a matrix of CSF vs. business processes that has two sections (see table 23): a 'detail' section, relating CSF to the business processes, and an 'analysis' section, which indicates the relative 'importance' to CSF performance of each business process, and forms the basis for the establishment of the Most Critical Processes (MCPs). Next, we explain each section.


Table 23. Example of the matrix CSF versus ASAP work packages for project preparation phase.

CSF in ERP implementations ASAP Processes

Sust

aine

d m

anag

emen

t sup

port

Effe

ctiv

e or

gani

zatio

nal c

hang

e m

anag

emen

t G

ood

proj

ect s

cope

man

agem

ent

Ade

quat

e pr

ojec

t tea

m c

ompo

sitio

n C

ompr

ehen

sive

bus

ines

s pro

cess

reen

gine

erin

g U

ser i

nvol

vem

ent a

nd p

artic

ipat

ion

Ade

quat

e pr

ojec

t spo

nsor

role

A

dequ

ate

proj

ect m

anag

er ro

le

Trus

t bet

wee

n pa

rtner

s D

edic

ated

staf

f and

con

sulta

nts

Stro

ng c

omm

unic

atio

n in

war

ds a

nd o

utw

ards

Fo

rmal

ized

pro

ject

pla

n/sc

hedu

le

Ade

quat

e tra

inin

g pr

ogra

m

Prev

entiv

e tro

uble

shoo

ting

App

ropr

iate

usa

ge o

f con

sulta

nts

Empo

wer

ed d

ecis

ion

mak

ers

Ade

quat

e ER

P im

plem

enta

tion

stra

tegy

A

void

ER

P cu

stom

izat

ion

Ade

quat

e ER

P ve

rsio

n …

.. C

ount

W Project Kickoff A Kickoff Meeting T Prepare for kickoff meeting 1 1 2T Conduct kickoff meeting 1 1 1 1 4T Company wide project introduction 1 1 1 3A Project team standards meeting T Prepare for standard meeting 1 1 2T Conduct standard meeting 1 1 1 3W Quality Check A Perform quality check and approval T Conduct quality check 1 1T Signoff project preparation phase 1 1 2 Number of CSF occurrences 2 0 0 0 0 1 7 0 0 1 3 3 0 0 0 0 0 0 0

5.3.2 PQM Matrix Detail Section

The matrix has two axes: one represents the business processes and the other represents the CSF. The management team focuses in turn on each CSF and considers the following question: “which business processes need to be performed particularly well for us to be confident of achieving this CSF?” (Ward 1990, p. 121).

Many processes influence the achievement of a CSF but the team must judge which the truly critical processes are. After the first pass a 'sufficiency test' is applied: “If the identified processes are performed well, are they sufficient to manage the CSF in question?” If the answer is 'no' then additional processes need to be defined. This analysis is repeated for all CSF, each of which will have a different set of critical processes.


5.3.3 PQM Matrix Analysis Section

After the definition of the processes which are most relevant for each CSF, there is the need to make an analysis of priorities, which is done by using three indicators:

• The count - the more important business processes are potentially those which impact most CSF and a simple count is provided in a column in the analysis section matrix.

• Assignment of a 'quality' rating - A 'quality' rating for each process is provided in a column in the analysis section. This rating is normally the subject of considerable debate among the team. The 'basic' ranking that PQM uses to assess the current quality of the business processes is: A = needs no improvement, B = works well, room for minor improvement, C = functions, several areas for improvement, D = process in place but not functioning, E = embryonic.

• Identifying the 'big burners' - In addition to 'count' and 'quality' a number of teams also identify the 'big burners', those business processes that consume a significant proportion of the money, people or assets for which the team is responsible. The processes to which this test applies are designated with an asterisk in the ‘big burners’ column.

Now the matrix is complete and the most critical processes can be established.

5.3.4 Establishing the Most Critical Processes

According to Ward (1990, p. 123), the Most Critical Processes (MCP) are those “processes whose performance must be improved if the CSF are to be managed successfully.” The identification of MCP is made through the creation of a matrix of CSF counts versus process quality rating. The project team must decide which zones have the MCP.

While all CSF are equal in importance, the processes vary in their scope and the amount of the team's resources that is devoted to each of them. The general role is that under no circumstances must the quality rating of a 'big burner' process be allowed to slip; and where it has a current quality rating of 'D' or 'C', immediate attention is required in the form of improvement processes.

The process structure of the PQM method is too simple since it only provides one level of process analysis. Since most cases imply project process structures that are more complex, here we propose the improvement of the PQM analysis section to provide more depth to complex project structures. In section 5.7, we propose an extension to the standard PQM method, where we provide a new criticality indicator for complex implementation project process structures.


5.4 SAP Implementation Methodologies

Nowadays, most of the ERP vendors propose rapid implementation methodologies. Examples of these methodologies are: Peoplesoft express, Oracle AIM advantage and Accelerated SAP. “These methodologies are characterized by a fairly rapid scoping and module assessment process and then configuring of the software to align business processes that are in scope. Small teams of consultants and business experts working together usually accomplish the configuring process” (Blick et al. 2000).

5.4.1 ASAP Implementation Methodology

The ASAP implementation methodology is a structured implementation approach that can help managers achieve a faster implementation with quicker user acceptance, well-defined roadmaps, and efficient documentation at various stages. This is specifically targeted for small and medium enterprises adopting SAP. The phases of the ASAP methodology, also known as the ASAP roadmap are (ASAP 1999):

1. Project Preparation - the purpose of this phase is to provide initial planning and preparation of SAP project. The steps of this phase help identify and plan the primary focus areas to be considered such as: objectives, scope, plan and definition of project team.

2. Business Blueprint - the purpose of this phase is to create the business blueprint, which is a detailed documentation of the results gathered during requirements workshops/meetings. It will allow the implementation project team to clearly define their scope, and only focus on the SAP processes needed to run the organization business.

3. Realization - the purpose of this phase is to implement business and processes requirements on the business blueprint. The objectives are final implementation in the system, an overall test, and the release of the system for production (live) operation.

4. Final Preparation - the purpose of this phase is to complete the final preparation, including testing, end user training, system management and cut over activities, to finalize the readiness to go live. The final preparation phase also serves to resolve all open issues.

5. Go Live & Support - the purpose of this phase is to move from a pre-production environment to live production operation. A support organization must be set up for end users to provide long-term support. This phase is also used to monitor system transactions and to improve overall system performance. Finally the completed project is closed.

The structure of each phase is the following: each phase is composed of a group of work

packages. These work packages are structured in activities, and each activity is composed of a group of tasks. For each task, a definition, a set of procedures, results and roles are provided in the ASAP roadmap documentation (ASAP 1999).

5.4.2 Other SAP Methodologies

There are several SAP implementation methodologies. Most of the consulting companies have their own methodology. However, most of these methodologies are based on the methodologies proposed by the SAP enterprise. The main reason is in the need to obtain a certification from SAP


ensuring that the consulting company and its methodology satisfy SAP rules. Initially, SAP proposed the SAP procedure model methodology. Khan (2002, p. 50) presents a comparison analysis between ASAP and the SAP procedure model (see table 24). Table 24. Comparing conventional and SAP methodologies (source: Khan 2002). Issues ASAP Conventional methodology 1 Time frame Fast implementation Slow implementation 2 Approach Rushed without in-depth analysis Based on extensive analysis and

consensus 3 Reengineering More due to implementation of new

SAP supported processes Less because tendency is to mirror existing processes

4 Features/functionality Vanilla Custom 5 Implementation Very focused and narrow Comprehensive 6 Configuration Primarily done by consultants Significant employee participation 7 Upgrades Less testing required as minimal code

changes are implemented More testing required due to extensive code modification

8 Cost Low High 9 Documentation Minimal Extensive 10 ABAPtm development Minimal due to vanilla implementation Extensive due to excessive custom

requirements 11 Number of consultants Relatively few are required Large team of experts is required 12 Employee turnover Low due to less knowledge gained

during implementation High as extensive knowledge gained can be leveraged for a better job

13 Knowledge transfer for employees

Low since project is rushed and consultants allocate insufficient time

High since features are configured gradually with employee participation

Esteves and Jorge (2001) also compared ASAP methodology with other three SAP

implementation methodologies: Summit R/3, the ERP methodology of Coopers & Lybrand; and Method blue, the ERP methodology of IBM. The results suggest that:

• All the methodologies use process modeling as the basis for the implementation stages. They mention the need for an intensive process modeling and the definition of requirements before the parameterization of the SAP system.

• ASAP is more concerned with the TO-BE analysis step, i.e., how the organization will be, while the other methodologies are more concerned with the AS-IS analysis step, i.e., how the organization is nowadays, and the clear definition of project goals.

• ASAP is very well structured regarding the implementation project tasks, perhaps too much detailed in terms of the number of tasks from the viewpoint of implementation projects in SME. However, it lacks the vision of change management, return on investment, training and project management as a whole. The other methodologies lack of rigor and detail in the definition of implementation project tasks.

• All the implementation methodologies analyzed are more oriented to implementation tasks achievement than to implementation goals achievement. Therefore, they seemed to be more operational oriented rather than strategic oriented.

• ASAP has the advantage of being a methodology that requires more discipline and planning from the implementation project team.


• We think that neither the three methodologies are oriented for SME, at least as what is considered a SME in Europe since all three required a lot of resources, especially human resources.

• All three lack of a monitoring scheme that is not solely the accomplishment of implementation tasks according to scheduled times or within budget. There is the need to establish metrics according to organizational, business needs and goals defined at the beginning.

• All have a lack of knowledge management procedures. All treat this issue as essential but none proposes specific activities for knowledge management. They only provide some recommendations about the issue. We think this is due to the fact that consulting companies have there specific knowledge management methodologies and they apply them combined with their SAP implementation methodology.

5.5 Research Methodology

The research methodology consisted in two stages: • Use of PQM to establish the relationship between ASAP implementation work packages

and CSF for ERP implementation projects. • Use of two ERP implementation experts to validate the relationships previously defined.

We started by using the PQM method (Hardaker and Ward 1987, Ward 1990) to relate the CSF

with the ASAP work packages. Next, we describe the following steps of the PQM method, as we have applied them in our research case (see figure 17):

• First step: define the mission. We defined the following mission: “To implement the ERP system, according to the organization's business and organizational needs” and then “to show that the ERP implementation will add value through the satisfaction of the organization requirements previously defined”. This mission reflects the intention of the whole group of people involved in an ERP implementation project;

• Second step: define CSF. We used the CSF unified model proposed by Esteves and Pastor (2000);

• Third step: define the processes. In our case, the processes are those defined in the ASAP methodology;

• Fourth step: establish the relationship of CSF versus ASAP work packages. This is done through the creation of the matrix presented in table 23. For each one of the five SAP implementation phases a matrix was created.


Phase 5Phase 4Phase 3Phase 2Phase 1 Phase 5Phase 4Phase 3Phase 2Phase 1

CSFsinERP Projects

ASAP Methodology

Processes

CSFsinERP Projects

ASAP Methodology

Processes

CSFsRelevance

ProcessQualityManagement(PQM)

+CodingProcedure

CSFs in ERP Projects

ASAP Methodology

Processes

CSFs in ERP Projects

ASAP Methodology

Processes

CSFs Relevance

Process Quality Management(PQM)

+Coding Procedure

CSFsinERP Projects

ASAP Methodology

Processes

CSFsinERP Projects

ASAP Methodology

Processes

CSFsRelevance


+CodingProcedure

CSFs inERP Projects

ASAP Methodology

Processes

CSFs inERP Projects

ASAP Methodology

Processes

CSFsRelevance


+CodingProcedure

CSFsinERP Projects

ASAP Methodology

Processes

CSFsinERP Projects

ASAP Methodology

Processes

CSFsRelevance


+CodingProcedure

CSFsinERP Projects

ASAP Methodology

Processes

CSFsinERP Projects

ASAP Methodology

Processes

CSFsRelevance


+CodingProcedure

Figure 17. CSF relevance research framework followed.

According to Hardaker and Ward (1987, p. 118), “the object is to single out the processes that have a primary impact on this particular CSF”. What we are looking for are those essential activities and not all of them. The matrix in table 23 has been built in the following way. We focused on each CSF and asked this question: Which ASAP work packages must be performed especially well for us to be confident of achieving this CSF? Then, we looked at all the processes and decided which ones were important for that CSF. Each time we established a relationship between a CSF and a process, we marked a ‘1’ in the corresponding cell of the matrix (see table 23).

A second process was used to validate and to get more reliability in the research. We used a coding procedure to analyze the ASAP documentation. First, the coding process was carried out by the doctoral student. The coding procedure consisted in coding line-by-line all the ASAP work packages using a predefined list of codes, in this case the list of CSF. Then, the advisor analyzed the coding process. Disagreements on coding were settled through consultation between researchers and in some cases, with additional input from documentation on ASAP methodology searched from the net.

Part of the full matrix of CSF versus ASAP work packages built for the first phase of ASAP, the project preparation phase, is represented in table 23 (see section 5.3 – PQM method overview).

5.5.1 Validation

The second phase examined the validation of the relationships between ASAP implementation work packages and CSF by two ERP implementation experts. The main purpose of this phase was to improve the reliability of our results. The first expert is a SAP consultant with more than 8 years of experience. This consultant is a SAP R/3 and ASAP certified consultant by SAP AG. The second expert worked as an international auditor and consultant for 16 years and participated in


several ERP implementations worldwide. Currently, he is a lecturer in a well known European business school.

After their formal agreement to participate in the study, we submitted to them a file by email that contained (1) each of the CSF matrixes that we developed for each ASAP phase and (2) the validation procedures. The procedures were the following:

• Next, in each worksheet you will find each one of the ASAP phases and its tasks and their relationship with CSF for ERP implementations. Please review for each task in each phase the relationships between the task and each CSF. The CSF definition is presented in one worksheet (CSF definition).

• If you not agree with the relationship defined please mark it in red. • Please write on the right side of the table the reason for your discrepancy. • If you think there are more relationships please marking them with yellow and the number

1. • Please write on the right side of the table the reason for your choice.

Overall, the impression of the experts was that our definition of the relationships between

ASAP implementation processes and the CSF was rigorous and accurate. However, they proposed a few adjustments. These adjustments concerned the inclusion of the project manager role CSF in some tasks, especially in those related to tests and data migration, and trust between partners CSF in some tasks. The process of analyzing the adjustments consisted in verifying if both experts were proposing the same adjustment and their argumentation was similar. If they agreed, we included the new relationship. Some adjustments were proposed by only one expert. In this case we review their comments and compared it with the ASAP documentation. This procedure helped to decide the acceptance or not of the adjustment proposed. From the 8 adjustments proposed, we accepted 6 of them.

The experts also criticized some of the relationships already proposed. In some cases, their disagreement was due to the fact that they did not have in mind the complete and rigorous definition of the task. This also caused some disagreements between the experts. To solve these situations we provided them with additional information from ASAP documentation. At the end, we only had to remove three of the relationships initially proposed. One of the experts commented by email: “I recognize that often in the SAP implementations people don’t follow literally the tasks definitions which I admit sometimes is a mistake”.

The final version of each CSF matrix is presented in appendix D. Next, we discuss the findings from all the ASAP implementation phases.


5.6 Critical Success Factors Relevance Schema

Table 25 represents the CSF relevance for each CSF in each phase. The values were calculated in the following way. We have built a matrix of CSF versus ASAP work packages such as the one in table 23 for each implementation phase, and for each CSF we summed the number of occurrences of that CSF. For instance, the sum of 2 in the CSF Sustained Management Support means that we defined 2 relationships between this CSF and 2 ASAP tasks. Then, we converted the number of occurrences (raw scores) into a normative scale of ten scores. In a scale of this kind, results from 1-3 are considered irrelevant, from 4-7 normal relevance, and 8-10 they are considered of high relevance. In our case, we see that almost all the factors are higher than 4. Thus, their relevance is normal or high in most cases. We do not pretend to say that a CSF with a low summation it is not important; what we say is that it is less relevant in that period of the project. CSF have all the same importance. Therefore, all of them should be carefully respected and analyzed. Table 25. CSF relevance along the SAP implementation phases.

SAP Implementation phases Perspectives Critical Success Factors 1 2 3 4 5

Sustained management support 8 6 5 5 8 Effective organizational change management 6 9 5 5 6 Good project scope management 5 3 4 4 4 Adequate project team composition 4 4 4 4 4 Comprehensive business process reengineering 4 7 4 3 4 User involvement and participation 5 9 10 8 6 Adequate project sponsor role 7 6 4 5 7 Adequate project manager role 10 9 9 10 10

Strategic

Trust between partners 6 4 4 4 6 Dedicated staff and consultants 4 4 4 4 6 Strong communication inwards and outwards 8 7 6 8 10 Formalized project plan/schedule 8 7 7 7 7 Adequate training program 5 5 5 6 4 Preventive trouble shooting 4 4 8 8 7 Appropriate usage of consultants 6 9 9 6 4

Organizational Perspective

Tactical

Empowered decision makers 4 4 4 5 4 Adequate ERP implementation strategy 5 4 4 4 6 Avoid ERP customization 4 4 5 3 4 Strategic Adequate ERP version 4 3 3 3 4 Adequate infrastructure and interfaces 6 6 7 6 4 Adequate legacy systems knowledge 4 4 4 4 4 Formalized testing plan 4 4 9 6 4

Technological Perspective

Tactical

Adequate migration process 4 4 5 6 4 The analysis of table 25 shows that: • In phase 1 (project preparation), the most relevant CSF are sustained management

support, project manager role and formalized project plan/schedule. We are at the beginning of the implementation project and it is very important to identify and plan the primary focus areas to be considered.


• In phase 2 (business blueprint), the most relevant CSF are project manager role, effective organizational change management and user involvement. The goal of this model is to create the Business Blueprint that is a visual model of the business’ future state after which organizations have crossed the SAP finish line. It will allow the implementation project team to clearly define their scope, and only focus on the SAP processes needed to run the organization business.

• In phase 3 (realization), the most relevant CSF are adequate infrastructure and interfaces, project manager role, and user involvement. In this phase the configuration of SAP system begins, that is why the adequate ERP configuration factor is so important as well as the involvement of users. They help in the system parameterization.

• In phase 4 (final preparation), the most relevant CSF are project manager role and preventive troubleshooting and it is time to convert data and to test the system.

• In phase 5 (go live & support), the most relevant CSF are project manager role, sustained management support and strong communication inwards and outwards.

One of the main results from the table 29 is that organizational factors have more relevance

along the SAP phases than technological ones. Once again, there is the need to focus more on people and process than on technology itself. This is not new, and other studies have proved the same aspect in other types of IS implementation projects. This aspect is very important since as Felix and Harrison (1984) quoted, “technical problems can usually be detected and repaired before the system is put in jeopardy. The cost may be high in terms of either budget or schedule, but the repair can be made. Organizational and personnel problems often cannot be redressed, and continue to jeopardize the success of the system itself”.

Next, we describe each CSF along the ASAP phases, classified by organizational and technological perspectives.

5.6.1 Organizational Perspective

Sustained management support is more relevant at the beginning and at the end of the implementation. The reason is that at the beginning senior management should help in the rollout of the project, analyze the business benefits, define the mission and scope of the project and provide the resources needed for the project. At the end, there is the need to encourage the system usage and help in the commitment of user involvement.

Effective organizational change management and business process redesign are more relevant in the second phase. In this phase the business blueprint is defined, and the business processes are analyzed, redesigned (some) and documented. There is the need to understand how the organization intends to run its business within the SAP system and the changes in the organization.

Adequate project team composition has the same relevance along all the phases since they play an important part in the whole project. ASAP methodology does not focus too much on this CSF since it assumes that the right people were chosen.

Good project scope management is relevant at the beginning when managers define the scope and in the last phase because the scope is usually revised and changed according to the results of the go live system tests.


Adequate project sponsor role is more relevant at the beginning when people need to be motivated to start the project and to obtain the necessary resources and in the last phase when project sponsor needs to encourage the use of the system.

Adequate project manager role is relevant in all phases. It is less relevant in the second and third phases than in with the others because these phases are dedicated to business modeling and configuration tasks and here the role of the project manager is to guarantee that everything goes according to the plan.

User involvement and participation is relevant in the phases where their know-how is important to achieve a good customization of the system to organizational needs. They participate in the definition of business requirements, help in the analysis of the ERP configuration and in conversion of data and the testing of the system.

Trust between partners is relevant at the beginning when all the stakeholders involved in the project should share their goals and knowledge and at the end when they have to analyze and again share their knowledge to finish the project with success.

Dedicated staff and consultants is more relevant in the last phase where there is the need to dedicated more effort in order to the system go live and also be available to help users answering their questions and reduce their doubts about the new system.

Appropriate usage of consultants is relevant especially in the second and third phases. On the second phase the knowledge of consultants is important to improve the business processes, and on the third phase consultants product knowledge on the ERP system parameterization.

Empowered decision makers is more relevant in the second and fourth phases because there is the need to take quickly decisions related with the business processes redesign (second phase) and the adequate customization of ERP system (fourth phase) in order to accomplish project plan/schedule on time.

Adequate training program is more relevant in phase 4 because it is when the training program of end users starts, but in the previous phases there are also training concerns related with project team training and to prepare end user training.

Strong communication inwards and outwards is more relevant at the first two phases where there is strong need of communication between senior management and the project team in the definition of project plan and scope, and in the last phase where there is the need of a strong communication with the whole organization to start the go & live of the SAP system.

Formalized project plan/schedule relevance decreases during the implementation project. The reason is that at beginning it is important starting planning as early as possible. However, along the project, modifications to accomplish the results expected.

Preventive trouble shooting is more relevant in the last three phases, especially in the fourth phase during which issues arise when the production system is being tested and old data converted to the new system.

5.6.2 Technological Perspective

Avoid ERP customization is more relevant in phase 3, when the SAP system is configured and more than 8.000 tables must be parameterized. The software configuration should follow the business requirements defined in the previous phase.


Adequate ERP implementation strategy is more relevant at the first phase because is in this phase that the SAP implementation strategy should be decided.

Adequate ERP version has the same relevance along all the phases. From the beginning until the end of the project implementation, SAP recommends that the project team follows the upgrade of SAP releases and should consider the adoption of new ones.

Adequate infrastructure and interfaces is more relevant in phases 3 and 4, when there is the need to configure the infrastructure for the production operation (go live). In these phases are also configured the interfaces with other systems, and the creation of reports and forms.

Adequate legacy systems knowledge is less relevant at the first phase because this phase is related with the preparation of project implementation. In phase 3 the need of knowledge of legacy systems is more relevant in order to minimize the effort of configuration, to help in conversion of data and the creation of interfaces.

Formalized testing plan is more relevant in phase 3 and 4 because in these phases the system needs to be tested after the parameterization process. The test should include not only functional testing but also the user’s testing.

Adequate data migration process is more relevant in phase 4 because it is in this phase that data is migrated to the ERP system. The data migration process may be done using automatic procedures, or manually, or a mix of both. Finally, users must certify that they accept the data migration results.

Regarding the definition of the most relevant CSF, we opted for accepting as the most relevant

CSF in each phase all the CSF with a score up to eight (see figure 18). This CSF relevance schema suggests that organizational and project management factors have more relevance along the SAP implementation project phases. Once again, there is the need to focus more on people and process than technology itself.


Effe

ctiv

e or

gani

zatio

nal c

hang

e

Use

r inv

olve

men

t and

par

ticip

atio

n

Ade

quat

e pr

ojec

t man

ager

role

Usa

ge o

f app

ropr

iate

con

sulta

nts

Adequate project m

anager role

User involvem

ent and participation

Comm

unication inwards and outw

ards

Preventive trouble shooting

Adequate project manager role

Sustained management support

Communication inwards and outwards

Formalized project plan/schedule

Adequate projec

t manager r

ole

Communication inward

s and outward

s

Sustained managem

ent support

4

Final Preparation

User involvement and participationAdequate project manager role

Usage of appropriate consultantsPreventive trouble shooting

Formalized testing plan

SAPImplementation

Project

BusinessBlueprint2

Project Preparation1

3Realization

Go Live

5

Figure 18. Most relevant CSF model proposal for a typical SAP implementation project.

5.6.3 Strategic and Tactical Factors along the ERP implementation Phases

Based upon the schema presented in table 25, we analyzed the evolution of strategic and tactical factors along the ERP implementation phases. Our findings suggest that while both good strategy and tactics are essential for a successful ERP implementation project, their importance shifts as the project moves through its lifecycle. The strategic issues are most important at the beginning, tactical issues gain in importance towards the end as figure 19 and table 26 show. Strategic perspective has a high or normal relevance along the ERP implementation phases while the tactical perspective starts by low and normal relevance and gradually increases to normal and high relevance.


0

1

2

3

4

5

6

7

8

9

Low Normal High Low Normal High Low Normal High Low Normal High Low Normal High

Project Planning Business Blueprint Realization Final Preparation Go Live & Support

Strategic Tactical

Figure 19. Strategic and tactical perspectives along ERP implementation phases.

Table 26. Strategic and tactical perspectives along ERP implementation phases.

Perspective ERP implementation phase Relevance Value Strategic Tactical Low 3 7 Normal 6 3 Project planning High 2 2 Low 5 6 Normal 3 5 Business blueprint High 3 1 Low 6 4 Normal 3 5 Realization High 2 3 Low 6 3 Normal 3 7 Final preparation High 2 2 Low 4 8 Normal 5 3 Go Live High 2 1


Next, we analyze our findings phase by phase: Project preparation – In this phase, strategic factors seem to have more relevance than

tactical factors. Project manager role and sustained management support are the highest relevant strategic factors while formalized plan/schedule is the highest tactical factor.

Business blueprint – Strategic factors are still the highest relevant factors on this phase. However, strategic factor types change. Project champion role is the most relevant in all phases, but sustained management support relevance decreases, and organizational change and user involvement and participation arise as the most relevant strategic factors. Regarding tactical factors, usage of appropriate consultants is the highest relevant one.

Realization – In general we evidenced that strategic factors relevance decreases and tactical factors gain relevance. Project champion role and user involvement and participation are still the most relevant strategic factors, while trouble shooting, usage of appropriate consultants are the most relevant tactical factors.

Final preparation – Strategic factors are still decreasing their relevance while tactical factors are more relevant in general. Project champion and user involvement and participation remain the most relevant strategic factors. Trouble shooting and communication are the most relevant tactical factors.

Go live & support – Again, strategic factors gain more relevance on this phase, while tactical factors loose a little of their relevance. Project champion role and sustained management support are the most relevant strategic factors. Communication is the highest relevant tactical factor.

According to Scott and Vessey (2002), “if certain of the more far-reaching strategic factors are

handled well, then tactical factors that are handled less may not endanger the project. Although the implementation would proceed less effectively and efficiently, the enterprise system implementation could still be achieved. However the reverse would not necessarily be true – even if the tactical factors were handled well, inappropriate handling of the strategic factors could doom the project”. Although we agree with Scott and Vessey (2002), we think that at long term probably the importance of strategic and tactical factors may change since the implications of tactical factors for knowledge creation may be stronger than the strategic factors in terms of project team. For instance, the tactical CSF dedication of staff and consultants may have implications on the duration of the activities and in the collaboration with consultants. However on the long term, its impact may be higher since the lack of dedication of staff affects knowledge transfer from the consultants to the project team since team members spend few time with consultants. This aspect may impact the knowledge for the future system maintenance.

5.6.4 Organizational and Technological Factors along the ERP implementation Phases

We also analyzed the evolution of organizational and technological factors along the ERP implementation phases (see table 27). Our findings suggest that while both organizational and technological perspectives are essential for a successful ERP implementation project, their relevance shifts as the project moves through its lifecycle. Organizational issues are most important at the beginning, while technological issues gain in importance towards the middle as


figure 20 shows. The organizational perspective has a high or normal relevance along the ERP implementation phases while the technological perspective starts by low and normal relevance and gradually increases to normal and high relevance. Table 27. Organizational and technological perspectives along ERP implementation phases.

Perspective ERP implementation phase Relevance Value Organizational Technological Low 5 5 Normal 7 2 Project planning High 4 0 Low 5 6 Normal 7 1 Business blueprint High 4 0 Low 7 3 Normal 5 3 Realization High 4 1 Low 5 4 Normal 7 3 Final preparation High 4 0 Low 6 6 Normal 7 1 Go Live High 3 0

0

1

2

3

4

5

6

7

8

Low Normal High Low Normal High Low Normal High Low Normal High Low Normal High

Project Planning Business Blueprint Realization Final Preparation Go Live & Support

SAP Implementation Phases

Num

ber C

SFs

organizational technological

Figure 20. Organizational and technological perspectives along ERP implementation phases.


Next, we analyze our findings phase by phase: Project preparation – In this phase, organizational factors have more relevance than

technological factors. Adequate project manager role, sustained management support and formalized plan/schedule are the most relevant strategic factors while adequate infrastructure and interfaces is the most relevant technological factor. The main reason for these CSF relevance is due to the fact that this phase is dedicated mostly to define and organize the project.

Business blueprint – Organizational factors are still the most relevant factors on this phase. However, organizational factor types change. Adequate project manager role is the most relevant in all phases, but sustained management support relevance decreases, organizational change, user involvement and participation, and usage of appropriate consultants arise as the most relevant organizational factors. Regarding technological factors, adequate infrastructure and interfaces is the most relevant one. This phase is mainly dedicated to the business analysis and modeling.

Realization – In general we evidenced that organizational factors relevance decreases and technological factors gain relevance. Adequate project manager role, user involvement and participation, and usage of appropriate consultants are still the most relevant organizational factors, while formalized testing plan and adequate infrastructure and interfaces are the most relevant technological factors. This relevance is according to the fact that in this phase the ERP system is parameterized. Therefore most of the technological tasks are done in this phase.

Final preparation – Organizational factors increase a little their relevance while technological factors decrease their relevance. Adequate project manager and user involvement and participation remain the most relevant organizational factors. Strong communication inwards and outwards gains relevance in this phase. Adequate infrastructure and interfaces stills the highest relevant technological factor. This phase is dedicated to the system testing and users training. The final adjustments to the system are done in this phase.

Go live & support – Again, organizational factors still have more relevance on this phase, while technological factors loose significantly their relevance. Adequate project manager role and strong communication inwards and outwards are the most relevant organizational factors. Regarding technological factors all have a normal relevance in this phase. This phase is dedicated to the system go live. Therefore is important to communicate and involve everyone in this process to achieve success.


5.7 Identification of the Most Critical Work Packages

To be able to identify critical work packages, we have extended the analysis section of PQM in order to deal with more complex project structures involving such packages. To accomplish software project complex structures in the analysis section, we introduced one indicator that we named ‘work package criticality’ indicator.

5.7.1 Work Package Criticality Indicator

We defined work package criticality as “the importance a work package has with regard to the number of relationships between the software project CSF and the tasks that compose that work package”. The calculation of criticality indicator is worked out as described in table 28.

For each work package we sum all the relationships between CSF and the tasks of that work package. As each work package has a different number of tasks, we divide the sum by the total number of tasks of this work package in order to compare the value obtained with the value of other work packages. Table 28. Formal definition of criticality indicator. Rel ij - Relationship between task(i) and CSF(j)

= iprelationsh aexist not does thereif 0

iprelationsh a exists thereif 1Relij

Wp.n - Criticality of work package (n) within phase (p). Numtask is the number of tasks of work package n.

Numtask1 1

.

RelW

∑ ∑= ==

NumTask

i

NumCSFs

jij

np

5.7.2 An Example

In this section we analyze two work packages of the ASAP preparation phase (phase one): project kickoff and quality check work packages. The matrix of table 3 represents the different CSF and the structure of these work packages with the relationship between tasks/activities/work packages and CSF. According to the ASAP (1999) documentation, the purpose of the kickoff work package “is to formally announce to the company the initiation of the SAP project, which includes the overall goals, detailed task plans, and processes. Consultants, steering committee, senior management, project managers from the company and SAP, and any other implementation partners must be involved. The kickoff meeting is focused on the company as a whole, while the project team standards meeting is focused on the project team”. The purpose of the quality check work package is to provide final verification of all prior project planning and deliverables from this phase. All issues regarding scope, project environment, and initial technical setup must be addressed.


For example, by applying the criticality indicator for work package criticality described above we obtain 2.8 for project kickoff and 2.5 for quality check; thus, project kickoff is more critical, which means that more attention should be put in this work package. Table 29 presents the results of count (according to PQM) and criticality indicators to all the work packages of the project preparation phase within the ASAP methodology. If we only focus on the count indicator we see that, for instance, project standards and procedures (W1.2) work package has a bigger number of CSF impacts than technical requirements planning (W1.4) work package. Thus, we could think that the project standards and procedures work package is more critical in project preparation phase than the technical requirements planning work package. However, the analysis of the criticality indicator helps to refine the analysis. Through the calculation of the criticality based in our framework we evidence that technical requirements planning is a more critical work package. Thus, managers should put more efforts in the realization of this work package in order to be successful.

Figure 21 represents graphically the count and the criticality indicator. A position of a work package in the graphic higher and right means this work package is more critical. We would like to emphasize that this analysis does not mean that the other work packages are not important; we only evidence the importance of the work packages based in a CSF point of view and relative to the number of tasks in each work package. In the next section, we analyze all the phases of ASAP methodology and the criticality of all its work packages.

W1.1W1.2

W1.3 W1.4

W1.5

0

5

10

15

20

0 1 2 3 4 5

Work Package Criticality

Num

ber o

f CSF

s im

pact

Figure 21. Most critical work packages in project preparation phase.

5.7.3 Critical Work Packages per Phase

We applied the procedure described in section 7.1 to all the phases of ASAP methodology and the result is presented in table 29.


Table 29. Work packages criticality by ASAP phase.

Phase Wkp Work packages Count Wp Stens

W1.1 Initial project planning Org 19 4.7 9 W1.2 Project standards and procedures Org 19 3.4 7 W1.3 Project kick-off Org 7 3 6 W1.4 Technical requirements planning Tec 8 3.9 7

Preparation

W1.5 Quality check Org 4 2.5 5 W2.1 Blueprint phase Org 12 4.4 8 W2.2 Organizational change management Org 14 3.7 7 W2.3 Project team training business blueprint phase Org 6 2.8 5 W2.4 Establish development system environment Tec 12 1.9 4 W2.5 Define the business organization structure Org 10 4.5 9 W2.6 Business requirements definition Org 19 3.7 7

Business Blueprint

W2.7 Quality check Org 4 2.5 5 W3.1 Project management realization phase Org 17 4.2 8 W3.2 Organization change management process Org 6 2.7 5 W3.3 Conduct project team training Org 6 2.4 5 W3.4 Baseline configuration and confirmation Tec 10 2.2 4 W3.5 System management Tec 7 2 4 W3.6 Perform the final configuration and confirmation Tec 9 1.8 4 W3.7 Perform ABAP/4 development Tec 0 0 0 W3.8 Develop conversion programs Tec 7 2 4 W3.9 Develop application interface programs Tec 8 2.7 5 W3.10 Develop enhancements Tec 4 0.7 2 W3.11 Create reports Tec 10 2.3 5 W3.12 Create forms Tec 8 2.6 5 W3.13 Establish authorization concept Tec 5 1.2 2 W3.14 Establish archiving management Tec 6 2.8 5 W3.15 Prepare end-user documentation and training material Org 8 2.8 5 W3.16 Final integration test Tec 7 2.6 5

Realization

W3.17 Quality check Org 4 2.5 5 W4.1 Project management of the final preparation phase Org 13 4.5 9 W4.2 End-user training Org 3 2.8 5 W4.3 System management Tec 6 2.4 5 W4.4 Detailed project planning Org 13 2.8 5 W4.5 Cutover to the production system Tec 10 2.5 5

Final Preparation

W4.6 Quality check Org 4 2.5 5 W5.1 Production support Org 11 4.9 9 Go Live W5.2 Project end Org 10 3.6 7

In the Project Preparation Phase the most critical work packages are: initial project planning,

project standards and procedures, and technical requirements. The outcomes of these work packages are the baseline guides for the overall project. The purpose of the initial project planning work package is to allow the start detailed planning for the project. The key elements of the project are defined and the project scope is defined, the project plan is prepared.

In the Business Blueprint Phase the most critical work packages are: blueprint phase preparation, organizational change management, and the definition of the business requirements and organization structure. The purpose of this phase is to primarily prepare the business blueprint


document for the SAP implementation (Kale 2000) which details the TO BE processes, including the written and pictorial representations of the organization’s future structure and business processes. The purpose of the change management work package is to address the organizational and human resource factors that impact the SAP implementation. It includes a series of change processes that allow the change team to manage organizational risk, accelerate SAP implementation and optimize organizational processes.

In the Realization Phase the most critical work packages are: project management realization phase, prepare end-user documentation and training material, establishing archiving management, sustaining the organization change management process, and development of interface application programs. The purpose of change management work package is to conduct periodic project team and organizational risk assessments and to expand the change communications, knowledge transfer, sponsorship and development processes that were initiated during the business blueprint phase. Then, we have training both project team and prepare the training of end-users. The purpose of the project management realization phase is to establish a cycle of project management activities to ensure that the implementation project is on schedule.

In the Final Preparation Phase the most critical work packages are: project management of the final preparation phase, end-user training and detailed project planning. The purpose of project management is to perform the established cycle of project management activities in order to keep the implementation project on target. Next come training end users and detailed project planning work packages. The purpose of the detailed project planning is to identify issues that impact the initial plan for production support and cutover prepared in phase 3, and to adapt the plan accordingly (ASAP 1999).

In the Go Live Phase the two critical work packages that composed this phase have almost the same criticality. The purpose of production support work package is to provide support to users and maintain optimal system performance. Project end work package is to officially close the project. Any open issues still pending resolution are reviewed and closed.

5.7.4 Overall SAP Work Packages Criticality

We also categorized the work packages into organizational and technological work packages (see table 29). Organizational work packages are related with concerns like organizational structure and culture, business processes and project management. Technological work packages focus on aspects related to the particular ERP product in consideration and on other related technical aspects, such as hardware and base software needs. Next, we converted the criticality scores of table 6 into a normative scale of ten scores (‘stens’). In such scale, range 1-3 ranks as low criticality, range 4-7 ranks as normal criticality and range 8-10 ranks as high criticality. In general the analysis (see figure 22) makes objectively evident that the most critical work packages are those related to organizational aspects.


High

Normal

Low

High

Normal

Low

Criticality

Organizational TechnologicalOrganizational Technological

W 2.4, W 3.4, W 3.5, W 3.8, W 3.6W 2.4, W 3.4, W 3.5, W 3.8, W 3.6

W 2.1, W 3.1

W 1.1, W 2.5, W 5.1

W 1.2, W 2.2, W 2.6, W 5.2

W2.3, W3.15, W4.2, W3.2, W4.4, W 1.5,W2.7, W3.17, W4.6, W3.3

W 3.14, W3.9, W 3.11, W 3.12, W 3.16, W 4.3, W 4.5

W 1.4

W 3.10, W 3.13

W 3.70

4

8

0 3

Figure 22. Analysis of organizational versus technological SAP work packages.

Figure 22 shows how all the organizational work packages have normal and high levels of criticality, while technological work packages have low and normal levels, with work package W1.4 (technical requirements planning) which purpose is to identify the technical infrastructure needed to implement the SAP system and to clarify customer’s expectations having the highest relevance score.

The reason for these results lies in the fact that CSF are mostly related to an organizational perspective rather than a technological one (Esteves and Pastor 2001). This result is very important for managers. In this respect, ERP implementations are not different from other complex IS projects, for which Felix and Harrison (1984, p. 161) already said: “technical problems can usually be detected and repaired before the system is put in jeopardy. The cost may be high in terms of either budget or schedule, but the repair can be made. Organizational and personnel problems often cannot be redressed, and continue to jeopardize the success of the system itself”.


Figure 23 shows the overall criticality analysis along the ASAP phases. From the figure we see that the first two phases, Project Preparation and Business Blueprint, together with the last phase Go Live and Support, are the ones with more criticality.

W 5.1

W 5.2

W 4.2, W 4.3, W 4.4, W 4.5, W 4.6

W 4.1

W 3.7

W 3.4, W 3.5, W 3.6, W 3.8

W 3.2, W 3.3, W 3.9, W 3.11, W 3.12, W 3.14, W 3.15, W

3.16, W 3.17,

W 3.1

W 2.4, W2.7

W 2.3

W 2.2, W2.6

W2.5

W 1.5

W 1.3

W 1.2, W 1.4

W 1.1

W 3.10, W 3.13

0

4

8

12

0 1 2 3 4 5

W2.

Figure 23. Criticality analysis along SAP implementation phases.

In the initial phases is when most of strategic decisions are made and the business model is defined. The last phase represents the last effort to customize the SAP system according to the need of the organization. Obviously, project managers should put more attention and effort in these phases in order to achieve a successful SAP implementation project.


5.8 Conclusions

This chapter provides a schema of these CSF relevance along the phases of the ASAP methodology and a most relevant CSF model proposal. The CSF relevance schema was developed through the application of PQM method, based on the CSF unified model for ERP implementation projects and the ASAP documentation. It is important to point out that organizational factors have more relevance along the ERP implementation project phases. Once again, there is the need to focus more on people and process than technology itself. In our opinion, the proposed relevance findings are useful because:

• We have a clear orientation of the relevance of each CSF along the SAP implementation project;

• With this knowledge, we can better control and monitor of SAP implementation projects, and drive them towards success, or high levels of satisfaction.

Furthermore, we propose an extension to the PQM method in order to analyze the most critical

processes in complex project structures such as a SAP implementation project. We proposed a new indicator for processes criticality analysis and then we applied it to the ASAP implementation methodology structure in order to define its most critical processes. Although we have applied the analysis extension proposed in this paper to a SAP implementation project, it can be applied to other ERP systems or other software projects that have a complex software project structure, as the one explained in this paper.

The analysis described here for work packages criticality can also be applied to activities, since they have the same dependence of tasks. In that sense, activity criticality analysis can be calculated using the same procedure of work packages. The criticality indicators described in this study are not intended to substitute the PQM analysis; instead, they attempt to give more analytical expression to the work done by the project teams when they define the most important tasks based in a CSF approach. The analysis of this indicator:

Will help managers to plot and prioritize for attention on those most critical components, Will help in the better allocation of organization resources , Will help to avoid 'bottlenecks' in software implementation projects and, Will help the development of new ERP implementation methodologies.

5.9 References

Anderson, S. 1995. “A Framework for assessing cost management system changes: The Case of Activity-based Costing Implementation at General Motors, 1986-1993”, Journal of Management Accounting Research, 7, pp. 1-51.

ASAP 1999. “Accelerated SAP Methodology (ASAP) Roadmap”, ASAP documentation, version 4.5, SAP AG company.

Association of Project Management (UK) (2000). APMP syllabus, abridged glossary of project management terms, January 2000.


Bergamaschi S., Reinhard N. 2000. “Implementation of Enterprise Systems”, ENANPAD 2000 - XXIV Encontro da Associação Nacional dos Programas de Pós-Graduação em Administração.

Blick G., Gulledge T., Sommer R. 2000. “Defining Business Process Requirements for Large-Scale Public Sector ERP implementations: A Case Study”, European Conference on Information Systems, Wien (Austria).

Cooper R., Zmud R. 1990. “Information Technology Implementation Research: A Technological Diffusion Approach”, Management Science, 36(2), pp. 123-139.

Duncan W. 1996. “A guide to the Project Management Body of Knowledge”, Project Management Institute (PMI) Standards Committee, 1996.

Esteves J., Jorge J. 2001. “Comparative Analysis of SAP Implementation Methodologies” (in portuguese), 2º. Conference of Associação Portuguesa de sistemas de informação (APSI), Evora (Portugal).

Fairley R. 1999. “Managing by the Numbers: A tutorial on Quantitative Measurement and Control of Software Projects”, International Conference on Software Engineering (ICSE), pp. 677-678.

Felix R., Harrison W. 1984. “Project Management Considerations for Distributed Processing Applications”, MISQ Quarterly, 8(3), September 1984, pp. 161-170.

IEEE 1996. “IEEE/EIA Standard – Industry Implementation of ISO/IEC 12207: 1995, Standard for Information Technology – Software Lifecycle Processes”, IEEE Computer Society, 1996.

IEEE 1998. “IEEE standard for Software Project Management Plans”, IEEE Std 1058-1998, IEEE Computer Society, December 1998.

Glaser B., Strauss A. 1967. “The Discovery of Grounded Theory: Strategies for Qualitative Research”, first edition, Aldine.

Hardaker M., Ward B. 1987. “Getting Things done: How to Make a Team Work”, Harvard Business Review, Nov/Dec 1987, pp. 112-119.

Kale V. 2000. “Implementing SAP R/3: The Guide for Business and Technology Managers”, Sams Publishing.

Khan A. 2002. “Implementing SAP: with an ASAP methodology focus”, Writers Club Press, New York (USA).

Magal S., Carr H., Watson H. 1988. “Critical Success Factors for Information Centers”, MIS Quarterly, pp. 413-424.

Nah F., Lau J., Kuang J. 2001. “Critical Factors for Successful Implementation of Enterprise Systems”, Business Process Management Journal, 7(3), pp. 285-296.

Parr A., Shanks G. 2000. “A Model of ERP Project Implementation”, Journal of Information Technology, 15(4), pp. 289-304.

Pinto, J., & Prescott, J. 1988. “Variations in Critical Success Factors Over the Stages in the Project Lifecycle”, Journal of Management, 14(1), pp. 5-18.

Pinto J., Slevin D. 1987. “Critical Factors in Successful Project Implementation”, IEEE Transactions on Engineering Management, vol. EM-34, nº. 1, February 1987, pp. 22-27.

Pinto J., Slevin D. 1988. “Critical success factors across the project lifecycle”, Project Management Journal, 19 (3), pp. 67–75.

Rockart J. 1979. “Chief executives define their own information needs”, Harvard Business Review, March - April 1979.


Savolainen V. 1991. “Definition of favourable atmosphere for effective IT decisions”, Sol HG. and Vecsenyi J. (eds.), Environments for supporting decision processes, Elsevier Science Publishers B.V. (North Holland), pp. 129-140.

Scott J., Vessey I. 2002. “Managing Risks in Enterprise Systems Implementations”, Communications of the ACM, 45(4), pp. 74-81.

Shenhar A., Wideman R. 2000. “Optimizing Project Success by Matching PM Style with Project Type”, Project Management Forum.

Somers T., Nelson K. 2001. “The Impact of Critical Success Factors across the Stages of Enterprise Resource Planning Implementations”, 34th Hawaii International Conference on System Sciences.

Ward B. 1990. “Planning for Profit”, chapter 5, in “Managing Information Systems for Profit”, edited by T. J. Lincoln, John Wiles & Sons Ltd.

Yin R. 1994. “Case Study Research, Design and Methods”, 2nd ed., Sage Publications.

Chapter 6 – Pilot Case Study 147

Chapter 6

Pilot Case Study

Chapter Summary: This chapter describes a pilot case study of an ERP implementation in a PortugueseSME. We focused on the identification of organizational factors that affected the ERPimplementation project. The pilot case study helped to test the research framework and thepreparation of the in-depth case study, especially the interview questions. As outcomes, there was apreliminary list of findings regarding CSF management, and a grounded theory ERPimplementation model. We also analyze the ERP implementation project from a national culturalperspective using Geert Hofstede’s dimensions. Our findings enforce that some of the problems inERP implementation projects are not of technological nature but may be attributed to organizational factors while some issues are related to national culture.


Thesis Introduction


Research Design






CSFsIdentification


CSFsIdentification




ERP Context

6


6.1 Introduction

In recent years, it has been proved that Small and Midsized Enterprises (SME) strongly contribute to national economies. SME constitute around 95 percent of enterprises and account for up to 70 percent of employment in most countries around the world. “Like the large enterprises within their markets, SME are impacted by the rapidly changing marketplace and their own ability to respond to these changes. ERP provide the platform for SME address the competitive demands for the rapidly changing marketplace and be successful in terms of: improved customer relations and management, improved cycle time, improved quality, increased sales volumes, improved margins, reduced product development time, reduced manpower for routine operations, improved market share” (Kale 2000, p. 72).

The adoption of ERP systems is now reaching SME, bringing up problems in ERP implementation projects which are specific to this type of companies. As Kale (2000) acknowledges, since SME have modest IT/IS resources and budgets they expect to benefit largely from implementing off-the-shelf application products like ERP systems. They do not have the depth experience and a constant availability of adequate expertise to be able to handle the in-house development of an enterprise wide system.

This chapter reports the results of a pilot case study carried out in a Portuguese SME that implemented the SAP R/3 system in 1998 by following a big-bang implementation approach. The big-bang approach is characterized by the installation and the go live of all implemented ERP modules at the same time. The interpretive paradigm adopted in our research reflects our aim for understanding the phenomenon of ERP implementation in a SME within the organizational and national contexts where it occurs. The paper is structured as follows. First, we present the literature review on ERP. Then, we describe the case study background. Next, we present the research methodology. Subsequently, we describe the findings.


As we believe that the understanding of ERP implementation projects cannot be achieved without considering the organizational context where they occur, the chosen research method was the in-depth case study method (Yin 1994). In order to identify the organizational factors that affect an ERP implementation in a SME we opted for an interpretive paradigm research approach (see chapter 3 – Research Design).

6.2.1 Data Collection

The project manager of the ERP implementation project was initially contacted in order to accept to collaborate in this research project and to permit the study to be carried out. After permission has been obtained, the project manager granted access to several documents produced during the project. Later, he was asked to be visited and interviewed as well as other persons that played relevant roles during the ERP implementation project. Our first task was to analyze the documentation created during the ERP implementation project that was made available by the project manager. The project documentation helped to understand the project background and to


prepare the questions for the interviews. The project documentation was analyzed following Grounded Theory (GT) method procedures (see below). The most used technique for data collection was semi-structured interviews. Following the contact with key informants in the company, interview schedules were agreed upon. Interviews were tape recorded and transcribed to ensure accuracy of written data, and to minimize researchers’ bias. Initially, three interviews were made respectively with the project manager, another member of the project team and a key-user. Then, we interviewed the remainder members of the project team. The interviews lasted approximately one hour with the exception of the project manager interview that lasted around two hours. Immediately after each interview, field notes commonly known as memos in GT were written. A memo is “the researcher’s record of analysis, thoughts, interpretations, questions, and directions for further data collection” (Strauss and Corbin 1998, p. 110). Data from interviews were then triangulated with the documentation so far accumulated.

6.2.2 Data Analysis

In order to build theory from this case study, we adopted the Grounded Theory (GT) method. GT is a general method developed by Glaser and Strauss (1967) for building theories that are grounded in data systematically gathered and analyzed (Glaser and Strauss 1967). A theory is defined by Strauss and Corbin (1998, p. 22) as “a set of well-developed categories (e.g. themes, concepts) that are systematically interrelated through statements of relationship to form a theoretical framework that explains some relevant social, psychological, educational, nursing or other phenomenon”.

Strauss and Corbin (1998, p. 23) explain that by using GT “a theory is inductively derived from the study of the phenomenon it represents. That is, it is discovered, developed, and provisionally verified through systematic data collection, analysis, and theory stand in reciprocal relationship with each other. One does not begin with a theory, and then prove it. Rather, one begins with an area of study and what is relevant to that area is allowed to emerge”. The GT method has three main phases: open coding, axial coding, and selective coding. Next, we describe in detail each one of these phases.

6.2.2.1 Open Coding

Open coding is the analytic process through which concepts are identified and their properties and dimensions are discovered in data. Regarding our study, we first analyzed the literature on ERP systems and the ERP project documentation which helped to develop a preliminary list of categories. One of the researchers started coding as soon as transcripts from the first interviews became available. Then, the other two researchers analyzed the coding process. Disagreements on coding were settled through consultation between researchers and in some cases, with additional input from interviewees and documentation to the ERP project or searched from the net.

The coding process of all interviews and project documentation allowed major themes/categories to emerge. We started coding line by line with a priori list of categories that resonate with prior literature (Eisenhardt 1989). We used as priori categories the list of critical success factors for ERP implementations (see chapter 4 – Unified Model of Critical Success Factors) and the national culture dimensions provided by Hofstede (1991). These categories


facilitated but not constrained the data analysis since the categories were validated with the data gathered. Sub-categories for these categories emerged from the data and they provided a deeper explanation of the management and relevance of critical success factors in ERP implementations.

During the open coding phase we wrote code notes (another form of memos) to explain how some concepts emerged. Since data collection and data analysis form an iterative process in GT method, analysis of the first data helped to improve the next interviews and to focus and to obtain more information about new ideas that were raised in early interviews.

6.2.2.2 Axial Coding

Axial coding is the process of relating codes (categories and properties) to each other, via a combination of inductive and deductive thinking. Rather than looking for any kind of relations, grounded theorists emphasize causal relationships, and fit things into a basic paradigm of generic relationships, denominated paradigm model. The paradigm model is “an analytical tool devised to help analysts integrate structure with process” (Strauss and Corbin 1998, p. 123). The paradigm model consists of the following elements:

• The causal conditions are “those which lead to the occurrence or development of a phenomenon” (Strauss and Corbin 1998, p. 100). Causal conditions are also described as antecedents conditions (Dey 1999).

• The intervening conditions are “the broad and general conditions bearing upon action/ interactional strategies” (Strauss and Corbin 1998, 103) or more generally as “the broader structural context”.

• The contextual conditions are “the specific set of properties that pertain to a phenomenon; that is, the location of events or incidents pertaining to a phenomenon along a dimensional range. Context represents the particular set of conditions within which the action/interactional strategies are taken” (Strauss and Corbin 1998, p. 96).

• Action/interaction strategies refers to the ways in which the phenomenon is managed, handled, carried out and responded to, in a certain context and under specific conditions.

• Consequences are the outcomes of the phenomenon. As Dey (1999) points out, the definition of intervening conditions in Strauss and Corbin (1998)

is more commonly associated to the notion of context rather than with the contextual conditions. In this study we follow the recommendation from Dey (1999) in that contextual conditions represent the broad and general conditions, and intervening conditions represent the specific set of properties that pertain to a phenomenon.

6.2.2.3 Selective Coding

Selective coding is the process of choosing one category to be the core category, and relating all other categories to that category. The essential idea is to develop a single storyline around which everything else is draped. To ensure credibility and validity of the GT process, we asked participants and some colleagues for their feedback in some versions of the GT report. Their suggestions were incorporated on the final report. The findings of the GT application are described below.


6.3 Case Study Context

PhotoPics S.A. (fictitious name) is the Portuguese subsidiary of the PhotoPics multinational company. The PhotoPics Group was created in Germany around 1849 to develop lenses and microscopes. The company started in Portugal in 1973 and the Portuguese unit is now the main one of the PhotoPics Group worldwide. It has a total of 660 employees, most of them wage earners with approximately 100 salaried employers. Table 30 describes the different actions taken to improve information technology infrastructure in Photopics. Table 30. Information technology evolution in Photopics Period Actions Until 1997 - Only dumb terminals connected through a dedicated infrastructure.

- Comet Top software package to support logistics, production planning, and accounting.- Only the administrator and the financial director used PCs. - No internet connection.

Beginning 1997 - Analysis of Comet Top upgrade or adoption of an ERP system due to Y2K and Euro. First quarter 1997 - Decision to adopt SAP system. 1997 - Implementation of a computer network.

- Upgrade of Comet Top to a Unix version until SAP go live. - Training of users on using PCs (average age of users was 40 years old).

6.3.1 ERP Implementation Phases

PhotoPics followed a typical ERP implementation lifecycle (see table 31) with a big-bang approach. The project goal was the implementation of SAP R/3 system, version 3.1H with the main SAP modules. An Overview of SAP system is provided in appendix A. The number of expected end-users was 30 to 40. Initially, it was estimated that no be-spoke development would be made and that only enhancements to forms and reports would be tailored. Table 31. ERP implementation phases in Photopics Phase Description Planning This was the basis for the entire project. The goal of this phase was to detail the project

definition and its functional needs. The project structure was defined. This phase was arduous due to three main aspects: the definition of all processes that attempted to be implemented in the new system, contact with all the process stakeholders, and the difficulty to obtain information.

Design The goal of this phase was to produce the technical specification of how to implement the chosen solution and the beginning of the parameterization and the preparation of a prototype that allowed the demonstration of the system working for each planned situation. This phase was felt as fundamental for the system comprehension since the internal project team took its first contact with the SAP system.

Realization The goal of this phase was to obtain the configuration of the SAP system according to the design, the development of some complementary programs that served as interfaces to SAP, and the creation of training manuals and final tests.

Go live & Support

The goal of this phase was to put the new system at work. The go-live phase was started a month behind schedule given some changes in the scope of the project. The expressions “the company will stop” or “it will not work” were in the mind of everyone, but everything worked perfectly. At the end of this phase an analysis of the general difficulties of the SAP implementation project was made.


6.4 A Grounded Model of ERP Implementations

In this section we describe the specific paradigm model (see figure 24) that we developed by using GT from the data collected from our case study.

Euro conversionY2K problems

Adoption of SAP system

Inadequate infrastructure

GlobalizationOrganizational structure

Organizational culture

Project managerselection

Lack of computer literacy

Inadequate legacy systems

ERPImplementation

TechnologicalCSFs

OrganizationalCSFs

TacticalCSFs

StrategicCSFs

Consultingcompanyselection

ERP Market

Lack of legacysystem

expertise

Newhardware

infrastructure

NationalCulture

Organizational• Business process reengineering• Change of mentality• Keep project team members

Technological• New ERP projects• Continuous system improvement• Internal ERP knowledge improvement

Need for systems integration

Organization structure changes

Inadequate business processes

Need for a better IS architecture

Legacy systems obsolescence

Figure 24. An exploratory model for ERP implementation projects.

6.4.1 Phenomenon

Strauss and Corbin (1998, p. 101) stated that phenomena are “the central ideas in data represented as concepts”. According to their account, the purpose behind naming phenomena is to enable researchers to group similar events, happenings, and objects under a common heading or classification. The phenomenon in the paradigm model is represented by the central category


(sometimes called core category), which represents the main theme of the research. The phenomenon addressed in this study is the implementation of an ERP system in a SME. ERP implementation at PhotoPics was considered to be a successful one.

6.4.2 Causal Conditions

The circumstances that led to the ERP implementation at PhotoPics were: the need for systems integration worldwide at PhotoPics Group; the need for a better IS architecture at PhotoPics SA; legacy systems obsolescence; most of the business processes were inadequate and they needed a strong reengineering effort; and the Euro conversion and Y2K problems. In the first quarter of 1997 the company selected the SAP R/3 system. The main reason was that this software seemed to be the best answer to the company needs. The fact that SAP system is a German software certainly transmitted security to a German company and also contributed to the decision.

6.4.3 Environmental Context

By the time ERP implementation at PhotoPics took place, many other companies, including SME, were abandoning their legacy systems and migrating to ERP systems. Again, problems related with the Y2K and the unavoidable changes in IT systems related to the forthcoming adoption of a single currency by most EU countries were viewed as strong justifications for carrying out deep changes in IT systems. The parent company decided to integrate the information of all its subsidiary companies worldwide. Therefore, the company decided to unify information and to have a better control of its subsidiary organizations such as the Portuguese PhotoPics. The parent company decided to adopt SAP R/3 as the common ERP system worldwide. The parent company kept the ownership of the project implementation, but each local organization had total freedom in the implementation process. At that time ERP vendors started approaching the SME market and they beginning to offer ERP solutions adapted to SME.

6.4.3.1 National Culture

National culture has been defined as a set of core values that shapes the behaviour of individuals as well as the whole society (Adler 1997). Hofstede (2001) defines national culture as “the collective programming of the mind which distinguishes the inhabitants of one country from another. Basic values and beliefs are acquired early in life, though socialization and education and this was inhabitants of a country come to share certain basic beliefs and assumptions and the tendency to prefer certain states of affairs over others”.

Terpstra and David (1991) showed that organizational cultures are influenced by national culture and the greater the differences between countries, the greater the difference between organizations’ attitudes and practices (Datta and Puia 1995).

Robey and Rodriguez- Diaz (1989) mention that culture may impede IT implementation efforts because the differences in the way IT is interpreted and given meaning. Harvey (1997) and Krumbholz et al. (2000) mention in their cross-national studies of IT implementations that national culture impacts information systems design in myriads of way. Based on Hofstede’s (1991) study of national cultures and organizations, we analyzed the findings of PhotoPics case study from three


dimensions: power distance, uncertainty avoidance and individualism-collectivism. Table 32 describes the dimensions and Hosftede’s scores for Portugal. Table 32. Cultural dimensions suggested by Hofstede (1991) with score and mean for Portugal. Dimension Description Score Mean Power distance Power distance is the degree to which members of a society accept as

legitimate that power in institutions and organizations is unequally distributed. Higher power distance scores indicate an order of inequalities, special privileges for those of higher status, superiors consider subordinates as a different kind of person.

63 51

Uncertainty avoidance

Uncertainty avoidance is the degree to which members of a society feel uncomfortable with uncertainty and ambiguity, which leads them to support beliefs that promise certainty and to maintain institutions that protect conformity.

104 64

Individualism/ Collectivism

Hofstede (1991) proposes a single dimensional structure called individualism-collectivism, where those cultures that emphasize the autonomy of the person are grouped under individualism, while those cultures whose most important values place emphasis on the dependency of the individual with respect to groups are clustered under collectivism.

27 51

Most of the criticisms to Hofstede (1991) work are related to the problem of nation state

concept (Myers and Tan 2002). Although we acknowledge that this is an important issue in some countries, it is less relevant in the Portuguese case since Portugal is a nation for more than nine centuries and there is a strong notion of the nation state entity. Next, we relate and discuss each national culture dimension with the PhotoPics ERP implementation project.

6.4.3.2 Power Distance

The score of Portugal is 63 (mean 51), which means that Portugal has a high power distance score. High power distance inhibits sharing of information since information is equated with knowledge and power. This is not imply that people do not share information, but that more time and energy must be devoted to accepting information sharing as an operating premise (Randolph and Sashkin 2002). The political and culture issues emerged as important factors in the organizational environment in our case study of PhotoPics (see context section above). In this case, we emphasize the issue of losing organizational power and influence. Most of PhotoPics managers had a long career within the organization and they controlled their departments with authority like ‘feuds’ as one of the interviewees mentioned. Each department director filtered the information for the organization owner and the one shared among managers. Conflicts among senior managers arose as they tried to dominate and impose their view in the ERP project, since most of them were aware that the results of the ERP project could influence their future career. Since managers were not happy with the project, they passed the negative image to their subordinates, which caused more general disagreement with the project.


6.4.3.3 Uncertainty Avoidance

According to Hofstede (1991), the Portuguese society has a high level of uncertainty avoidance, scored 104 (mean 64). People scoring high on this dimension attempt to avoid uncertainty in all forms. When situations are unstructured, unclear, or unpredictable, individuals from high UA societies such as Portugal and Spain “could be presumed to provide socially acceptable responses that are condoned by a large percentage of the population and thus serve to reduce personal risk, while being more likely to resist innovative ideas. In the case of PhotoPics the uncertainty was very high during the whole project. Uncertainty was mainly due to the people being afraid of losing power (top and middle management) and lower levels, where people were afraid of losing their jobs because of organization bankruptcy or the decision to reduce the number of employees. This uncertainty led some managers to express their disagreement during the project and to create difficulties to the implementation process by taking attitudes such as: omitting information; avoiding participation in project tasks; failing to attend to important meetings; delaying to make decisions in order to delay the whole ERP project. There was also a lot of uncertainty among internal project team members since it was the first time they implemented an ERP system.

6.4.3.4 Individualism-Collectivism

According to Hofstede (1991), the Portuguese society is a collectivist society. It is expect that work in teams would be very well acceptable. However, other issues such as low tolerance for ambiguous situations and the preference for formal rules among managers and workers typically conflicts with the required roles of team members and managers (Nicholls et al. 1999). PhotoPics workers had been doing their tasks in the same way during many years and they were not happy to change their way of working. One of the reasons for this disappointment was their age. Most employees were over 50 year old with more than 20 years working at PhotoPics. Some of them were also expecting retirement (the legal age is 65 years). The work relationships were in some sense like being part of a family. Hofstede (1991) states for this case that the relationship between owner and employee is viewed in a moral perspective, and is like a familiar relationship were both have obligations: protection in exchange of loyalty. Most of the employees of PhotoPics doubted about the real intentions from the new top management with the introduction of this new expensive IT system. There also was a notorious loss of trust on their managers that led most employees to start showing indifference to the SAP project.

6.4.4 Organizational Context

The organizational culture of PhotoPics is characterized as a bureaucratic culture. According to Wallach (1983), bureaucratic cultures have clear lines of responsibility and authority, work is highly organized, compartmentalized and systematic. The information and authority flows are hierarchical and based on control and power. Overall, bureaucratic companies tend to be mature, stable and relatively cautious.

Before the ERP implementation project started, the administration decided to recruit new members, with academic education and proved skills and experience in their field. At that moment,


PhotoPics had a conservative organizational culture with power and influences concentrated in a few members with long careers within the organization. Almost all the senior staff had no academic education and their whole career had been made within the organization. The channels of power and communication were quite complex. Most of the business processes were complex and inefficient. Technology and innovation were associated with costs and troubles. Political factors had a strong impact on this project. The interests of stakeholders within the organization were challenged as senior and middle level managers lost power and influence. Many employees feared losing their jobs or that such an expensive project could originate the organization’s rupture. They also feared an increase of expectations regarding their efficiency. Some managers intentionally concealed information about their intentions with the SAP system to team members, some managers disseminated false information in attempts to discredit the ERP implementation project, while others avoided participating in the project. Top executives faced an internal conflict as they were being forced to carry out changes that they felt that could be against their interest. Conflicts among senior managers arose as they tried to dominate and impose their view in the ERP project, since most of them were aware that the results of the ERP project could influence their future career within the organization.

6.4.5 Information Technology Context

The parent company realized that existing systems did not support its strategy. PhotoPics IT systems were quite old, its IT infrastructure was quite rudimentary, and its personnel had a low level of computer competences (see case context section).

6.4.6 Intervening Conditions

6.4.6.1 Project manager Selection

Since adequate project manager role is one the ERP critical success factor for ERP implementation projects, we describe this aspect in the next section – actions/interaction strategies.

6.4.6.2 Consulting Company selection

Several consultants participated in the SAP implementation at PhotoPics. The main consultants involved were from one of the five bigger consulting companies in the world. Consultants selected by the parent company were from another consulting company. The consultant selection made by the Portuguese branch of PhotoPics was due to: SAP recommendation, the geographic location, and because the PhotoPics financial auditors knew the consulting company. At the time of the implementation project this consulting company lacked senior personnel in the SAP implementation area, a fact that was then unknown to PhotoPics.


6.4.7 Action/ Interaction Strategies

In the Action/interaction strategies we used as a priori categories the CSF identified in chapter 4 – Unified of Critical Success Factors. Next, we describe the findings according to each CSF categorized by organizational and technological perspectives.

6.4.7.1 Organizational Perspective


Top management support and commitment were critical to achieve success in the project. Top managers were always available to discuss doubts and trouble-shooting and they made prompt decision-making in order to avoid bottlenecks. This commitment was vital for disseminating the project to the whole organization and especially for dealing with opponents to the ERP project. It was the organization CEO who played the role of project sponsor. According to most interviewees he was the person that drove forward the ERP project. Another important aspect is that there was not an official steering committee in the project. This is a SME and the CEO and the project manager had frequent meetings with senior managers and they were involved in all the main critical decisions regarding the project.

Effective organizational change management

The organization started changing its processes during the ERP implementation. Probably, due to a lack of experience in change management of the project manager and the consultants, there wasn’t a formal organizational change plan. The organizational change affected all levels and aspects such as organizational structure and culture. Probably the most important change was the creation of a logistics department that took over logistics functions so far carried by the financial department.

The project manager mentioned that organizational change procedures should exist, since several job descriptions were changed and/or eliminated and in some cases need for training could have been predicted. In most cases that aspect was analyzed a posteriori. The project manager believed that an organization with a good human resources management should be able of doing a good organizational change program. When employees see their jobs changed and need intensive training, or some functions are emptied, some employees must look for an alternative within the organization or outside. If no precautions are taken, an organization may be confronted with several employees with long years of career that do not want to retire or cannot be pushed to retirement. At that time, the implementation methodology did not incorporate specific procedures for knowledge management or organizational change management. Top management started, facilitated and supported the organizational changes and implied decision-making tasks during the project. Another aspect was that the changes were visible only within a one year span after the system go-live. The organization needed one year to adapt, as well as to understand the new organizational model.


Good project scope management

The project scope definition was quite limited and weak. It focused mainly on the modules and the functions to be implemented. The lack of project strategic vision was a weakness. Since the ERP system was imposed, the project manager and top management did not carry out a strategic analysis of the implementation, especially in what concerns long-term impact. Goals were not properly defined at the beginning. The single goal to be expressed was that ERP implementation would be carried out within a determined period.

Adequate project team composition

The implementation project structure is represented in figure 25. Most of the internal team members were new to the organization. The project team included young university graduates that recently completed their studies. Although these people had no organizational and/or ERP knowledge, they had very good skills and they were very motivated to learn. The purpose of hiring these people was to prepare them for working in the organization and to develop internal knowledge in ERP. This also minimized the risk of expertise turnover.

Photopics AdministratorConsultant Partner

IS DirectorConsultant Project Manager

Production plan directorPP consultant

Photopics Trainee

Logistics plan directorMM consultant

Photopics Trainee

IS plan directorBC consultant






Photopics Trainee


Photopics Trainee


Photopics Trainee


Photopics Trainee



Figure 25. The ERP implementation project structure.

The team members hired specially for the ERP implementation were not familiar with the company. Thus, they could carry out the analysis process from a more neutral position and work on the improvement of business processes without bias. The project team included key-users and chief department directors. The directors were assigned the responsibility of the ERP modules corresponding to their own departments. According to the project manager, the responsibility for implementing each module was assigned to each current chief department director, excepting logistics and IS directors who were new within the organization. At present, they admit that their lack of ERP and business knowledge and the lack of knowledge about organizational culture and politics were weaknesses. The involvement of key-users was also important. This helped them to adapt to the new system and facilitated the parameterization stage (third phase). Key-users brought in operational knowledge and served as enablers of change.


Comprehensive Business Process Reengineering

Team members modelled all the business processes based on interviews to users with the help of key-users. They used classical representation techniques, namely those suggested by SSADM. Although the reengineering of business processes started in the gap analysis their effective change occurred only in the go-live phase. Parallel to the implementation of the ERP system, managers started changing the business processes in the organization and explaining the changes to the organization. The project team admits that this should have been done before the implementation since some processes were totally obsolete or inadequate. The reengineering process was not finished at the time of finishing the case study (beginning of 2003). From them on, during the post-implementation period and using the knowledge that project team has at the present, they continue to reengineer processes by extending processes functionality through the current discovery of functionality in the ERP system.

Adequate project sponsor role

As mentioned before, it was the organization’s CEO who played the role of project sponsor. According to most interviewees he was the person that drove forward the SAP project. The CEO used the implementation project to reengineer the business processes. He also provided all the resources need for the project and he always supported the project manager and project team members in the main implementation tasks and meetings. He was present in all the main events to promote the ERP system within the organization. His organizational position was vital in the decisions that required rapid decision making since most of the other senior managers followed his decisions, sometimes without a total agreement but respecting the decisions. Although he made an informal control of the project he did not define key performance indicators or any kind of measures to evaluate the ERP implementation project. The only used measures were the project being on time, project tasks accomplishment and cost analysis.


The project manager was recruited specifically for the SAP implementation project. He made the connection between the implementers (internal team members and external consultants) and top management. He admits that someone with experience in SAP would have better performed the job, especially at the early stages of the project. The project manager stresses that skills to manage conflicts and people are crucial in a project of this kind. He says that a SAP project is more about managing willingness, expectations and conflicts than about technology.

Mastering foreign languages (German and English) emerged as an important aspect for the project manager. As PhotoPics is owned by a German company, mastering the German language was an important competence for the project manager although that was not considered at selection time. This was fundamental to communicate and share knowledge with the parent company and it contributed to solve many problems and to improve collaboration. In what concerns the English language, the project manager had to review specialized literature on ERP systems, usually published in English.



Users were involved in the project even though some claimed the contrary. Due to their lack of business knowledge, team members interviewed users in the analysis process, and managers approved the processes procedures. In most cases users themselves did the process analysis for their specific processes. Key-users were particularly relevant in this task and during tests. Members of the project team reported that the major problem when involving users was that each user thought his/her opinion was more important and valuable than that of others (see political factors in organizational context section).

Trust between partners

Since the beginning, the project manager created and promoted relationships of cooperation and trust among the stakeholders: the SAP supplier, consultants and the organization senior managers. Initially, there was an excess of trust in the consulting company. But, even after it was realized that the external consultants did not have the expected skills and experience, the relationship between internal and external members was very good along all the implementation phases due to the fact that both recognized their own limitations and mistakes. The relationship with SAP Company was very good, with SAP collaborated in several tasks to solve problems and to help in some decisions. After the Go Live of the system, SAP audited the system to provide more confidence on the system and to the project team.

Dedicated staff and consultants

Most of the project team members were fully dedicated to the ERP implementation project, or at least 80% of their time spent in the project. For most of the new project members it was their first job. According to the project manager, this contributed to increase their dedication and motivation to the project. Although consultants were very dedicated to the project there was a high turnover, especially at the beginning since the consulting moved the senior consultants to other projects and the organization did not accept the proposed new junior consultants. After this period, consultants and project team members established a unified and cohesive project team with strong cooperation among them. The dedication of staff and consultants helped to share knowledge between them and to achieve creative solutions for the problems that arose.

Strong communication inwards and outwards

The communication plan was divided in two types: communication inwards (among team members and between them and top management) and communication outwards (with the rest of the employees). Inwards communication worked very well. A special room was allocated to team members that facilitated knowledge sharing and cooperative work. In what concerns outwards communication, the project team regularly presented newsletters, invitations to participate in promotion events, and an intranet was implemented. However, the interest of employees was minimal.


Project monitoring and control mainly consisted on verifying the accomplishment of the project plan and schedule. With no goals defined at the beginning and with the lack of experience in


project management, there were no project metrics being used. However, project meetings were used to continuously monitor and control the project. There were weekly meetings with project team and monthly meetings with top managers. At the end of each phase there was a meeting with all managers. The estimated duration of the project was not achieved but all the planned tasks were performed.


The consultants proposed a training plan that was accomplished. However project team members complained about their training: training was made at the end of the design phase instead of the end of the planning or at least the beginning of analysis phase; training was very basic and focused in the potential of the ERP, and trainers had little training experience. Therefore, team members developed their own skills based in self-study and self-training during the project. Team members recognized that training should have been done earlier in the project.

In what concerns end-users, the consultants provided the initial training but as soon as team members developed ERP knowledge, they have been the responsible for training. The first step in end-users training was to define a training plan that included basic training in computer use because almost all the users were computer illiterate. The training started early for end-users. This helped to keep them in contact with the system and to start the process of adaptation to ERP. Project manager noted that starting training too early might be a problem because some users tend to forget what they learned which implies continuous reinforcing training courses. On the other hand, late training will bring problems to the go-live phase and extra effort for team members. The optimal solution seems to be training just before they start using the system, and to use an ERP parameterization as close as possible to the final one since this provides a better and quick adaptation to what users will have to deal with after the go-live phase. The training process must be seen as continuous, something that will not finish after the go-live. Nowadays, PhotoPics pays special attention to this aspect. One thing that failed in the training plan was new or changed business domain training, i.e., training that addresses aspects such as what is a production request, a production confirmation sheet, what is process integration, process workflow and so on. The lack of such training affected organizational change. The project manager admits that an ERP training plan must be a mix of technical and organizational training.


Several problems appeared during the ERP project mainly due to project team inexperience and to the political factors described above. Two main issues affected the ERP project: the lack of knowledge about the legacy systems and the difficulties with data conversion. In what concerns the legacy system, there was lack of documentation and there were no people with any knowledge about the legacy systems. Most of the information was obtained via the parent company. The data dealt with by the legacy system was not enough for the new system, or it was not structured according to the new business model. Therefore, there was the need to create several conversion programs and some manual data insertion. With the ERP knowledge acquired meanwhile, the project team admit that there were better data conversion solutions that those adapted in the project. One of the problems was that the parent company imposed a conversion program (from the same vendor of the old legacy system) and this was not a good solution.


Appropriate usage of consultants

External consultants played an important role in the whole project. There was a careful selection of consultants according to their skills. However, the positive expectations regarding the role to be played by consultants soon disappeared as the project started. Some of these consultants abandoned the project as they moved to other consulting companies. Due to the consulting company lack of experts at that moment, most of the substituting consultants were junior consultants with lack of knowledge in ERP projects and in the PhotoPics business. This was unfortunate for PhotoPics, as this situation was not anticipated in the contract agreement. This caused a delay in the project. The positive side of these junior consultants was their motivation and dedication to the project.

As soon as the internal project team felt knowledgeable about ERP, they decided which consultants should remain and what new consultants should be hired. There was a lot of turnover of consultants with some of them changing their participation in the project to a part-time basis. Since the project manager felt quite unconfident with the consulting company, he decided to hire other external consultants to cooperate in specific activities. The role of these ‘third party consultants was crucial to improve the quality of the project and to help the project team to make decisions in aspects about which it lacked knowledge.

Empowered decision-makers

Project team members and the project manager had a total support from the president of the company to make decisions. This helped to avoid project bottlenecks and also to improve the reengineering of business processes. Although there was the need for frequent meetings, the decision making was usually rapid and problems solved promptly. Although some senior managers brought out some problems, the intervention of the president of the organization was essential to solve these issues. Most of these issues were political (see national culture section: power distance dimension). The decision to avoid ERP customization also helped to solve some issues since each time there was a conflict regarding the business processes the solution was to adopt the system functionality.

6.4.7.2 Technological Perspective

Adequate ERP implementation strategy

The organization opted for a big-bang implementation strategy. A big-bang implementation replaces existing systems in a single event at once. It requires an intensive testing phase to check all business processes in detail (Welti 1999, p. 8). In the case of PhotoPics that did not represent a big challenge since the existing systems were not very complex and, as project manager mentioned, it did not make sense to start the logistics module without the financial module; the same applies to the other ERP modules. So, why not to start all modules at the same time? At implementation time there were around 40 users at PhotoPics and from these only 3 to 5 would be using the finance module.

The implementation methodology chosen was the methodology proposed by the consulting company (see case description section for more details). All the activities were planned and carried out according to that methodology. The design phase was considered the most critical and


complex. The project manager stressed that most ERP implementation methodologies take for granted that data are “well behaved”, i.e. that it will be easy to transfer data from the old to the new system and that old data will be adequate to the ERP needs. In most cases this is not true and substantial resources should be allocated to this task.

Avoid ERP customization

The administration and project team had decided that they would follow the business concepts and practices embedded in the “standard” ERP system. Therefore, it would be necessary to change the PhotoPics business processes (see business process reengineering section above). During the to-be and gap analysis a lot of issues arose but, as the project manager mentioned, ERP had standard solutions for these issues that did not require further development. The decision was later recognized as wise as it reduced the project complexity, simplified the parameterization, and reduced the maintenance effort and costs. Furthermore, it later will be easier to upgrade to new ERP versions. So, there was no need to make additional programming, except to extract information from the ERP system in special formats used in PhotoPics. In that case there was the need to create some programs and interfaces.

Adequate ERP version

At he beginning and following advice from the consultants and the vendor the most adequate version for their business requirements was chosen. In this case, they adopted the latest version of SAP at the moment. The project team started with the version 3.1.H and during the production phase they moved to the 3.1.I. This initial upgrade did not bring major problems. They spent 10 days verifying that everything was correct. The project manager mentioned that “there are always some errors that occur but nothing dangerous”. He also mentioned the fact that there was no need for system customization which helped a lot in this task.

Adequate infrastructure and interfaces

The process of adapting the organization infrastructure for the new ERP system started before the project implementation. The decision was to eliminate the legacy system after the go live so there was no need to develop any type of interfaces for legacy systems. Meanwhile, there was the need to create some MSaccess databases to solve some functionality provided by the legacy system while the ERP system was not totally configured. After that period all the old databases were eliminated.

Adequate legacy systems knowledge

The project manager and team members admitted they had a lack of knowledge about the legacy system. There was only a single person in the organization that knew something about the system but his tasks was limited to the installation of new tapes for upgrading system functionality or with information about materials to be loaded. This person collaborated actively in the project and helped to minimize and understand the system by project team members.



The initial testing plan was followed but there was some delays due to problems in the data migration process (see below). Users participated extensively in the testing tasks which helped to practice their training learning and obtain some feedback from them. Their involvement and participation also helped to do some adjustments into the ERP system.

Adequate data migration process

The data migration was early defined and scheduled. A specific tool was used to support data migration, but according to interviewees, this tool complicated the process so it was substituted by ‘batch input’ procedures which facilitated the migration. After the data migration, the validation of the data migrated into the ERP system did not cause too much problems because the amount of data was not much.

6.4.8 Consequences

6.4.8.1 Organizational Consequences

Business process reengineering (BPR) - Although BPR started in the gap analysis, its effective change occurred in the go-live phase (see actions/interaction section for a detailed explanation of the BPR process). The SAP system brought in new business processes and helped in the reengineering of the old ones. As the project manager mentioned, PhotoPics is a manufacturing organization with no unique processes. Therefore, they would not loose competitiveness by adopting SAP best practices. On the contrary, the adoption of practices that SAP provides helped to reengineer the existent business processes and simplified implementation and future maintenance efforts.

Change of mentality - One of the most interesting consequences of this SAP implementation was the induced change of mentality. From the beginning, most of the users disagreed with the implementation of the system but their attitude reversed progressively after the go-live phase. Nowadays, they recognize that SAP is useful, that it has helped to improve the business and they think that more business analysis is still necessary, with managers demanding more people to improve the work. The main reasons for the changeover were: top management commitment, the continuous training and the support of team members. Some users were moved from their old functions while others had intensive training. Now, only a few employees are still not using the system. Some of them were middle managers that, due to their age and education, had difficulties to adapt to the new system. The solution was to train some subordinates of these middle managers that would then help them in the tasks that demand the use of SAP. Nowadays, users are no longer afraid of changes. They are aware that the system is something about continuous improvement process.

Keep team members - In relation to the project team, the young graduates were incorporated into the organization with substantial increase of salaries. This helped to keep and improve the SAP knowledge in the organization and avoid dependency on consultants. A continuous learning process was developed with continuous training in SAP in order to improve SAP internal knowledge.


6.4.8.2 Technological Consequences

According to Hillman and Willis-Brown (2002), the initial success of post-go-live phase depends on three critical steps: housekeeping i.e. organizations must stabilize their systems before implementing other applications; adding functionality and to reengineer necessary processes and, extending and integrating. PhotoPics followed exactly these steps. The first step was to fix all the errors that occurred after the go-live phase. Then, they called SAP to make an audit of the ERP system in order to identify inconsistencies and deficiencies. The stabilization of the ERP system introduced credibility and trust in the system. The second step consisted on correcting some process discrepancies and improved some functionality. The problems related with consultants and their lack of knowledge, led to the development of internal skills by the implementation team that were very useful to implement the system and also to maintain it in the future. At this moment the team has enough SAP knowledge to do most of the work by themselves, using consultants only for specific tasks. Finally, the third step that is currently being carried out consists in the implementation of other SAP modules such as QM and, as a team member refers, on continuously adapting the system to new functionality. This is very important because each day the team learns new things about the system.

6.5 References

Adler N. 1997. “International Dimensions of Organizational Behaviour”, 3rd ed., South Western College Publishing, Cincinnati (USA).

Datta D., Puia G. 1995. “Cross-border Acquisitions: An Examination of the Influence of Strategic and Cultural fit on Shareholder value creation in U.S. acquiring Firms,” Management International Review, 35 (4), pp. 325-336.

Dey I. 1999. “Grounding Grounded Theory: Guidelines for Qualitative Inquiry”, Academic Press. Eisenhardt K. 1989. “Building Theories from Case Study Research”, Academy of Management

Review, 144, pp. 532-550. Glaser B., Strauss A. 1967. “The Discovery of Grounded Theory: Strategies for Qualitative

Research”, first edition, Aldine, 1967. Harvey F. 1997. “National cultural differences in theory and practice: Evaluating Hofstede's

national cultural framework”, Information Technology & People, 10(2), pp. 132-146. Hillman T., Willis-Brown A. 2002. “Extending the Value of ERP”, Industrial Management & Data

Systems, 1021, pp. 35-38. Hofstede G. 1991. “Cultures and Organizations: Software of the Mind”, McGraw-Hill: New York. Hofstede G. 2001. “Culture's Consequences: Comparing Values, Behaviours, Institutions and

Organizations across Nations”, 2nd ed., Thousand Oaks CA. Sage, London (UK). Holland C., Light B., Gibson N. 1999. “A Critical Success Factors Model for Enterprise Resource

Planning Implementation”, European Conference on Information Systems. Kale V. 2000. “Implementing SAP R/3: The guide for business and technology managers”, SAMS

publications, 2000, Indiana, USA. Krumbholz M., Galliers J., Coulianos N., Maiden N. 2000. “Implementing Enterprise Resource

Planning Packages in Different Corporate and National Cultures”, Journal of Information Technology, 25, pp. 267-279.


Myers M., Tan F. 2002. “Beyond Models of National Culture in Information Systems Research”, Journal of Global Information Management, 101, pp. 24-32.

Nicholls C., Lane, H., Brechu M. 1999. “Taking self-managed teams to Mexico”, Academy of Management Executive, 13(3), pp. 15-25.

Randolph W., Sashkin M. 2002. “Can organizational empowerment work in multinational settings?”, Academy of Management Executive, 16 (1), pp. 102-115.

Robey D., Rodriguez-Diaz A. 1989. “The Organizational and Cultural Context of Systems Implementation: Case Experience from Latin America,” Information & Management, 17, pp. 229-239.

Strauss A, Corbin J. 1998. “Basics of Qualitative Research: Grounded Theory Procedures and Techniques”, Sage Publications, Newbury Park, CA.

Terpstra V., David, K. 1991. “The Cultural Environment of International Business”, 3rd ed., Cincinnati (USA), South-Western Publishing.

Wallach E. 1983. “Individuals and Organizations: The Cultural Match”, Training and Development Journal, February, pp. 29-36.

Welti N. 1999. “Successful SAP R/3 Implementation: Practical Management of ERP Projects”, Addison-Wesley.

Yin R. 1994. “Case Study Research: Design and Methods”, Thousands Oaks, Sage, CA.

Chapter 7 – Towards Key Performance Indicators for CSF 167

Chapter 7

Key Performance Indicators for CSF

Chapter Summary: This chapter presents the usage of Goals/Questions/Metrics (GQM) method to developa tentative set of Key Performance Indicators (KPI) for each CSF in order to improve themanagement, control and monitoring of the CSF defined previously. As a result, we propose aGQM plan with different metrics to monitor and control CSF while implementing an ERP system. Due to the extensive number of CSF, we focus on the most frequently cited CSF and the ones wehad some working experience in the past: sustained management support, business process reengineering, training, and user involvement and participation. The idea of this work is not to present an exhaustive list of KPI. Instead, we attempt to present a form to develop these metrics infuture ERP implementation projects and provided the first set of metrics that should be extendedand adapted according to the specific needs of ERP implementation projects. Therefore, a generalframework to develop KPI for the rest of CSF is presented.


Thesis Introduction


Research Design






CSFsIdentification


CSFsIdentification




ERP Context

7


7.1 Introduction

Although CSF have been identified in ERP implementation projects, little has been done in relation to the management and the operationalization of these CSF. Usually, the metrics proposed in the ERP implementation methodologies are related with milestones and costs aspects. This is particularly due to the fact that these ERP methodologies follow the common definition of project success: on time and on budget. Project evaluation is critical to understand, control and monitor the CSF of an ERP implementation project. ERP project success is influenced by a large number of factors, and most of the times it is difficult to measure them objectively.

Due to the high number of CSF, 23, and the constraints of the duration of this doctoral research project, we had to choose a small group of CSF in order to develop a set of KPI for each CSF. The two main criteria to select each CSF were: first, the number of citations on the CSF ERP literature that we presented in table 13 in chapter 4. Second, the previous professional experience of the doctoral student since our idea was not only to rely in the academic literature but also on industry experience to provide a more practical and relevant set of KPI than just a simple academic proposal. Thus, in this chapter we present a set of metrics to control and monitor sustained management support, business process reengineering, training and user involvement and participation in ERP implementation projects in order to help managers to achieve success in their projects.

According to Jurison (1999, p. 28) the purpose of project control is: “to keep the project on course and as close to the plan as possible, to identify problems before they happen and, implement recovery plans before unrecoverable damage is done”. Sandoe et al. (2001, p. 164) pointed out that “having both business and project measures to show progress may be the momentum that keeps the project on track at critical times and keeps the project motivated to meet deadlines”. As a result of this study, we are interested in a small, combined set of metrics to help managers understand the situation of the ERP project.

We tried to collect the KPI using case studies, in particular the pilot case study conducted (see chapter 6 - Pilot Case Study). However, we discovered that in the Photopics case there was no definition of KPI, and the control and monitoring of the project was based in project duration, costs, requirements achieved and a set of simple metrics for project performance. Thus, we decided to use the Goals/Question/Metric (GQM) method to develop the set of KPI for ERP implementation projects. The result of the application of this method is a GQM plan. The GQM plan is a document that contains the goals, questions, and metrics for a measurement program (Solingen and Berghout 1999), in this case an ERP implementation project. This chapter is organized as follows. First, we present the research methodology used, and we describe the GQM method. Next, we present the GQM plan for each CSF mentioned above. For each CSF we include a literature review which helped to create the GQM plan. Then, we present the GQM plan proposed. Finally, we present some considerations.



The purpose of this study is to develop a set of metrics to control and monitor training issues in ERP implementation projects. We used the GQM method to develop a measurement program. The steps were:

• Definition of goals related with each CSF in ERP implementation projects. • Definition of questions associated for each goal. • Definition of metrics associated to each question. • Definition of the preliminary GQM plan.

Since we could not obtain a real case study to develop the GQM metrics using a GQM team,

we developed the metrics based on the implicit models associated with each CSF. The implicit models are those models built by the experts during years of experience (Solingen and Berghout 1999). “Those implicit models give valuable input into the measurement program and will often be more important than the available explicit process models” (Solingen and Berghout 1999, p. 23). In our research, these implicit models are all the theories and studies related with each CSF. A literature review on each CSF topic as related to ERP implementations was made in order to acquire knowledge related with these CSF. The information provided by the literature was the main source of information. We used the concept of preliminary GQM plan due to the fact that the final GQM plan must be validated by the project team that is going to use it. Here, we only provide a proposal for this plan.

7.3 A GQM Preliminary Plan on ERP Implementations

We present below an overview of GQM approach and then we describe each of the components of the GQM preliminary plan: measurement goals, questions and metrics. For the measurement goal defined, the following aspects are described: goal description and its refinement into questions, and finally, refinement from questions to metrics.

7.3.1 GQM Method Overview

The GQM approach is a mechanism that provides a framework for developing a metrics program. It was developed at the University of Maryland as a mechanism for formalizing the tasks of characterization, planning, construction, analysis, learning and feedback. GQM does not provide specific goals but rather a framework for stating measurement goals and refining them into questions to provide a specification for the data needed to help achieve the goals (Basili et al. 1994). The GQM method was originally developed by V. Basili and D. Weiss, and expanded with many other concepts by D. Rombach. The GQM method contains four phases: planning phase, definition phase, data collection phase and interpretation phase (for more details see Solingen and Berghout 1999).

The definition phase is the second phase of the GQM process and concerns all activities that should be performed to formally define a measurement program. One of the most important outcomes of this phase is the GQM plan. A GQM plan or GQM model documents the refinement


of a precisely specified measurement goal via a set of questions into a set of metrics. Thus, a GQM plan documents which metrics are used to achieve a measurement goal and why these are used - the questions provide the rationale underlying the selection of the metrics. The definition phase has three important steps:

• Define measurement goals - Measurement goals should be defined in an understandable way and should be clearly structured. These measurement goals should be relevant to the business, represent strategic goals from management, and support high priority processes of the organization (Solingen and Berghout 1999).

• Define questions - Questions should be defined to support the interpretation of measurement goals. Questions are a refinement of measurement goals from an abstract level to an operational level, which is more suitable for interpretation. By answering questions, one should be able to conclude whether a measurement goal is reached. As Solingen and Berghout (1999) state, the questions should be defined at an intermediate level of abstraction between the metrics and the measurement goals. The list of questions is developed through interviews.

• Define metrics - Once measurement goals are refine into a list of questions, metrics should be defined that provide all the quantitative information to answer the questions in a satisfactory way. The metrics defined must ensure that sufficient information should be available to answer the questions.

7.4 ERP Business Process Reengineering

Business Process Reengineering (BPR) has been popularized in recent years as the most important technique for restructuring business operations to achieve improvements. However, the technique is not new. BPR originated in the 1950s as large enterprises began to explore the potential impact of computers on the efficiency and effectiveness of their business processes. In the early 1990s, BPR had an explosive dissemination, especially after the publication of the book by Hammer and Champy (1993) entitled “Reengineering the Corporation: A Manifesto for Business Revolution”. Another reason is the fact that during the 1990s an increasingly competitive world was driving the use of BPR (Hammer and Champy 1993) and business restructuring to improve profitability and return on capital employed (Martin and Cheung 2000). According to Hammer and Champy (1993, p. 32), BPR is “the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical, contemporary measures of performance, such as cost, quality, service and speed”.

A process is “a lateral or horizontal organizational form, that encapsulates the interdependence of tasks, roles, people, departments and functions required to provide a customer with a product or service” (Earl 1994, p. 13). A business process is “comprised of the people who conduct it, the tools they use to assist them, the procedures they follow and the flows of material and information between the various people, groups and sub-activities” (Tjaden et al. 1996). Whitman and Gibson (1997) developed a study for discovering why enterprises use BPR. In order of importance, the reasons are: to improve inefficient business processes, to be industrial leader, to reorganize business functions, and to improve current industry position.


Jih and Owings (1995) suggested that management is taking a more holistic approach to the redesign and packaging of business processes and their relation with information technology. The benefits from reengineering arise from combinations of organizational changes with information and information technology (Hammer and Champy 1993, Davenport 1993, Lillrank and Holopainen 1998, Jarrar and Aspinwall 1999). Therefore, there is a strong relationship between BPR and organizational change management procedures during a BPR project with the support of top management. This evidences the need to integrate techniques for organizational design and change into BPR projects (Kettinger et al. 1997).

7.4.1 BPR and ERP

According to Krammergaard and Moller (2000), ERP systems pave the way for BPR since the implementation of ERP systems requires examination of many business processes (Boudreau and Robey 1999, Taylor 2000). The frontiers of which comes first, BPR and then ERP, or ERP and then BPR, are not quite well defined in most of the cases. Some organizations use ERP systems to promote a BPR (e.g. Martin and Cheung 2000), while others are driven into BPR during the implementation of an ERP system. A survey made to 220 European companies implementing SAP showed that simultaneous implementation of BPR and SAP has proved to be the most effective and powerful method for business improvement (Chemical Marketing Reporter 1996). Another important issue in BPR/ERP projects is the cycle time expended for redesigning the processes and obtaining the expected results.

7.4.1.1 BPR Methodologies

Bancroft et al. (1998) defined a four-basic-steps approach for a BPR method: choose a process, understand it to the extent needed, redesign it, and implement the change. Kale (2000, p. 136) proposes an eight-step BRP methodology. Usually authors identify two dimensions in a BPR initiative, magnitude of change and scale of the change effort involved:

• Magnitude of change - although the initial concept of BPR was associated with a radical change, nowadays these changes are on a continuum from streamlining to reinvention (Bancroft et al. 1998). “Streamlining a business process implies making incremental changes to the current process to increase quality, decrease cycle time, or reduce cost. Reinventing a business process means scrapping the current one and creating a process that truly meets the needs of the company” (Bancroft et al. 1998, p. 116).

• Scale of the change effort involved – this dimension refers to the portion of business involved in the BPR project. Bancroft et al. (1998) quoted that the more departments and people involved in the change, the greater the scale and therefore the higher complexity of effort. Some organizations adopt the approach of starting with a small portion in a pilot project and the extend the experience to the whole organization, to an approach with major sections.


7.4.1.2 BPR Concerns in the ERP Context

Based on a survey, Jarrar and Aspinwall (1999) defined a set of CSF for a successful BPR project categorized in four main aspects: culture, structure, and process and information technology. Although the analysis of Jarrar and Aspinwall (1999) was not related with ERP projects, we think these factors should be taken into account in future research. Some of those CSF in BPR projects (such as employee involvement, top commitment, training, assign the ‘best’ people, involve outside consultants) are very similar to some of the CSF in ERP projects (see chapter 4 – unified model of CSF). On both cases the organizational perspective is more important than the technological perspective. Based on field interviews of BPR experts, Kettinger et al. (1997) consider four major project characteristics in BPR planning: project radicalness, process structuredness, the potential for IT enablement and customer focus. Figure 26 represents a summary of the main concerns in a BPR approach during ERP implementation projects. These concerns were based on the articles referenced in this work and the literature inside them.

Process DimensionDesign of crosscutting business processes

Define which processes must changeAlignment of business processes and ERP

Involvement of outside consultantsCustomer focus

Top-down approach

Product DimensionERP customization

Adequate ERP modulesInfrastructure resources planning

Involvement of IT expertsRapid development of IT requirements

People DimensionEmployee involvement

Assign best people for BPRTraining plan

Cross functional teams and teamworkTop management commitment

Continuous and comprehensive communication

Change Management DimensionBPR in advance or during ERP implementation

Stimulating organizational improvementPre-reengineering ‘cultural audits’Emphasis on soft skills (attitude)

New reward and recognition systemCustomer focus BPR

Project radicalnessProcess structuredness

Potential IT enablementCustomer focus

Process DimensionDesign of crosscutting business processes

Define which processes must changeAlignment of business processes and ERP

Involvement of outside consultantsCustomer focus

Top-down approach

Product DimensionERP customization

Adequate ERP modulesInfrastructure resources planning

Involvement of IT expertsRapid development of IT requirements

People DimensionEmployee involvement

Assign best people for BPRTraining plan

Cross functional teams and teamworkTop management commitment

Continuous and comprehensive communication

Change Management DimensionBPR in advance or during ERP implementation

Stimulating organizational improvementPre-reengineering ‘cultural audits’Emphasis on soft skills (attitude)

New reward and recognition systemCustomer focus BPR

Project radicalnessProcess structuredness

Potential IT enablementCustomer focus

Figure 26. BPR concerns in the ERP context.

7.4.2 Towards a BPR Strategic View for ERP Implementations

Based on the literature review that we made on the BPR topic, we propose that managers must develop a strategic view of BPR instead of a tactical one. In most ERP implementation projects, BPR is seen as a consequence of an ERP implementation and hence its importance is dismissed. At the tactical level managers are worried in redesigning their business in order to align the ERP system and the current business processes. However, a BPR effort in strategic terms is an intervention, and probably the most important intervention associated with the adoption of the ERP system.

A BPR intervention is not merely the adaptation of an ERP system or the business processes of an organization, it implies changes in the way of doing business as well as on the structure and


culture of an organization; it is changing the way of working of an organization and the process-oriented vision that organization needs to integrate. As Kale (2000, p. 132) refers, “the most important outcome of BPR has been viewing business activities as more than a collection of individual or even functional tasks; it has engendered the process-oriented view of business”. Thus, the BPR effort must be seen as an enabler of organizational and business improvement. The BPR intervention may have deep effects not only on the short term of organizational behavior, but also on its long term behavior and strategy. Two main reasons arise in order to develop this strategic view: current changes in the business world and the rising knowledge organization.

The concepts of ERP and BPR are unique and to understand better how they are related to each other one has to follow the path of process study of the problem. In essence, understanding the existing business processes is one of the key elements in ERP implementations. Implementing an ERP system involves reengineering the existing business processes to the best business process standard (Bingi et al. 1999). ERP systems are built on best practices that are followed in the industry domain. Therefore, in practice, BPR is aimed at only when the customer’s requirements are not met within the scope of customization allowed by the ERP system. The organization business strategy outlines ‘what’ you want to do. BPR outlines ‘how’ you want to do it - reengineering (human and system) behaviors in your business to achieve those goals. ERP answers the question ‘with what’.

As a system, the ERP is a tool to help change behaviors. As a philosophy, ERP is a strategy for changing that behavior. Soliman and Youssef (1998) note that information technology, in general, and ERP systems in particular, are central to the success of the BPR method. The main consulting organizations have their own BPR methodologies and are based on the use of specific tools, such as Coopers&Lybrand (currently PriceWaterhouseCoopers) that used a proprietary process modeling and simulation tool called SPARKs. Kettinger et al. (1997) made an extensive review of BPR methods and techniques available. In sum, ERP becomes a philosophy (with technical tool overtones) that supports a BPR effort. These changes should support the business strategy. Project team members and managers must identify the core business processes in order to prioritize the BPR approach. Techniques such as the PQM method could be applied. Table 33 represents a summary of the main issues that arise in a BPR approach during an ERP implementation project. Table 33. Main issues in a BPR approach during an ERP implementation project. Positive aspects Negative aspects

• Stimulates business improvement. • Alignment of business processes and ERP

system. • Design of crosscutting business processes.

• Causes project delays. • Requires additional effort from employees. • Most of the times is too technological

oriented. • Adoption of certain ERP functionality

implies the adoption of several modules. We summarized the main issues of measuring BPR: define which business processes must

change, define who collects the BPR metrics, define which ERP processes must change, and analyze when BPR monitoring must be done, Organizational/business implications of BPR. Some authors propose some metrics to define and measure the effectiveness of business processes. For instance, Tjaden et al. (1996) proposed a set of metrics, namely: simplicity, flexibility, integration and efficiency, which are based in what they call the business process structural characteristics. We recommend that these metrics be incorporated in a BPR approach within an ERP


implementation project. The goal of this study is not to define these metrics or core business processes identification. Instead, we want to help monitoring the BPR actions along the ERP implementation project.

7.4.3 Measurement Goal of the GQM Preliminary Plan

In our case of BPR, the definition of the measurement goal associated with BPR is made using the template provided by Basili et al. (1994). We defined one measurement goal based in our CSF (see table 34). Table 34. Goal for comprehensive business process reengineering CSF. Analyze The actual redesign of business processes For the purpose of Understanding BPR With respect to ERP implementation projects From the viewpoint of Project managers and their project teams In the context of Organizations under BPR/ERP initiatives

7.4.4 Questions

For the above measurement goal we defined a set of questions (see table 35) based in the BPR dimensions (see figure 26). The questions for our measurement goal focus on identifying objective and quantifiable aspects that were related to the baseline characteristics of the business processes that need change. Table 35. The definition of questions related with business process reengineering CSF. Dimensions Questions Change management 1. What is the magnitude of redesign for each business process?

2. What jobs are affected by the changes? 3. How many departments are affected?

People 4. How many users are involved? 5. Are key-users for each business process involved?

Process 6. How many business processes need to be redesigned? 7. Which other business processes are affected with the business process redesign? 8. What is the complexity associated with these business processes? 9. What is the effort of redesigning these business processes? 10. How long is the redesign going to take?

Product 11. How many ERP processes need to change?

7.4.5 Description of Metrics

In this section we show the definition of each metric and the relationship between the questions defined above and the metrics (see table 36). We also represented graphically the relationships (see figure 27). The graphic represents the three levels: measurement goals, questions, and metrics. Metrics can help answer more than one question. For instance, in this case with the metric users involved (metric four) we can know how many users were involved and how many key-users were involved.


Table 36. The definition of metrics for BPR and their relationship with questions. 1 Magnitude of redesign Magnitude of redesign that is necessary for each business process. Q1 2 Number of jobs

affected Number of jobs that are affected for each business process redesigned. Q2

3 Number of departments affected

Number of departments that are related with each business process redesigned.

Q3

4 Users involved Users involved in the BPR process. Q4 5 Number of business

processes redesigned Number of business processes that need to be redesigned. Q6

6 Number of business processes affected

Number of business processes that need changes due to the redesign of another business process.

Q7

7 Complexity of business processes

“Sum of the number of activities, the number of people in each activity, the number of material flows into and out of the process, and the number of material flows between the activities of the process” (Tjaden et al. 1996).

Q8

8 BPR effort This metric is related with the portions of business involved in the BPR redesign. It is composed of the total number of departments, the number of business processes redesigned and the people involved in each phase.

Q9

9 Duration of business process redesign

Estimated time necessary to redesign each business process. Q10

10 Number of ERP processes affected

Number of ERP processes that need changes due to the BRP process Q11

G

1.31.21.1 1.4

1

1.81.71.6

432

1.9

5 876

Business Process Redesign

1.10

9

1.11

10

1.5

Goals

Questions

Metrics

G

1.31.21.1 1.4

1

1.81.71.6

432

1.9

5 876

Business Process Redesign

1.10

9

1.11

10

1.5

Goals

Questions

Metrics

Goals

Questions

Metrics

Figure 27. Graphical representation of the GQM plan for BPR.

The metrics description was done by using a special form that we created for the task. For each metric we defined the following aspects: what they measure, when they must be measured, what possible values they could have, metric scale, who will measure it, what medium is used for data collection. Most of the metrics proposed are direct measurements except the metrics related with percentages.


7.4.6 Interpretation of BPR Metrics

Regarding the magnitude of redesign metric, Kettinger et al. (1997) developed a “project radicalness planning worksheet” in order to assess the BPR project radicalness. This worksheet includes eleven factors related with BPR project planning: strategic centrality, feasibility of IT to change process, process breadth, senior management commitment, performance measurement criteria, process functionality, project functionality, project resource availability, structural flexibility, cultural capacity for change, management’s willingness to impact people and value chain target. Each factor is measured in a Likert scale (1-5 scores). However, their view is not for each business process but for the project as a whole. We think that this worksheet is very useful at the beginning of the BPR project to define the BPR plan and allocate the adequate resources. This also is important to establish management commitment and support (other CSF in ERP implementation projects). Higher radicalness implies more commitment and lower radicalness implies more analysis of existing processes in order to improve them (Kettinger et al. 1997).

Based on the magnitude and the scale of effort involved in a BPR approach, Bancroft et al. (1998) proposed a matrix of magnitude versus scale of effort. BPR effort is quite similar to the complexity of each business process. The more departments and people involved in the change, the greater the scale and therefore complexity of the BPR effort. As Bancroft et al. (1998, p. 118) pointed out, “identifying the correct quadrant helps the project team and the executive sponsor to choose the appropriate project process and appreciate the amount of change required. This knowledge will positively influence their success rate”. Therefore, it will be useful for each business process to locate its correct quadrant in order to define the best project processes to redesign it. As we show in chapter 5 – Critical Success Factors Relevance, the BPR factor is more relevant in the three initial phases of an ERP implementation project. Therefore, the effort to monitor and control this CSF should be put in these three initial phases.

7.5 ERP Sustained Management Support

Green (1995) defines top management as the CEO and his/her direct subordinates all of them, responsible for corporate policy. Top management is represented in a project in the figure of the steering committee and the project sponsor. Welti (1999) considered a capable and powerful steering committee as absolutely crucial for a project, as it has to fulfill very important tasks and responsibilities, e.g. assuming ownership, managing the implementation of project policy, controlling project planning and progress, enabling fast decisions, deciding on organizational issues, making resources available, supporting the project manager, motivating the management. Project sponsor role is considered as another CSF in an ERP implementation. Therefore, it will be analyzed in the next phase of this research. We (Esteves and Pastor 2000) stated that sustained management support is related with “sustained management commitment, both at top and middle levels during the implementation, in terms of their own involvement and the willingness to allocate valuable organizational resources. Management support is important for accomplishing project goals and objectives and aligning these with strategic business goals”. Top management support is needed throughout the implementation project (e.g. Esteves and Pastor 2001, Nah et al. 2001) and it must be committed with its own involvement and willingness to allocate valuable resources to


the implementation effort (e.g. Jarvenpaa and Ives 1991, Holland et al. 1999). Bingi et al. (1999) mention that “top management needs to constantly monitor the progress of the project and provide direction to the implementation teams”. According to Purba et al. (1995, p. 178), top management has “an overall responsibility for accepting and approving the project initiatives outlined in the information technology strategic plan, including funding and prioritization of projects before they are initiated”. In the context of small business, Yap et al. (1992) proposed and validated a measure of top management support. Their measure consists of: (1) level of support for the computerization project; (2) frequency of attendance at project meetings; (3) level of involvement in information requirements analysis; and (4) level of involvement in decision-making relating to the project. Next, we discuss the two main issues of sustained management support: support and commitment.

7.5.1 Management Support

According to Krammergaard and Moller (2000), “top management involvement is critical, while only top managers are equipped to act as the mediator between the imperative of the technology and the imperative of the organization”. One of the tasks of top management is to assist in project review meetings. According to (Jurison 1999, p. 31), the purpose of project review meetings is “to assess progress and identify areas of deviations from the plan so that corrective action can be taken”. The author also states that project review meetings provide visibility to plans and progress and create opportunities for obtaining and enforcing commitments from the participants.

Welti (1999, p. 137) mentions that “active participation by upper management is crucial to the adequate resourcing of the project, to taking fast decisions, and to promoting company-wide acceptance of the project”. Another important aspect is the recognition from top management that ERP implementations require the use of some of the best and brightest people in the organization for a notable period of time. Therefore, top management must help to identify these people, free them from other responsibilities, organize them into an interdisciplinary team, and empower them for the responsibility of the project (Chen 2001).

7.5.2 Management Commitment

Other important aspect is the commitment with the project. Top management needs to publicly and explicitly identify the project as a top priority (Wee 2000). Some view points of commitment are:

• Commitment to an IS development project involves “doing what is necessary throughout the stages of system development, installation, and use to assure that the problem is understood and that the system development solves that problem” (Ginzberg 1981, p. 54).

• The Capability Maturity Model (CMM) defined commitment as “a pact that is freely assumed, visible, and expected to be kept by all parties” (CMU 1994).

• A more broad definition is given by O’Reilly and Chatman (1986). They view commitment as a psychological state of attachment that defines the relationship between a person and an entity. O’Reilly and Chatman (1986) described commitment


as the degree to which an individual internalizes or adopts the goals and values of the organization.

• In another definition, commitment is described as “an individual's affective attachment to the goals and values of an organization, to (his or her) role in relation to these goals and values, and to the organization for its own sake apart from its purely instrumental worth to the individual (DeCotiis and Summers 1987).

Dong and Ivey (2000) defined two types of top commitment: commitment to resource and

commitment to change management. Case studies on ERP systems suggest that the commitment of top management to resources is key to facilitating implementation processes (Hirt and Swanson 1999). Newman and Sabherwal (1996) identified the determinants of commitment in information systems development projects: project determinants, psychological determinants, social determinants and, structural determinants. They also proposed a model explaining the dynamics of commitment and how these determinants affect the levels of commitment. However, this model does not define these levels and it also does not take into account the research made by other authors related with commitment development such as Meyer and Allen (1991) and Conner and Patterson (1982). The management commitment development model to software process improvement proposed by Abrahamson and Jokela (2000) takes into account these studies.

Based in an extensive literature review on the commitment topic, Meyer and Allen (1991) defined three forms of commitment:

• Affective commitment refers to the employee’s attachment to, identification with, and involvement in the organization.

• Normative commitment reflects a feeling of obligation to continue membership with the organization.

• Continuance commitment refers to an awareness of the costs associated with leaving or abandoning the organization.

Meyer and Allen (1991) emphasize the need to consider these three forms of commitment as

components of commitment rather than types of commitment. It means that an employee can experience all three forms of commitment with varying degrees. Other models for explaining commitment have been proposed, but Meyer and Allen (1991) model is the most used and validated. This is the main reason why we decided to adopt this model in our study since we did not find any study related with commitment in ERP implementation projects. We analyzed both three components in the ERP context:

• Affective commitment is related with the involvement of top management in ERP project activities, as they show their identification with the project through the participation in the different project events showing that they share the project values. Top management commitment “when percolated down through the organizational levels results in an overall organizational commitment. An overall organizational commitment that is very visible, well defined, and felt is a sure way to ensure a successful implementation” (Bingi et al. 1999).

• Normative commitment is related with the obligation to remain within the project. One of the CSF in ERP implementation projects is the dedication of staff to the ERP project, since usually staff is not dedicated 100% for the project. They usually keep


doing their normal activities in parallel. Chen (2001) says that top commitment must not be limited to the conception of the project (giving their blessing to the ERP system) but should continue through its completion. Their commitment implies that they are willing to spend significant amounts of time serving on the steering or executive committee, overseeing the implementation team.

• Continuance commitment is related with the costs associated with leaving or abandoning the project and the organization in some cases. This is an important point in ERP projects since one of the issues is the turnover of people in a project of this nature. Usually, the turnover affects more project team members and consultants.

Figure 28 represents a summary of the main concerns with top management support during

ERP implementation projects. These concerns were based on the articles referenced in this work and the literature inside them. We categorized the different concerns in four dimensions: change management, process, people and project dimensions.

Project DimensionPeople Dimension

Change Management DimensionProcess-oriented vision (Bancroft et al. 1998)Commitment to change management (Dong and Ivey 2000)Commitment along the whole project (Chen 2001)Definition and monitoring of the change plan (Bancroft et al. 1998)

Process Dimension

Assigning best people (Chen 2001)Empowering project team members (Chen 2001)Commitment at all levels (Bingi et al.1999)Continuous and comprehensive communication (Welti 1999)Motivate employees (Welti 1999)

Align ERP project with organization strategy(Kraemmergaard and Moller 2000)Involvement in requirements analysis (Yap et al. 1992)

Attendance at project meetings (Whitten 1999)Involvement in decision-making (Welti 1999)Resources funding (Hirt and Swanson 1999)Support project manager (Bingi et al. 1999)Project monitoring and control (Bingi et al. 1999))Awareness of ERP project complexity (Wee 2000)

Top ManagementSupport

Commitment Project DimensionPeople Dimension

Change Management DimensionProcess-oriented vision (Bancroft et al. 1998)Commitment to change management (Dong and Ivey 2000)Commitment along the whole project (Chen 2001)Definition and monitoring of the change plan (Bancroft et al. 1998)

Process Dimension

Assigning best people (Chen 2001)Empowering project team members (Chen 2001)Commitment at all levels (Bingi et al.1999)Continuous and comprehensive communication (Welti 1999)Motivate employees (Welti 1999)

Align ERP project with organization strategy(Kraemmergaard and Moller 2000)Involvement in requirements analysis (Yap et al. 1992)

Attendance at project meetings (Whitten 1999)Involvement in decision-making (Welti 1999)Resources funding (Hirt and Swanson 1999)Support project manager (Bingi et al. 1999)Project monitoring and control (Bingi et al. 1999))Awareness of ERP project complexity (Wee 2000)

Top ManagementSupport

Commitment

Figure 28. Top Management concerns in the ERP context.

7.5.3 Measurement Goals of the GQM Preliminary Plan

We defined two measurement goals based in our CSF: time spent on support activities (see section 7.5.1) and level of commitment (see section 7.5.2): Table 37. Goals for top management support CSF. Analyze The time spent by top managers on support activities and review meetings. For the purpose of Analyzing. With respect to ERP implementation projects. From the viewpoint of Project managers and their project teams. In the context of Organizations under ERP initiatives.


Analyze The support and commitment level of top managers For the purpose of Understanding With respect to ERP implementation projects From the viewpoint of Project managers and their project teams In the context of Organizations under ERP initiatives

7.5.4 Questions

For each measurement goal we defined a main question and then, we defined a set of sub-questions related with the measurement goal (see table 38). The question for measurement goal one focuses on identifying objective and quantifiable aspects that were related to the baseline characteristics of the support activities performed along the project. Top managers are involved in two main activities: support meetings and review meetings. The question for measurement goal two is related with the presence of top managers in the meetings and the actions they proposed along the ERP project, especially communication events. Table 38. The definition of questions for top management CSF. Goal Question Sub-question

One What are the main characteristics of the support activities?

1. In which way is the support meeting requested (phone, email, etc.)? 2. For which domain is the support requested? 3. How long do support meetings take on average? 4. How many support meetings were done per phase? 5. How many support meetings were cancelled? 6. How many support activities were postponed? 7. What is the attendance in support meetings? 8. How many review meetings were done per phase? 9. How many review meetings were cancelled? 10. How many review meetings were postponed? 11. What is the attendance in review meetings? 12. How long do review meetings take on average? 13. What is the frequency of review meetings? 14. Are reviews made speedy in decision processes? 15. What is the percentage of scheduled review meetings done per phase? 16. How many events did top management propose?

Two What is the level of commitment?

1. What is the level of affective commitment? 2. What is the level of normative commitment? 3. What is the level of continuance commitment?


In this section we show the definition of each metric and the relationship between the questions defined above and the metrics (see table 39). We also represent graphically the relationships (see figure 29).


Table 39. The definition of metrics for top management and their relationship with questions. Metric Questions

1 Support meeting request medium Q1.1 2 Domain for the support meeting Q1.2 3 Duration of support meeting Q1.3 4 Number of support meetings per phase Q.14 5 Support meetings cancelled in each phase Q1.5 6 Support meetings postponed in each phase Q1.6 7 Attendance on support meetings Q1.7, Q2.1 8 Number of review meetings per phase Q1.8 9 Review meetings cancelled in each phase Q1.9 10 Review meetings postponed in each phase Q1.10 11 Attendance on review meetings Q1.11, Q2.1 12 Duration of the review meeting Q1.12 13 Frequency of review meetings Q1.13, 14 Undertaken time in decision making Q1.14, Q2.2 15 Percentage of scheduled review meetings versus review meetings done per phase Q1.15 16 Number of events proposed by top managers Q1.116, Q2.1 17 Level of involvement in information requirements analysis Q2.2 18 Level of involvement in decision-making Q2.2 19 Project turnover Q2.3

G1 G2

Q2Q1

1.31.21.1 1.4

1

1.71.61.5

432

1.8

5

1.101.9

876 9

1.141.13

1110

1.15 1.16

141312 15

Sustained Management Support

1.11 1.12

16

2.1

17

2.2

18

2.3

19

Goals

Questions

Metrics

G1 G2

Q2Q1

1.31.21.1 1.4

1

1.71.61.5

432

1.8

5

1.101.9

876 9

1.141.13

1110

1.15 1.16

141312 15


1.11 1.12

16

2.1

17

2.2

18

2.3

19

G1 G2

Q2Q1

1.31.21.1 1.4

1

1.71.61.5

432

1.8

5

1.101.9

876 9

1.141.13

1110

1.15 1.16

141312 15


1.11 1.12

16

2.1

17

2.2

18

2.3

19

Goals

Questions

Metrics

Goals

Questions

Metrics

Figure 29. Graphical representation of the GQM plan for sustained management support.

7.5.6 Interpretation of Metrics

The metrics related with the first goal are concerned with the characteristics of the type of support that top managers do in an ERP implementation project. Therefore, metrics focus on the number of support and review meetings and topics related with attendance, and the number or meetings realized, cancelled or postponed. Review meetings are scheduled at the end of each


implementation phase. Thus, we propose an analysis of metrics following the ERP implementation project phases. We show in chapter 5 – Critical Success Factors Relevance, that management support is more relevant at the beginning and at the end of the implementation project. The reason is that at the beginning, top management should help in the rollout of the project, analyze the business benefits, help to define the mission and scope of the project and provide the resources needed for the project. At the end, there is the need to encourage the system usage and help in the commitment of user involvement. Therefore it is important to control and monitor management support since the beginning in order to keep top managers committed with the project.

Cap Gemini (Cap Gemini 1996) made a survey to 220 European companies that have implemented SAP and they discovered that over 70% of the implementation teams reported only once a month or less to senior management. If you take into account that on average, the duration of an ERP implementation is some seven to twelve months, changes are being decided upon by senior leadership in fewer than ten meetings. Cap Gemini (1996) states that ten meetings is not enough time to ensure that all decisions are made in a thoughtful, deliberate, and well-informed manner. Therefore, they recommend a much stronger governance procedure.

7.6 ERP Adequate Training Program

Training is one of the most cited CSF in ERP implementation projects (see chapter 4 – unified model of critical success factors). In order to realize significant benefits from ERP systems a considerable amount of training is required (Wortmann 1998). There must be a training plan and it should take into consideration both technical staff and end-users, with its scope depending on the type of implementation approach selected. Some organizations use an in-house training approach while others prefer to use training consultants from outside (see chapter 4 – Unified Model of Critical Success Factors). In chapter 5 – Critical Success Factors Relevance, we show that training activities in a SAP implementation are in the ranking of the most critical activities. Koch (1996) mentioned that “without proper training, about 30 to 40 percent of front-line workers will not be able to handle the demands of the new system”. Hence, ERP systems are complex and demand rigorous training. As Bingi et al. (1999, p. 14) say:”It is difficult for trainers or consultants to pass on the knowledge to the employees in a short period of time”.

From the project management perspective a training evaluation activity may seem to be an add-on, a luxury, another costly element of a project consuming resources. Unlike training monitoring which focuses on technical aspects of delivery of training and control of planned variables. According to Goldstein (1993, p. 9), “most organizations do not collect the information to determine the utility of their own training programs”. We think that the same happens in the case of ERP implementation projects, especially when managers are only worried with the training costs rather than measuring its effectiveness. One of the most important benefits on evaluating training is that it “can serve as a diagnostic technique to permit the revision of programs to meet the large number of goals and objectives” (Mann and Robertson 1996, p. 15). Other benefits gained by evaluating training affect decision making, particularly because evaluations can help decide between alternative training programs and to decide who should participate in future programs (Mann and Robertson 1996). Some of the main arguments for better evaluation of


training are: to validate training as a business tool, to justify costs incurred in training, to help improve the design of training, and to help in selecting training methods.

Training is one of the most costly components of an ERP implementation project (Esteves et al. 2001). An organization may have to undertake ERP training for three different groups (Kale 2000):

• The managerial personnel who are key members of their departments and have been nominated as the members of the functional team.

• Key-users who form the core of the super-users to be entrusted with the task of life-scale testing the system and also training other end-users.

• All other end-users who would be using the system as part of their routine operational duties.

There is another other important group, the trainers. They should be carefully selected, since in

most projects, trainers demonstrated lack of experience, and courses were inadequately structured, usually because those trainers were junior consultants.

7.6.1 Training Methods

Training may include classroom instruction supplied by the ERP vendor or from Web, interactive, and other distance learning courses. It is helpful to ask referral ERP users what training tools proved most useful to them. “The company’s ERP evaluation committee should consider what kinds of training are available from prospective vendors and what percentage of the total cost of the new system should be budgeted for training. Many vendors recommend at least 10 to 15% (McAlary 2000, Kale 2000). Some recommend an estimated 120 hours per person. It is likely that the training investment will help drive the rollout plan. That is, the more you spend on training, the faster your rollout may be accomplished.” (McAlary 2000).

Users are most often trained by a training staff that first learned how to use the ERP system during the project pilot phase. User training is ideally performed on the customer’s premises, using examples from the organization line-of-business data and the new ERP system. However, it is often difficult to get trainees to sit through day-long, onsite training. They are inclined to run in and out of the training sessions, answering telephone calls and responding to everyday problems, within their departments. This is disruptive and reduces the effectiveness of the training task. The figure of the training manager is very important in an ERP project. His major responsibility is “to ensure the availability not only of the instructors, but also to release the various personnel from their normal functions at appropriate times so that they can participate in the scheduled training sessions” (Kale 2000, p. 233).

7.6.2 Training Schedule

Some case studies of ERP implementations have shown the importance of effective training at all levels (e.g. Bancroft et al. 1998, Miller 1999, Kale 2000). Training should be synchronized with the overall implementation project. Formal training of all users is not normally deployed at the beginning of the implementation. Some organizations embark upon training programs several months before the ERP goes live, by which time users have forgotten their training (De Bruin


1997, Welti 1999). As Gupta (2000) states, poor end-user training is a common problem in all ERP implementations. “The ERP system is ready to go live but no one in the organization knows how to use it, and personnel also lack training in the maintenance aspects of the system” (Gupta 2000, p. 116). According to McAlary 2000, training can take place as late as two weeks before the beginning of the implementation cycle that deals with the trainees domain. One way to minimize the problems arisen from the time lag between the actual training and the commencement of ERP going into production is doing refresher courses (Kale 2000).

7.6.3 Training Curriculum

The consensus that is emerging in relation to ERP training is that the training that matters is not technological but rather it must develop the ability to figure out the underlying flow of information through the business itself (Wheatley 2000). This is not just training in using the new system, but also in the new processes and in understanding the integration within the system – how the work of one employee influences the work of others (Krammergaard and Moller 2000, Wheatley 2000). The implementation of an ERP system involves a lot of organizational change in organizations. When organizations are asked what they would have done differently, most respond that they would have offered more training on how the system would change processes and to use the system (Krammergaard and Moller 2000). Therefore, there is the need to incorporate specific training related with it. As Bancroft et al. (1998, p. 138) pointed out “users must be informed as to the business needs for such change as well as which keys to when”, where change refers to the reengineered process associated with the new ERP system and the novel way of operating. We call this type of training organizational training. Most consultants suggest that end-users should be trained by using the new ERP parameterization according to the organization needs as this provides a better and quickly adaptation to what they will find after the go-live phase.

Another important aspect is the commitment of users to training. In terms of short term perception of training skills transfer, Axtell and Maitlis (1997) mention that if new skills are to be transferred to the workplace, trainees first need to feel that the training course is relevant to their jobs, and must also be committed to using what they have learned. Therefore, is important at the beginning of the ERP training program to explain to users what are the objectives and benefits of training. After one year, the factors influencing the transfer of training skills are the degree of autonomy in their jobs and their original motivation to use what they have learned. Thus, the predictors of training skills transfer after one year are different from those just after the training course (Axtell and Maitlis 1997).

7.6.4 Training Evaluation

According to Brinkerhoff (1988), a good training evaluation should be able to prove that the program:

• Is aimed at important and worthwhile organizational benefits; • Operates smoothly and effectively and is enjoyed by participants; • Achieves important skills, knowledge and attitude objectives; • Uses the best available and most cost-effective designs; • Is used effectively on the job; and


• Provides valuable and cost-effective organizational benefits. Another important aspect with regard to training evaluation is “what” must be evaluated.

Kirkpatrick (1998) has identified four levels of outcomes of training which are hierarchically ordered:

1. Reaction – this level assesses the initial reactions of participants to a course. This, in turn, offers insights into participants’ satisfaction with a course, a perception of value. Trainers usually assess this through a survey, often called a ‘smiley sheet’.

2. Learning – this level measures the amount of learning that results from training and determines how much behavior can change back on the job. Trainers usually assess this with criterion-referenced tests.

3. Behavior – this level measures the degree of transfer from what was learned to how the trainee behaves on the job, which in turn determines how much organizational impact the training can have. This assessment is based on the objectives of the course and these assessed through tests, observations, surveys, and interviews with co-workers and supervisors.

4. Results – this level is a measure of organizational and business impacts of the training. Some assess this measurement by tracking business measurements, others assess it by observations, some by surveys and still others assess by qualitative measures.

The last level is the most difficult level to assess. First, most of training courses do not have

explicitly written their organizational/business goals; second, the methodology for assessing the impact is not yet refined; and third after a long period after training occurs, evaluators have difficulty solely in attributing changes in business results to training. An effective evaluation of a training program must evaluate each level in Kirkpatrick’s hierarchy in order to an organization be able to understand the full effects of the training program (Kirkpatrick 1998). Kirkpatrick created his model in 1959 but it is still the most used and accepted evaluation training model. Other authors such as Alliger et al. (1997) have augmented and improved this theory in order to establish a fifth level related with training ROI.

7.6.5 An ERP Training Framework Proposal

Kirkpatrick’s model and the extensions made to this model are a good start to develop an evaluation training program for ERP implementation projects. However, we attempt to define a level 0 in this model that is related with the management and monitoring of the training program itself. Based on Kirkpatrick’s model of training evaluation and also on the structure of training proposed by Nickols (2000), we propose an ERP training monitoring and evaluation framework (see figure 30). The framework take into account the training activities (see table 40), the implementation phases where they occur (we used as reference the ASAP implementation methodology), the levels of evaluation proposed by Kirkpatrick, and the period when Nickols (2000) suggests to evaluate each level. We also take into account the groups of trained personnel. In that sense, we distinguish between project team training and end-users training. In the case of


key-users, usually consultants recommend to have training at the same time as the project team does. Table 40. ASAP Training activities of ASAP implementation methodology. Phase ASAP Training Activities Project Preparation Create project training team

Align end-user training with the documentation strategy Business Blueprint Prepare Project training team

Draft end-user training and the documentation plan Realization Conduct project training team

Prepare end-user documentation and training material Final Preparation Prepare for end-user training

Conduct end-user training Go Live

Draft end-user training

End-user training

Team training

Project Preparation Business Blueprint Realization Final Preparation Go & Live Post-Implementation

Create training plan

Team Reactions

Team Learning Team Behaviour

Team Results

End-user Reactions

End-user Learning End-user Behaviour

End-user Results

Training Plan Monitoring

End-user follow-up

and training

Draft end-user training

End-user training

Team training

Project Preparation Business Blueprint Realization Final Preparation Go & Live Post-ImplementationProject Preparation Business Blueprint Realization Final Preparation Go & Live Post-Implementation

Create training plan

Team Reactions

Team Learning Team Behaviour

Team Results

End-user Reactions

End-user Learning

End-user Reactions

End-user Learning End-user Behaviour

End-user Results

Training Plan Monitoring

End-user follow-up

and training

Figure 30. A proposed ERP training framework.

7.6.6 Training as a Continuous Process

We recommend that the training process be seen as a continuum, something that will not finish after the go-live of the ERP system. Not all the end-users are trained during the ERP implementation project nor training is sometimes the basic one to start working with the system. Training will follow along all the ERP lifecycle. Managers must define clearly which employees and skills they will need at the moment of the go-live, in order to achieve a successful ERP


implementation project. Training objectives definition is an important aspect. Managers usually assume the interest of provided training courses. However, training courses can be inadequate to project and organization objectives or at least not focusing in the major project issues (see training curriculum section). The typical vision of “on time, on budget” in terms of training objectives definition is also sometimes applied. We think that this vision should be multidimensional and focusing into technological, organizational, process and strategic aspects.

7.6.7 Goals of the GQM Preliminary Plan

We defined one measurement goal based in our CSF (see table 41). Table 41. Goal for adequate training program CSF. Analyze Training For the purpose of Analyzing With respect to ERP implementation project From the viewpoint of Organization In the context of ERP Implementation project

7.6.8 Questions

For the above measurement goal we defined a set of main questions (see table 42) based in the training levels. The questions for our measurement goal focus on identifying objective and quantifiable aspects that were related to the characteristics of the training program. Table 42. The definition of questions for adequate training program CSF. Dimension Questions Level 0 1. How many users need to be trained?

2. When is the training going to be taken? 3. How long is the training going to take? 4. How many hours of training do we need? 5. How many hours of training each user will have? 6. How many hours of training by ERP module? 7. How many hours of training were given? 8. What is the proportion of organizational training versus technical training? 9. What is the proportion of estimated training plan really done? 10. What sort of people are selected to provide training and how are they chosen?

Level 1 11. Are users satisfied with the training they got? Level 2 12. Was the material relevant to their work? Level 3 13. What skills, knowledge, or attitudes have changed? Level 4 14. Are the newly acquired skills, knowledge, or attitude being used in the everyday

environment of the learner? Level 5 15. What is the overall cost of training?

16. Are there enough resources for the training program?


In this section we show the relationship between the questions defined above and the metrics (see table 43). We also represented graphically the relationships (see figure 31). The metrics


defined should be analyzed according to the three types of users: team members, key-users and end-users. Table 43. The definition of metrics for training and their relationship with questions. Dimension Metric Questions

1 Nº users per course Q1 2 Period of training Q2,Q8 3 Nº. hours per user Q3, Q4 4 Nº. hours of training Q3, Q5 5 Nº. hours of organizational training Q6, Q7 6 Nº hours of technical training Q6, Q7 7 Proportion of estimated training done Q8

Level 0

8 Quality of trainers Q9 Level 1 9 Reaction Q10 Level 2 10 Learning Q11 Level 11 Behavioral Q12 Level 4 12 Results Q13

13 Cost of training Q14 Level 5 14 Training budget Q15

G1

321 4

1

876

432

9

5 876

Training

10

9

11

10

5 12

11

13

12

Goals

Questions

Metrics

G1

321 4

1

876

432

9

5 876

Training

10

9

11

10

5 12

11

13

12

Goals

Questions

Metrics

Figure 31. Graphical representation of the GQM plan for training.

7.7 ERP User Involvement and Participation

In the IS literature, the terms user involvement and user participation have frequently been used to mean the same thing. However, Barki and Hartwick (1989, 1994) claimed that the two concepts are different, and thus need to be defined separately:

• User involvement is defined to as “a psychological stage of the individual, and defined as the importance and personal relevance of a system to a user” (Hartwick and Barki 1994, p. 441), i.e., their attitude toward the development process and its product (the IS itself) and,


• User participation is defined as the observable behavior of users in the IS development and implementation, i.e., the set of operations and activities performed by users or their representatives during the IS development process (Hartwick and Barki 1994) or activities during the system implementation (Kappelman and McLean 1991).

Kappelman and McLean (1991) mention the term “user engagement” to include both user

participation (the behavior) and user involvement (the attitude). Thus, according to their account, user engagement is “used to refer the total set of user relationships toward IS and their development”.

7.7.1 User Involvement

Many reasons have been given to involve users in IS implementation projects. User involvement is predicted to increase user satisfaction and acceptance (Ives and Olson 1984) by: developing realistic expectations about system capabilities, providing an arena for bargaining and conflict resolution about design issues, leading to system ownership by users, decreasing user resistance to change, and committing users to the system. Kappelman and McLean (1991) suggested that user involvement is something distinct from, although associated with, user participation and, that the psychological state of user involvement may be more important than user participation in understanding IS success. An important aspect related with user involvement is ‘user perceived control’. Baronas and Louis (1988, p. 114) stated that “by involving end-user in decisions relating to implementation, workers may become more invested in the success of the implementation and more satisfied with the system through the social-psychological mechanism of perceived control”. Personal control has been defined in terms of choice, predictability, responsibility and ability to reduce or get relief from an unpleasant condition. Baronas and Louis (1988) suggested that:

• Systems implementation is likely to be experienced by nontechnical users as a period of transition during which users make sense of, and cope with, various differences between old and new systems and their anticipations of these differences;

• Systems implementation is likely to represent a threat to user’s perceptions of control over work.

Traditionally, the assumption in terms of user involvement is that if the organizational structure

of an IS project is in place and appropriate committee meetings attended, their integration and coordination will occur. However, as Amoako and White (1997, p. 41) state “unlike the technical side of project management, these activities are very loosely defined, and very often include no mechanisms for the integration that will achieve the desired results”. Therefore, there is the need for the distinction between structural integration and effective management of the involvement process. Characteristics such as user expertise, degree of organizational decentralization, project complexity, users’ previous experience with IS could determine the degree of their involvement. Kappelman (1995) divides user involvement in two types: user process involvement and user system involvement. User process involvement refers to the psychological identification of users with the process of IS development (i.e. their subjective attitude toward the IS development task).


In addition, user system involvement refers to the psychological identification of users with respect to the information system itself (i.e. their subjective attitude toward the product of development).

7.7.2 User Participation

According to Briolat and Pogman (2000), “user participation is advocated in order to discover users’ needs and points of view, validate specifications, and hence build better IS for the organization”. Participation reflects what specific behaviors are performed, how many of these behaviors are performed, and how often they are performed (Barki and Hartwick 2001). The role of user participation in organizational activity can be viewed from the perspective of two different behavioral theories (Ives and Olson 1984). These theories are ‘planned organizational change’ and ‘participative decision-making’. The implementation of a new IS often implies a planned change in the way that an organizational unit pursues its objectives. Participative decision making emphasizes the role of individuals in working groups. Ives and Olson (1984) also outlined how user participation (at that time they named it user involvement) can improve system quality by: providing a more and complete assessment of user information requirements, providing expertise about the organization the system is to support, avoiding development of unacceptable or unimportant features, and improving user understanding of the system. Mckeen and Guimarães (1994) showed that user participation has a positive relationship with user satisfaction. They also argued that four factors affect this relationship: task complexity, system complexity, and user influence and user-developer communication. Barki and Hartwick (2001) define four dimensions of user participation:

• Responsibility – the performance of activities and assignments reflecting overall leadership or accountability for the project.

• User-IS relationship – the performance of development activities reflecting users’ formal review, evaluation, and approval of work done by the IS staff.

• Hands-on-activity – the performance of specific physical design and implementation tasks.

• Communication activity – activities involving formal or informal exchanges of facts, needs, opinions, visions, and concerns regarding the project among the users and between users and other project stakeholders.

Based in a meta-analysis study, Pettingell et al. (1988) concluded that the inclusion of users in

definition and design stages is the best way to increase their perception of the value of the system. Jiang et al. (2002) suggest that preproject partnering helps to involve users during the project and to motivate them in order to achieve project success. Preproject partnering refers to a work philosophy in which system stakeholders work together before the project begins (Cowan et al. 1992). The purpose of preproject partnering is to build a foundation among stakeholders for collaboration. In addition to identifying key stakeholders and their objectives, partnering emphasizes the activities of identifying potential conflict areas, providing a process for resolution of conflict, and incorporating a continuous improvement component in the project process. These results show the importance of involve users before the project starts and then in all the implementation phases. Figure 32 presents a summary of the constructs proposed by different


authors for user involvement and participation. These constructs are the basis for the development of our metrics program.

Beh

avio

ral s

tate

Psyc

holo

gica

l sta

te

ERPImplementation

Success

User Participation

User Involvement

Responsibility (Barki and Hatwick 2001)

User Process Involvement (Kappelman 1995)

User System Involvement (Kappelman 1995)

User-IS relationship (Barki and Hatwick 2001)

Hands-on-activity (Barki and Hatwick 2001)

Communication (Barki and Hatwick 2001)

Figure 32. Constructs proposed by different authors for user involvement and participation.

7.7.3 User Involvement/Participation in the ERP Implementation Context

In this section we try to understand user involvement and participation in an ERP implementation context. We focus on why user involvement and participation is important and how it could be done. These are some of the main reasons to involve users: maximize user acceptance, improve system functionality, and improve ERP configuration. User involvement and participation provides the project manager and the project management with an intelligent function (Kawalek and Wood-Harper 2002). Organizations intending to implement an ERP system must be willing to dedicate some of their best employees to the project for a successful implementation (Bingi et al. 1999). Bingi et al. (1999) mention that these employees should not only be experts in the business processes of the organization but also be aware of the best business practices in the industry. They should exhibit the ability to understand the overall needs of the company and should play an important role in guiding the project efforts in the right direction. These employees can play different roles in the project. Some will integrate the project team, others will be key-users and some others will be end-users that will help in specific moments according to the project needs. As Baronas and Louis (1988) mentioned, users perceived IS implementations as a period of transition during which personal control is threatened. This aspect is often detected in ERP implementation projects since in most cases these implementations are associated to changes in


their working routines. This threat may cause conflicts during the ERP implementation project and resistance to ERP system acceptance.

According to Amoako and White (1997), user involvement and participation management requires at least two forms of two-way communication: Communication between the various team members (inwards communication), and communication between project team and user or management groups (outwards communication). Not surprisingly, strong communication inwards and outwards as another CSF in ERP implementation projects (Esteves and Pastor 2000, Nah et al. 2001). This two-way communication must inform users of project changes that might affect their activities, and users must get adequate feedback on their concerns. It requires also telling and showing users that their input is valued, used and will be sought constantly, i.e. that they must be committed with the project. Amoako and White (1997) also suggest a set of guidelines in order to manage user involvement and participation.

User participation deals with the topics related to the management of their time and activities within the organization, and managers must decide how much effort these users dedicate to their usual activities and to the project, and when they do both things. Most organizations cannot afford the effort of completely sacrificing these users towards ERP project needs. Some project managers also argue that the involvement and participation of users delays the accomplishment of task schedules. Therefore, and due to time pressures, most of them decide to avoid the use of users. Esteves and Pastor (2001) studied the relevance of user involvement and participation along the phases of a specific SAP implementation project with the ASAP methodology and their conclusion is that user involvement and participation is more critical in design, realization and preparation phases. These are the phases where their know-how is very important to achieve a good fit of the ERP system to organizational needs. A detailed task where users must be especially involved is in the definition of forms and reports. Project team members must get end-user requirements, then customize forms and reports, and finally get user acceptance (Welti 1999). As Welti (1999) says, this is a time-consuming task but most of those documents represent the company image to the customer. He suggests that forms and reports should be discussed and settled with the user in the realization phase.

In order to understand the involvement and participation of users in ERP implementation projects, we analyzed a typical implementation methodology, in this case the Accelerated SAP methodology (ASAP) and its related tasks. ASAP is the methodology that is used to perform a rapid implementation of the SAP R/3 system. Other vendors provide this type of methodologies such as Baan (Dynamic Enterprise Modeler) and QAD (Qwizard). Table 44 represents the different stakeholder roles in a SAP implementation project and the five ASAP implementation phases. The ASAP methodology is structured in phases, work packages, activities and tasks. For each role we quantified the number of work packages (wp) that role is defined as “involved” in each phase. In none of the phases end-users are directly expressed as needed, except the role of the business process owner. Power (or key) users are involved in all phases except on phase one, project preparation phase. The purpose of this phase is to provide initial planning and preparation of the SAP implementation project. The steps of this phase help identify and plan the primary focus areas to be considered such as: objectives, scope, plan and definition of project team. Both, business process owners and power users are more involved in the third and fourth phases, when the system is parameterized and tested, whereas in the second phase their role is to help in business process modeling and redesign.


Table 44. Roles used along a SAP implementation project.

SAP implementation project roles

Proj

ect P

repa

ratio

n

(5 w

p)

Bus

ines

s blu

epri

nt

(7 w

p)

Rea

lizat

ion

(17

wp)

Fina

l Pre

para

tion

(6 w

p)

Go

& L

ive

(2 w

p)

Project manager 4 6 11 5 2 Project sponsor 2 2 2 1 2 Steering committee 2 3 4 1 Project team 2 2 7 3 1 Business team leader 3 4 13 4 1 Technical team leader 4 4 11 5 Consultants 4 11 4 1 IT professional (different functions) 2 11 2 End-user Power user 1 7 3 1 Business process owner 1 8 1 Key site sponsors 1 1 Line manager 1 Core change team 3 3 2 1 1 Extended core change team 2 1 1 Project risk manager ABAP developer 4 Development manager 4 SAP reviewer 2 1 1 1 SAP project manager 2 Help desk provider 1 1 1 Documentation and training developers 1 1

Paradoxically, the lack of proposed direct involvement of end-users in ASAP implementation

projects (especially in project preparation and business blueprint phases) contradicts the need to ensure that users participate in these tasks in order to improve user acceptance and to achieve project success. Usually, ERP implementation methodologies are more worried with the system implementation and they presuppose that end-users will accept the ERP system. The rest should be provided by implementation consulting methodologies.

7.7.4 A Framework for Monitoring User Involvement and Participation Proposal

Based on the literature review on user involvement and participation and ERP implementations, we propose a framework for monitoring user involvement and participation on ERP implementation projects (see figure 33). The framework takes into account the ERP implementation phases, user involvement and participation dimensions, and the different user roles in an ERP project. This framework is adapted from the framework proposed by Olson and Ives


(1980) for specifying types of user involvement. In and ERP implementation project these user roles are quite well typified in the ERP implementation methodologies.

Operating personnel

Operational managementSupervising personnel

Executive management

General controlImplementationPhysical design

System definition

Specific Activities

Stag

es in

SD

LC

Mem

bers

hip

onPr

ojec

t tea

m

Sign

off

on

proj

ect p

hase

s

Rec

eive

regu

lar

stat

us re

ports

Serv

e as

info

rmal

Lias

on to

IS st

atus

Operating personnel

Operational managementSupervising personnel

Executive management

General controlImplementationPhysical design

System definition

Specific Activities

Stag

es in

SD

LC

Mem

bers

hip

onPr

ojec

t tea

m

Sign

off

on

proj

ect p

hase

s

Rec

eive

regu

lar

stat

us re

ports

Serv

e as

info

rmal

Lias

on to

IS st

atus Team members

End-usersKey-users

IS-personnel

User process involvementUser system involvement

ReponsibilityUser-IS relationship

Hands-on-activityCommunication

Project

prep

aratio

n

Busine

ssblu

eprin

t

Realiza

tion

Final p

repara

tion

Go-Live

Post-im

plemen

tation

UserRole

s

ERP Implementation Phases

Use

r In

volv

emen

t an

d Pa

rtic

ipat

ion

Dim

ensi

ons

Team members

End-usersKey-users

IS-personnel

Team members

End-usersKey-users

IS-personnel

User process involvementUser system involvement

ReponsibilityUser-IS relationship

Hands-on-activityCommunication

Project

prep

aratio

n

Busine

ssblu

eprin

t

Realiza

tion

Final p

repara

tion

Go-Live

Post-im

plemen

tation

Project

prep

aratio

n

Busine

ssblu

eprin

t

Realiza

tion

Final p

repara

tion

Go-Live

Post-im

plemen

tation

UserRole

s


Use

r In

volv

emen

t an

d Pa

rtic

ipat

ion

Dim

ensi

ons

Olson and Ives (1980) framework for specifying types of user involvement.

Extended framework for monitoring user involvement and participation.

Figure 33. A framework for monitoring user involvement and participation in ERP projects.

We proposed that user involvement and participation metrics should be interpreted taken into consideration three dimensions: user involvement and participation dimensions, ERP user roles and ERP implementation phases. Users play different roles and have different relevance along the ERP implementation according to their roles (see table 44). Therefore, the metrics values are affected by the interrelation between these dimensions. For instance, it is expected that k-users involvement participation will be higher in design, realization and preparation phases. We defined five types of users: team members, key-user, IS personnel and end-users. Users can also be categorized by their different levels (Olson and Yves 1980): executive management (top level), operational management (middle level), supervisory personnel, and operating personnel. Although we did not mention before, other stakeholders like the ERP vendor play an important role in an ERP implementation project and it would be also desirable to analyze its involvement in the ERP implementation project. There is the evidence that some ERP projects failed in achieve good levels of all stakeholders. Regarding users activities, instead of defining them in another dimension as Olson and Ives (1980) framework, we consider them as part of the ERP implementation phases since all the ERP implementation methodologies provide a detailed explanation of work packages, activities and tasks by user role along the different ERP implementation phases.

7.7.5 Goals of the GQM Preliminary Plan

We defined two measurement goals based in our CSF, user involvement and user participation (see table 45).


Table 45. Goals for user involvement and participation CSF. Analyze User participation For the purpose of Monitoring With respect to ERP implementation project From the viewpoint of Project team In the context of ERP implementation project

Analyze User involvement For the purpose of Monitoring With respect to ERP implementation project From the viewpoint of Project team In the context of ERP implementation project

7.7.6 Questions and Metrics

For each measurement goal we defined a set of questions and related metrics (see table 46 and table 47). To define these questions we made an extensive literature review on user involvement and participation topic (see background section). The questions of user participation measurement goal are based in the Hartwick and Barki (2001) survey. We adapted this survey to the context of an ERP implementation project. For each question we defined metrics that answer the respective question. The questions for measurement goal two is related with user involvement and they arose from the literature review we made on the topic and especially on the instrument operationalized by Zaichowsky (1985) “personal involvement inventory”. This instrument was developed “to measure a person’s involvement with products” (Zaichowsky 1985, p. 349). Table 46. The definition of questions for user involvement measurement goal. Dimension Questions Involvement What is the type of involvement for each user?

There were preproject partnering activities? What is the level of involvement?

Table 47. The definition of questions for user participation measurement goal. Dimension Questions Responsibility How much responsibility did users have for estimating project and systems costs?

How much responsibility did you have for requesting additional funds to cover unforeseen time/costs overruns? How much responsibility did you have for managing the project (e.g. staffing the project team, calling and running meetings, report to senior manager, etc.)? How much responsibility did you have for overall success of the project and the system? How much responsibility did you have for initiating the project? How much responsibility did you have for determining system objectives? How much responsibility did you have for estimating project and system benefits? What specific behaviors are performed? How many of these behaviors are performed? How often they are performed?


User-project team relationship

Did the project team draw up a formal agreement of work to be done during the project? Were you able to make changes to the formal agreement concerning work to be done by the project team during the project? Did you sign off the formal agreement concerning work to be done by the project team during the project? Did you formally evaluate an information requirements analysis developed by the project team concerning the system? Did you formally review work done by the project team concerning the system? Did you formally accept and sign off work done by the project team concerning the system? Did you formally review an information requirements analysis developed by the project team concerning the system? Did you formally evaluate work done by project team concerning the system? Did you approve project timetables? Did you prepare project progress reports?

Hands-on activities

Did you [design; help to design; have nothing to do with designing] input/output forms? Did you [design; help to design; have nothing to do with designing] screen layouts? Did you [design; help to design; have nothing to do with designing] report formats? Did you [prepare; help prepare; have nothing to do with preparing] users manuals? Did you [design; help to design; have nothing to do with designing] the user-training program? Did you [train; help train; have nothing to do with training] other users to use the system? Did you [design; help to design; have nothing to do with designing] system security procedures? Did you [set; help set; have nothing to do with setting] system access priorities? Did you [determine; help determine; have nothing to do with determining] data access privileges? Did you participate in testing activities?

Communication activities

How often did you communicate informally with other users concerning the project? How often did you exchange facts, opinions, and visions concerning the project with other users? How often did you discuss your reservations and concerns regarding the project with other users? How often did your communicate informally with the project team concerning the project? How often did you exchange facts, opinions, and visions concerning the project with project team? How often did you discuss your reservations and concerns regarding the project with the project team? How often did the project team discuss their reservations and concerns regarding the project with you? How often did you communicate informally with senior management concerning the project? How often did you exchange facts, opinions, and visions concerning the project with senior management? How often did you discuss your reservations and concerns regarding the project with senior management? How often did senior management discuss their reservations and concerns regarding the project with you?



In this section we show the relationship between the questions defined above the metrics (see tables 48 and 49). Table 48. The set of metrics for user participation goal.

Dimensions Metrics Responsibility Responsibility for project estimation

Responsibility for estimating costs Responsibility for requesting additional funds to cover unforeseen time/costs overruns Responsibility for managing the project Responsibility for overall success of the project Responsibility for initiating the project Responsibility for determining system objectives Responsibility for estimating project and systems benefits Types of behaviors performed Estimated duration of behavior.

User-project team relationship

User’s participation in project plan Changes made by users to project plan Participation in project sign off Participation in evaluation of information requirements analysis Participation in sign off of information requirements analysis Participation in review meetings Participation in support meetings

Hands-on activities Participation in forms design Participation in screens layout Participation in reports format Participation in user manuals preparation Participation in training plan Participation as trainer Participation in systems security procedures Participation in system access priorities Participation in data access privileges Participation in testing activities

Communication activities

Communication between users Communication between users and project team Communication with senior managers

Table 49. The relationship between questions and metrics for user involvement. Type of user involvement 1 Preproject partnering 2

Participation Essential 3 Participation Needed Participation Desirable Participation Exciting Participation Interesting Participation Vital Participation Significant Participation Fascinating

Level of involvement

Participation Important


Participation Wanted Participation Of concern to me Participation Relevant Participation Interested Participation Valuable Participation Beneficial Participation Matters to me Participation Useful Participation Means a lot Participation Appealing

Participation trivial

7.7.8 Interpretation of Metrics

Hartwick and Barki (2001) analyzed the questions in terms of the different user roles in a project. They concluded that the role that users play on team was found to have a strong impact on overall participation, as well on each of the four participation dimensions. It is expected that users that are members of the project team have more participation than nonmembers, both overall and on each of the four dimensions. Users that become the project managers are expected to have more participation than members overall, but not similarly to other dimensions. For the responsibility dimension the difference between managers and team members was much greater than the difference observed for the other three dimensions.


7.8 Towards a Framework to Develop KPI

Based on the experiences described above, we propose a framework to develop KPI for CSF in ERP implementation projects (see figure 34).

Team members

End-usersKey-users

IS-personnel

Project

prep

aratio

n

Busine

ssblu

eprin

t

Realiza

tion

Final p

repara

tion

Go-Live

Post-im

plemen

tation

Project

prep

aratio

n

Busine

ssblu

eprin

t

Realiza

tion

Final p

repara

tion

Go-Live

Post-im

plemen

tation

UserRole

s


Cri

tical

Suc

cess

Fa

ctor

D

imen

sion

s Top Management

Figure 34. A framework to develop KPI for ERP implementations.

Our framework emphasizes the need to take into account the different stakeholders involved in the ERP implementation project and the need to take into account that the CSF relevance changes along the ERP implementation phases as we shown in chapter 5 – CSF relevance. We also think it is important the involvement and participation of the stakeholders in the KPI development process to achieve ownership and acceptance of the KPI.

After the definition of the GQM plan the measurement data should be interpreted bottom-up. “As the metrics were defined with an explicit goal in mind, the information provided by the metrics should be interpreted and analyzed with respect to this goal, to conclude whether or not it is attained” (Solingen and Berghout 1999, p. 23).

7.9 Considerations

This study attempts to define a first set of metrics for: sustained management support, business process reengineering, training, and user involvement and participation in ERP implementation projects. We think these metrics have two important proactive characteristics: metrics help to detect deviations from the project plan and to act before damage is made, and second, these metrics can have the effect of motivating and encouraging top managers in the involvement and commitment with the ERP project. The feedback from the stakeholders is important for the ERP


project team and steering committee. They can analyze the feedback and possibly incorporate improvements in the ERP implementation project plan.

The purpose of this study is not to describe an exhaustive list of metrics. Instead, we attempt to present a form to develop these metrics in future ERP implementation projects and provided the first set of metrics that should be extended and adapted according to the specific needs of ERP implementation projects. This study only provides the first step to propose a set of metrics for each CSF mentioned before.

Next steps are the validation and interpretation of these metrics. Calero et al. (2001) propose two possible kinds of validation methods that can be applied: case study or control experiments. We also think that action research method would be very useful since the researcher could participate with his knowledge on KPI and ERP implementation in the development process. We would like to remark that we are conscientious that this GQM preliminary plan will be subject to changes during the next steps of the research due to new information gathered and experience gained in the feedback sessions. Currently, we are developing a software application for the management of the metrics defined here. Additional research will attempt to define metrics to other CSF defined in the literature of ERP implementation projects.

7.10 References

Abrahamson P., Jokela T. 2000. “Development of Management Commitment to Software Process Improvement”, IRIS 23 conference.

Alliger G., Tannenbaum S., Bennet W., Traver H., Shotland A. 1997. “A Meta-Analysis of the Relations among Training Criteria”, Personnel Psychology Journal, 50, pp. 341-358.

Al-Mashari M., Zairi M. 2000. “Supply-chain Re-engineering using Enterprise Resource Planning (ERP) Systems: An Analysis of a SAP R/3 Implementation Case”, International Journal of Physical Distribution & Logistics Management, 30(3/4), pp. 296-313.

Amoako, K., White, K. 1997. “When is User Involvement not User Involvement?”, The Executive’s Journal, 13(4), pp. 40-46.

Axtell C., Maitlis S. 1997. “Predicting Immediate and Longer-term Transfer of Training”, Personnel Review, 26(3), pp. 201-213.

Bancroft N., Seip H., Sprengel A. 1998. “Implementing SAP R/3”, 2nd ed., Manning Publications. Barki, H., Hartwick, J. 1989. “Rethinking the Concept of User Involvement”, MIS Quarterly,

13(1), 53-63. Barki, H., Hartwick, J. 1994. “Measuring User Participation, User Involvement, and User

Attitude”, MIS Quarterly, 18(1), 59-82. Barki H., Hartwick J. 2001. “Communications as a Dimension of User Participation”, IEEE

Transactions on Professional Communication”, 44(1), pp. 21-35. Baronas, A., Louis, M. 1988. “Restoring a Sense of Control during Implementation: How User

Involvement Leads to System Acceptance”, MIS Quarterly, pp. 111-124. Basili V., Caldera C., Rombach H. 1994. “Goal Question Metric Paradigm”, Encyclopedia of

Software Engineering Marciniak J. ed., John Wiley & Sons, pp. 528-532 Bingi P., Sharma M., Godla J. 1999. “Critical Issues Affecting an ERP Implementation”,

Information Systems Management, 16(3), pp. 7-15


Boudreau M., Robey D. 1999. “Organizational Transition to Enterprise Resource Planning Systems: Theoretical Choices for Process Research”, International Conference on Information Systems, pp. 291-299.

Brinkerhoff R. 1988. “Achieving Results from Training”, Joss-Bass, San Francisco, USA. Briolat D., Pogman J. 2000. “User Involvement Influence on Project Productivity in a Rad

Environment: a Quasi-experiment”, European Software Control and Metrics Conference, Munich, Germany.

Brown C., Vessey I. 2003. “Managing the Next Wave of Enterprise Systems: Leveraging Lessons from ERP”, MIS Quarterly Executive, 2(1), pp. 65-77.

Calero C., Piattini M., Genero M. 2001. “Method for Obtaining Correct Metrics”, Third International Conference on Enterprise Information Systems, pp. 779-784.

Cap Gemini 1996. “Business Leader’s Experience with SAP Implementations”, Cap Gemini, www.capgemini.com

Chemical Marketing Reporter 1996. “SAP Software Implementation Works Best with Reengineering”, 250(8), p.16.

Chen I. 2001. “Planning for ERP Systems: Analysis and Future Trend”, Business Process Management Journal, 7(5), pp. 374-386.

CMU 1994. “Capability Maturity Model”, Software Engineering Institute, CMU/SEI-94-HB-1, appendix 6.

Conner D., Patterson R. 1982. “Building Commitment to Organizational Change”, Training and Development Journal.

Cowan C., Gray C., Larson L. 1992. “Project Partnering”, Project Management Journal, 22(4), pp. 5-11.

Davenport T., Short J. 1990. “The New Industrial Engineering: Information Technology and Business Process Redesign”, Sloan Management Review, summer 1990.

Davenport T. 1993. “Process Innovation: Reengineering Work through Information Technology”, Harvard Business School Press, Boston.

Davenport T. 1998. “Putting the Enterprise into the Enterprise System”, Harvard Business Review, July-August, pp. 121-131.

DeCotiis T., Summers T. 1987. “A Path Analysis of a Model of the Antecedents and Consequences of Organizational Commitment,” Human Relations, 40, pp. 445-450.

Dong L., Ivey R. 2000”A Model for Enterprise Systems Implementation: Top Management Influences on Implementation Effectiveness”, Americas Conference on Information Systems.

De Bruin P. 1997. “Unpublished 1997 Sapphire Conference Notes” in Gibson and Mann 1997. Earl M. 1994. “The New and Old of Business Process Redesign”, Journal of Strategic Information

Systems, 3(1), pp. 5-22. Esteves J., Carvalho J., Santos A. 2001. “Towards an ERP Lifecycle Costs Model”, Information

Resources Management Association IRMA. International Conference, Toronto Gibson J., Mann S. 1997. “A Qualitative Examination of SAP R/3 Implementations in the Western

Cape”, research report, University of Cape Town. Ginzberg M. 1981. “Key Recurrent Issues in the MIS Implementation Process”, MIS Quarterly,

5(2), pp. 47-59. Green S. 1995. “Top Management Support of R&D Projects: A Strategic Leadership Perspective”,

IEEE Transactions on Engineering Management, (42:3). Goldstein I. 1993. “Training in Organizations”, Brooks/Cole, Pacific Grove Ca.


Gupta A. 2000. “Enterprise Resource Planning: The Emerging Organizational Value Systems”, Industrial Management & Data Systems, 100(3), pp. 114-118.

Hammer M., Champy J. 1993. “Reengineering the Corporation: A Manifesto for Business Revolution”, HarperCollins, New York.

Hirt S., Swanson E. 1999. “Adopting SAP at Siemens Power Corporation”, Journal of Information Technology, pp. 243-251.

Holland C., Light B., Gibson N. 1999. “A Critical Success Factors Model for Enterprise Resource Planning Implementation”, European Conference on Information Systems, pp. 273-279.

Jarrar Y., Aspinwall E. 1999. “Business Process Re-engineering: Learning from Organizational Experience”, Total quality management, 10(2), pp. 173-186.

Jarvenpaa S., Ives B. 1991. “Executive Involvement and Participation in the Management of Information Technology”, MIS Quarterly, pp. 205-227.

Jiang J., Chen E., Klein G. 2002. “The Importance of Building a Foundation for User Involvement in Information System Projects”, Project Management Journal, 33(1), pp. 20-26.

Jih W., Owings P. 1995. “From In Search of Excellence to Business Process Re-engineering: the Role of Information Technology”, Information Strategy, 11, pp. 6-19.

Jurison J. 1999. “Software Project Management: The Manager's View”, tutorial, Communications of the Association for Information Systems, 2(17).


Kappelman L. 1995. “Measuring User Involvement: A Diffusion of Innovation Perspective”, The Data Base for Advances in Information Systems, 26(2/3), pp. 65-86.

Kappelman, L., McLean, E. 1991. “The Respective Roles of User Participation and User Involvement in Information Systems Implementation Success”, International conference on information systems, New York, 339-348.

Kawalek P., Wood-Harper T. 2002. “The Finding of Thorns: User participation in Enterprise System Implementation”, The Data Base for advances in information systems, 33(1), pp. 13-22.

Kettinger W., Teng J., Guha S. 1997. “Business Process Change: A Study of Methodologies, Techniques, and Tools”, MISQ, 21(1), pp. 55-80.

Kirkpatrick D. 1998. “Evaluating Training Programmes: The Four Levels”, Berrett-Koechler Publishers

Koch C. 1996. “Surprise, Surprise”, CIO magazine, June 15, 1996. Kraemmergaard P., Moller C. 2000. “Evaluation of ERP Implementation: A Case-Study of an

Implementation”, International Conference on Information Systems Analysis and Synthesis, Florida, USA.

Lillrank P, Holopainen S. 1998. “Reengineering for Business Option Value”, Journal of Organizational Change Management, 11(3), pp. 246-259.

Mann S., Robertson I. 1996. “What Should Training Evaluations Evaluate?”, Journal of European Industrial Training, 20(9), pp. 14-20.

Martin I., Cheung Y. “SAP and Business Process Re-engineering”, Business Process Management Journal, 6(2), 2000, pp. 113-121.

McAlary S. 2000. “Three Pitfalls in ERP Implementation”, Strategy &Leadership Magazine, October/November/December, pp. 49-50.


Mckeen J., Guimarães T. 1994. “The Relationship Between User Participation and User Satisfaction: An Investigation of Four Contingency Factors”, MIS Quarterly, 18(4), pp. 427-452.

Meyer J., Allen N. 1991. “A Three-component Conceptualization of Organizational Commitment”, Human Resource Management Review, 2(1), pp. 61-89.

Miller G. 1999. “ERP Implementation Lessons Learned”, white paper, Proaction Management Consultants

Nah F., Lau J., Kuang J. 2001. “Critical Factors for Successful Implementation of Enterprise Systems”, Business Process Management Journal, 7(3), pp. 285-296.

Newman M., Sabherwal R. 1996. “Determinants of Commitment to Information Systems Development: A Longitudinal Investigation”, MIS Quarterly, 20(1), pp. 23-54.

Nickols F. 2000. “Evaluating Training: there is no ‘Cookbook’ Approach”, Distance Consulting Company.

Olson M., Ives B. 1980. “Measuring User Involvement in Information System Development”, International Conference on Information Systems, pp. 130-143.

O’Reilly C., Chatman J. 1986. “Organizational Commitment and Psychological Attachment: The Effects of Compliance, Identification, and Internalization on Prosocial Behaviour”, Journal of Applied Psychology, 71, pp. 492-499.

Pettingell K., Marshall T., Remington W. 1988. “A Review of the Influence of User Involvement on System Success”, 9th International Conference on Information Systems.

Purba S., Sawh D., Shah B. 1995. “How to Manage a Successful Software Project”, John Wiley & Sons.

Sandoe K., Corbitt G., Boykin R. 2001. “Enterprise Integration”, John Wiley & Sons. Soliman F., Youssef M. 1998. “The Role of SAP Software in Business Process Reengineering”,

International Journal of Operations & Production Management, 18(9/10), pp. 886-895. Solingen R., Berghout E. 1999. “The Goals/question/Metric Method: A Practical Guide for Quality

Improvement of Software Development”, McGraw-Hill. Taylor J. 2000. “Participative Design: Linking BPR and SAP with an STS Approach”, Journal of

Organizational Change Management, 3(11), pp. 233-245. Tjaden G., Narasimhan S., Mitra S. 1996. “Structural Effectiveness Metrics for Business

Processes”, working paper, the Center for Enterprise Systems, Georgia Institute of Technology.

Wee S. 2000. “Jugling Toward ERP Success: Keep Success Factors High”, ERP News, February 2000.


Wheatley M. 2000. “ERP Training Stinks”, CIO Magazine, June 2000. Whitman M., Gibson M. 1997. “Factors Affecting the Use of Information Technology in Business

Process Reengineering”, Information Resources Management Journal, 10(3), pp. 5-16. Wortmann J. 1998. “Evolution of ERP Systems”, in U.S. Bititci and A. S. Carrie eds..,

Proceedings of the International Conference of the Manufacturing Value-Chain, Kluwer Academic Publishers, pp. 11-23.

Yap C., Soh C., Raman K. 1992. “Information Systems Success Factors in Small Business”, Omega, 20(5/6), pp. 597-609.

Zaichowsky, J. 1985. “Measuring the Involvement Construct”, Journal of Consumer Research, 12, pp. 341-352.

Chapter 8 – Confirmatory Case Study 204

Chapter 8


Chapter Summary: This chapter describes an in-depth case study of an ERP selection and implementation in a public Higher Education Institutions (HEI. This chapter addresses the problem of ERP implementation in HEI. It attempts to contribute to the understanding of ERP implementations inthis kind of organizations by identifying and analyzing the major factors that affect this type ofprojects. Special attention has been paid to contextual influence and to organizational factors. Furthermore, this case study helped to validate the theory developed and the research propositionsdefined in previous chapters. We also compare the findings of this case study with the pilot casestudy. Finally, we present an analysis of the CSF relevance along the ERP implementation phases of this case study.


Thesis Introduction


Research Design






CSFsIdentification


CSFsIdentification




ERP Context

8


8.1 Introduction

In recent years, a growing number of Higher Education Institutions (HEI) worldwide are exploring the use of ERP systems as a means of supporting their organizational processes while through linking areas like financial, real estate, and staff management, management of students and the support of teaching and learning. This adoption of ERP systems by HEI is bringing up problems in ERP implementation projects which are specific to this type of organizations. Since HEI comparatively have modest IT/IS resources and budgets they expect to benefit largely from implementing software package application products like ERP systems. They do not usually have the experience and a constant availability of adequate expertise to be able to handle the in-house development of an enterprise wide system.

This chapter reports the results of an in-depth case study carried out in a Spanish HEI that implemented an ERP system in 2001 by following a big-bang implementation approach. The big-bang approach is characterized by the go live of all implemented ERP modules at the same time. The interpretive paradigm adopted in our research reflects our aim for understanding the phenomenon of ERP implementation in a HEI within the full fledged organizational context where it occurs. In order to keep the confidentiality of the research site and the people involved in this case study, we have deliberately omitted the name of the institution and ERP product. The chapter is structured as follows. First we present the literature review on ERP in HEI. Then, we describe the case study context. Next, we present the research methodology. Subsequently, we describe the findings. Then, we compare the findings of this case study with the findings of the pilot case study described in chapter 6. Next, we analyze the CSF relevance in this case and we compare it with the findings of chapter 5. Finally, some conclusions are outlined.

8.2 ERP in Higher Education Institutions: Literature review

The implementation of ERP within HE sector started in United States HEI and colleges in 1996 with the aim of improving and integrating the administrative processes in student registration, human resources systems and financial processing (Frantz et al. 2002). Then, HEI-ERP rapidly grew worldwide with the aim of improving HEI administrative systems and efficiency while at the same time providing a focus on customer service and embracing of e-commerce strategies (Van Dyke and Sinclair 2003). Van Dyke and Sinclair (2003) identified on the literature some important issues regarding ERP implementations in HEI. One of the most important issues is the organizational change management issues that are new for universities, because these systems were primarily designed for corporate non-university organizations. The authors point out the need to research about how to successfully implement business systems (such as ERP systems) in non-business settings such as HEI. Currently the number of studies of ERP implementation in HEI is small but growing. The studies undertaken have addressed different topics such as:

• Reasons to adopt an ERP by universities (Oliver and Romm 2000). • ERP implementation strategies (McCredie and Updegrove 1999, McConachie 2001).


• Critical success factors in an ERP implementation project in an Australian university (Nielsen 2002a).

• ERP customization versus standard implementation (Noyes 2003). • Analysis of a multicampus implementation (Solis 2003). • ERP implementation best practices (Swartz and Orgill 2001, Frantz et al. 2002, Rigelhof

2003). • ERP implementation in small universities (Yakovlev 2003). • Knowledge management issues (Nielsen 2002b). • Change management issues (Chatfield 2000). • The impact of ERP systems on an organization’s culture (Beekhuyzen 2001). • User acceptance (Mayer 2000).

Overall, the HEI practitioner on ERP is prevalent with thirteen articles published between 1998

and 2002 in the two EDUCAUSE journals (Wagner 2002, p. 49). The 2003 survey conducted by EDUCASE (Crawford and Rudy 2003) shows that ERP systems/administrative systems is ranked as the second most important issue for EDUCASE members. Crawford and Rudy (2003) present a list of problems to be addressed in the future:

• Understanding of which technological and functional factors are driving the ERP solution. • Analysis of the service and process improvement associated with a successful

implementation. • Executive leadership commitment to support an ERP project. • Migration to an environment characterized by shared data repositories versus traditional

central data ownership. • Integration with other existent systems. • Adaptation of business processes to the embedded best practices configured in an ERP

system. • Involvement and participation by a broad representation of stakeholders. • Adequacy of internal personnel resources for the ERP project. • Implementation partner selection. • Definition of the ERP project plan for the specific case of HEI. • Benefits of the ERP post implementation phase.

8.3 Case Study Context

The Spanish HEI of our case study defines its mission in terms of quality teaching, research and technology transfer, it was created in the 70’s and it is composed of several academic schools, and research institutes with more than 30.000 students, and more than 2.000 teachers.

The HEI Economics Management area is composed of two general departments, the Economics Department and the Technology Transfer Unit. There also is Economics Management personnel in each structural unit. Until 1999, both the Economics Department and Technology Transfer Unit had their own legacy systems which were totally independent. The units (schools and institutes) were responsible for sending the accounting documents to the Economics Department or


Technology Transfer Unit and these departments processed them in the respective legacy systems. Table 50 describes the different actions taken to improve IT infrastructure in our studied HEI. Table 50. Information technology evolution in SHEI. Period Actions Until 1998 • Diverse legacy systems for different purposes in Economics Management.

• No connection between the legacy systems. • Different Economics Management procedures within the Economics Management

area. Beginning 1998 • Analysis of legacy systems upgrade or adoption of an ERP system due to Y2K

problem, Euro conversion, and maintenance costs. • Selection of an ERP system.

End of 1998 • Decision to adopt the ERP system. • Selection of the ERP implementation consulting company.

1999-2001 • Beginning of ERP implementation project. • Adaptation of the IT infrastructure.

8.3.1 ERP Implementation Phases

This HEI followed a typical big-bang ERP implementation approach with a well known European ERP package. The number of expected end-users was around 220. The HEI implementation project followed the typical implementation phases (see table 51): planning, design, realization, and go-live and support. At the beginning of the project, it was estimated that some be-spoke development would be made to fulfil some special requirements. Table 51. ERP implementation phases in SHEI.

Phase Description Planning This was the basis for the entire project. The goal of this phase was to detail the project

definition and its functional needs. The project structure was defined. This phase was arduous due to three main aspects: the definition of all processes that attempted to be implemented in the new system, contact with all the process stakeholders, and the difficulty to obtain information.

Design The goal of this phase was to produce the technical specification of how to implement the chosen solution and the beginning of the parameterization and the preparation of a prototype that allowed the demonstration of the system working for each planned situation. This phase was felt as fundamental for the system comprehension since the internal project team took its first contact with the ERP system.

Realization The goal of this phase was to obtain the configuration of the ERP system according to the design, the development of some complementary programs that served as interfaces to ERP, and the creation of training manuals and final tests.

Go live & Support

The goal of this phase was to put the new system at work. The go-live phase was started a month behind schedule given some changes in the scope of the project. The expressions “the company will stop” or “it will not work” were in the mind of everyone, but everything worked perfectly. At the end of this phase an analysis of the general difficulties of the ERP implementation project was made.

This ERP project had a delay of one year in relation to the initial project plan (see figure 35).


Teamcomposition

Design Realization Final Preparation Go

Feb. May. Sep. Dec.1999 20001998

ERPSelection

ConsultingSelection Project Planning Implementation Go

2001

Project plan proposal

Real project duration

Figure 35. ERP project duration in SHEI.


In the confirmatory case study research design we followed the same research procedures as in the pilot case study (see chapter 6 - pilot case study). Again, in order to identify the organizational factors that affect an ERP implementation in a SHEI we opted for an interpretive research approach.

8.4.1 Data Collection

The SHEI President (vice president at the moment of the ERP implementation) and the ERP project manager were initially contacted in order to accept to collaborate in this research project and to permit the study to be carried out. After permission has been obtained, the project manager granted access to several documents produced during the project. Later, she was asked to be visited and interviewed as well as other persons that played relevant roles during the ERP implementation project. Our first task was to analyze the documentation created during the ERP implementation project that was made available by the project manager. The project documentation helped to understand the project background and to prepare the questions for the interviews. The project documentation was analyzed following the Grounded Theory (GT) method procedures (see below). The technique used for data collection was semi-structured interviews. Following the contact with key informants in the company, interview schedules were agreed upon. Interviews were tape recorded and transcribed to ensure accuracy of written data, and to minimize researchers’ bias. Initially, we interviewed the ERP project manager. Then, we interviewed the remainder members of the project team. The interviews lasted approximately one hour with the exception of the project manager interview that lasted around two hours. Immediately after each interview, detailed field notes or memos were written. A memo is “the researcher’s record of analysis, thoughts, interpretations, questions, and directions for further data collection” (Strauss and Corbin 1998, p. 110). Data from interviews were then triangulated with the documentation so


far accumulated. We also had several informal talks with the interviewees after the initial interview.

8.4.2 Data Analysis

In order to build theory from this case study, we adopted the Grounded Theory (GT) method. For a detailed explanation of GT method see chapter 3 - research design and chapter 6 – pilot case study. The GT method has three main phases: open coding, axial coding, and selective coding. Next, we describe in detail each one of these phases.

8.4.2.1 Open Coding

We first analyzed the literature on ERP systems and the ERP project documentation which helped to develop a preliminary list of categories. One of the researchers started coding as soon as transcripts from the first interviews became available. Then, the other researcher analyzed the coding process. Disagreements on coding were settled through consultation between researchers and in some cases, with additional input from interviewees and documentation to the ERP project or searched from the net.

The coding process of all interviews and project documentation allowed major themes/categories to emerge. Again, we used as priori categories the list of CSF for ERP implementations and the categories of the pilot case study. These categories facilitated but not constrained the data analysis since the categories were validated with the data gathered. Sub-categories for these categories emerged from the data and they provided a deeper explanation of the management and relevance of critical success factors in ERP implementations. During the open coding phase we wrote code notes (another form of memos) to explain how some concepts emerged. Since data collection and data analysis form an iterative process in GT method, analysis of the first data helped to improve the next interviews and to focus and to obtain more information about new ideas that were raised in early interviews.

8.4.2.2 Axial Coding

In this phase we followed the paradigm model proposed by Strauss and Corbin (1990). The paradigm model is described in detail in chapter 6 – pilot case study.

8.4.2.3 Selective Coding

Selective coding is the process of choosing one category to be the core category, and relating all other categories to that category. The essential idea is to develop a single storyline around which everything else is draped. To ensure credibility and validity of the GT process, we asked some colleagues for their feedback in some early versions of the GT report. Their suggestions were incorporated on the final report. Finally, we sent a copy of the final report to the interviewees and we asked them for feedback on the generated theory. Some of the interviewees provided additional information to clarify some aspects. All the suggestions were included in the final report. The findings of the GT application are described below.


8.5 A Grounded Theory Model for ERP Implementations

In this section we describe the specific paradigm model (see figure 36) that we developed by using GT from the data collected from our case study.

Euro conversion,Y2K problems

ERP system adoption







ERPImplementation

in a HEI

TechnologicalCSFs

OrganizationalCSFs

TacticalCSFs

StrategicCSFs


ERP Market


expertise

Newhardware

infrastructure


Organization structure changes Inadequate

business processes


Legalrequirements


Technological• New ERP projects• ERP maintenance• Internal ERP knowledge

Euro conversion,Y2K problems

ERP system adoption







ERPImplementation

in a HEI

TechnologicalCSFs

OrganizationalCSFs

TacticalCSFs

StrategicCSFs


ERP Market


expertise

Newhardware

infrastructure


Organization structure changes Inadequate

business processes


Legalrequirements


Technological• New ERP projects• ERP maintenance• Internal ERP knowledge

Figure 36. A model for ERP implementation projects.

8.5.1 Phenomenon

Strauss and Corbin (1990, p. 101) stated that phenomena are “the central ideas in data represented as concepts”. According to their account, the purpose behind naming phenomena is to enable researchers to group similar events, happenings, and objects under a common heading or classification. The phenomenon in the paradigm model is represented by the central category


(sometimes called core category), which represents the main theme of the research. The phenomenon addressed in this study is the implementation of an ERP system in a HEI.

8.5.2 Causal Conditions

Based on the project documents and the interviews, we identified the following reasons to adopt the ERP system:

• Legacy systems obsolescence. The existent legacy systems were technologically obsolete in terms of operating systems and the software language used. The legacy systems were developed in the middle 80s and their databases were designed and maintained independently, which manifested conceptual differences and their coordination was made, mainly through documentation in paper support

• Maintenance process complex and expensive. The previous systems could only respond to new legal and functional requirements by means of in-house perfective, corrective and adaptative maintenance. Besides the legal and circumstantial changes (Y2K, Euro conversion), usually there was a high number of petitions of changes on the part by the end users. These facts converted the maintenance task of the previous systems increasingly complex and expensive, especially due to be carried out on obsolete systems and technologies.

• Y2K Problem and Euro conversion. The previous systems should be adapted to avoid the related with the Y2K and the euro conversion. This change would be complex and expensive due to its longitudinal impact in the whole extension of the functionality offered by such systems.

• Existence of an isolated system in the Technology Transfer Unit. The Technology Transfer Unit had its own IS which did not incorporate public sector treasury, something legally required for public institutions and it was not appropriately integrated with the rest of the Economics Management processes of the SHEI.

8.5.3 Environmental Context

By the time ERP implementation at our HEI took place (beginning 1999), none of the Spanish universities were implementing ERP systems. However, most of Spanish universities were thinking about improving their information systems possibly through abandoning their legacy systems and migrating to ERP systems. Again, problems related with the Y2K problem and the new Euro currency were viewed as strong justifications for carrying out deep changes in information systems. At that time ERP vendors started approaching the HEI market and they began to offer ERP solutions adaptable to the HEI market.

The Spanish government also started changing legal requirements and obligations in terms of financial reporting, especially with regard to budget control.

8.5.4 Organizational Context

The organizational culture of our studied HEI is characterized as a bureaucratic culture. According to Wallach (1983), bureaucratic cultures have clear lines of responsibility and authority,


work is highly organized, compartmentalized and systematic. The information and authority flows are hierarchical and based on control and power. Overall, bureaucratic companies tend to be mature, stable and relatively cautious.

Our HEI possesses a culture where most of the times, delays in decision making and expected results are explained in terms of “due to the process” which refers to the high procedure orientation within this HEI. In this context, it was expected from top management that the ERP implementation would change the way things worked in the organization. However, there was the general perception that organizational culture would not let the achievement of the maximum benefits from the ERP system, mainly due to the lack of power of some of the involved units.

8.5.5 Information Technology Context

SHEI realized that existing systems did not support its strategy. As mentioned before, SHEI legacy systems were quite old, its IT infrastructure had become quite rudimentary, and part of its personnel had a low level of computer competences (see case study context section).

8.5.6 Intervening Conditions

Since an adequate project manager role is one the ERP implementation CSF, we describe this aspect in the next section – actions/interaction strategies. The HEI started the selection of the consulting company after the selection of the ERP system. The main arguments for selecting the consulting company were: ERP vendor recommendation, and experience on ERP implementation in the public sector. At the time of the implementation project this consulting company lacked senior personnel in the ERP implementation area, a fact that was then unknown to the HEI.

8.5.7 Action/ Interaction Strategies

In the action/interaction strategies we used as a priori categories the CSF from the unified model first proposed in chapter 4. Although some studies such as Nielsen (2002) have tried to identify critical success factors specific for HEI projects, we opted by our generic model for ERP implementation projects. Next, we describe the findings according to each CSF.



According to the interviewed actors, in the case of the SHEI the continuous support of the top management was exercised specifically by the then vice-president of the university. It was he the one that participated more actively in the ERP implementation process, mainly after the initial deviation regarding the first project plan. A member of the team commented in this way the initial involvement of the vice-president: “More than anything it was that we were blocked, and it was he who made us leave. Little by little he started defining tiny, good objectives... this goes for tomorrow, then, two weeks these other tiny goals, and he was controlling their realization, if not


(laughs)…” Also, the vice-president participated in almost all the meetings of the steering committee; he motivated the project team and contributed with his knowledge about the operation of the university, both at the general level and in terms of its financial management.

According to some interviewees, at that time, top management in general, including provost, vice rectors and president, played a more political action than a management one, which complicated some decision making processes. Some interviewed actors think that top management should have had more authority during the ERP project in order to realize some organizational changes.

The large size of SHEI with organizational structure frontiers very well defined, and the high levels of management autonomy from the organizational units, clashed with the transversal and integrative nature of a solution like an ERP system. At the beginning of the project, some organizational unit managers showed their adversity to the pursued organizational change.

At that moment, the vice-president role was crucial as a mediator during some tensions arising from resistance to change. A member of the steering committee manifested that “... a project of this type was not high-priority for the university”. Initially, the top management presented the ERP project like a project bounded for the Economics Management area; they did not look at it as a strategic project for the whole university.

Effective organizational change management

According to the implementation consulting company, the change management process was in charge of the SHEI, because the SHEI decided to assume this task instead of hiring it from the consulting company. In that sense, one of the vice-president initiatives was to create three working groups: a group for the analysis of functional skills and competences, another group for planning training, and a third group for the definition of processes. The first two groups obtained useful results but after the go-live of the new ERP system, although without establishing adequate relationships between them, while the third group did not conclude with results that could be used in the ERP implementation project, neither before or after go-live. Some interviewees say there was lack of coordination among the three working groups, and that they should have begun their respective tasks before the beginning of the ERP implementation project, or at least in its beginnings.

Good organizational change management implies that there must be an integrative project vision, built with the support of the organizational units. However, several interviewees commented things like “it was a project of the Economics Department and as such, the project was responsibility of them”. But the evolution of the project has confirmed that the implications have reached to the whole management of the SHEI, and many problems have emerged which initially were not acknowledged as related with the ERP implementation project.

A member of the steering committee indicated that the responsibility of this committee from the beginning was the supervision of the system implementation at operational level, starting from a project team and an initial project plan previously established by top management and the consulting company. Equally, the steering committee could not impact in the established working groups neither it was coordinated appropriately with them.

One of the main changes pursued by top management with the help of the ERP project was the integration and standardization of Economics Management criteria and information along all the structural units of the SHEI. Such purpose has been only partially achieved due to the disparity of


viewpoints and stances on its opportunity, from units totally agreeing to others initially against this standardization.

In the most favorable side, the Economics Department had come out very optimistic expectations in the project, not because of the ERP system itself but rather to the situation of obsolescence of its own legacy system and for the opportunity, according to some interviewees of taking advantage of the ERP implementation project to carry out an internal reorganization of the unit.

In the other end, some of those unit managers that showed from the beginning a rejection to the system made it mainly for three reasons: first, because they knew some bad experiences of ERP implementations in non academic organizations; second, because they were already sufficiently satisfied with the Economics Management functionality locally offered by their respective dedicated and isolated legacy systems; and third, because they did not see justification to change their local Economics Management processes. These three reasons were argued in a very explicit way in the case of the Technology Transfer Unit.

On the level of change achieved, while some interviewees say that they lacked political will to force some changes that were according to them justified, most of the interviewees manifest a satisfactory general opinion, with comments like the following one: “given the culture of this university, getting everything integrated [with respect to Economics Management processes] in an unique system, although some errors exist and in some cases the system was customized, it is a victory for those responsible for the project.” Another interviewed actor commented in this respect: “for these things to happen, I am sure that there was a lot of negotiation power that had to be used by top management, because there were many tensions.”

On the planning and materialization of the change management associated to the ERP project, widespread agreement exists about the convenience of having approached the change management analysis and preparation tasks before the beginning of the implementation project, instead of addressing it during the implementation, mainly in what refers to the integration and standardization of Economics Management criteria and information among units. In this line, a member of the project team comments: “... but of course that would mean for some units to admit that they had repeating tasks, and if these tasks were eliminated or moved to another unit, they [some unit managers] would stop to have so much influence and they would loose some organizational power, and there would not be justification for so many employees in some units...”.

Good project scope management

The interviewed actors said that, in general, the project scope has been approximately the same defined at the beginning. With enough flexibility, the project manager and the steering committee had agreed in a justified way to make some incorporations and changes in the implementation priorities of some functionalities and modules. For example, in the middle of the project they decided to incorporate the inventory management module which was not initially planned. Regarding the flexibility in project scope management, some actors manifest the lack of documentation about the decisions taken and lack of justifications in terms of functionality to be implemented, incorporations of new functionality, priority changes, etc., having these actors the impression of certain improvisation or decision making on the march.


Adequate project team composition

With the exception of the software vendor role, the project team has covered the rest of areas of interest along the whole project. However, the unanimous opinion, including that of the interviewed implementation consultants, is that the excessive turnover of the implementation consultants complicated the implementation process. With regard to the internal project team, almost all their members continued doing their full working activities in parallel with the ERP project. This factor complicated the progress of the project, diminished the satisfaction of team members, and it is given as a justification for the little and poor cooperation of these members with the external implementation consultants.

Following the same line of previous IS/IT outsourcing decisions, top management decided to not create an internal team of experts in the implemented ERP system because they decided to outsource the future ERP system maintenance. Given the nature of the implementation carried out, this strategy is questioned by many actors that consider the current situation as one of excessive dependence with regard to the implementation consulting company. Even one of the external consultants comments that “... if I could request a whish list of things, I would like to start the project [of the SHEI] with two internal consultants working with us like we have made in some clients of the private sector. It would be like…we select one or two employees and we remove them from their working activities, and we recruit another one [from the market] and we also provide him to you”

According to some interviewees, the transfer of knowledge towards the external consultants should have been made through the IT/IS department personnel specialized in Economics Management and initially assigned to the project. These people knew extensively the needs of Economics Management, the limitations of the existent legacy systems and some of the limitations of the ERP systems. However, the IT/IS department avoided totally any implementation tasks from the beginning of the project, limiting its intervention to offer services related with the technological infrastructure. Several interviewed actors, among them some from the IT/IS department, relate such avoidance with the process of outsourcing the IT/IS functions to a new IT company owned by SHEI, whose business model was not at odds with the maintenance of business applications. Some opinions point out an additional reason for such attitude from the IT/IS department: the incorporation of an external project manager for the ERP implementation project, in detriment of an internal leadership from the IT/IS department.

Initially, the consulting company intended to constitute a steering committee with wide and open intervention. According to a consultant, “... then the number of people was reduced [by SHEI] first for incompatibility reasons... a very democratic forum is good, but for certain things it is difficult to decide between 20 people, in order to make decisions we had to be less people. A second reason for such a reduction was work load, since the day-by-day demonstrated there were people that could be devoted to this project and other people that could not. And to have people, units, and so on, it was complicated because they had their work also far away from here in some cases…it was complicated”. The same consultant defines that starting position of the SHEI as pragmatic, although he considers that it was taken to an extreme reductionism, since during almost the whole project most of the steering committee and project team participants were practically the same people. Other interviewees agreed with this aspect, and some members of these groups complain about the insufficient representation of the structural units in the project team and the steering committee.


Comprehensive Business Process Reengineering

Before starting the ERP the implementation, the steering committee commissioned a project team member to model the existent Economics Management processes, task that he completed during the first phase of the implementation project. After the analysis of the Economics Management processes, a redesign of some Economics Management processes was made without still considering the ERP system. Based on the generated documentation, the external consultants extended the analysis of processes before starting the system configuration phase. With this they obtained the “as-is” analysis that already incorporated some improvements based on the use of the functionality of the ERP system.

According to most of the interviewees, after the “as-is” analysis, both the “to-be” analysis (description of the redesigned processes) and the “gap-analysis” (description of the differences between the previous processes and the pursued ones) were made on the march for each Economics Management process approached, and immediately configured on the ERP system. This incremental focus did not allow the creation of a global transversal model of Economics Management that would include most of the processes analyzed before their configuration. In general, the result was that it was preferred to adapt the ERP system to the existent processes that on the contrary.

During the functional analysis phase, no method or modeling tool was used; neither the final model of Economics Management processes was documented. This contributed for the fact that currently there is no documentation on the processes analysis. According to some interviewees, the ERP implementation carried out did not take the opportunity to deeply reengineer the Economics Management processes, task not yet done and which they consider necessary in a short term. One of the interviewees comments on the topic: “an organizational change [it is needed] even deeper of that the one made, and that the units wanted, and that nowadays in some places they recognize that it should have been made. A university with a budget like ours and with more than two hundred dedicated people to Economics Management, no [it is not efficient], I mean, the existent organization for the Economics Management... is too big”. According to the then vice-president, “in those moments the resistance to the ERP project was such that it was considered preferable to look for an intermediate point in the improvement of processes instead of aiming at radical changes”.

With regard to the tensions around the analysis and possible process changes, the case of the Economics Management processes associated with the Technology Transfer Unit deserves a special attention. Contrary to what happened in other areas, Technology Transfer Unit had an extensive and detailed list of requirements for the new system, requirements that already described the functionality offered by its existing dedicated system. In the steering committee often the people responsible for this unit showed their strong rejection to change their processes and their system in favor of the new ERP solution.

Several actors think that with this aspect, a true abyss appeared among the philosophy of operation of the ERP standard for Economics Management, and philosophy and practices of Economics Management carried out by Technology Transfer Unit. Those practices were very well covered by its legacy system but they were more Economics Management approaches of private company rather than a public institution. One of the interviewees comments in this respect: “to them [Technology Transfer Unit] it has supposed that they should acquire the mentality of the concept of budgetary accounting that bears to understand that there are budgetary transactions. The


problem is that they did not want to understand it. Income and expenses and there is nothing more”.

An interviewee expressed his vision on the position of Technology Transfer Unit: “... they had implemented their customized system which had been developed for them, they cooked it, they ate it up, and they modified it, they were so autonomous and so free of everything, everything, of all control that obviously they were very happy.” A member of the project team adds another reason for the rejection from Technology Transfer Unit: “... to integrate everything in an Economics Management model for the SHEI meant to find repeated processes, and to eliminate them, and clearly that means possible loss of personnel, autonomy, and organizational power”. Finally, a third reason pointed out by another interviewee was the rejection of Technology Transfer Unit to decentralize part of its processes towards the units and towards the Economics Department. Another interviewee insisted in “... the fear to the loss of power clearly, was to break a speech that they had maintained at institutional level, that they were those that dealt with all the [research] projects of the university, well... it is true that finally they do, the same as it is true that the Economics Department deals with all the financial issues of the university”.

The Technology Transfer Unit case has been the most conflicting topic in the whole ERP implementation project in the SHEI. After many meetings, debates and tensions, the ERP implementation in Technology Transfer Unit has become a set of bespoke developments around the ERP system, rather than an ERP configuration starting from the ERP standard. On the other hand, the current system has facilitated a bigger integration between the Technology Transfer Unit and other units.

Adequate project sponsor role

Officially, the figure of ERP project sponsor did not exist. However, there is overall agreement that the then vice-president acted as such. One of his crucial functions was to act as mediator among the parts. He helped to energize the activities of the team, to define objectives and to reach small goals, and she contributed decisively in the resolution of the most conflicting situations. As expert on the management model of the university, because he lived the whole process of its creation, the vice-president helped to the people that represented central departments such as Economics Department. The units were listened and they worked together, working out consensus from some initially opposed ideas. According to some opinions, there was a lack of formal monitoring and controlling along the project.


The project manager was hired after the selection of the ERP system and the implementation consulting company, and also after the creation of the initial project team. The project manager comments that this circumstance by itself already limited his initial performance. His external origin on one hand helped him to maintain neutral positions in relation to some organizational conflicts, but on the other hand it was an initial inconvenience for understanding the organizational culture of the university. There is agreement among the interviewees in the convenience of incorporating somebody external to the organization to manage a project of this type.

A positive aspect of the project manager, commented by diverse actors, was his open attitude to discuss and to solve conflicts, always trying to follow the legal mechanisms and the appropriate


procedures for Economics Management. The main negative aspect indicated by most of the interviewees was his lack of previous experience in ERP implementation projects.

Some interviewees mentioned the sensation of lack of monitoring and formal control of the project transmitted by the project manager and the project team in some moments. The project manager and the consulting company did not adopt any implementation methodology, which is also behind the projected uncertainty. In the same sense, they did not use in this project the typical checklists usually used at the end of each implementation phase. The implementation consulting company argues that these lists were not adapted to the project since it was a pioneer project in this industry. However, it did not propose any adapted checklist that would have improved the project control. According to the project manager and other interviewees, the project did not receive help in terms of project management from the consulting company since the assigned consultants had a more functional profile than a project management profile.


The implication and wider participation of users refers, according to the interviewees, to the end users of Economics Department and Technology Transfer Unit. According to the project documentation and the opinion most of the interviewed actors, the level of implication and participation of users of the units along the project was low, due to the fact that the project team and the steering committee did not involve them sufficiently. According to the then vice-president, this situation was due to the limitation of budgetary resources that did not allow the partial liberation of some users so that they could be devoted more to the project. The vice-president comments in relation to the units: “they were given the opportunity to participate but their day-to-day activity is tight and they were not given enough resources”. In consequence, people that participated in the ERP project had to carry out an added on effort to their daily work. If more the personnel from the units would have been (more) involved this would have helped to diminish the uncertainty that existed around the project among the community.

The immense majority of the decisions were taken at the levels of project team and steering committee, groups that have been criticized by the scarce representation of the structural units. In fact, formally, both the project team and the steering committee included representative members of the units. However, some opinions manifest that those people acted more personally than as representatives of the units.

According to the opinion of an interviewee: “this is somehow the vision of general services [Economics Department and top management] versus the vision of the local units, the conception that those that really deal with the things are the general services, and that the units obey, they contribute and so on”. Clarifying this vision, other interviewees indicate that the explicit opinion was asked to the units in several occasions, for example in the validation of the definition of the processes, but that the units did not respond to such demands.

Only at the end of the project, in the validation phase, key-users from the units were involved and jointly with key users from the Economics Department, they were validated the resulting Economics Management model. Some Economics Department users comment that the conjunction of the following facts caused a lot of stress, late implication of the units, lack of time to assimilate the training of the new system, and the coincidence the end of the year (and the related accounting procedures) with the training and testing activities.


Trust between partners

Initially, during the ERP selection and the beginning of the implementation, there was a high level of trust among the SHEI, the implementation consulting company and the ERP vendor in Spain. Soon after, the mutual trust entered in crisis for diverse reasons.

Regarding the initial relationship between the SHEI and the implementation consulting company, most of the interviewees say that SHEI surely trusted excessively in the consulting company who at the beginning “they were sold with the mark” or “they were hung the medal” of being the only consulting company with experience in such a type of ERP implementation in Spain. However, at the beginning the consulting company omitted that their previous experience consisted in an extensive customization and little configuration of the international standard maintained by the ERP vendor.

On the other hand, initially the ERP vendor in Spain referred openly to the SHEI like “its strategic partner” for the university sector in Spain, and it committed to facilitate the Spanish standard of all the needed modules by beginning of the implementation. This did not happen and, in fact, the ERP vendor postponed several times the delivery of one module, causing a considerable delay in the beginning of the project. Such uncertainty on the delivery of the ERP system caused a lot of insecurity and stress in the implementation consulting company, atmosphere that was transmitted to the rest of the project team and the steering committee. In this respect, a consultant comments: “... here a moment arrived where the insecurity was quite big in general, I repeat not only because [part of the] the product was not delivered, but because ourselves [the consultants] we did not take positions of force... perhaps it would be necessary to say... ok, the product is not ready yet”. This sensation of insecurity was shared between the consulting company and the SHEI, which contributed to a positive atmosphere of collaboration. In some way the SHEI was aware that the consulting company was also suffering the lack of commitment and collaboration of the ERP vendor. In fact, the ERP vendor was detaching gradually from the project, even ending up with one of its commercial representatives manifesting that the project ERP-SHEI was no longer considered as “strategic” for his company.

Dedicated Staff and consultants

In this implementation, with the exception of the project manager that had total dedication to the project, the rest of the team members were discharged partially of their daily tasks, without detaching of them, to be able to have a partial dedication to the project. That limited dedication was one of the reasons pointed out by several interviewees when highlighting the lack of a truly integrated and cooperative project team during great part of the project, excepting the final phase, the go live and support phase.

The consultants think that the team members’ partial dedication is also behind the initial difficulties of consultants to better understand the organization and to find more creative solutions to some specific problems of the SHEI project. During the whole project, there was a room for the consultants while the rest of the members of the team continued in their habitual workplaces.

As the project advanced and the internal team spent more time with the consultants, creative solutions for some problems arose, such as the profiles management and user administration and authorization. According to the majority of opinions, the project supposed an enormous extra effort for most of the members of the internal team, especially for the personnel of the Economics Department.


One of the aspects mentioned by all the interviewees, excepting the consultants, it is the excessive rotation of consultants, especially the consultant project managers. This aspect caused a lot of uncertainty in the project, because not always the new consultant project managers were experts on the HEI sector or they did not know the project status.

Several interviewees made comments like: “Every time that a new consultant project manager arrived we had to revise everything again”. Several interviewees also commented the contradictions that arose during these rotations, as a team member explained: “One told us that something could not be made with the ERP system, another consultant came and he already said that yes, we could do that. So we began to take advantage of the changes. Every time they changed of consultant project manager we asked him what the previous one had said again that was not possible, or his solution to some problems. More than once the things could be made”.

Strong communication inwards and outwards

During the ERP implementation project, there was not a formal communication plan. Communication activities such as: the elaboration of publications, reports on the project status, articles in the SHEI intranet or in the university portal were not carried out during the implementation project.

The communication did not work appropriately inside the team. Several interviewees commented their sensation that in many meetings it was not possible to progress due to the uncompromising position of some team members and the steering committee that monopolized many meetings with some few conflicting topics of interest for their areas. In the section of the project sponsor role CSF, we have already mentioned the positive role of the vice-president in mediating the conflicts and improving the internal communication. Some team members also commented the lack of communication with the consultants. A team member mentioned that “It seemed that we lived and we spoke of two different worlds, we did not understand each other”. Later on in the project, the communication among these groups improved substantially.

The communication to the rest of the university worked well toward the SHEI top hierarchical levels. However, this communication did not spread toward the inferior levels in most of the cases, what caused uncertainty in the future users and suspicions in other organizational groups, always due to the lack of information. With the lack of a communication manager and a communication plan, the issue was left in the hands of few representatives of the structural units in the steering committee. According to some interviewees, in reality these people acted more individually rather than representatives of their structural units, and therefore they didn't exercise function some of information on the project to their units. One of those people commented that “Many times the fear was due to the lack of information, institutional information I mean. Each time we [steering committee members] met, we decided some things, but they did not come out of there.”

Initially top management promoted the project internal and externally in a way that created very high expectations. However, the lack of adequate communication during the rest of the project had a negative impact in the management of such expectations. For example, it was never formally communicated that the SHEI was the first organization that implemented in Spain the public sector module, neither that such a module was delivered with a lot of delay from the ERP vendor. These aspects impacted in the project duration and its costs. Due to the lack of information toward the rest of the organization, the informal communication networks began to work and they spread for the rest of the organization rumors on the project, sometimes correct but many other


times uncorrected. Such a situation caused that currently many people of the SHEI maintain a negative perception on the project, ignoring the project details and how some events occurred.


The first and only formal ERP implementation project plan was defined at the beginning of 1999. All the interviewees mentioned that this ERP project plan was very ambitious and optimistic, since it defined the go live of the ERP system on January of the 2000. It was not a detailed plan, being limited to describe the main phases of the project, duration, objectives and the main tasks within each phase. The concrete duration of tasks was not detailed neither the allocation of resources.

Another important aspect is that this plan did not distinguish between the implementation of the conventional ERP modules and the pilot project, the implementation of the public sector module. Soon, this issue showed that the ERP project plan was impossible to follow, since the delay in the delivery of public sector module by the ERP vendor and the initial answer of the transfer of technology unit in the face of the outlined change (see figure 35 of the section 8.1 to compare initial plan with real project). Indeed, the ERP project plan did not mention the need of ERP customization and the effort required to this task to satisfy the Transfer of Technology Unit requirements. According to some interviewees neither the consultant nor the steering committee acknowledged the required effort.

Starting from the initial ERP project plan, the control and monitoring of the project was made informally during the ERP implementation, without the help of an implementation methodology that could guide the project. Key performance indicators or other types of metrics were not used to evaluate the progress of the ERP implementation project.


In this project the training process had two important stages: the project team training and the end users training. According to the interviewees, the initial project team training in September of 1999 was very basic. This training was realized by the consulting company which used a generic ERP system version (not configured) and most of the sessions were based on PowerPoint presentations, without the project team members have any contact with the ERP system. The main problem pointed out in the training process was the lack of adaptation from the training courses contents to the Economic Management needs in the public sector. The project team members complained that they were trained in very generic concepts and in some cases very technical concepts that were not useful for them. Some interviewees regretted that this training was never evaluated and the interviewed project team members complained about the lack of advanced training, especially in the functionality of data extraction and reporting.

The training contents of the key users were similar to the end users, with the only difference that key users were trained in all the ERP modules while end users were only trained in the ERP modules that they would use in the future. The key users also complained about the lack of advanced training, and in the functionality of data extraction and reporting.

Initially, the end user training was also very basic. They were only trained in the minimum functionality required for the ERP system Go Live. During their ERP system training some problems in terms of economic management concepts were detected in many end users. This knowledge and competencies were not related with the ERP system but with the economics


management topic. Therefore, the project team and steering committee decided to provide training on this topic. After two years from the ERP system go live, there stills exists continuous training specific to economics management concepts.

In spite of those initial problems, the widespread opinion is that the end users training ended up worked very well. Finally, the way it was approached, with internal trainers supported by the implementation consultants, transmitted trust and security to the users and helped them to have a more adapted training to their reality.

Although the end users training was carried out with enough anticipation, end users complained that it realized very little before the ERP system go live, what “forced the rhythm a little”. Several end users commented the feeling of receiving too much information in very little time. They mentioned that they really finished assimilating the new concepts with the use of the ERP system. Other interviewees (not end users) mentioned in this respect that very few end users took advantage of the ERP training environment system which was available after the training process. Most of the interviewees that the training contents assimilation problem appeared mainly due to the quick change in the way of working and to the new economics management competences. According to some interviewees, the users really began to worry with the ERP system when finally they had to introduce the first data and documents: “Here the true education began in the ERP system”.

Although there was a user's manual in paper, a key user interviewed devaluates its utility and he mentioned the lack of an online help manual incorporated into the ERP system: “Something that if you had a doubt, it would explain to you in a very quick way the steps to proceed. Because this was not made, it caused problems with the end users”.


Along the ERP implementation project arose several problems that “surprised” the project team, in the sense that they were not expected problems by the project team in that moment. Those problems were the main cause of the deviations regarding the initial ERP implementation project. The main deviation was caused one by the great delay in the delivery of the public sector module from the ERP vendor (see section trust between partners). The data migration was problematic and it caused several delays (see section data migration process). The effort and time for the data migration process were not properly predicted at the beginning of the project and it demanded a great effort of hours of dedication by some project team members and key users. Another unexpected problem was the complexity in the creation of interfaces with other systems, especially with the systems of academic administration (see section appropriate interfaces and infrastructure).

The lack of an ERP implementation methodology contributed to an unclear perspective of the activities to carry out during the ERP implementation project. In this sense, some interviewees mentioned that the general perception was the one of going solving “unexpected problems” as they appeared, but that many of those problems in fact were “expected” and therefore their resolution could be anticipated and their impact minimized. Another related topic is the slow decision making process that complicated in several occasions or delayed the resolution of these unexpected problems.

The project risks management was carried out informally, what caused that some interviewees mentioned that “more than risk management it was problems management since when we realized we already had above the problem”.


Appropriate usage of consultants

The analysis of the curricula of consultants attached in the ERP implementation proposal of the consulting company shows that most of the consultants of the initial ERP project team begun to work in ERP projects in 1998, and some of them in 1997. This finding confirms the comments of most of the interviewees that mentioned that the initial consultants integrated in the project did not possess great ERP experience. However, those same interviewees mentioned that the integrated consultants with posteriori for the implementation of some ERP modules had a significant experience, but the interviewees noticed lack of consultants with a general vision and integral knowledge on the ERP system, and somebody more senior with long experience in similar ERP implementations.

Besides the little experience in ERP implementation projects, the initial consultants also lacked knowledge in the links between financial accounting and budgetary. One of the project team members mentioned: “They did not have clear how the financial accounting ties with the budgetary area. They ignored it from the beginning and they did not make anything, and this has been the problem. In that sense I am deceived... Then after the go live we saw that the treasury did not match for any side.”

A steering committee member considered that consultants lacked of negotiation power mainly in the ERP system customization factor which they accepted without too much resistance, in spite of at the beginning warning of its future impact. Several interviewees mentioned things like “the consultants were little consultants” and that they provided very few alternative solutions to the problems, always trying to impose one as the only one possible with the excuse that “the rest could not be done”. The partial dedication of the internal project team affected negatively the initial collaboration with the consultants which caused them a lack of perception of the SHEI modus operandis. Some interviewee commented the attitude of some project team members which cooperated little with the consultants in understanding the problems, and at the same time they were waiting for answers to its problems from the consultants. This type of situations caused some uneasiness in both parts, since sometimes the consultants did not have enough information to give an appropriate answer.

Some internal project team members think that some consultants showed little implication in the project, mainly at the beginning, which was amplified by an excessive turnover in the initial team of consultants (sees section dedicated staff and consultants). An interviewee commented: “their [the consultants] attitude was like: tell me what you want and we will make it”. It is almost unanimous among all the interviewees of the internal project team that the initial attitude of the consultants was one of few teamwork, little collaboration and motivation, being rather an “authoritarian” attitude. According to some interviewees, the consultants adapted little to the SHEI context, with some interviewees commenting that “we spoke in different languages”.

Lately, the things have changed thanks to the knowledge that the key users have developed on the ERP system that has given them more decision making flexibility and authority. An interviewee commented that while at the beginning a normal answer from the consultant was that “this cannot be done”, nowadays this answer has been transformed in “We do not know how to solve it”. With regard to the solution provided, some members of the internal team complained that the consultants did not create documentation in most of the cases. They also complained on the scarce transfer of ERP knowledge between the consultants and the internal team members and key users. The ERP knowledge shared was limited to the indispensable to carry out the ERP


implementation, not enough to guarantee the future ERP system maintenance. According to some key users and project team members, any new problem “forces” them to call the consulting company to explain the procedures to proceed and most of the times this implies an unnecessary dependence on the consulting company since the procedures are very easy to learn. They are of the opinion that there are simple things that the users should know themselves providing them more responsibility, but this is very difficult to obtain from the consulting company. An interviewee emphatically mentioned: “we have arrived to the point of telling them [the consultants]... look, when you make it [solve some problem] you warn me because I want to see it, I sit down to your side and I document it. It is simple as that”.

Empowered decision-makers

According to some interviewees, the SHEI matrix structure difficult enough the decision making process along the ERP implementation project. Most of the decisions should have been consensual, even the decisions at operative level. Some interviewees mention situations of lack of power in the decision making process. A member of the project team and the steering committee says: “All had to agree and nobody had to be unhappy.”

Logically, the slow decision making implied the realization of many more meetings of those than some interviewees considered necessary which caused more project delays. Some interviewees indicated a lack of consensual project vision. Some of them remember the uncompromising position of the Transfer of Technology Unit in relation to many aspects of the ERP implementation project. Another reason for the slow decision making process was the partial dedication of most of the team members, complicated by the priorities and momentary urgencies of their normal tasks.

The perception of one of the interviewees, representative of a more general opinion and based on the rhythm and form of the decision making process, it is that “this project was not high-priority for the SHEI top management”, what probably caused that neither it has been assumed as high-priority by many of the involved stakeholders.

Another aspect that may be able to hinder the empowerment and decisional authority in the ERP implementation project is the negative interaction among the political power and top management, which was mentioned by a steering committee member: “in the SHEI there are many politicians acting as managers... and many managers doing politics”.


Adequate ERP implementation strategy

SHEI opted by a big-bang implementation approach as we mentioned before. Some interviewees suggest that due to the attitude of the Transfer of Technology Unit and the public sector module not finished at that moment, it would be better to opt by a phased implementation approach, initially with all the economic and financial part, and later the implementation of the public sector module and the Transfer of Technology Unit integration.

The ERP project did not use any specific ERP implementation methodology, with the initial one very generic and not followed later since the project activities were defined on the run. A consultant mentioned that “by one side there are things that do not depend on the type of


implantation, they are part of methodology of the project, but when those landmarks that you marked previously and then you cannot follow them, you begin to change them, like we began to do this because the other we do not have it, I do not have it because it is not finished yet…, I think that indeed this [not follow an implementation methodology] escaped a little bit to all of us [consulting company and project team]”.

The argumentation of the consulting company to not use the ERP vendor implementation methodology was that it could not be used for public sector module implementation. However, this argument is not valid since the ERP vendor implementation methodology was developed for all the ERP modules. Other HEI have used the same implementation methodology with success.

Another issue was to start implementing the ‘Controlling’ module without finished the business processes analysis. One of the interviewees mentioned that they started with this module because one of the consultants knew the existent controlling legacy system in this SHEI. Thus, they decided to use his knowledge to configure the ERP controlling module. Initially, the standard controlling module was used. After its configuration, the project team started the configuration and customization of the rest of ERP modules. The internal functional responsible for the controlling module mentioned that the controlling module had to be configured again after the go live because the changes in other modules caused that this module could not give response to the SHEI needs. As he mentioned, “there are functional dependencies between the ERP modules even that consultants say there are not”. He also thinks that this module should be implemented at the end because “the controlling module is a module of results which collects information from other ERP modules. Thus, in function of these modules one can know what information to use and obtain in the controlling module”.

Avoid ERP customization

There were two different approaches to the ERP customization which are related with the functional areas, one for the Economics Department and structural units, and the second for the Transfer of Technology Unit. In the first case, the ERP system implemented is a result of a standard configuration of the standard ERP system. Although the solution improved the economic management processes, same interviewees think that the current ERP system do not provides an adequate answer to Spanish HEI.

In the case of the Transfer of Technology Unit, the ERP system was customized through the inhibition, change and extension of its standard functionality which also caused modifications to keep the integration with the Economics Department. The Transfer of Technology Unit had a legacy system developed for them during several years and it answered very well to their needs”. To see more details about their reluctance to the reengineer process please read the CSF business process reengineering. The transfer of technology unit managers and end-users were very happy with their legacy system. However, some interviewees mentioned that their legacy system did not fit with public sector rules and procedures, which was one of the most important objectives of the ERP system implementation in this HEI.

The main argument to customize the ERP system was the lack of functionality of the standard ERP system to answer the specific needs of the Transfer of Technology Unit in terms of budgeting and project management processes. An interviewee mentioned that “few changes were made. The only thing that changed was that the transfer of technology unit abandoned its legacy system and started using the ERP system, but it was not beyond that. Here arose the first mistake... the project


objective was to integrate the transfer of technology unit with the rest of functional area but since all there [in the transfer of technology unit] were against it, well… a little was left… that is, it was integrated but in a similar way to which they had. Then, they reproduced their legacy system in ERP system”.

The solution of ERP customization brought problems on the long term, especially with the upgrade of new versions and the total dependence on the consulting company. The new ERP versions may have new characteristics that conflict with the changes made or they remove structures that the organization needs in its customized system (Smith 2000). The impact of the ERP customization was precariously analyzed perhaps to avoid changes in the Transfer of Technology Unit processes and avoid organizational power conflicts.

The consulting company alerted formal and informally in a continuous manner the project manager and the steering committee about the risks related with the ERP customization. However, the steering committee opted to take those risks without an exhaustive evaluation of the impact on the long term and without creating some contingency plans to mitigate those risks. For instance, there must be a demanding attitude in relation to the creation of documentation of the ERP customization and ensuring the knowledge transfer of these tasks to team members. None of these activities was made in this SHEI.

Some interviewees including consultants agreed that the ERP customization implied a high dedication of consultants to this task, around the 70-80% of the total dedication of the project. According to some consultants, this implied less dedication to other ERP modules, and the elimination of some tasks, such as configuration of reports and data extraction functionalities. Some of these tasks still not done which cause a lot of dissatisfaction from Economic Management users. The Transfer of Technology Unit argues that the consulting company knew from the beginning the customization needs and the problem was that the consultants did not adequately estimate the effort for these tasks. Nowadays, and after all the effort made in the customization, the situation is not satisfactory to anyone. The Transfer of Technology Unit expressed formally its dissatisfaction indicating that it loosed important functionalities compared with its previous legacy system.

Adequate ERP version

At the end of the year 1999, the SHEI decided to implement the version 4.0 of the ERP system for all the ERP modules, and since there was no upgrade of the ERP system. This version was not the most recent in that moment. According to the consulting company, the decision of implementing this version was forced by the fact that the Spanish public sector module was only available in the version 4.0. Thus, in order to avoid problems in the integration of modules, the version 4.0 was chosen for the rest of ERP modules.

A project team member commented the difference between the situation in 1999 and the current one: “Maybe it should not have been implemented that version and it should be implemented a most recent version, but in that moment the managers decided to not implement the last ERP version because it was immature and also that it could not be implemented because we depended of the Spanish public sector module. There were a series of reasons to force the decision. Nowadays, we can say that we can implement the version 4.6 because there is the version 4.6 for the Spanish public sector module. However, I remember that the Spanish version 4.6 was not


available in 1999. That we could do other combinations, yes, it could be discussed but in that moment the decision was to implement version 4.0”.

With regard to the decision of the initial ERP version, an interviewee pointed out the delay in the decision making and the implementation project duration: “you should think that since people decide one thing until it is implemented, a period of time already passed, and in that time it can happen that a new ERP module or a new version is available in the market,... And it is that when you already have finished the ERP implementation, they can ask you... why don't we have the new ERP version? Then you need to explain them that they decided the ERP version 2 or 3 years ago and during this was the period taken to implement it”.

The standard upgrades of the ERP system do not cause big problems when the organization implemented the standard ERP system. However in the SHEI case, there was extensive customization (see section avoid ERP customization). Thus, the simple upgrade of a new release, version 4.0H of the public sector module took one year and half. In general interviewees think that this is notoriously a lot of time, “an atrocity” like one of the interviewees said. Currently, due to the lack of incremental upgrade of versions, the SHEI has implemented a version that is considered “old” compared with the latest version of the ERP system. The ERP vendor at the end of 2003 announced that it will maintain the version 4.0 two years more. After that period, everyone will have to upgrade to a new version.

According to several interviewees, the lack of upgrade of versions is often used by the consulting company and the ERP vendor to justify for not satisfying some of the initial project requirements. Several team members commented things like: “Yes that has been said [by the consulting company and the ERP vendor] that there are things that do not work in this version and that in future versions they will work, or that evidently the ERP vendor won't fix them for a version that will already end in four days.”

In opposition, the consulting company and the ERP vendor argue that the problem was the extensive customization of the ERP system. The established contracts of acquisition and implementation of the ERP system do not include any clause with respect to possible delays in the project, not even about the responsibility of the ERP vendor and the consulting company in defining adequate times to make the upgrades.

Adequate infrastructure and interfaces

In the SHEI project, the definition and development of the necessary interfaces passed to a second plane as the project went being delayed. With regard to the interfaces with other systems, the most important problems are related with the connection with the academic management systems. These interfaces have not been used in the last years by the Economic Department because there are significant differences in terms of data obtained from the banks and the data from the academic management area. Several interviewees hope that this problem will be solved in the future with the new IS for academic management area. Some interviewees have transmitted the idea that each area solve their IS problems with their own and independent solutions, what causes many problems when connecting the different systems. “If the SHEI had an integrated vision of its systems this would help”, an interviewee told us.


Adequate legacy systems knowledge

All the interviewees agreed that there was a profound knowledge related with the existent legacy systems for the economics management area within the SHEI. These legacy systems had been developed for the SHEI, most from the IS/IT department personnel and in the case of the Transfer of Technology Unit, by an external company. The ERP implementation consulting company mentioned the excellent work and support from IS/IT department whenever they had been required to help in the legacy systems issues. The ERP implementation consulting company also valued positively the work developed by IS/IT department in: the definition of interfaces with other systems, the tasks of migration of data, and in the more technical aspects related with the hardware infrastructure and networks.


The initial testing plan was designed following the ERP implementation modules structure. All the interviewees mentioned the enormous effort and resources need to this task.

Just before the go live of the ERP system, in the testing process, the activity that caused more effort was the validation of the data migrated from the legacy systems. Some key users commented that many times they carried out the data migration and then the data were validated in the ERP system. Sometimes, this step had to be repeated many times and in some cases to be annulled because the data was not correct (see next section: adequate data migration process). Some key users commented things like: “it was a quite frustrating task, because sometimes you spent here an entire Saturday working and at the end we did not progress anything”.

The enormous effort required for the data migration and the later system testing relegated to a second position other tasks, mainly the part of design of reports and data extraction. According to several interviewees the configured reports were not enough validated, since currently some reports still not provide the correct information. The same interviewees also mentioned that some economic management processes continue without being completely validated in the ERP system, which may explain that nowadays there are problems to annul some documents.

Adequate data migration process

In this case study, the data migration process had two important tasks. The first task, carried out by the implementation consulting company, consisted in the identification and definition of the format of the data from the legacy system that were needed to migrate into the ERP system. The second task, carried out by the IS/IT department, consisted in the identification, preparation and extraction of the data from the legacy systems. Some interviewees of the IS/IT department mention that the data extraction caused a lot of work. There were two legacy systems: the system used by the Economics Department and the system of the Transfer of Technology Unit. While the IS/IT Department knew the system of the Economics Department very well since they had developed it themselves, they ignored absolutely the system used by the Transfer of Technology Unit, developed by an external company. This implied that the IS/IT Department had to carry out a previous analysis of this system, in which was also very important the collaboration of the personnel of the Transfer of Technology Unit.

With regard to this issue, some interviewees involved in the process mentioned that they lost a lot of time with the data migration of all the historical of the Transfer of Technology Unit that were initially defined and that finally it was not carried out. Some of interviewees commented


things like: “The intransigence of the Transfer of Technology Unit was absolute [in this issue]. They requested the historical data of the last 10 years, what was unthinkable. With this we lost a lot of time because of their lack of cooperation. At the end they ended up realizing that it was not viable”; “after working many hours in the migration of the historical data of projects, at the end, the Transfer of Technology Unit decided not to use it because the results on the ERP system did not match with its results, although the data in their system did not match with what they said. Result: at the end we the data migrated were not used”. According to the IS/IT department all the data from the legacy systems that the consulting company requested them were carried out and the corresponding files given to the consultants.

The third task, carried out again by the consulting company, consisted on the final migration from these data files to the ERP system. This task and the previous one were carried out following an iterative process. The IS/IT department sent the files with the data to the consultants. Then, they migrated and validated them; in many occasions the process had to be repeated for inconsistencies (sees section formalized testing plan). Many data migrated at the end were not carried out for lack of time or inconsistency of the data. Although some data sets should be introduced manually, finally the project team decided to introduce manually only the indispensable data to proceed with the ERP system go live.

A project team member commented the following: “at the beginning they said that any problem would occur, that everything would be okay, but then the experiences were that not.” All the interviewees are unanimous when mentioning the enormous effort of the data migration process. The project manager commented that “there were a lot of work and many bad understood the data migration”.

8.5.8 Consequences

8.5.8.1 Organizational Consequences

Business Process Reengineering (BPR) - Although BPR started in the design phase, its effective change occurred in the go-live phase. Parallel to the implementation of the ERP system, managers started changing the business processes while explaining them to the organization. The project team admits that this should have been done before the implementation since some processes were totally obsolete or inadequate. BPR is not finished yet. Currently, during the post-implementation period and using the knowledge that the project team has acquired, they are continuously improving processes by extending functionality through the current discovery of functionality in the ERP system. The ERP system brought in new business processes and is helping in the reengineering of the old ones. As the project manager mentioned, SHEI does not have any distinctive Economics Management processes. Therefore, they would have not lost competitiveness by adopting the ERP best practices. On the contrary, the adoption of practices that ERP provides helped to reengineer the existent business processes and simplified implementation and future maintenance efforts.

Change of mentality – The users have slowly changed their perception and attitude against the system. At the beginning, most of the users disagreed with the implementation of the system but their attitude reversed progressively after the go-live phase. Nowadays, they recognize that the


ERP system is useful, that it has helped to improve the HEI processes and they think that more business analysis is still necessary, with managers demanding more people to improve the work. The main reasons for the changeover were: top management commitment and the support of project team members, specially the Economics Management key-users. Some users were moved from their old functions while others had intensive training. Now, only a few employees are still not using the system. Some of them are managers of small units that have not enough Economics Management documents to justify one person allocated to Economics Management tasks. The solution has been to create a special group in the Economics Department that manages all the Economics Management documents from the small units.

Keep project team members – The users have slowly changed their perception and attitude against the system. At the beginning, most of the users disagreed with the implementation of the system but their attitude reversed.

8.5.8.2 Technological Consequences

New ERP projects – SHEI has implemented new ERP modules and SHEI managers have defined a set of new projects to extend the functionality of the implemented ERP system such as: electronic signature, internet platform, and data warehouse.

ERP maintenance – SHEI opted for an outsourcing solution for the ERP system maintenance. The implementation consulting company made a contract with the organization. The main reason for this choice was the knowledge the implementation consulting company has of the organization and the way the ERP system is implemented. However, some users complain about their support and attitude with some interviewees mentioning that it is a bit “arrogant”.

Most of the maintenance tasks are related with problems that were not solved during the implementation. With regard to the support tasks required by most of the users there is the complain that they still have the same vision and behavior as with their old legacy systems. Although one of the main reasons to adopt an ERP system was to avoid the huge effort on personal changes into the legacy systems like such size of windows and menus, which is not affordable in the new context. Nowadays, the people responsible for the maintenance are trying to explain them the new philosophy of working and avoid constant requests.

Lack of internal ERP knowledge – The decision to outsource the ERP system maintenance reduced the need to keep and improve the ERP knowledge in the organization. This fact increased the dependency on the consulting company. Nowadays, SHEI managers know that they are totally dependent of the consulting company and they are trying to change this in the near future.


8.6 Comparison with the Pilot Case Study

In this section, we compare the results from the confirmatory case study with the ones of the pilot case study.

8.6.1 Causal conditions

Causal conditions Photopics SHEI

– Organization structure changes. – Need for systems integration. – Legacy systems obsolescence – Inadequate business processes. – Need for a better IS architecture. – Euro conversion – Y2K problem.

– Legacy systems obsolescence. – Maintenance process complex and expensive. – Y2K Problem and Euro conversion. – Existence of an isolated system in the Technology

Transfer Unit.

The reasons to adopt an ERP system were quite similar in both case studies. However, the ERP

initiative on the SHEI case was technology-driven focusing more on the replacement of its legacy systems and systems integration and in the Photopics case the ERP initiative was business-driven focusing on business process reengineering. These options have long term implications especially in terms of change management. Orlikowski and Hofman (1997) argue that technology-related change is unpredictable. Furthermore, Nicolaou (2003) mentions that for this type of projects it is often hard to measure and evaluate attainment of any anticipated benefits, easier to distract from the original system scope, and business benefits lag in terms of their realization due to adjustments needed in the system’s post-implementation phase.

8.6.2 Organizational Factors

8.6.2.1 Sustained management support

Sustained management support Photopics SHEI

– There was visible, consistent support and an active role in communication and reward.

– Top managers conducted or attended regular reviews to assure and verify progress.

– There was a clear prioritization (relative to other initiatives, programs and concerns).

– There were accountabilities, expectations, roles and responsibilities for the organization.

– The role performed by the vice-president as project champion.

– Lack of a vision of the project as not solely a project for Economics Management but a project for the whole organization.

– Lack of authority. – The ERP project was not considered strategic for

the organization but only for the economics management area.


Brown and Vessey (2003) found that not just support, but active engagement, of top managers is critical for enterprise system success. According to the authors, “top executives doing this through two visible means: 1) by being active members of the project oversight board, and 2) by being committed sponsors and champions” (Brown and Vessey 2003, p. 66). In our case studies, the president and vice president were members of the steering committee and they also acted as project sponsors and champions (see below). However, we noted some differences between top management in a private company like Photopics and a public company like SHEI. Top managers on Photopics were more interested in ERP benefits, minimize opportunity costs, and do productivity. Managers in the SHEI had to deal with public interest, and not only with benefits costs and productivity. The other main difference is the decision making process. While in PhotoPics decision making process was fast in order to avoid delays in the SHEI case many issues had to be mediated and balanced before decision-making could take place. McCredie and Updegrove (1999) reinforce our findings stating that “a problem that seems to crop up regularly in higher education is that often decisions are revisited several times. In other words, a decision is often viewed as only a ‘temporary indication of direction’ that can be questioned over and over”.

8.6.2.2 Effective organizational change management

Effective organizational change management Photopics SHEI

– There was no formal change management plan.

– Top management supported organizational changes.

– Changes affected all organizational levels and the organizational culture.

– Resistance to the project was noticed. – There was great uncertainty about jobs and to

the future of the organization. – Changes were visible only within one year

span after the system go-live. – Project ownership.

– There was not a formal change management plan. – High resistance to the ERP project. – Different organizational expectations along the

organization. – Lack of political commitment to take some

decisions. – Positive expectations form the economics

department. – Negative expectations from the transfer of

technology unit. – High uncertainty and stress regarding the new job

roles. – Structural units shown resistance to assume new

job responsibility. – Lack of project ownership. – Given the HEI culture, the magnitude of change

achieved is considered satisfactory.

In both cases there was not a formal change management plan. Although significant change took place within both organizations, it appears that organization managers did not gave importance to this issue before and at the beginning of the project lacking a formal change management planning. The findings suggest: the need to plan the change management process from the beginning, the involvement of the different stakeholders to obtain support and reduce ERP project resistance, and minimize the effort of the change process.

Evidence has shown that organizational change has to be managed prior to, during, and after ERP implementation (Cooke and Peterson 1998). Most of the interviewees on both cases stressed the need to have time to change the culture of the organization. Besides the awareness that


structure and culture need to change due to the ERP implementation, interviewees also mentioned that the results of this change will be reflected in a long term period. These findings reinforce Markus and Benjamin (1996) assertion that IS organizational change has two primary aspects: structural and cultural change. Furthermore, both case studies show the importance of the IS people improve their skills in order to act as change agents as suggested by Markus and Benjamin (1996).

This aspect was especially emphasized by the interviewees of SHEI which is a public sector institution. In the SHEI case IS people played the IS traditional worldview of sole providers of IT services. On the long term, this attitude affected negatively the ERP fit to the organization, and the dependency to the ERP implementation consulting company.

Another aspect is the relationship between change management and communication CSF. Both case studies suggested the need to communicate the changes before they occur in order to reduce resistance and motivate the users to use the future ERP system.

Finally, the project ownership issue. Photopics top management and project team owned the project and the consultants advised. The third party consultants help to improve the project ownership because the consulting company was always confronted with a second opinion from these consultants. In the SHEI case, the consulting company owned the project. According to Windsor (2003), the most successful partnerships in public sector involve the leveraged model of consultancy, whereby the client ‘owns’ the project and the consultant ‘shadows’ and advises the organization during the implementation. At the end of the implementation, the consultant can step off the project and the client can manage the next stage alone because the organization has retained ownership of the project from the beginning and has the capability to take it forward. But this will only work if the client organization is prepared to put forward the right people. This represents a big investment. Photopics, a private sector organization followed this approach, while SHEI opted for a future outsourcing of the post implementation which caused a dependency on the consulting company. Finally there was widespread agreement in both case studies about the convenience of approaching the change management at the beginning of the project.

8.6.2.3 Adequate project team composition

Adequate project team composition Photopics SHEI

– People selected for the project team had the adequate skills.

– An internal team to develop ERP internal knowledge was created.

– Initially, there was a lack of organizational and business knowledge.

– Key-users played an important role in terms of knowledge and enablers of change.

– Personnel selected for the project team had the knowledge and skills necessary about the existing business processes.

– The time dedicated to the project was not considered as critical factor for the team members’ selection process.

– Lack of units’ representation in the steering committee.

– Lack of team members to create an ERP internal body of knowledge.

– Desintailing of IT services from the project. The first thing to notice is the size of the project team. In the Photopics case, the project team

was small, few members, but dedicated most of them fully dedicated to the project during most of


the implementation project period. Some members were incorporated to create an ERP body of knowledge within the organization. The SHEI project team composition was bigger than Photopics in order to accommodate the people from the different organizational units which were significantly more than Photopics units. However, in the case of SHEI, after a first definition of the team composition, it was reduced since the number of members was quite high. Top management also was very careful in the selection of steering committee members in order to avoid the dissemination of information and also benefit the decision making process. Thus, top management defined a small steering committee with most of its members being part of the project team too. The steering committee did not represent the different stakeholders in the organization.

Almost all the project team members had a partial dedication to the project (see section dedicated staff and consultants). The prediction of team member hours to the project was quite simple and not realistic. SHEI only incorporate members from the organization.

8.6.2.4 Good project scope management

Good project scope management Photopics SHEI

– Project scope poorly defined. – Lack of project strategic analysis. – Lack of goals definition at the beginning. – Modules and functions to be implemented as

the project scope.

– In general, the implementation project followed the initial project scope definition.

– There were some changes on the implementation priority of some functionality and modules.

– Incorporation of new functionality like for example inventory administration.

– Lack of documentation regarding the changes on the project scope.

One of the main problems with project scope management is “scope creep”. Scope creep is the

term often used to describe the continual extension of the scope of some projects. During the ERP implementation project, different stakeholders will detect “critical” functionality that needs to be added and they will lobby hard for additions to the original scope (Swartz and Orgill 2001, p. 23). In both case studies project scope creep happen because there was a poor scope definition at the beginning. The main reason for this poor scope definition was the lack of ERP system knowledge and superficial business requirements definition. In both cases, an initial scope not clearly defined caused some misunderstandings among internal stakeholders and also with the implementation consulting company. This fact may also affect the ERP implementation contract with the implementation consulting company “especially in a time-and-materials contract the vendor will be more than happy to add functionality for a price” (Swartz and Orgill, p. 23). Thus, it is important not only to have a good scope management plan but a precise and sufficiently detailed contract with the consulting company and the ERP vendor.

Scope creep usually negatively impacts at least in two factors: project timeliness and cost. This was evidenced especially on the SHEI case. Some studies (e.g. Sumner 1999, Wee 2000) have suggested that any proposed changes should be evaluated against business benefits and, as far as possible, implemented at a later phase.


8.6.2.5 Comprehensive business process reengineering

Comprehensive business process reengineering Photopics SHEI

– Redesign of business processes was carried out only in the second phase of the project.

– Key-users and users participation on the reengineering process.

– Modeling languages were used To document business processes

– Effective change of business processes occurred only after the system go-live.

– All changes were documented.

– Business process changes were not documented. – The incremental business process modeling

approach did not allow the creation of a longitudinal model of economics management area.

– Overall, the option was to adapt the ERP processes to the existent business processes.

– Initial resistance form the transfer of technology unit to adapt its business processes.

– The high initial resistance caused a smooth improvement in the business processes rather than a radical change.

– Lack of documentation about the final business processes implemented.

– The adaptation of the ERP processes caused a lot of customization.

While some studies have linked ERP failures to technical problems and a lack of functionality

in the software (Orenstein 1998), more have related such failures to the difficulties and traumas associated with drastic business process change (Holland and Light 1999). An ERP implementation is a type of BPR project but not the radical BPR project demanded by Hammer (1990). Holland et al. (2000) showed that most European organizations are still struggling with adopting these technologies, with few moving to adapt the environment to suite their current business environment. While these processes can be configured, they nevertheless represent relatively fixed processes. The emphasis is on changing the organization to ‘fit’ the technology rather than vice versa (Soh et al. 2000). In ERP application, the changes in business processes have to be complemented with organizational changes in structure and management systems (Pawlowski et al. 1999).

Murray and Coffin (2001) noted that many firms have made unnecessary, complex customizations to ERP software because the people making the changes do not fully understand the firm’s business practices or the interrelations between various business practices. This further underscores the importance of a clear business plan and a clear understanding of existing business practices (Nah et al. 2003).

One of the main issues associated with BPR is to decide the period to undertake this process. Organizations have done BPR in different stages: before the ERP implementation (e.g. Bancroft et al. 1998), during the ERP implementation (Esteves et al. 2003), or after the ERP implementation (e.g. Welti 1999). A survey made to 220 European companies implementing SAP showed that simultaneous implementation of BPR and SAP has proved to be the most effective and powerful method for business improvement (Chemical Marketing Reporter 1996).

Although the literature refers that “process modeling tools help aid customizing business processes without changing software code” (Holland et al. 1999), in none of the case studies any special process modeling tools were used.


8.6.2.6 Adequate project sponsor role

Adequate project sponsor role Photopics SHEI

– Project sponsor played the role of mediator. – Implication on the main implementation tasks. – Project sponsor had a great influence on

project manager and team motivation. – Project sponsor had the power to influence

decision making. – Project sponsor marketed the project

throughout the organization. – Project sponsor spent a great deal of effort

promoting the discussion (formal and informal) about the project in all the organization’s events.

– There was a lack of formal project controlling and monitoring.

– Role of mediator. – Implication on the main implementation tasks. – Project manager and team motivation. – To promote the discussion about the project in the

main university forums. – Lack of formal project controlling and monitoring.

Nah et al. (2001) mention that “there should be a high level executive sponsor who has the

power to set goals and legitimize change…a business leader should be in charge so there is a business perspective”. The project sponsor also should play an important role on the project leadership continuously striving to resolve conflicts and manage resistance” (Nah et al. 2001). For a more detailed overview of project sponsor role see chapter 4 – unified model of critical success factors.

In both case studies the project sponsor role was played by the president of Photopics and the vice-president of SHEI. Their involvement and participation on the project brought authority and strategic relevance to the ERP implementation project.

There are some similarities in both project sponsor roles: they acted as mediators in the conflicts, they fully supported project team members and especially the project manager, and they actively participated in the ERP project tasks. On the negative side, both case studies suggest a lack of formal project control and monitoring. We think that this issue is related with the initial delays on the project and both project sponsors knew that a formal control will caused more resistance to the project rather than motivate people to get involved with.

8.6.2.7 Adequate project manager role

Adequate project manager role Photopics SHEI

– Project manager’s work had implications in all the implementation phases.

– Project manager spent a great deal of effort on motivating project team members.

– Project manager promoted the system to the whole organization.

– Project manager lacked ERP experience. – Project manager was not familiar with

organizational culture.

– Project management responsibility. – Motivation of project team members. – Open manner to analyze problems. – Ability to manage unexpected problems. – Lack of experience of projects of this size. – Lack of organizational culture knowledge. – Lack of experience on ERP implementation

projects. – Lack of support on behalf of the consulting


Adequate project manager role Photopics SHEI

– Project manager had good skills to manage conflicts and people.

– Project manager’s language skills helped to facilitate communication with stakeholders and to master specialized literature.

company regarding the project management.

Both project managers were recruited externally to the ERP organizations. They had some

characteristics in common: they did not have previous experience in software projects and projects of this size, no ERP experience, and no familiarity with the organizational culture. However, they were some differences in their background. The SHEI project manager had a long experience in projects in the public sector, working in projects with small teams while the project manager of Photopics participated in few projects. However, they viewpoint in terms of project management practices was radically different. The Photopics project manager supported the idea that project management best practices should be used and that he was the responsible for defining, teaching, and enforcing the use of these practices. Even with the ERP implementation methodologies the Photopics project manager adopted the same position. The SHEI project manager adopted the project management practices that he had used for years in the public sector, and he did not believe in these best practices and he did not attempt to institutionalized them. He did not follow any ERP implementation methodology which caused a lot of problems (see section adequate ERP implementation strategy).

Another divergence is related with the project tracking. Whitten (2000, p. 25) mentions two main reasons for project tracking: to discover potential problems before they occur and to put recovery plans in place before unrecoverable harms occurs. The Photopics project manager followed a routine tracking of the project progress, scheduling weekly meetings, providing project reports and communicating with everyone. However, with no goals defined at the beginning and with the lack of experience in project management, there were no project metrics being used. In the SHEI case, the project tracking started well, with regular meetings and providing reports but as soon the delays started, the meetings were not regular, project tasks were constantly changed. Like in the Photopics there were no project metrics being used.

8.6.2.8 User involvement and participation

User involvement and participation Photopics SHEI

– There was user involvement especially in the second phase.

– Key-users participation was considered essential.

– Relations of power affected user involvement and participation perceptions.

– Lack of end users involvement and participation. – Wider involvement and participation of the

economic department personnel. – The involvement of the users of the structural units

along the project was low partly due to limitation of budgetary resources and for their initial resistance.

– Rejection from Transfer of Technology Unit. – Little representativeness of the end users in the

team and steering committee. – A project with a vision of general services opposed

to the structural units.


There was a different philosophy in the two case studies regarding user involvement and

participation. While in Photopics case the philosophy was to involve as much as possible end users to obtain their motivation and agreement, in the SHEI case was of reducing end users involvement to avoid entropy, organizational conflicts, and difficulty in obtaining consensus.

Other authors such as Sawyer (2001a, 2001b) have found that during ERP implementations end users needs, especially on the business blueprint phase, are filtered through intermediaries with stronger ties to the project initiative. The study of Alvarez and Urla (2002) mentions that responses of end users during the business blueprint phase are sometimes discounted by the analysts because the users tended to respond by telling stories about their legacy work practices. SHEI exemplifies Sawyer (2001a, 2001b) and Alvarez and Urla (2002) findings while Photopics case shows that a radical philosophy improves end users involvement and participation and the post implementation benefits of their satisfaction with the ERP system.

Sawyer (2001b) also pointed out that despite the project structure being designed to include end user participation it is the existing social network of the existent organization that influences the extent to which users are considered. Our case studies support the findings of Sawyer (2001b).

8.6.2.9 Trust between partners

Trust between partners Photopics SHEI

– There was a reasonable cooperation and trust between all the stakeholders.

– Intervention with the stakeholders in critical tasks and decisions.

– There was a special collaboration with SAP Portugal.

– ERP vendor audited the system after the go live.

– Too much trust on the implementation consulting company at the beginning.

– The ERP vendor delayed several times the delivery of one of the most critical modules.

– The uncertainty about the delivery of this module caused of insecurity and stress on the implementation consulting company, atmosphere that was transmitted to the rest of the team and the steering committee.

– This atmosphere helped to improve the collaboration between the HEI and consulting company.

– Change of mentality from the ERP vendor.

In the SHEI case, the uncertainty on the delivery on the part of the ERP vendor of one of the modules caused a lot of insecurity and edginess in the implementing consulting company, atmosphere that was transmitted to the rest of the team and the pursuit commission. In the Photopics case the initial delays were caused by the implementation consultant team and their lack of ERP knowledge. SHEI also got some initial problems with this issue. After the initial delay in both case studies the things improved considerably in relation to the cooperation between consultants and the organizations.

An important point is the attitude of the ERP vendor in each case. Although the ERP system is the same in both case studies and the same ERP vendor worldwide, we found that the behavior of the ERP vendor officers and representatives acted in a different manner in each case. While in the Photopics case they were very supportive, in the SHEI case it changed the attitude along the project.


8.6.2.10 Dedicated staff and consultants

Dedicated staff and consultants Photopics SHEI

– Most of the staff was dedicated to the project on a full time basis.

– New team members were highly motivated and dedicated.

– There was a high level of consultants’ turnover.

– There was a good cooperation between consultants and team members.

– Partial time dedication of project team members which caused them an extra effort.

– High turnover of consultants, especially consultant project managers which caused uncertainty and some contradictions in the decision making process.

– Little cooperation between consultants and team members which caused problems to understand the organization.

While in the Photopics case, the staff and key-users were dedicated full time to the project, in

the SHEI case they were partial dedicated. Some studies (e.g. McCredie and Updegrove 1999, Smith 2000) suggest that in US universities and colleges the workloads for staff are greatly underestimated by senior and project managers and it is left to operational managers to deal with the increased workloads and resultant workplace issues.

The dedication of team members also helps to “develop a core of people who will be able to understand in detail how the system uses the configured business entities. They are likely to become the leaders of the new way of doing business” (Bancroft et al. 1998, p. 144). This was the strategy of Photopics managers, the creation of internal team with ERP knowledge. Photopics recruited new members with the required new skills and competences. SHEI managers opted by minimizing team members dedication which led to a lack of ERP knowledge. SHEI decided to not incorporate new members since it was difficult economically and also organizationally to recruit them.

The partial dedication of team members in SHEI case did not allow is one of the reasons pointed out for the lack of cooperation with consultants. This issue had implications of the relationships among these stakeholders and in the adequate use of consultants and their work as we discuss next.

8.6.2.11 Strong communication inwards and outwards

Strong communication inwards and outwards Photopics SHEI

– There was a communication plan that covered both inwards and outwards communication

– A special room was allocated to team members and consultants.

– There were regular written communications using newsletters, invitations to participate in promotion events, and an intranet.

– Development and dissemination of communication aids.

– Employees showed minimal interest to the communication events.

– No communication plan. – Inwards communication did not work at the

beginning of the project. – Outwards communication worked well for the first

level of managers but did not work to the rest. – Organizational culture influenced the

communication. – Inefficient management of expectations. – Informal communication networks had a strong

impact in the project image.


At the beginning Photopics defined a formal communication plan which was extensively followed. Although ERP managers made a lot of effort on the communication process, most of the users complained about the lack of information regarding the changes. In the SHEI case, there was not a formal communication plan but the ERP project sponsor made a lot of effort on the communication process. Again, SHEI users complained of the lack of information. Bancroft et al. (1998, p. 146) argue that “invariably, when surveyed, people say they did not know about a change, or they knew something was happening but did not understand it”. Furthermore, the authors mention that it takes at least three occurrences before people begin to hear the message.

Both studies also suggest the need to take into account the organizational culture in the definition of the communication process. The organization communication research area has shown this influence, and some studies (e.g. D’Aprix 1996) have developed theories to relate both issues. Larkin and Larkin (1994) suggest that downward communication is most effective if top managers communicate directly with immediate supervisors and immediate supervisors communicate with their staff. A wealth of evidence shows that increasing the power of immediate supervisors increases both satisfaction and performance among employees. The Pelz (1952) effect shows that what matters most is not the supervisor’s leadership style but whether the supervisor has power. One way to give supervisors power is to communicate directly with them and to have them provide input to decisions. When the supervisor is perceived as having power, employees have greater trust in the supervisor, greater desire for communication with the supervisor, and are more likely to believe that the information coming from the supervisor is accurate (Roberts and O’Reilly 1974). Photopics communication process is a good example of the Pelz effect. In the SHEI case, although top management communicated with the supervisors, they did not transmit the information to their subordinates because they were more worried with their personal issues rather than the organizational issues. Thus, formal communication mechanisms did not work and informal communication was the main communication vehicle causing sometimes hindrances to effective change.

Finally, both cases show the importance of taking into account the different stakeholders and the different levels of communication and also different amount of information.

8.6.2.12 Formalized project plan/schedule

Formalized project plan/schedule Photopics SHEI

– The project plan was quite detailed. – There were weekly meetings for project

monitoring. – There were no measures for project

monitoring and control. – There was a delay on project duration. – All the tasks planned were performed.

– Project plan little detailed. – The initial plan did not have a detailed and accurate

estimation of the customization tasks. – Lack of periodic update of the project plan. – Project duration unrealistic. – Inefficient allocation of resources.

In the SHEI, the tasks were divided between team members in a way that minimized the need

for regular interaction and collaboration, undermining the nurturing of teamwork between members (Knights and McCabe 2000).

Timeliness of project and the forcing of timely decisions should be managed (Rosario 2000). Deadlines should be met to help stay within the schedule and budget and to maintain credibility


(Wee 2000). In both cases studies there were delays in the project duration. In the Photopics case it was smaller than in the SHEI case study. Both project managers agreed that it is very difficult to estimate the project duration with little ERP experience and without knowing the organization. However, Photopics project manager used project management best practices to rapidly manage the problems related with the project plan and schedule. In the SHEI case the project plan was not frequently updated and things were solved informally.

An unrealistic project plan and its lack of update may have an important impact in its perceived success or failure. Sieber et al. (1999) suggest that if the project has failed, the fact that not every detail of the plan was pursued can be typically used as the rationale for the project’s failure. Therefore, it is very important sets and monitors such ERP project plan and schedule.

8.6.2.13 Adequate training program

Adequate training program Photopics SHEI

– Initial training on computer use was carried out

– The training plan was accomplished. – Initial training started too late and it was very

basic and focused on the ERP potential and trainers had little training experience.

– The training of end users was carried out by project team members.

– The use of an ERP parameterization as closed as possible to the final one on the training courses was useful

– There was lack of organizational and business training.

– There was vision of training as a mix of technical and organizational training.

– There was vision of training as a continuous activity.

– Inefficient initial project team training based in a generic ERP system, lots of information in a short period of time and for most members not necessary.

– The mix consultant/key user as trainers was considered valuable.

– End user manuals were little operational and based on ERP menus.

– Lack of training on economic management by some end users.

– According to key users, there was little time to assimilate the training contents.

– There was not an online help manual.

Welti (1999) states that training starts with the training of the project team in the ERP system,

line, and project management and it ends with the end-users. Both case studies followed this training perspective. In the Photopics case, the end-users training was fully made by internal project team members and in the SHEI case it was a mix of internal team members and consultants. In each course there was an internal member and a consultant. The main difference was that Photopics team members spent a lot of time developing good training material and an end-users manual while in the SHEI case end-users complained about its quality.

User training should also be used as a change management mechanism. Thus, besides the typical technical training it should be explained the business objectives of the project and explain the new business processes and all the organizational changes associated. Both case studies used training in that sense. However, there was an agreement in both case studies that the business and organizational training was not enough. The SHEI case also reveals the need to do some refreshment courses on some business topics that are not directly related with the ERP system but


with the functions that users play since these users never had internal training since they started working on the organization.

One of the main problems with training is the difficulty for trainers (internal members and consultants) to pass on the knowledge to the employees in a short period of time (Bingi et a. 1999). Thus, it is very important to establish a continuous training program, adequate training documentation and use online training materials which can be accessed anytime by end users. The initial training evaluation (reaction training evaluation) maybe not so good due to the short period of time. A second evaluation after a period of ERP system usage may help to better evaluate the effects of training (learning training evaluation). A detailed explanation of training monitoring and evaluation is provided in chapter 7 – Key Performance Indicators.

8.6.2.14 Preventive trouble shooting

Preventive trouble shooting Photopics SHEI

– Several problems arose from political factors. – There was a lack of knowledge about legacy

systems. – There were several problems related to data

migration.

– Problems with data migration. – Users did not refer the truth about the state of old

data. – Some typing of manual data. – Problems with interfaces. – Problems associated with project management.

Troubleshooting errors are critical (Holland et al. 1999). In both case studies several problems

arose along the ERP implementation project. In the SHEI case it seems that the number of unexpected problems was higher but most of them were caused by lack of proper project planning and the lack of an ERP implementation methodology. While in Photopics a good project management approach improved the confidence on the ERP project, in the SHEI case the lack of project management caused a sensation of Chaos. In the SHEI, the other problems that arose were mostly organizational problems related with organizational culture and change management (see change management CSF above).

Both case studies suggested that the technical problems that arose were rapidly solved and the most common unexpected problems are related with data migration process (see below). We think that these problems arose but a lack of early planning since data migration process was not considered a critical issue at the beginning. We also think that it is important working closely with vendors and consultants to resolve these technical problems.

8.6.2.15 Appropriate usage of consultants

Appropriate usage of consultants Photopics SHEI

– Initial consultants had a lack of experience in ERP projects.

– There was a high turnover of consultants. – Third party consultants were used. – There was good project documentation.

– Initial consultants had a lack of experience in ERP projects.

– The future consultants had significant knowledge in some modules but there was a lack of knowledge on ERP modules relationships.

– Lack of a consultant with a vision and integral knowledge of the ERP system, somebody more


Appropriate usage of consultants Photopics SHEI

“senior” with long experience in similar installations.

– Consultant’s turnover. – Lack of knowledge transfer. – Lack of negotiation skills. – Small cooperation with the internal team members. – Lack of project documentation.

In both case studies, the initial consultants did not have experience on the ERP system. This

fact caused a lot of turnover of the consultants. The main discrepancies arise in terms of the cooperation between consultants and team members, the use of third party consultants, and project documentation. In the case there was a special room shared by consultants and team members which help to improve the cooperation among them. Furthermore, Noyes (2003) notes that consultants who are on site for the entire implementation of an ERP project will learn the culture, people, and particular policies and procedures of the host organization. This knowledge helps the consultant to maximize the new ERP system’s flexibility and minimize customization. However, Bancroft et al. (1998, p. 144) alert for the fact that “the consultants cannot possibly understand their client’s business and culture in sufficient detail to provide exactly what is required”. The case of SHEI is an example of how the lack of cooperation among consultants and team members, and the lack of organization characteristics knowledge impacted the ERP customization (see section avoid ERP customization).

Haines and Goodhue (2003) point out the need to analyze the level of knowledge that will remain in the organization after the consultants complete their tasks. “An organization has to assess which types of knowledge and skills are needed on a long-term basis to support the ERP system. This knowledge then has to be transferred in time into the organization to be available in-house when the consultants leave” Haines and Goodhue (2003, p. 30).

The use of third part consultants in the Photopics was considered as an efficient way of improving decision making, obtain ERP knowledge, and improve the adequate use of the consulting company. One of the main benefits was the reducing dependency on a single consulting company knowledge and work. The use of third part consultants may be a best practice for future ERP implementation projects.

8.6.2.16 Empowered decision-makers

Empowered decision-makers Photopics SHEI

– The support of the president of the organization was essential to avoid bottlenecks.

– The duality of political power versus managerial power caused some problems in the decision making process.

– The initial decision of avoiding customization helped to make decisions promptly.

– The matrix organizational structure and the policy of consensus for decision making caused delays in the project

– The partial dedication pf team members also caused problems in decision making.

– The duality of political power versus managerial power caused some problems in the decision making process.

– Lack of political willingness to take some


Empowered decision-makers Photopics SHEI

decisions. – Project tasks were not considered priorities by

managers or key users. Team members must be empowered must be empowered to make decisions on behalf of their

business division or function (Brown and Vessey 2003). Otherwise, the project will simply get bogged down in bureaucratic decision. Furthermore, they should be supported by the steering committee. Another issues is the definition of the decision making process. McCredie and Updegrove (1999) mentions that a crucial step in ERP implementations is the development of an appropriate decision making framework that will be used throughout the project. They emphasize the need of this framework because consensus decision making does not work for ERP projects. Top management needs to approve the decision making framework and actively support the implementation efforts along the ERP project (McCredie and Updegrove 1999).

Both, Photopics and SHEI organizations defined the decision making processes but with different approaches. While Photopics decision making process was mainly based on the president and the project team members decisions and then the steering committee, in the SHEI case it was a consensus decision making process based on the vice-president and the steering committee with few implications of project team members.

Although McCredie and Updegrove (1999) emphasized the need for a decision making framework, they do not provide it. In order to contribute to the development of this framework, we think there is the need to create an efficient and rapidly decision making process that sometimes will have to cut with bureaucratic procedures and against the organizational culture and structure. Project team members must play an important role on this framework since they are the ones that are obtaining the ERP knowledge and can provide the best solutions taking into account their knowledge of the organization. However, the increase on the importance of project team members may conflict with the power and politics within the organization. SHEI interviewees mentioned the need to cut with traditional rules of decision making in order to avoid bottlenecks (see trouble shooting CSF above) and also the problem of revisiting several times the same decision which is also stressed by McCredie and Updegrove (1999) in the case of HEI examples.

8.6.3 Technological Factors

8.6.3.1 Adequate ERP implementation strategy

Adequate ERP implementation strategy Photopics SHEI

– A big-bang implementation strategy was chosen

– Consultant implementation methodology was used.

– A big-bang implementation strategy was chosen. – Lack of an ERP implementation methodology. – The sequence of modules to implement was

inadequate.


Both organizations opted for a ‘big-bang’ implementation approach. Kale (2000, p. 112) mentions that an organization should consider this implementation approach where in all the ERP modules are implemented and put in production together. Holland and Light (1999) suggest that the propensity of an organization for change should influence the choice of ERP implementation project strategy. Thus, a ‘big-bang’ is preferred in organizations adapted easily to changes while a phased approach should be preferred by the others. This assumption of Holland and Light (1999) presupposes a smooth transition from the legacy systems to the new ERP systems. But as Kale (2000) notes, by implementing certain modules of the ERP system, the company should not hope to reap more significant benefits than those accruing from the traditional systems. And, as pointed out by some interviewees, the phased approach would not solve the problem of the resistance to the ERP project since both implementation approaches would have the same resistance level and perhaps in the phased approach it would be worst since each new go live of new modules would cause more reactions.

The second important issue is the ERP implementation methodology used. Bancroft et al. (1998, p. 138) mentions that “you may not follow every step in the process you choose, but it is extremely helpful to have a roadmap”.

An aspect that may influence the ERP strategy is the urgency on achieving the ERP system Go Live phase. The initial idea of the SHEI organization was to implement the ERP system in six months since the main problem was the Y2k problem. This solution was to implement the ERP system as quickly and cheaply as possible. Anderegg (2000, p. 58) defines it as the ‘breakneck’ strategy and it “seeks to eliminate as many steps as possible in attempt to create a quick implementation”.

Another decision to be taken is related with the option of customizing the ERP system or the implementation of the standard package with the minimum deviation from the standard settings. Next section discusses in detail this topic.

8.6.3.2 Avoid ERP customization

Avoid ERP customization Photopics SHEI

– PhotoPics decided to adopt the standard ERP system.

– Improvement of business processes was achieved through the adoption of ERP processes.

– The decision of adopting SAP default functionality simplified ERP parameterization

– The decision of adopting SAP default functionality reduced maintenance efforts and costs.

– The decision of adopting SAP default functionality facilitated future ERP upgrades.

– A lot of ERP system customization. – Intransigency of the Transfer of Technology Unit to

adopt ERP processes. – Problems with ERP version upgrades. – Lost of functionality by the Transfer of Technology

Unit regarding its legacy system. – A lot of time spent by consultants in the ERP

customization process.

This management of this CSF was done radically different on each case. While Photopics opted

by the used the standard ERP system, SHEI customized extensively its ERP system. Photopics top management opted by using the ERP best practices to reengineer Photopics business processes.


SHEI top management opted by doing a smooth transition with reduced redesign of its business processes. The main argument to customize the ERP system was the lack of functionality of the standard ERP system to answer the specific needs of the Transfer of Technology Unit in terms of budgeting and project management processes. The other main reason was the intention of this unit to know change its way of working and reproduce its legacy system on the new ERP system. The top management avoided organizational conflicts and they thought that by giving the demands, people would accept better the ERP system.

The SHEI organizational complexity affected the decision of adopting ERP best practices. However, the adoption of ERP best practices is not a guarantee that the ERP implementation will be a success. For instance in the SHEI case, some ERP modules were immature and they did (and still) not satisfy the requirements of HEI and public sector in general. Sjoquist and Lebel (2002) found that most public sector organizations on a worldwide scale share similar requirements, however each country tends to have unique differences. Although this is a difficulty to defining “best business practices” for public sector, “the basic functionalities of public sector best practices are, for the most part, similar to the private sector practices” (Wagner and Antonucci 2004). Thus, usually the public sector needs to add extensions to meet their specific requirements (Blick et al. 2000).

The different customization approaches had implication on the short and long term of the ERP implementation projects. For Photopics it was more easily to finish the ERP project while SHEI had to delay the go life one year according to the project plan. As Noyes (2003, p. 54) states, “the less customization, the more likely the project will be completed on time and on budget”. Feemster (2000) reports that in ERP implementations in US HEI where the software was minimally customized more outcomes follow.

In the case of Photopics consultants did not have to spend time in customization tasks and they spent more time in other tasks such as data extraction and reporting. In the case of SHEI consultants spend most of the times in customization tasks which caused the elimination of other implementation tasks, in special data extraction and reporting.

Besides the effects on time and budget of the ERP project, on the long term the ERP system customization increases the dependency on the consulting company, especially when there is a lack of internal ERP knowledge transfer and lack of project documentation. The ERP customization also has a huge impact on the upgrade of future versions (see next section adequate ERP version).

8.6.3.3 Adequate ERP version

Adequate ERP version Photopics SHEI

– The ERP latest version available at the time was adopted after an analysis supervised by the consultants and the vendor.

– The upgrade of the initial version did not bring major problems.

– The fact that there was no need for system customization helped the upgrade process.

– The ERP version adopted was the one recommended by the consulting company without an exhaustive analysis of existing versions.

– The adoption of version 4.0 was due to the fact that public sector module was implemented and tested only on that version, according to the consulting company.

– Since the go live, there was no upgrade of the ERP system.


In this case there is a difference between the ERP versions used. Photopics used an ERP

version that was mature and Photopics implemented the common ERP modules which have been implemented for years. SHEI implemented an ERP version which was mature for the typical ERP modules for the economic management like financial accounting or treasury but it also implemented a novel ERP module, the public sector module and the project system module. As we explained above on adequate ERP version CSF for the SHEI case, the public sector module was not finished by the ERP vendor at the moment of starting the ERP implementation which caused a long delay on the project and it was not extensive tested on the public sector. It seems that in the SHEI case, the ERP vendor and the consulting company used this implementation to prototype and test their software. These types of implementations are “often called beta sites and usually experience an abnormal amount of problems because of the newness of the software”(Anderegg 2000, p. 145).

Due to links with other ERP modules, the implementation of this module also implied that the rest of ERP modules had to be from a previous version of the last one available on the market at that moment. With regard to project system module, the main problems were related with the lack of consultants’ knowledge in this module and the data migration need to this module. We agree with Tornatzky and Fleischer (1990) that claim that complex technologies tend to be “fragile”, because they do not always operate as expected. This is special true in the case of technology that is not mature such as the early introduction of ERP modules in specific sector like HEI because ERP systems were primarily designed for corporate non-university organizations (Van Dyke and Sinclair 2003).

8.6.3.4 Adequate infrastructure and interfaces

Adequate infrastructure and interfaces Photopics SHEI

– Creation and implementation of the infrastructure plan.

– There were no interfaces with legacy systems. – Temporary ad-hoc databases were used to

solve some issues.

– Creation and implementation of the infrastructure plan.

– The definition and development of the necessary interfaces relegated to a secondary plan as the project went being delayed.

– The lack of an integrative vision of the SHEI systems caused many problems when connecting the different systems.

– Few validation interface tests. – Currently, still some problems with some

interfaces. McCredie and Updegrove (1999, p. 1) stressed the need to “do not underestimate the amount of

hardware needed to provide the level of performance users expect from a modern enterprise application”. Thus, there is the need to create an infrastructure plan that ensures “the minimal downtime and optimal response-time for achieving optimal operational productivity at optimum costs (Kale 2000, p. 244). Both organizations created and implemented an infrastructure plan using the implementation consulting companies experience on the early stages of the ERP


implementation projects. However, this step constituted a huge economic effort for both organizations.

The interfaces issue was radically different in both case studies. While in Photopics there was no need to develop interfaces with the legacy systems since they were eliminated, in the SHEI case there was the need to create interfaces with legacy systems external to the economics management area. The effort for the development of these interfaces was not sufficiently measured. The main problem associated with these interfaces was the data quality which was not satisfactory and at the end the interface was eliminated. Thus, some of the SHEI systems still not integrated and some data stills being introduced manually in the ERP system.

Kale (2000, p. 111) alerts for the need to schedule the development of interfaces in “such a way that the interfaces are operational when the ERP goes in to production”. This is also one the problems mentioned in the SHEI case. Due to project delays the development of interfaces and its validation were relegated to a second plan. Then, at the moment of using them, some did not work as expected and they could not be used.

8.6.3.5 Adequate legacy systems knowledge

Adequate legacy systems knowledge Photopics SHEI

– There was lack of knowledge of legacy systems.

– One IT person familiar with the legacy system integrated in the project team.

– Good knowledge of existing legacy systems. – Good support from IT people.

Holland et al. (1999) found that business and IT legacy systems determine the degree of IT and

organizational change required for ERP implementation success. Thus, the greater the complexity of legacy systems, the greater the amount of technological and organizational change required. The knowledge on the organization legacy systems is also important for the data migration process because “almost every functional module will require information from the legacy system” (Anderegg 2000, p. 220). Finally the knowledge of the legacy systems is very important for developing interfaces (see section adequate infrastructure and interfaces).

In the SHEI case there was a good knowledge of legacy systems because they were developed and maintained by the IS/IT department or by an external company. In the Photopics there was a lack of knowledge of the legacy system, only one person knew the system. Photopics strategy was to incorporate this person in the project team which helped in all the tasks associated with the legacy systems.

8.6.3.6 Formalized testing plan

Formalized testing plan Photopics SHEI

– The initial testing plan was followed. – Some delays occurred due to data migration

process. – Extensive participation of end-users on the

testing tasks.

– The testing plan was designed according to the ERP modules implemented.

– The phase of tests supposed an enormous effort and many resources, especially the data migration validation.


Formalized testing plan Photopics SHEI

– Their involvement contributed to a better understanding of the ERP system.

– Users suggested some ERP adjustments.

– The great effort required for the data migration and the later tests of the system have relegated to a second plan other tasks, mainly of design and validation of reports.

– Some business processes continue without being completely validated in the ERP system, which is pointed out as one of the reasons for the appearance of problems.

The testing process if effectively used may generate other advantages (Anderegg 2000, p. 142),

such as: reduce the amount of required education and training, elimination of future consultation services, generation of a high degree of user ownership, opportunity to reduce barriers between functional silos of the organization, business process reengineering, build better integrity and quality into the final delivered business process flow, etc.

While Photopics took advantage of the testing phase to involve the users which helped to validated the system but also to improve their learning, in the SHEI case the testing phase consisted in a problematic process since this phase was the one that was more reduced due to delays and project team seemed not interested in involving too much users in the whole project (see section user involvement and participation). There was some additional pressure on project team members and consulting company to finish as fast as possible the testing phase which caused a partial testing of the system. The lack of a detailed business process model and the business blueprint document also complicated the testing phase.

8.6.3.7 Adequate data migration process

Adequate data migration process Photopics SHEI

– Lack of knowledge or legacy systems. – IT people integrated in the project team. – Use of a tool for data migration which

complicated the process.

– The identification of the target data carried out by the consultants was correct and without problems.

– The identification, preparation and extraction of the data to transfer from the legacy systems carried out by the IT/IS department caused enough work.

– Since one of the legacy systems was developed by an external company it implied that IT/IS personnel had to carry out a previous analysis of this system, in which was also important the collaboration of the system users.

– At the end, some of the data migrated was not used due to incongruence and other data was not migrated due to the lack of time.

– There was the need to introduce some data manually.

While the data migration process was early defined in the Photopics case, in the SHEI case it

was delayed due to the project delays on the ERP system customization. This fact impacted in the amount of data migrated in both cases.


The data migration process includes the manual and the automatic (or electronic) method (for a detailed discussion of this topic see Anderegg 2000). In both case studies, the two methods were used. In Photopics case a lot of information was introduced manually since most of the data needed on the ERP system did not exist in any database. In SHEI case few data was introduced manually because the project team decided to introduce manually only the indispensable data to proceed with the ERP system go live.

The electronic method was extensively used in both case studies but using different migration techniques. While Photopics initially opted by using a commercial migration tool, in the SHEI case the IT/IS department developed different programs to carry out the data migration. Due to a bad selection of the migration tool and its complexity, Photopics got a lot of problems with its use, spending a lot of time learning and configuring it which cause some delays. Finally, Photopics team members opted to create some batch programs for extracting data which facilitated the process considerably. Although business experts recommend the use of migration tools, the Photopics case study shows that the lack of knowledge on the use of these tools may increase the complexity of the data migration process.

An important aspect of the data migration process is the validation of the loads into the ERP system. This task must be included in the testing plan (see formalized testing plan CSF above). Key to a successful migration, and before a final sign-off, is the reconciliation between the source and target systems (DMG 2004). The validation task must ensure that the project team rapidly may identify and correct data quality problems throughout the migration process. We think that all the issues with data migration process are not new to ERP implementation projects, and the IS literature have already identified and proposed solutions to them (Hammer 1997). Perhaps, the only difference is the amount of data to migrate from different legacy systems in a small period of time which may cause project delays.

8.6.4 Consequences

Consequences Photopics SHEI

– Business process reengineering. – Change of mentality. – Keep project team members. – New ERP projects. – Continuous system improvement. – Internal ERP knowledge improvement.

– Business process reengineering. – Change of mentality. – Keep project team members. – New ERP projects. – ERP maintenance. – Lack of internal ERP knowledge.

Both cases carried out BPR efforts but Photopics since the beginning defined them as strategic

for the ERP implementation success. Photopics took a radical approach while SHEI opted for an incremental redesigned. Thus, it is expected that in future ERP upgrades there will be more redesign efforts.

With regard to the change of mentality, it happened on both cases. However, in the Photopics case people expressed more publicly their change of attitude and their agreement with the ERP system. In the SHEI case people do not mention it so explicit, and usually they express the benefits of the ERP system informally and more in private. The change of mentality seems more faster in


the private organization than in the public organization. Photopics people do not fear to express this change like in the SHEI case which is associated with a mistake of behavior in the past. The way people dealt with the empowerment of some organizational levels was radically different in the two cases. While in Photopics people felt that the organization was given them a good opportunity which motivated them to do the best they could, in the SHEI case some structural units did not accept very well the new responsibility especially the introduction and management of the documents.

Photopics decided to create a new IS team within the IS department which is the responsible for the ERP system maintenance and evolution. This also help to manage the internal ERP knowledge obtained during the ERP implementation. In the SHEI case the team was disaggregated and although some members are nowadays responsible for some task maintenances their role is not officially recognized with some ambiguous situations. There is a common aspect in both cases, the abandonment of the project managers. While in Photopics case this abandonment was due to a career development of the project manager in a big organization, in the SHEI case was due to internal organizational issues. SHEI is a public organization which makes that some jobs are also associated with political and organizational issues. The implications of this abandonment are higher in the SHEI case, since there is a lack of ERP knowledge within the organization (see below).

Nicolaou (2003) mentions that “Monitoring the system on a post-implementation basis is a critical process that is designed to ensure that the ERP system operates smoothly and is able to provide adequate support for the organization’s operational processes”. Photopics constantly monitors the ERP system in order to achieve the best performance possible and fit the ERP system with the users requirements. SHEI is in a very premature stage yet and the issues still the problems not solved during the ERP implementation.

Both cases have started new ERP projects associated with the evolution of the ERP system implemented. While Photopics is the responsible for the development and implementation of these new ERP projects in the SHEI case stills the implementation consulting company as the main responsible.

The effort in terms of human resources and investment made by Photopics in the creation of the internal ERP body of knowledge had its benefits on the post implementation. This knowledge helps to continuous improve the ERP system, ERP maintenance, motivation to fulfill end-users requirements and especially avoid the dependency on consulting companies. As we explained before, in the SHEI case there is an enormous dependency on the consulting company. We would like to mention that some SHEI key-users and some project team members have developed some internal ERP knowledge but due to their individual motivation and this knowledge is not formally managed.


8.7 SHEI-CSF Relevance

To analyze the relevance of the CSF along the ERP implementation phases, we created a survey that consisted in two sections. In the first section we presented two tables (table 1 - real CSF relevance, table 2 – CSF relevance expected) with the CSF and the different implementation phases splitted in a scale of low, normal and high priority. The second section was a detailed definition of each CSF. At the end of each interview, we explained to the each one of the interviewed actors our intention of conducting the analysis of CSF relevance, and after their agreement we submitted them the survey by email. Table 52 represents the different CSF relevance values:

• Real value (R) for the SHEI implementation – obtained through the SHEI survey. • Expected value (E) for the SHEI implementation – obtained through the SHEI survey. • Theoretical value (T) – the value we proposed using PQM (see chapter 5: CSF relevance).

Table 52. SHEI-CSF relevance along the ERP implementation phases. Pr

ojec

t pr

epar

atio

n

Blu

epri

nt

Rea

lizat

ion

Fina

l pr

epar

atio

n

Go-

live

Critical Success Factors (CSF)

R E T R E T R E T R E T R E TSustained management support 2 3 3 2 2 2 2 2 2 2 2 2 3 3 3 Effective organizational change management 2 2 2 1 2 3 1 2 2 2 2 2 2 2 2 Good project scope management 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 Adequate team composition 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 Comprehensive business process reengineering 2 2 2 2 3 3 2 2 2 2 2 2 2 2 2 User involvement and participation 2 2 2 2 3 3 2 3 3 2 2 3 3 3 2 Adequate project sponsor role 2 3 3 2 3 2 2 3 2 2 3 2 2 3 3 Adequate project manager role 2 3 3 2 3 3 2 3 3 2 3 3 2 3 3 Trust between partners 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 Dedicated staff and consultants 2 2 2 2 3 2 1 3 2 2 3 2 2 3 2 Strong communication inwards and outwards 2 2 3 1 2 3 1 2 2 2 2 3 2 3 3 Formalized project plan/schedule 1 3 3 1 2 3 1 2 3 1 2 3 1 2 3 Adequate training program 2 2 2 2 2 2 2 2 2 2 3 2 2 3 2 Preventive trouble shooting 2 2 2 2 2 2 2 3 3 2 3 3 2 3 3 Appropriate usage of consultants 2 2 2 2 3 3 2 3 3 2 2 2 2 2 2 Empowered decision makers 2 2 2 2 3 2 1 3 2 1 3 2 2 3 2 Adequate ERP implementation strategy 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 Avoid ERP customization 2 2 2 2 2 2 2 3 2 2 3 2 2 2 2 Adequate ERP version 2 2 2 2 2 2 2 2 2 2 2 2 1 2 2 Adequate infrastructure and interfaces 2 2 2 2 2 2 2 2 3 2 3 2 2 3 2 Adequate legacy systems knowledge 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 Formalized testing plan 2 2 2 2 2 2 2 2 3 3 3 2 3 2 2 Adequate data migration process 2 2 2 2 2 2 2 2 2 3 2 2 3 2 2


Next, we discuss the relevance for each CSF in the SHEI case.


• Sustained management support – The only difference in relation to the theoretical and the expected values along the ERP phases is in the first phase. The score of this CSF is normal for the SHEI case, which is lower than the theoretical and the expected value. The main reason for this is lack of involvement at the beginning and some lack of control and formalism.

• Effective organizational change management – The differences arise in the second and third phases. It is in these phases that organizational change management tasks start. As we explained in the actions/strategies section, this CSF did not have a formal plan and several problems occurred. They scored the real value as low, and they scored the expected value as high, which indicates that they would expect more in the second phase.

• Good project scope management – The real, expected, and theoretical scores were equal along all the ERP phases.

• Adequate team composition - The real, expected, and theoretical scores were equal along all the ERP phases.

• Comprehensive business process reengineering – The only difference was in the business blueprint phase, which is the phase in which business processes are modeled and sometimes reengineered. In this case, participants scored the real value as normal, but they wished that its criticality be high, as in the theoretical value.

• User involvement and participation – The real value was scored as normal except for the last phase, which is the go live of the system. It was in the last phase that end-users participated most. Participants wished that the criticality be high, especially in the middle phases, in which business processes were modeled and the ERP system customized.

• Adequate project sponsor role – The real value was normal along the phases, but participants wished for a high value, because they expected more authority from the project sponsor.

• Adequate project manager role – Although participants scored the real value as normal, they wished that the criticality be high, as in the theoretical value. Participants were expecting more from the project manager, especially in terms of project control and monitoring.

• Trust between partners - The real, expected, and theoretical scores were equal along all the ERP phases.

• Dedicated staff and consultants – Participants scored the real value as normal, but they wished that its criticality be high. The expected value expressed their disagreement regarding the extra effort required during the implementation.

• Strong communication inwards and outwards – Participants scored the real value as low in the middle phases because of the lack of communication, especially with end-users. In this case, they did not wish a high criticality value due to the common organizational culture, which avoids extensive communication.


• Formalized project plan/schedule – The real value was low in all the phases, but participants expected a normal criticality or high in the last phase. The public sector does not rely so much in project management culture as we mentioned before.

• Adequate training program – The real value was scored as equal to the theoretical value in all the phases, but the participants expected a high criticality in the last phases. The main reason is the training of end users in these phases.

• Preventive trouble shooting – The expected and theoretical values were equal along the ERP phases, but the real value was low. The main reason for this was that participants thought that the several unexpected problems that occurred were common in this type of projects. Therefore, they considered that trouble shooting was not so critical.

• Appropriate usage of consultants – The real value was scored as normal, but participants expected a high value, as in theoretical value. They acknowledged the need to use consultants in business process reengineering and system customization.

• Empowered decision-makers – The participants scored the real value as low in the middle phases, because it was in that phase that empowerment was needed to avoid bottlenecks but did not occur. Therefore, they expected a high criticality for this CSF.


• Adequate ERP implementation strategy - The real, expected, and theoretical scores were equal along all the ERP phases.

• Avoid ERP customization – The real value was similar to the theoretical value. However, participants scored the expected value as high in the third phase, the ERP configuration phase. The main reason for this result was that a high number of conflicts arose from the discussion and implications of the ERP customization.

• Adequate ERP version – Participants scored all the values equally along the ERP phases, but in the last phase they scored the real value as low, because they thought that in that phase little could c be done to change the previously made decision

• Adequate infrastructure and interfaces – The real value was scored as normal in all the phases, but they wished that high criticality be in the middle phases. The main reason for this was the effort and the troubles caused by the interfaces in these phases.

• Adequate legacy systems knowledge - The real, expected, and theoretical scores were equal along all the ERP phases.

• Formalized testing plan – The participants scored the real value of this CSF as high in the last phase, because the delays in testing tasks was done in this phase instead of the previous one as it is customary.

• Adequate data migration process – The participants scored the real value of this CSF during the last phases as high, because of the problematic situations that took place in the SHEI case. However, they admitted that ideally it should be scored with a normal value like the theoretical score.

Overall, we found evidence that most of the participants scored the expected values very

similarly to the theoretical values. In the case of the real value some scores were different in some CSF due to the problems that took place during the implementation phases. In some cases, as in


infrastructure and interfaces, the expected and theoretical values were equal if we take into account the delay occurred in the project. The project delays caused that participants had a different idea on which implementation phase evaluate some implementation tasks. Finally, we would like to mention that without the analysis of the documentation and interviews it would be impossible to interpret the results of the survey, because participants sometimes expressed what happened in their specific case in the survey even more “clearly” than in the interviews.

8.8 Key Performance Indicators

As we mentioned before, one of the issues of this ERP implementation project was the lack of control and monitoring. The few KPI used were related with project duration and budget. Even the achievement of the ERP system requirements was not formally controlled. These KPI were disseminated only to a small group of people along the project.

However, there was one topic that was extensively monitored and controlled: training. The KPI used for training were similar to the reaction level proposed by Kirkpatrick. There were also diverse KPI related with the managerial dimension of training programs (see section 7.6 for a discussion of this topic).

8.9 Conclusions

Although there are similar characteristics in ERP implementations in both case studies, we also found some differences. One of these differences is related with the ERP project team composition. The specific organizational complexity of HEI and most of the public sector organizations may require bigger ERP project teams than in private sector organization projects. Thus, the adequacy of ERP project team knowledge should be revised and contextualized with the organizational complexity dimension.

On the technical side, different approaches were used like in the data migration process. The study of how the most adequate approach within each organizational context should be analyzed. The solutions provided in the business literature for ERP projects are usually based on big companies experiences. These experiences need to be understood and contextualized for SME which do not have the resources to use those approaches. Data quality management analysis needs also to be analyzed. Empirical research that examines determinants of data quality management adoptions and the degree of implementation is sparse (Nelson 2002).

The decision making process is also more complex in public sector organizations with the need to obtain more “consensual” solutions in these organizations. This fact may impact on the ERP project timeframe causing delays and bottlenecks if not predicted. IS research on project success has focused on the on time and on budget factors but there is a lack of study on the relationship between organizational complexity, decision making process and project duration and budget. Another topic is to analyze in what extent the typical ERP implementation methodologies should be adapted in order to integrate HEI and public sector decision making processes. The current ERP implementation methodologies were developed through extensive experience in ERP implementations in private sector organizations. As a summary, the research results evidence that:


• Most of the problems that arise in ERP implementation projects are associated with the activities identified as CSF in this research,

• The main concerns are organizational rather than technological. • The management of CSF is influenced by the context and, • When managers have taken into account the CSF identified, some of project problems have

been avoided or their impact significantly reduced in ERP implementation projects, and the organization is more likely to use more effectively the ERP system after its implementation.

• A CSF approach is also helpful to avoid problems on the long term since most of the CSF identified are strategic.

8.10 References

Alvarez R., Urla J. 2002. “Tell me a Good Story: Using Narrative Analysis to Examine Information Requirements’ interviews during an ERP Implementation”, The Database for Advances in Information Systems, 33(1), pp.38-52.

Anderegg T. 2000. “ERP: A-Z Implementer’s Guide for Success”, Resource Publishing, USA. Bancroft N., Seip H., Sprengel A. 1998. “Implementing SAP R/3”, 2nd ed., Manning Publications. Beekhuyzen J. 2001. “Organizational Culture and Enterprise Resource Planning (ERP) Systems

Implementation”, Honors dissertation, Griffith University, Australia. Bingi P., Sharma M., Godla J. 1999. “Critical issues affecting an ERP implementation”,

Information Systems Management, pp. 7–14. Blick G., Gulledge T., Sommer R. 2000. “Defining Business Process Requirements for Large-

Scale Public Sector ERP Implementations: A Case Study”, European Conference on Information Systems, Wien (Austria).

Brown C., Vessey I. 2003. “Managing the Next Wave of Enterprise Systems: Leveraging Lessons from ERP”, MIS Quarterly Executive, 2(1), pp. 66-77.

Buchanan D., Claydon T., Doyle M. 1999. “Organisation development and change: the legacy of the nineties”, Human Resource Management Journal, 9(2), pp. 20-37.

Chatfield C. 2000. “Organizational Influences on the Successful Implementation of an ERP System”, Honors dissertation, Griffith University, Australia.

Chemical Marketing Reporter 1996. “SAP Software Implementation Works Best with Reengineering”, 250(8), p.16.

Cooke D., Peterson W. 1998. “SAP implementation strategies and results”, Conference Board, Research Report.

Crawford G., Rudy J. 2003. “Fourth Annual EDUCAUSE Survey Identifies Current IT Issues”, EDUCAUSE quarterly, 26(2), pp. 12-26.

D’Aprix R. 1996. Communicating for Change – Connecting the Workplace with the Marketplace”, San Francisco: Jossey-Bass Publishers.

DMG 2004. “Data Migration Group”, http://www.datamigrationgroup.com [April 2004]. Esteves J., Pastor J., Carvalho J. 2003. “Organizational and National Issues of an ERP

Implementation in a Portuguese Company”, IFIP (w8.2+w9.4) conference, Athens (Greece), pp. 139-153

Feemster R. 2000. “Taming the software monster”, University business, p. 25.


Frantz P., Southerland A., Johnson J. 2002. “ERP Software Implementation Best Practices”, EDUCAUSE quarterly, 25(4), pp. 38-45.

Gulledge T., Sommer R. 2002. “Business Process Management: Public Sector Implications”, Business Process Management Journal, 8(4), pp. 364-376.

Hammer M 1990. “Reengineering Work: Don’t Automate Obliterate!” Harvard Business Review. Holland C., Light B. Beck P., Berduga Y., Millar R., Press N., Stelavad M. 2000. “An

International Analysis of the Maturity of Enterprise Resource Planning (ERP) Systems Use”, Americas Conference on Information Systems, Long Beach (USA).


Knights D., McCabe D. 2000. “Bewitched, bothered and bewildered: The meaning and experience of team working for employees in an automobile company”, Human Relations, 53, pp. 1481-1517.

Krumbholz M., Maiden N. 2001. “The implementation of enterprise resource planning packages in different organizational and national cultures”, Information Systems, 26(3), pp.185-204.

Haines M., Goodhue D. 2003. “Implementation Partner Involvement and Knowledge Transfer in the Context of ERP Implementations”, International Journal of Human–Computer Interaction, 16(1), pp. 23–38.

Hammer K. 1997. “Migrating Data from Legacy Systems: Challenges and Solutions,” in Building, Using, and Managing the Data Warehouse, Barquin and Edlstein (eds.), Prentice Hall.

Holland C., Light B. 1999. “A Critical Success Factors Model for ERP Implementation”, IEEE Software, 16(3), pp. 30-36.

Holland C., Light B., Gibson N. 1999. “A critical success factors model for enterprise resource planning implementation”. 7th European Conference on Information Systems, 1, pp. 273–297.

Larkin T., Larkin S. 1994. Communicating Change – How to Win Employee Support for New Business Directions. New York: McGraw-Hill, Inc.

Markus L. Benjamin R. 1996. “Change Agentry – the Next IS Frontier”, MIS Quarterly, 20(4), pp. 385-407.

Mayer N. 2000. “Enterprise Resource Planning Systems: A Comparison of Business and Academic User acceptance within a University Environment”, Honors dissertation, Griffith University, Australia.

McConachie J. 2001. “The effect of sub-cultures on the implementation of an enterprise system: an Australian regional university perspective”, Learning technologies 2001 conference, Noosa (Australia).

McCredie J., Updegrove D. 1999. “Enterprise System Implementations: Lessons from the Trenches”, CAUSE/EFFECT, 22(4), pp. 1-10.

Murray M., Coffin G. 2001. “A case study analysis of factors for success in ERP system implementations”, 7th Americas Conference on Information Systems, pp. 1012–1018.


Nah F., Zuckweiler K., Lau J. 2003. “ERP Implementation: chief information officers’ perceptions of critical success factors”, International Journal of Human-Computer Interaction, 16(1), pp. 5-22.

Nelson K. 2002. “Determinants of Data Quality Management Adoption and Implementation”, Americas Conference on Information Systems (AMCIS), pp. 114-118.


Nicolaou A. 2003. “Quality of post-implementation review for enterprise resource planning systems”, Forthcoming in International Journal of Accounting Information Systems.

Nielsen J. 2002a. “Critical Success Factors for Implementing an ERP System in a University environment: A Case Study from the Australian HES”, Honors dissertation, Griffith University, Australia.

Nielsen J. 2002b. “ERP system implementation in an Australian University – A Knowledge Management Focus”, 25th Scandinavian Conference on Information Systems.

Noyes J. 2003. “The ERP Dilemma: ‘Plain Vanilla’ versus Customer Satisfaction”, EDUCAUSE quarterly, 26(2), pp. 54-55.

Pawlowski S., Boudreau M., Baskerville R. 1999. “Constraints and flexibility in enterprise systems: A dialectic of systems and job”, Americas Conference on Information Systems, pp. 791–793.

Pelz, Donald C. 1952. “Influence: A Key to Effective Leadership in the First-Line Supervisor”, Personnel, 29, pp. 209-17.

Oliver D., Romm C. 2000. “Issues in University Administration Systems: A Regional Australian Case”, fifteenth Annual Conference of the International Academy for Information Management (IAIM), Brisbane (Australia), pp. 252-259

Orenstein D. 1998. “Retailers seek more ERP functionality”, Computerworld, November 2, 1998. Orlikowski W., Hofman J. 1997. “An Improvisional model for Change Management: The case of

Groupware technologies”, Sloan Management Review, winter 1997, pp. 11-21. Rigelhof R. 2003. “ERP Implementation Best Practices: A Success Story”, EDUCAUSE annual

conference. Roberts K., O’Reilly C. 1974. “Measuring Organizational Communication”, Journal of Applied

Psychology, 59, pp. 321-326. Rosario J. 2000. “On the leading edge: critical success factors in ERP implementation projects”,

BusinessWorld, Philippines. Sawyer S. 2001a. “A Market-based Perspective on Information Systems Development”,

Communications of the ACM, 44(1), pp. 97-102. Sawyer S. 2001b. “Socio-Technical Structures in Enterprise Information Systems Implementation:

Evidence from a Five-Year Study”, IEEE EMS International Engineering Management Conference, Albany (USA), pp. 172-178.

Sieber T., Siau K., Nah F., Sieber M. 1999. “Implementing SAP R/3 at the University of Nebraska”, International Conference on Information Systems (ICIS), pp. 629-649.

Sjoquist R., Lebel S. 2002. “Private, Public, Federal and International Financials: Demystifying the Functionality”, Whitepaper Montage, DMC, April 2002, [http://www.montage-dmc.com/papers/RSOAVGSUB.v1.pdf]

Strauss A., Corbin J. 1990. Basics of qualitative research: grounded theory procedures and techniques. Newbury Park, CA: Sage Publications.

Soh C., Sia S., Tay-Yap J. 2000. “Cultural fits and misfits: Is ERP a universal solution?” Communications of the ACM, 43, pp. 47-51.

Solis R. 2003. “A Multicampus ERP Implementation Case Study: What Worked and What Didn't”, NERCOMP conference.

Sumner M. 1999. “Critical Success Factors in Enterprise Wide Information Management Systems Projects”. Americas Conference on Information Systems (AMCIS), Milwaukee (USA).

Swartz D., Orgill K. 2001. “Higher Education ERP: Lessons Learned”, EDUCAUSE quarterly, 2, pp. 20-27.


Tornatzky L., Fleischer M. 1990. “The Processes of Technological Innovation”, Lexington Books. Van Dyke M., Sinclair M. 2003. “Managing the change associated with implementing

administrative information systems in universities”, Association for Tertiary Education Management (ATEM) conference, Adelaide (Australia).

Wagner E. 2002. “Narrating an organizational matter of fact: negotiating with Enterprise Resource Planning technology to achieve order within a traditional academic administration”, Doctoral thesis, London School of Economics, UK.

Wagner W., Antonucci Y. 2004. “An Analysis of the Imagine PA Public Sector”, 37th Hawaii International Conference on System Sciences.


Windsor St. 2003. “Change Management in the Public Sector – The New Holy Grail?”, Publicnet, May 2003. [http://www.publicnet.co.uk/publicnet/fe030520.htm].

Whitten N. 2000. “The Enterprize Organization”, Project Management Institute, Philadelphia (USA).

Yakovlev I. 2002. “An ERP Implementation and Business Process Reengineering at a Small University”, EDUCAUSE Quarterly, 25(2), pp. 52-57.

Wee S. 2000. “Juggling toward ERP success: keep key success factors high”, ERP News, February, available http://www.erpnews.com/erpnews/erp904/02get.html.

Chapter 9 – Contributions and Further Research

Chapter 9

Contributions and Further Research

Chapter Summary: This chapter presents the research contributions and how this research contributes to the current body of knowledge on ERP. Each research question is revisited and discussed. The additional methodological contributions and key findings of the study, along with limitations of thestudy are also presented. Then, we describe the implications for practitioners and for ERP/ISresearch. Finally, we evaluate the trustworthiness of this doctoral research.


Thesis Introduction


Research Design






CSFsIdentification


CSFsIdentification




ERP Context

9


9.1 Research Questions Addressed

This section attempts to answer the research questions raised in chapter 3. What are the Critical Success Factors (CSF) for an ERP implementation project? Based upon an extensive literature review, we have developed a unified model of CSF. The

unified model presents 23 CSF categorized in four perspectives: organizational, technological, strategic and tactical. Most of the CSF are organizational CSF which shows the importance of the organizational perspective in an ERP implementation project. The analysis of the CSF literature showed that management support is the most cited CSF in an ERP implementation followed by organizational change management. These CSF have almost nothing to do with technology and almost everything to do with people and process, due to the effort that has to be undertaken by the whole organization in a project of this nature. Further the model needed to be redefined since the analysis of the CSF regarding the project champion role, using a web survey, evidenced that the project champion role should be carried out by the project sponsor and that project sponsor and project manager roles are both critical in ERP implementations.

What is the relevance of each CSF along the implementation project stages? By applying the PQM method and using the ASAP implementation methodology as a reference

for the SAP implementation processes, we defined the CSF relevance for each CSF along the SAP implementation phases. Then, we extrapolated our findings to other ERP studies by comparing our relevance schema with others proposed by other colleagues. One of the limitations found with PQM method is that the process structure of the PQM method is too simple since it only provides one level of process analysis. Since most cases imply project process structures that are more complex, such as the typical ERP implementation processes structure, we have proposed an applied an improved PQM analysis section to provide more depth to complex project structures. In our extension to the standard PQM method, we provide a new criticality indicator for complex implementation project process structures. This criticality indicator was used to define and analyze the most critical SAP implementation processes.

How these CSF are managed and influence ERP implementation projects? Along the two case studies we evidenced that a carefully management of the CSF identified in

chapter 4 resulted in less problems and achievement of better results after the ERP implementation. This view supports the earlier argument by Ginzberg (1979), who suggested that the better the handling of the implementation process, the greater the chances of successful implementation. We think that the main conclusion of our studies is the evidence that managerial, organizational, cultural and national issues have a strong impact in ERP implementation projects. In the particular case addressed in this study if those organizational and cultural issues had been taken into account during the planning phase, it is very likely that most problems would have been avoided or mitigated during the ERP implementation project.


What are the Key Performance Indicators (KPI) related to the above CSF? We have used the GQM method to develop a tentative set of KPI for the most cited CSF. As a

result, we have proposed a GQM plan with different metrics to monitor and control CSF while implementing an ERP system. Due to the extensive number of CSF, we focus on the most frequently cited CSF and the ones we had some working experience in the past. Thus, we have proposed set of KPI for: sustained management support, business process reengineering, training, and user involvement and participation. The idea of this work is not to present an exhaustive list of KPI. Instead, we attempt to present a framework to develop these KPI in future ERP implementation projects and to provide the first set of KPI that should be extended and adapted according to the specific needs of ERP implementation projects. We also attempted to validate the set of KPI with the case studies, however in both case studies, the KPI used were quite simple, focusing on project duration, costs and project requirements achievement.

9.2 Methodological Contributions

One of our constant worries during the research has been to learn and apply the different research methods involved rigorously. During this period we found a lack of information regarding the usage of those research methods. Thus, we have decided to publish our experience with the research methods and in this way we have tried to contribute to the application and improvement of the following issues:

• Multimethod - Finally, we tried to combine different research methods and techniques in order to use them adequately to answer the research questions. The idea was not to use known research methods and techniques but try to understand methodological which methods were the most adequate (Esteves and Pastor 2004b). We applied the ideas of Mingers (2001) and also Morse (2003) which has been working in multimethod and mixing methods in social sciences.

• Grounded Theory - With some colleagues, we decided to describe our experience using Grounded Theory method (Esteves et al. 2002). We also defined some best practices in order to apply Grounded Theory within the IS field. Then, at the time of publishing Grounded Theory studies, we also found some issues that should be taken into account (Esteves and Pastor 2003).

• Web Surveys - The second methodological contribution was related with web surveys technique. We compiled the literature review on web surveys, and based in our experience using web surveys, we developed a set of guidelines for its usage. We also found two factors that may influence the outcomes of a web survey: the timeframe and advertisement factor (Esteves et al. 2003b).


9.3 Trustworthiness

Next, we discuss the trustworthiness related with the pilot and confirmatory case studies (see section 3.4 - Trustworthiness of the Research). With regard to the rest of research phases, we already explained in each respective chapter how we validated the research process and findings. Table 53 and table 54 show the trustworthiness analysis for the pilot and confirmatory case respectively.

We believe that the outcome of this research project is applicable for the implementation of ERP systems by other organizations, in addition to those involved in this doctoral research study.

Hence, we think that our case studies show the importance of not relying in only on information from interviews to support findings (triangulation). During the case studies we found that sometimes the documents helped to understand some contradictory answers from interviewees and also to help to have a first comprehension of the case studies background in the design of the questions for interviewers. During case studies the knowledge obtain form the documents also was useful to show to some interviewees that we had made some previous work and that we were aware of the relevant issues. After acknowledging this, they started speaking frontally and clearly about the issues.

One of the issues regarding the trustworthiness is the translation of the interview transcripts to English. We coded the interviews in their native language, Portuguese language in the pilot study, and Spanish language in the confirmatory case study. However, in the presentation of the results, we present the quotations in English. We are aware that this translation may cause some biases in some sentences. With regard to confirmability, in this study it means reaffirming what we saw, heard or experienced about the phenomenon. Table 53. Pilot case study trustworthiness. Trustworthiness criteria Undertaken research actions Credibility Two months analyzing project documentation.

Six months conducting interviews. 13 participants gave input during data collection and interpretation. Peer debriefing

Transferability Theoretical sampling Theoretical concepts were represented by data from all the stakeholders except the ERP vendor. Transfer findings to the confirmatory case study. Thick description of the pilot case study.

Dependability Use of all categories that emerged from the data. Auditing trail by the doctoral supervisor.

Confirmability Report with initial interpretations was provided to participants for feedback. Participants wrote notes and suggestions for improvement and also commented the points where they thought the interpretation did not follow reality.


Table 54. Confirmatory case study trustworthiness. Trustworthiness criteria Undertaken research actions Credibility Six months analyzing project documentation.

Six months conducting interviews. 20 participants gave input during data collection and interpretation. Examination of the individuals who appeared to be the exceptions in the Case study (negative analysis). Report with initial interpretations was provided to participants for feedback.

Transferability Theoretical sampling Theoretical concepts were represented by data from all the stakeholders except the ERP vendor. Thick description of the confirmatory case study.

Dependability Use of all categories that emerged from the data. Auditing trail by the doctoral supervisor.

Confirmability Report with initial interpretations was provided to participants for feedback. Participants wrote notes and suggestions for improvement and also commented the points where they thought the interpretation did not follow reality.

9.4 Limitations of this Research

One of the clear limitations of this study is that we have focused more on the identification of CSF and analysis of how they were managed rather than in explaining the determinants of these CSF. Although our Grounded Theory model provides some clues and suggestions, in the future there is the need to explore this issue.

With regard to the ERP stakeholders, in this thesis the results are general and do not take into account the specificities of each stakeholder involved in an ERP implementation.

The other main limitation is the number of case studies conducted as confirmatory studies, in this only one. Additional research, across multiple case studies is needed in order to verify the analysis developed in this thesis. In the Spanish context there are no universities that had implemented an ERP system.

The number of CSF derived is quite large, 23 factors. To understand what these factors fully involve, it would be necessary dedicated a longer period than the time available for a doctoral thesis realization. Each CSF study could easily be a doctoral thesis topic. The number of CSF limited the definition of KPI because the effort to revise the literature on each factor and then to analyze and create a set of reasonable KPI implied a considerable dedication.

This study provides a tentative set of KPI for some of the most cited CSF. Thus, another limitation in this part of the thesis is the validation of the KPI proposed. There are two main reasons for this fact. The first reason is the time needed to create the set of initial KPI as we mentioned above. The second is the problem of obtaining the agreement of any organization that was in the process of implementing an ERP system. Furthermore, the extensive time needed to conduct such a study and the fact that a study of this type would require a different research approach such as action research in order to improve the set of KPI proposed in this thesis.


9.5 Implications

The following sub-sections describe some implications of the research results for ERP practitioners, organizations, ERP vendors, and ERP/IS research.

9.5.1 Implications for Further Research

This research provides a basis of research into ERP systems, especially in the identification and analysis of the management of CSF in ERP implementations.

The CSF unified model also may help to study other topics related with ERP implementations. For instance, CSF may help to understand the knowledge types required for a successful ERP implementation. We have started analyzing the relevance of knowledge types along the SAP implementation phases, in cooperation with Roy Chan and Michael Rosemann from Queensland University, and whose research focuses on knowledge types for ERP implementations (see Esteves et al. 2003c). Our research model helps to provide some exploratory insights on knowledge types needed for the management of CSF and also to analyze the relevance of these knowledge types along the SAP implementation phases.

With regard to the project champion role, an important question that arises from this study is how project sponsors and managers can be found within organizations? Another aspect upon which some interviewees focused was that sometimes project sponsors and managers are people external to the organization, which may difficult the apprehension and diffusion of ERP knowledge within the organization. Further research should focus on these aspects and on the resources needed to help both roles in the accomplishment of their work. As we mentioned before, in some ERP projects there is no project sponsor figure, at least officially defined as such. Until now, there are no studies that show the impact of the absence of project sponsor figure or what is the impact of the owner of the company as unofficial project sponsor. His implication can be seen in two perspectives, one if the organization owner is involved is because the project is very important and the second is that instead of seeing the organization owner as a motivator of ERP system use, employees can see it as a mandated event.

Finally, the cultural and social issues were not address in this study. Empirical evidence shows that the word “champion” is associated with “winner”, power, autocracy and competition. “Champion” also means to support or fight for someone else. This two definitions may explain why in certain cultures is not usual that project champion role is officially defined. Instead, people prefer the word project leader. Future research should analyze this social and national issues in IS projects in general. Shane et al. (1995) also shown that national culture impacts on championing strategies. Their findings suggest different championing strategies according to different countries and not a solely strategy worldwide. Probably in ERP implementation projects should be the same, and perhaps ERP strategies and implementation methodologies should consider national culture and its effect on stakeholder roles, in particular project champion, project sponsor and project manager roles.

In this study we analyzed Hofstede (1991) dimensions of national culture one by one. Future research should also consider the influence of associations of dimensions like power distance/uncertainty avoidance or uncertainty avoidance/individualism effects. The literature on IS evidences a lack of research on corporate and national culture. The influence of culture has mainly


been focused in the IS solution and how it fits with the organizational culture, or the cultural changes. Another aspect to consider is whether ERP implementations significantly differ from the implementation of other types of systems in the past or currently (e.g., data warehousing, CRM, SCM). This research path can bring up conclusions regarding the specificity of ERP implementation projects or the identification of general trends in IS implementation.

The Grounded Theory model presented in the thesis should be applied to other ERP case scenarios. Another recommendation is to expand the Grounded Theory model with a stakeholder perspective by including the perceptions and interests of each stakeholder within the model. We have started analyzing our confirmatory case study using stakeholder theory (Esteves and Pastor 2004a)

As we mentioned above one of the limitations of this study is the study of the determinants of the CSF identified. Nowadays, research on CSF identification does not provide the reason why some CSF are more relevant in some organizations than others. Future studies should also attempt to understand the impact of some decisions taken in the ERP selection phase in these CSF. For instance the selection of project manager or the consulting company or the ERP strategy like decision to customize the ERP. On a more proactive view, we think that another research study would be the analysis of how ERP selection could be improved in order to better manage the implementation CSF. For example, an analysis of how project manager selection should be made in order to satisfy the CSF.

With regard to the CSF model presented, in the future it should be extended by defining the relationships among the CSF identified. We already started the definition of a preliminary model of CSF relationships by using Partial Least Squares (PLS) technique. After the PLS analysis, we attempt to develop a simulation application based on the PLS model (Esteves et al. 2003a). This application will help managers in monitoring their ERP implementation projects by knowing in each moment the grade of satisfaction in each CSF and its impact of the overall ERP implementation project success. The PLS model could also serve as the basis to create an ERP project profile like the project implementation profile created by Pinto and Slevin (1989), an instrument of the same name was developed in an attempt to create an empirical method of assessing the status of any project.

The results presented on this study may also help to analyze how CSF should be managed in order to obtain certain product and service innovations based on a standard ERP system. As we showed in this thesis, organizational culture and structure as environmental conditions may affect an ERP implementation and more special the identification and management of CSF. Thus, there is the need to conduct more multiple case studies to understand these relationships. These studies may also help to define a set of best practices for different types of cultures, organizations and environments.

Implementing an ERP system involves reengineering the existing business processes to the best business process standard. ERP systems are built on best practices that are followed in the industry domain. Therefore, in practice, BPR is aimed at only when the customer’s requirements are not met within the scope of customization allowed by the ERP system. In both case studies there was the need to align business processes with the ERP business processes. The academic literature on IS alignment is relatively sparse. The business process management issue should also take into account the differences between private and public organizations (Gulledge and Sommer 2002). Another important issue is to know the evolution of the best practices provided by each ERP


vendor. Most of these best practices are not from the industry but from other different domains that gradually were improved for different domains. Thus, there is the need to understand the evolution of these best practices to understand how well they fit in certain industry domains. Nowadays, the ERP vendors are approaching the SME but there is the need to analyze if the proposed ERP systems for SME are based on these industry needs or just an adaptation of ERP for big companies.

Our study highlights the need to analyze the evolution of the ERP software modules and its impact on the ERP implementation project success or failure. The confirmatory case study shows how a pilot implementation of one of the modules may cause a lot of conflicts. McCredie and Updegrove (1999) alerts that intense competition on the ERP market can drive an ERP vendor to concentrate on the bells and whistles of future versions rather than to focus on the mundane but critical issues of quality and supportability of the current version. Pollock et al. (2003) develop the notion that ERP systems have a ‘biography’, which helps us to analyze the evolution of software along its lifecycle. Furthermore, the authors evidence the need to understand the various characteristics an ERP package accumulates through previous stages of design and the process by which its history or ‘biography’ continues to shape later adopting organizations.

With regard to the set of KPI proposed on this thesis, we attempt to define KPI for the rest of CSF and we also attempt to validate those KPI through action research studies.

9.5.2 Implications for Practitioners

There are several practical implications within this thesis. Here we highlight the main implications for practitioners. Thus, we emphasize the implications from the CSF relevance schema and the case studies.

9.5.2.1 Implications from the CSF unified model and its relevance schema

We think the CSF relevance schema (table 29) and the most relevant CSF model (figure 19) will be valuable documents for the management of CSF because managers will know the variety of factors affecting an ERP implementation project success and their relative importance across ERP implementation phases. These CSF relevance models provide guidance to practitioners in planning and monitoring an ERP implementation project with more emphasis in ERP system. The ERP implementation methodology is an important component of the SAP implementation strategy, and therefore it is necessary that CSF should not only be identified, there is also the need to establish the relationship between these CSF and the implementation project processes in order to verify if these processes support the accomplishment of CSF. Finally, this knowledge may help in the allocation and management of project resources in each ERP implementation phase.

These findings have implications in the way organizations should manage their ERP implementation projects. Some of these implications are:

Organizations should consider strategic and organizational factors early in the project lifecycle, during project preparation and business blueprint.

The transition from strategy to tactics and from organizational to technological issues must be carefully managed since it means changing the relevance of CSF. Therefore, it should exist a careful monitoring of these new CSF.


The project champion role is the highest relevant CSF along all the ERP implementation phases. Therefore, organizations must put special attention on the selection of this person and try to select the most adequate person for this role.

The adequate project manager role is the most relevant CSF along all the ERP implementation phases. Therefore, organizations must put special attention on the selection, motivation and retention of this person and try to select the most adequate person for this role.

ERP project monitoring and controlling involves a dynamic multi-success-factor management since the most relevant CSF may change along the project.

Project managers must have adequate skills for both dealing with multi-success-factors, or at least the organization must have people that support this shift along the project.

9.5.2.2 Implications from the case studies

The comparison of both studies suggests that although these organizations are from two different industries, one is a private sector manufacturing organization, and the other is a public sector HEI, their ERP implementation projects shared most of the issues which are related with project management competences.

With respect to technology, it seems that the type of organization affects the level of ERP fit. We evidence that the overall impression in the case of the manufacturing company, the ERP fits the organization needs while in the case of the HEI the impression is that the system does not fit quite well and it is in a premature stage that needs more development from vendors. This evidence is in accordance to the history and evolution of ERP systems. These systems evolved from manufacturing systems and in recent years they are approaching other industries like the public sector and more recently HEI. Organizations must analyze the level of maturity of the ERP systems to their industries and verify that the functionality announced by ERP vendors is really implemented instead of being only “bells and whistles”. The maturity of the ERP system must also be analyzed within national contexts since some countries impose legal rules and there are cultural differences that ERP systems may not respond to (Krumbholz and Maiden 2001). In order to improve their ERP systems for specific industry solutions such as higher education and public sector, some ERP vendors are doing agreements with organizations within these sectors to carry out pilot implementation projects with the purpose of develop and validate their ERP systems and develop their ERP best practices for these industry sectors.

Some technical solutions devised in principle to solve and accelerate some tasks during the ERP implementation project may in fact increase the project complexity and the need of more resources. This is the example of the migration tools which if not supported by an expert may be more problematic than expected. ERP implementation projects with few resources should measure the impact of using this type of tools in terms of time consuming effort and resources.

With respect to organizational and process impacts, the new ERP may destroy the territorial boundaries at one fell swoop. The potential for greater efficiency and better service are enormous but so are the challenges. Wagner and Antonucci (2004) stress the need of public sector organizations to work more to instill a culture of customer service in order to achieve success in ERP implementations.


Overall our findings show that both organizations studied, which differ widely in many of the organizational characteristics, benefited through implementing these ERP systems and that without such an integrate system they could improve their business in the coming years. However, Photopics case shows that implementing the standard ERP helps to avoid a lot of problems such as the ones occurred in the SHEI case. Implementing consulting organizations must play an important role on advising organizations on the issues of ERP customization. Future upgrades/enhancements are made more complex and costly by the need to rework the custom elements of the system. Senior management commitment is needed to ensure that the change is properly managed and led.

9.6 Summary of Contributions

This thesis has shown that CSF identification and management allows for a better management of ERP implementation projects. This thesis fills a gap at the intersection of CSF factor research and socio-technical research. It draws links between CSF approach, ERP project management, software package and IT implementations. We have demonstrated new connections between the ERP implementations and CSF identification and management that will hopefully stimulate further research. The specific contributions of this thesis are:

• An annotated bibliography which is a reference for researchers interested in the implementation of ERP systems.

• A new CSF unified model for ERP implementation projects which combines previous research CSF studies. It extends previous research by providing a definition for each CSF and categorizing them in four perspectives: organizational, technological, strategic and tactical.

• A CSF relevance schema along the ERP implementation phases. • A new criticality indicator for defining the most critical processes using PQM method. • The definition of the most critical processes on SAP implementations based on ASAP

implementation methodology. • A set of KPI for some CSF and a systematic approach to develop the rest of KPI. • A CSF management analysis in two organizational contexts: a small and midsized

enterprise and a public HEI. • A novel grounded theory model for ERP implementation projects.

Along with these specific contributions, we have outlined areas of future research including

CSF relationships establishment, creation of an ERP project profile, knowledge management types and CSF, effects of organizational and national culture on ERP implementation projects. This is certainly not the end of the story in the solution of successfully ERP implementation projects. In particular, although the findings here seem to work well in practice, there still exists few theoretical works on the socio-technical perspective of ERP implementation projects. We think that future research on this perspective aligned with stakeholder analysis might be particularly fruitful. Hopefully this thesis will encourage more work on this area.


9.7 References

Esteves J., Pastor J. 2003. “Publishing Grounded Theory Research Studies: Are IS Journals and Conferences Ready for Them? International symposium on Research Methods (ISRM), Tampa (USA).

Esteves J., Pastor J. 2004a. “Towards a Stakeholder Analysis of an ERP Adoption in a Higher Education Institution”, 1st international workshop on information, knowledge and management: Re-assessing the value of ICT in public and private organizations, Bologna (Italy).

Esteves J., Pastor J. 2004b. “A Multimethod Research Approach to Study Critical Success Factors in ERP Implementations”, European Conference on Research methods, Reading (UK).

Esteves J., Ramos I., Carvalho J. 2002. “Use of Grounded Theory in Information Systems Area: An Exploratory Analysis”, European Conference on Research Methods (ECRM), Reading (UK).

Esteves J., Casanovas J., Pastor J. 2003a. “Modelling with Partial Least Squares Critical Success Factors Interrelationships in ERP Implementations”, AMCIS 2003, Tampa(USA).

Esteves J., Casanovas J., Pastor J. 2003b. “The Importance of Timeframe and Advertisement in Internet Surveys: An Exploratory Analysis”, 54th International Statistics Institute Conference, Berlin (Germany), pp. 318-319.

Esteves J., Chan R., Pastor J., Rosemann M 2003c.”An exploratory Study of Knowledge Types Relevance along Enterprise Systems Implementation Phases”, the fourth European Conference on Organizational Knowledge, Learning and Capabilities (OKLC), Spain.

Ginzberg M. 1979. “A Study of the Implementation Process”, TIMS Studies in the Management Sciences, 13, North-Holland Publishing Company, pp. 85-102.

Gulledge T., Sommer R. 2002. “Business Process Management: Public Sector Implications”, Business Process Management Journal, 8(4), pp. 364-376.

Hofstede G. 1991. “Cultures and Organizations: Software of the Mind”, McGraw-Hill: New York. Krumbholz M., Maiden N. 2001. “The implementation of enterprise resource planning packages in

different organizational and national cultures”, Information Systems, 26(3), pp.185-204. McCredie J., Updegrove D. 1999. “Enterprise System Implementations: Lessons from the

Trenches”, CAUSE/EFFECT, 22(4), pp. 1-10. Mingers J. 2001. “Combining Research Methods: Towards a Pluralistic Methodology”,

Information Systems Research, 12(3), pp. 240-259. Morse, J. (2003) “Principles of mixed methods and multimethod research design” in Tashakkori

and Teddlie (2003), pp. 189-208. Pinto J., Slevin D. 1989. “The project implementation profile”, Project Management Institute

Proceedings, pp. 174-177. Pollock N., Williams R., Procter R. 2003. “Fitting Standard Software Packages to Non-standard

Organizations: The ‘biography’ of an Enterprise-wide system”, technology analysis & strategic management journal, 15(3), pp.317-332.

Shane S., Venkataraman S., MacMillan I. 1995. “Cultural Differences in Innovation Championing Strategies”. Journal of Management, 21(5), 1995, pp. 931-952.

Wagner W., Antonucci Y. 2004. “An Analysis of the Imagine PA Public Sector”, 37th Hawaii International Conference on System Sciences.

Appendix A – SAP system overview

271

Appendix A – SAP system overview SAP System Overview

The SAP system is a collection of software that performs standard business functions for corporations. The system has become very popular because it provides a complete solution to standard business requirements such as manufacturing, accounting, financial management, and human resources. SAP is a product developed and marketed by the German Company SAP AG. SAP is a German acronym for “Systemanalyse und Programmentwicklung,” which can be loosely translated into “Systems and Application Products.” Founded in 1972 by IBM application developers, SAP AG originally developed application products for the European marketplace. For nearly two decades, the company grew slowly. Early versions of its software were mainframe-based and appealed particularly to very large European corporations. Within the United States, sales were mainly to the Fortune 500.

SAP Historical Account

In SAP site we can find a quick history (presented in http://www.sap-ag.de/press/index.htm) :

• 1972 - SAP is founded • 1988 - Company goes public (Frankfurt) • 1992 - SAP R/3 solutions are launched • 1996 - SAP R/3 Release 3.1 is Internet-enabled • 1996 Company begins developing industry-specific solutions; AcceleratedSAP™

rapid implementation methodology is introduced • 1997 - New solutions for customer relationship management, supply chain

management and business intelligence are launched • 1998 - SAP delivers industry solution maps, business technology map, and service

map for complete customer lifecycle solutions and support • 1998 - Company is listed on the New York Stock Exchange • 1999 - SAP delivers on its EnjoySAP™ initiative to make SAP software easier to

learn, tailor and use • 1999 - SAP delivers mySAP.com

SAP Importance and Motivation

The importance of SAP is evidenced by the following points: • SAP employs over 28,900 people in more than 50 countries.

(http://www.sap.com/company/). • SAP has more than 64.500 installations with 12 millions of users worldwide and is

currently used by companies of all sizes, including more than half of the world's 500 top companies (http://www.sap.com/company/).

• SAP AG., an European software company, SAP is the world's largest inter-enterprise software company, and the world's third-largest independent software supplier.

• SAP AG. is the only vendor that provides detailed documentation about its implementation methodologies.

The following points can explain the motivation for SAP option:

• Globalization. The information systems industry is undergoing change; it no longer acknowledges current, basic business systems as advanced or satisfactory. Systems that merely (and mechanically) guarantee the accuracy of data are commonplace. Additionally, many organizations are faced with the complexities of diversification and process orientation - all in a global marketplace. Therefore, their systems are


272

more complex because of the data-processing intensity and the need for increased integration among systems. What organizations really need are facilities that enable them to make decisions and solve difficult problems. They need tools that have their core competencies in mind, that give them increased productivity, scalability and flexibility. Software products like SAP seek to be those tools.

• Benefits of SAP usage. Given a successful implementation, SAP can increase the value of organization's investment in information technology. It will cost a considerable amount during implementation, but afterwards, the benefits can be very substantial. First, SAP enables an organization to carry out intensive, decentralized data processing. Second, the organization should no longer need to maintain several separate systems.

• SAP strategy. Caruso and Johnson (1998) mention that following its dramatic high-end market penetration, SAP's growth strategy now focuses on expanding into additional vertical industries, on continuing to move into mid-market opportunity, and on expanding R/3's reach and user count within SAP's current customer base.

SAP R/3 System

With the introduction of its client/server SAP R/3 system in 1992, SAP AG, which already had a sizeable lead in the ERP market, unveiled a system that was attractive to medium- and small-sized companies as well as to the large companies already using SAP software. The main characteristics of the SAP R/3 system are:

• The SAP R/3 system runs on virtually any hardware/software platform and can use many different database management systems.

• The SAP R/3 code is written in an interpretive language called ABAP. (ABAP is a German acronym that, loosely translated, means “Advanced Business Application Programming.”) ABAP is very similar to COBOL in its syntax. Use of the ABAP language allows SAP customers to extend the functionality of the base product.

All SAP R/3 applications are delivered in a three-tier client/server architecture. The three

layers are: • Presentation layer - The PC-based GUI interface that is used by the end-user

community. • Application layer - The SAP application servers that service requests for data and

manage the interface to the presentation layer. • Database layer - The actual DBMS that communicates with the application servers

to fulfill their requests for data. While SAP is available for many different hardware platforms and operating systems, the

majority of SAP systems use Unix-based servers for hosting SAP (Burlenson 1999).

SAP Application Modules

The SAP R/3 application offers end users the ability to run their entire business from a single application vendor. Some SAP application features are:

• Customers choose to run their entire enterprise from SAP, while others run SAP only for specific business processes, such as manufacturing or finance. SAP is designed to allow customers to choose their own set of business functions, and it is sold in many configurations--both as specific business functions and as enterprise-wide solutions (Burlenson 1999).

• SAP customer can choose whatever applications meet his site's specific business requirements. In addition, the customer is free to customize his SAP installation, adding new database entities as well as new functionality. The result of all of this flexibility is that virtually every SAP installation has its own specific configuration and set of functions.


273

• SAP products are distributed as applications with functional modules inside each application. Applications are generally focused on particular business functions. The modules within each application perform specific business tasks such as capital investment management, personnel administration, and quality management. The major applications are: BC Basis (includes ABAP/4 Programming Language), AM Asset Management, CO Controlling, FI Financial Accounting, HR Human Resources, IS Industry Specific Solutions, PM Plant Maintenance, PP Production Planning, PS Project System, QM Quality Management, SD Sales and Distribution, MM Materials Management, WF Business Work Flow

• SAP also offers comprehensive vertical industry solutions to over 20 different industries such as: Banking, Chemicals, Healthcare, Automotive, Higher Education &Research, Aerospace & Defense, Consumer Products, Retail, Public Sector, Insurance (for more details see http://www.sap.com/solutions/industry/index.htm).

• In addition to basic business functions, SAP also offers products in the following areas (see http://www.sap.com/products/ for details): SAP Business Intelligence initiative, SAP Supply Chain Management initiative, SAP Customer Relationship Management initiative, SAP Electronic Commerce, SAP Human Resources, SAP Treasury, SAP Real Estate, SAP Environment, Health, & Safety.

•

Appendix B – Summary of ERP topics researched and for further research

274


Phase Main topics researched Topics for further research

Gen

eral

Dire

ctio

ns

ERP systems overview, their expectations and motivations are subjects very well covered in the publications found. Recently, some researchers have focused on knowledge management concerns and they have applied some theories in the ERP context. Few issues have been addressed in terms of business modeling and how this area can be improved. The review shows that development of ERP products has been centered in technological issues.

Issues unanswered such as ERP complexity, integration and flexibility should be addressed in the future. Technologically, other areas where researchers can help are the development of interfaces, componentization and integration of technologies. The improvement of business modeling techniques, analysis of business models fit and adequacy of ERP systems to business models are also areas where there is a lack of research.

Ado

ptio

n

The research in this phase has focused on how some types of organizations have adopted ERP systems and the requirements, risks and benefits associated. One study is centered in the modeling of organizational culture before selecting and installing an ERP system. Some insights for researchers that want to research in this phase are proposed by Oliver and Romm (1999).

A main issue in this phase is the development of approaches to help the adoption decision. This approach would help to assess why an ERP approach is the most adequate for a specific organization and why the current information system should be substituted. This approach would include the definition of requirements, goals and benefits of the new solution. There is also the need to study how organizations, once they decide to adopt an ERP system, evaluate the impact of the new adoption decision on the business and organizational processes, and in some cases on the organization strategy.

Acq

uisi

tion

The research in this area has focused on ERP selection methods and criteria affecting the ERP selection, specially the ERP selection process for SMEs and its particularities. One of the studies analyzed the differences in characteristics of the ERP system selection process between SMEs and large organizations. One of the studies proposes a novel way to help vendors specify their products.

Future research should encompass the selection of both product and implementation consultants. There is also the need to study the role of each party (vendor, customer and consultant) and their influence in ERP selection. An important issue is the definition of those decisions the organizations face prior to implementing the ERP solution. Other open issues are: contractual agreements analysis, different price models, analysis of returns on investments and analysis of hardware and base software needs associated to ERP system acquisitions.


275

Impl

emen

tatio

n ph

ase

Some authors have studied implementation approaches and they have proposed some new ones. However, I detected that 'implementation' does not mean the same to everyone, and each author has his own model of implementation phases/stages. I think that critical success factors research is quite well covered although some of the studies do not provide a precise definition of the critical success factors found and some of them are based in only one case study. Therefore, more effort should be put in their definition and subsequent validation. There is only one study that focuses on ERP success definition (Markus et al. 2000). Some studies have focused on ERP impacts at organizational, technological and business level, business process reengineering and organizational change management issues. The few studies developed are not enough to create a body of knowledge on the area. Case studies constituted the largest category of publications. However, I detected that in some of them, there is a lack of research methodology explanation, lack of enough data to interpret some of the presented results, and most of them lack assumptions or hypotheses (in theoretical terms) for further studies.

Adequate ERP implementation methodologies have been pointed as one of the critical success factors. However, there is a lack of studies regarding the definition, usage and adequacy of these methodologies and their value in ERP projects. As we mentioned above, critical success factors are quite well studied. However, we noted that their operationalization is not. There is the need to develop approaches to put in practice and manage the critical success factors identified in some studies. The development of techniques and approaches for the control and monitorization of ERP implementation projects is an area to be improved. It is also important to relate critical success factors with implementation methodologies. There is the need of more in-depth case studies that document ERP implementations. It would be useful to analyze knowledge transfer and knowledge management during ERP implementations. User involvement and satisfaction have not been studied in depth. Some studies have shown that implementing ERP systems is far more likely to succeed when user involvement is high and when users have realistic expectations relating to the scope of the project and system functionality (Bonner 2000). Also, there is the need to understand the different stakeholders (such as steering committee, project members, consultants, vendors) in ERP implementation projects.


276

Use

and

Mai

nten

ance

The main issues researched on this area are ERP post-implementation benefits, limitations and factors that affect ERP usage. Some studies analyze the impact of ERP systems in organizations performance and accounting functions. Some authors analyze technological issues such as ERP upgrades, security, maintenance tasks and databases performance.

At a time when most organizations are starting this phase, a lot of issues arise; issues which focus mainly on the technological perspective. ERP impact on organizations at all levels (technological, organizational and business) should also be analyzed. There is also the need to study the level of integration of ERP systems in organizations. It would be interesting to define critical success factors for the usage and maintenance phase. User satisfaction and human factors affecting this satisfaction should be studied. Usability is also an important topic and probably the human computer interaction area can help on this analysis. The way organizations create and manage knowledge related to their ERP systems and the usage of knowledge theory on this subject would be a topic for a valuable research. With regard to ERP maintenance, other open issues are: outsourcing services, maintenance models and techniques, improvement of ERP maintenance based in previous bespoken maintenance, management of upgrades and their impact.

Evol

utio

n Ph

ase

The issues studied here have also been mainly technology-oriented, such as development of interfaces with other systems, the integration of customer relationship management modules and usage of web technologies. Another important issue studied is workflow management with new approaches and architectures being proposed.

One of the trends is to know how are ERP vendors improving their platforms and the effect on actual ERP systems installed in organizations. Research on how ERP platforms may be combined with other tools is needed, especially for the creation of standards and improvement of ERP efficiency. There is also the need to analyze when an organization should go for emerging ERP capabilities and how to integrate them in the overall IS. Finally the need to analyze the organizational perspective and see what is the impact of these emerging capabilities in organizations.

Ret

irem

ent P

hase

We did not find any publication related to this phase but some publications (e.g. Davenport 1998; Scott 1999a) cited some cases of ERP systems retirement for various reasons. Some publications appeared in the Press (e.g. New York Times, Wall Street Journal, the Economist) relating some ERP implementation disasters. The most famous retirement case is FoxMeyer Drugs (Scott 1999a). Now, the majority of organizations are in the implementation or in the use and maintenance phases. We expect that in the future these cases will be analyzed in more detail.


277

ERP and Education

Main Topics Researched

The analysis of IS curricula is quite well covered in research studies as well as response of universities to the demand of people with ERP knowledge. Some ERP courses are quite explained in detail. However, their importance in relation to the ERP market is not. Studies of ERP adoption and usage by universities are very useful for other universities that are in the process of adopting an ERP system.

Topics for Further Research

An important issue is how universities are dealing with ERP evolution and how are they planning and adapting their courses to this evolution. Another issue is the ERP market satisfaction with the people that acquire ERP academic knowledge. In relation with ERP adoption and usage by universities, studies related with all the phases of the ERP lifecycle could already be undertaken.

Appendix C – An overview of the major IS research paradigms

278

Appendix C – An overview of the major IS research paradigms

Table 55. An overview of the major IS research paradigms (source: Khazanchi and Munkvold 2002) Positivist Interpretivist Critical Research Ontological assumptions

“Naïve realism” in which an understandable reality is assumed to exist, driven by immutable natural laws. True nature of reality can only be obtained by testing theories about actual objects, processes or structures in the real world.

Relativist; the social world is produced and reinforced by humans through their action and interaction.

Historical realist; social reality is historically constituted; human beings, organizations, and societies are not confined to existing in a particular state.

Epistemological assumptions

– Verification of hypothesis through rigorous empirical testing.

– Search for universal laws or principles.

– Tight coupling among explanation, prediction and control.

– Understanding of the social world from the participants’ perspective, through interpretation of their meanings and actions.

– Researchers’ prior assumptions, beliefs, values, and interests always intervene to shape their investigations.

– Knowledge is grounded in social and historical practices.

– Knowledge is generated and justified by a critical evaluation of social systems in the context of researchers’ theoretical framework adopted to conduct research.

Relationship between theory and practice

It is possible to discover universal laws that govern the external world.

– Generative mechanisms identified for phenomena in the social sciences should be viewed as ‘tendencies’, which are valuable in explanations of past data but not wholly predictive for future situations.

– Generalizations point to regularities of process rather than cross-sectional differences.

– Generalization in critical research focuses on the “totality” of relationships.

– There can be no theory-independent collection and interpretation of evidence to conclusively prove or disprove a theory.

Role of the researcher

Objective, impartial observer, passive, value-neutral.

Interactive, the researcher interacts with the human subjects of the enquiry, changing the perceptions of both parties.

Transformative; initiating change in social relations and practices, helping to eliminate the bases of alienation and domination.

Appendix D – PQM matrix for each SAP implementation phase

279


Next, we present the PQM matrix for each SAP implementation phase:

1. SAP Phase 1 – Project Preparation. 2. SAP Phase 2 – Business Blueprint. 3. SAP Phase 3 – Realization. 4. SAP Phase 4 – Final Preparation. 5. SAP Phase 5 – Go Live & Support.


280

1. SAP Phase 1 – Project Preparation

ASAP Phase 1

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e In

fras

truct

ures

and

Inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

Define project mission statement 1 1 1 1 1 1 1 7 Define business drivers 1 1 1 1 1 5 Identify business measurements 1 1 1 1 1 5 Identify project measurements 1 1 1 1 1 1 6 Develop change charter 1 1 1 1 1 5 Assemble project charter components 1 1 1 3 Approve project charter 1 1 1 1 1 1 6 Create and issue project charter 11 Review implementation proposal 1 1 1 1 1 1 1 1 8 Confirm implementation proposal 1 1 1 1 1 1 1 1 1 1 10 Check strategy for corporate rollout 1 1 1 1 1 5 Review and refine implementation strategy 12 Plan environment 1 1 1 1 1 1 6 Set up environment 1 1 1 3 Establish project team working environment 7 Refine organization and roles 1 1 1 1 4 Assign people to roles 1 1 1 1 1 5 Assign people to core change roles 1 1 1 1 4 Conduct project team transition meeting 1 1 1 3 Create the extended change team 1 1 1 1 1 5 Determine project organization 11


281

ASAP Phase 1

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e In

fras

truct

ures

and

Inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

Create project work plan 1 1 1 1 4 Create project budget plan 1 1 1 3 Create project resource plan 1 1 1 1 1 5 Prepare project plan 6 Review suggestions from pre-implementation 1 1 1 3 Refine training course plan 1 1 1 1 4 Register and schedule team training 1 1 1 3 Organizational change management training and team building 1 1 2 Create project team training plan 6 W1.1. Initial project planning 19 Identify project communication plan 1 1 1 3 Define project documentation 1 1 1 3 Create issue management plan 1 1 1 1 1 5 Create organizational change management plan 1 1 1 1 1 1 6 Create scope management plan 1 1 1 1 1 1 1 7 Create team building plan 1 1 1 1 1 5 Define project planning and monitoring plan 1 1 2 Define strategy for using R/3 services 1 1 1 3 Determine quality assurance standards 1 1 1 1 1 5 Define project management standards and procedures 13 Project review preparation 1 1 1 3 Define system configuration standards 1 1 1 3 Define end user training and documentation strategies 1 1 1 1 4


282

ASAP Phase 1

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e In

fras

truct

ures

and

Inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

Define testing strategies 1 1 1 3 Define post-implementation service and support strategy 1 1 2 Define system authorization standards for project team 1 1 1 3 Determine system problem and errors handling procedures 1 1 1 3 Define system enhancement and modification approvals 1 1 1 1 1 5 Define ABAP development standards 1 1 Define implementation standards and procedures 14 Determine required systems 1 1 1 1 1 5 Determine client deployment strategy 1 1 1 3 Define release strategy 1 1 1 3 Define transport system strategy 1 1 1 1 4 Define system landscape strategy 8 W1.2. Project procedures 19 Prepare kickoff meeting 1 1 1 3 Conduct kickoff meeting 1 1 1 1 1 5 Company-wide project Introduction 1 1 1 3 Kickoff meeting 6 prepare for standards meeting 1 1 1 3 conduct standards meeting 1 1 1 3 Project team standards meeting 4 W1.3. Project kickoff 7 Complete technical requirements questionnaire 1 1 1 3 Define technical infrastructure needs 1 1 2


283

ASAP Phase 1

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e In

fras

truct

ures

and

Inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

Identify technical requirements 3 Size initial hardware 1 1 1 1 4 Review system sizing results 1 1 1 3 Approve sizing results 1 1 1 1 1 5 Order initial hardware 1 1 1 1 1 1 1 7 Order remote network connection 1 1 1 3 Procure hardware 8 W1.4. Technical requirements planning 8 Conduct quality check 1 1 Sign off project preparation phase 1 1 1 1 4 Perform quality check and obtain approval 4 W1.5. Quality check project preparation phase 4 Project preparation Phase 22 Total 24 12 8 4 3 7 19 47 13 5 22 26 6 4 15 0 7 2 4 11 2 2 1 Sten 8 6 5 4 4 5 7 10 6 4 8 8 5 4 6 4 6 4 4 6 4 4 4


284

2. SAP Phase 2 – Business Blueprint

ASAP Phase 2

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e In

fras

truct

ure

and

Inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

Prepare project preparation review 1 1 1 1 1 1 1 7 Conduct project preparation review 1 1 1 1 1 1 1 1 1 9 Follow up on project preparation review recommendations 1 1 1 1 1 1 6 Project preparation review 9 Prepare for status meeting 1 1 1 1 4 Attend status meetings 1 1 1 3 Follow-up on action items 1 1 1 3 Correct project variances 1 1 2 Refine project plan 1 1 1 3 Conduct project team status meetings 6 Prepare for the steering committee meeting 1 1 1 1 4 Attend the steering committee meeting 1 1 1 1 4 Follow-up on action items 1 1 1 3 Conduct steering committee meetings 5 Conduct team building activities 1 1 1 1 1 1 6 Define end user roles and responsibilities 1 1 1 3 General project management 8


285

ASAP Phase 2

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e In

fras

truct

ure

and

Inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

W2.1. Project management blueprint phase 12 Develop perceived organizational impacts 1 1 1 1 4 Create a business impact map 4 Develop a leadership risk assessment tool 1 1 1 3 Administer the leadership risk assessment tool 1 1 1 3 Create leadership risk profile 1 1 1 3 Conduct leadership risk workshop 1 1 1 1 4 Integrate leadership risk assessment with sponsor-building process 1 1 1 3 Complete the baseline leadership risk assessment 6 Implement senior sponsorship process 1 1 1 1 1 5 Implement key site sponsorship process 1 1 1 1 1 1 1 7 Develop sponsorship strategy 7 Develop a project team risk assessment tool 1 1 1 3 Administer the project team risk assessment tool 1 1 1 3 Create a project team risk profile 1 1 1 1 4 Conduct project team risk workshop 1 1 1 1 4 Implement action plan resulting from risk workshop 1 1 1 3 complete the baseline project team risk assessment 7


286

ASAP Phase 2

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e In

fras

truct

ure

and

Inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

Identify the organizational context for the change project 1 1 2 Create the organizational risk assessment plan 1 1 1 1 4 Develop the organizational risk assessment tool 1 1 2 Conduct line manager engagement meetings 1 1 1 3 Administer the baseline organizational risk assessment tool 1 1 1 1 4 Create the baseline organizational risk profile 1 1 1 3 Conduct organizational risk workshop(s) 1 1 1 1 4 Summarize results and debrief with key site sponsors 1 1 2 Create and provide feedback packages to line managers 1 1 1 1 4 Implement action plan resulting from organizational risk workshop(s) 1 1 1 1 4 Complete the baseline organizational risk assessment 7 Identify point person to manage project communication 1 1 1 1 4 Develop foundation for project communications 1 1 1 3 Integrate risk assessment results into ongoing communications 1 1 2 Disseminate project-specific information across the organization 1 1 1 1 4 Establish change communication framework 6 Establish the skills development team 1 1 1 3 Develop the organizational change management training strategy 1 1 1 3


287

ASAP Phase 2

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e In

fras

truct

ure

and

Inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

Select internal or external training delivery partners 1 1 1 3 Define processes for evaluating and managing training effectiveness 1 1 2 Establish management structure for skills development process 5 Create the core knowledge transfer team 1 1 2 Define the core knowledge transfer processes 1 1 2 Establish management structure for knowledge transfer process 3 W2.2. Organizational change management 14 Refine training schedule 1 1 1 3 Prepare for training 1 1 2 Attend project team training 1 1 2 Review and assess post training skills 1 1 1 1 4 Conduct project team training 6 W2.3. Project Team Training business Blueprint phase 6 Document physical system(s) layout and distribution 1 1 1 3 Define and document printing infrastructure 1 1 2 Document network topology 1 1 2 Document interface topology 1 1 1 3 Define change request management 1 1


288

ASAP Phase 2

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e In

fras

truct

ure

and

Inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

Define release management strategy 1 1 2 Define desktop management strategy 1 1 2 Approve technical design 1 1 Create technical design 6 Install Initial hardware 1 1 2 Verify initial systems technical environment 1 1 1 1 4 Install and configure development system 1 1 2 Install PC clients for project team members 1 1 Create user master records for project team members 1 1 Create operating system and database security for project team 1 1 2 Install and configure printing services for project team 1 1 2 Configure remote network connection 1 1 2 Set up remote connection to SAP 1 1 Set up development environment 3 Install and configure development system clients 1 1 2 Configure and test transport system 1 1 2 Document the 'DEV-Clients' section of IT infrastructure document 1 1 Set up initial system landscape 3


289

ASAP Phase 2

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e In

fras

truct

ure

and

Inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

Conduct basis and system administration workshop 1 1 1 3 Define system administration for development system 1 1 1 1 4 Configure CCMS 1 1 Define backup strategy and configure SAPDBA 1 1 2 Verify system administration functions 1 1 2 Identify authorization objects for tasks 1 1 1 3 Define change request and transport process 1 1 Define release management strategy 1 1 1 3 Maintain System Administration Procedures 9 Create enterprise IMG and maintain project header data 1 1 Generate project IMG and project IMG views 1 1 Initialize IMG 1 W2.4. Develop system environment 12 Schedule organizational structure workshop requirements 1 1 2 Distribute organization structure guidelines 1 1 2 Conduct organization structure workshop 1 1 1 1 1 1 1 7 Recommend and approve organization structure 1 1 1 1 1 1 1 7 Define Business organization structure 10


290

ASAP Phase 2

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e In

fras

truct

ure

and

Inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

W2.5. Business organization structure definition 10 Schedule business process workshops 1 1 1 3 Conduct business process guideline workshop 1 1 1 1 1 5 Prepare for business process workshops 6 Determine global parameters 1 1 1 1 1 1 6 Determine enterprise standards 1 1 1 1 1 1 6 Conduct general requirements workshops 7 Determine business requirements 1 1 1 1 1 5 Determine the need for extended functions 1 1 1 1 4 Determine reporting requirements 1 1 1 1 4 Determine required interfaces 1 1 1 1 4 Determine conversion requirements 1 1 1 1 1 5 Determine require enhancements 1 1 1 1 1 1 1 7 Clarify deficient areas 1 1 1 1 4 Refine business requirement descriptions and models 1 1 1 3 Determine need for additional detailed workshops 1 1 2 Schedule detailed requirements workshops 1 1 Conduct business workshops 11


291

ASAP Phase 2

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e In

fras

truct

ure

and

Inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

Determine detailed requirements 1 1 1 1 1 5 Refine business process definition and models 1 1 1 1 4 Conduct detailed requirements workshops 6 Perform organizational optimization analysis 1 1 1 1 4 Refine project organization and roles 1 1 1 1 1 5 Assemble business blueprint 1 1 1 1 4 Identify baseline scope 1 1 1 1 4 Verify business blueprint completeness 1 1 1 3 Complete business blueprint 10 Prepare for the business blueprint review 1 1 2 Conduct the business blueprint review 1 1 1 1 1 5 Business blueprint review and sign off 6 Define end user training and documentation requirements 1 1 2 Develop prototype 1 1 2 Finalize end user training and documentation plan 1 1 2 Draft end user training and documentation plan 2 W2.6. Business requirements definition 19 Conduct quality check 1 1


292

ASAP Phase 2

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e In

fras

truct

ure

and

Inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

Sign off business blueprint phase 1 1 1 1 4 Perform quality check and Obtain Approval 4 W2.7. Quality check business blueprint phase 4 Business Blueprint Phase 19 total 17 39 2 7 26 36 20 36 5 9 28 26 12 3 40 9 4 7 2 21 4 3 4 Sten 6 9 3 4 7 9 6 9 4 4 7 7 5 4 9 4 4 4 3 6 4 4 4


293

3. SAP Phase 3 – Realization

ASAP Phase 3

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e In

fras

truct

ures

and

Inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

Prepare Business blueprint review 1 1 1 1 1 1 6 Conduct business blueprint project review 1 1 1 1 1 1 1 1 1 9 Follow-up on business blueprint review recommendations 1 1 1 1 1 1 6 Business blueprint review 9 Prepare for status meeting 1 1 1 3 Attend status meetings 1 1 1 3 Follow-up on action items 1 1 2 Correct project variances 1 1 1 1 4 Refine project plan 1 1 1 3 Conduct project team status meetings 6 Prepare for steering committee meeting 1 1 1 3 Attend steering committee meeting 1 1 1 1 4 Follow up on action items 1 1 1 3 Conduct steering committee meetings 6 Determine production support plan 1 1 1 1 1 1 1 7 Determine cutover plan 1 1 1 3 Initial planning for production support and cutover 7


294

ASAP Phase 3

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e In

fras

truct

ures

and

Inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

Conduct team building activity 1 1 1 1 1 5 Project management 5 Prepare project review 1 1 1 3 Conduct project review 1 1 1 1 1 1 6 Follow up on recommendations 1 1 1 1 4 Realization review 10 W3.1 - Project management realization phase 17 Define ongoing project team risk management process 1 1 2 Conduct periodic project team risk assessment(s) and workshop(s) 1 1 2 Document and analyze implementation risks over time 1 1 Develop sustained project team risk management process 3 Define organizational risk management process 1 1 1 3 Conduct periodic organizational risk assessment(s) and workshop(s) 1 1 1 1 4 Document and analyze implementation risks over time 1 1 2 Create and provide feedback package(s) to line managers 1 1 1 1 4 Conduct risk management meetings with key constituencies 1 1 2 Deliver key project communications 1 1 1 1 4 Manage ongoing project sponsorship process 1 1 2


295

ASAP Phase 3

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e In

fras

truct

ures

and

Inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

Manage ongoing skills development process 1 1 1 3 Maintain knowledge transfer team and process 1 1 1 3 Expand organizational change management training and team building 1 1 1 3 Develop sustained organizational risk management process 6 W3.2 - Sustaining organizational change management processes 6 Refine training schedule 1 1 1 3 Prepare for training 1 1 Review project team risk assessment results 1 1 1 3 Attend project team training 1 1 2 Review post training skills 1 1 1 3 Conduct project team training 6 W3.3 - Project team training realization phase 6 Refine baseline 1 1 1 1 4 create configuration plan for baseline 1 1 1 3 Determine test cases 1 1 2 Create test plan for baseline 1 1 1 3 Assign resources 1 1 1 3 Approve plans for baseline configuration 1 1 1 3


296

ASAP Phase 3

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e In

fras

truct

ures

and

Inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

Refine project IMG 1 1 Develop plans for baseline configuration 7 Establish general settings 1 1 2 Establish organizational structure 1 1 2 Incorporate predefined settings 1 1 2 Configure general settings and organizational structure 2 Configure processes and functions 1 1 1 3 Migrate objects to QA environment 1 1 Test baseline 1 1 1 1 1 5 Document and resolve issues 1 1 1 3 Refine business blueprint 1 1 1 3 Verify baseline configuration completion 1 1 2 Configure and validate baseline 5 Prepare baseline scenarios 1 1 2 Develop baseline confirmation agenda 1 1 1 1 4 Prepare for baseline confirmation session 1 1 1 1 1 5 Prepare baseline confirmation 7 Perform baseline scenarios 1 1 2


297

ASAP Phase 3

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e In

fras

truct

ures

and

Inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

Review and sign off baseline confirmation 1 1 1 3 Perform baseline confirmation 3 W3.4 - Baseline configuration and confirmation 10 Develop failure test plan 1 1 1 1 1 4 Develop volume test plan 1 1 1 1 4 Develop stress test plan 1 1 1 3 Develop system administration test plan 1 1 1 1 4 Develop printing and fax test plan 1 1 1 1 1 5 Develop system test plan 6 Determine possible failure scenarios 1 1 2 Define disaster recovery procedures 1 1 1 1 1 5 Establish service level commitments 1 1 1 3 Define service level commitment 5 Verify client copy utilities 1 1 1 3 Verify daily checks 1 1 2 Verify transport system 1 1 2 Verify backup and recovery procedures 1 1 1 3 Establish system administration functions 4


298

ASAP Phase 3

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e In

fras

truct

ures

and

Inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

Install hardware 1 1 2 Verify systems technical environment 1 1 1 1 4 Install quality assurance system 1 1 Set up user master records 1 1 Secure quality assurance system 0 Set up printing services 1 1 2 Set up client management and transport system 0 Set up quality assurance environment 4 Verify workload and data storage quantity estimates 1 1 1 3 Design production system disk layout 1 1 2 Define production system design 4 Define production system security 1 1 Define production operating procedures 1 1 2 Define production system administration 1 1 Define production system printing environment 1 1 2 Define production database administration procedures 1 1 Create SAP system operation manual 1 1 Define production system management 2


299

ASAP Phase 3

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e In

fras

truct

ures

and

Inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

Install production hardware 1 1 2 Verify production system technical environment 1 1 1 1 4 Install production system 1 1 2 Install and configure network environment 1 1 2 Install desktop hardware and components 1 1 2 Secure operating system and database 1 1 2 Install printers and configure printing services 1 1 2 Set up production environment 4 W3.5 - System management 7 Refine final scope 1 1 2 Create configuration plan for final scope 1 1 2 Determine test cases 1 1 2 Create test plan for final scope 1 1 1 1 4 Assign resources 1 1 2 Schedule configuration workshops 1 1 2 Approve plans for final scope configuration 1 1 1 1 4 Develop plans for final scope configuration 6 Conduct workshop (cycle 1 - n) 1 1 2


300

ASAP Phase 3

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e In

fras

truct

ures

and

Inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

Document business process decisions (cycle 1 - n) 1 1 2 Document and resolve issues (cycle 1 - n) 1 1 Conduct configuration workshops (cycle 1 - n) 3 Configure processes and functions (cycle 1 - n) 1 1 Migrate objects to QA environment (cycle 1 - n) 1 1 Test final configuration (cycle 1 - n) 1 1 1 3 Verify final configuration completion 1 1 2 configure and validate final scope (cycle 1 - n) 4 Prepare final confirmation scenarios 1 1 2 Develop final confirmation agenda 1 1 Prepare for final confirmation sessions 1 1 Prepare final confirmation 3 Perform final confirmation scenarios 1 1 1 3 Review and sign off final confirmation 1 1 1 1 4 Perform final confirmation scenarios 4 W3.6 - Final configuration and confirmation 9 Create and register developers 0 Create change requests 0


301

ASAP Phase 3

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e In

fras

truct

ures

and

Inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

Prepare ABAP development project 0 Define application hierarchy and development classes 0 Create central repository objects 0 Coordinate ABAP development 0 W3.7 - Prepare and coordinate ABA development 0 Create conversion detailed definition 1 1 1 3 Create conversion programs 1 1 1 1 4 Complete manual conversion procedures 1 1 1 1 4 Create conversion procedures 4 Define conversion test procedures 1 1 1 1 4 Test and review conversion programs 1 1 1 1 1 5 Approve conversion test results 1 1 1 3 Migrate programs to the QA environment 1 1 Test and migrate conversion programs 7 W3.8 - Develop conversion programs 7 Create interface detailed information 1 1 1 1 1 1 6 Develop online interface programs 1 1 1 1 4 Develop batch interfaces 1 1 1 1 4


302

ASAP Phase 3

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e In

fras

truct

ures

and

Inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

Create interface programs 7 Define interface procedures 1 1 1 3 Test and review interface programs 1 1 1 1 1 1 6 Approve interface results 1 1 1 2 Migrate programs to QA environment 1 1 Test and migrate interface programs 4 W3.9 - Develop application interface programs 8 Create enhancement detailed definition 0 Check for approval 1 1 2 Create enhancements 0 Develop enhancement procedures 2 Define enhancement test procedures 0 Test and review enhancement programs 1 1 1 3 Approve enhancement test results 1 1 2 Migrate enhancements to QA environment 1 1 Test and migrate enhancement programs 3 W3.10 - Develop Enhancements 4 Create report detailed definition 1 1 2


303

ASAP Phase 3

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e In

fras

truct

ures

and

Inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

Check for approval 1 1 1 1 4 Develop reports 1 1 2 Create report procedures 7 Define reports test procedures 1 1 1 3 Test and review reports 1 1 1 3 Approve reports for results 1 1 1 1 4 Migrate reports to QA environment 0 Test reports 5 W3.11 - Create reports 10 Create form detailed definition 1 1 2 Check for approval 1 1 1 1 1 5 Develop forms 1 1 1 3 Create form procedures 6 Define test procedures for forms 1 1 1 3 Test and review forms 1 1 1 3 Approve form test results 1 1 1 1 4 Migrate forms to QA environment 0 Test forms 5


304

ASAP Phase 3

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e In

fras

truct

ures

and

Inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

W3.12 - Create forms 8 review company security 1 1 document transactions associated with job functions 1 1 conduct authorization interview with data owners 1 1 2 identify information access and service use 1 1 create authorization management procedures 1 1 Create authorization detailed design 2 Create activity groups 1 1 Generate authorization profiles 1 1 Create user master models for job roles 0 Test user master models 1 1 2 Implement authorization concept 2 Identify activity groups for users 1 1 Create user masters 1 1 2 Validate user masters for job functions 1 1 Refine authorization design 1 1 Sign off authorization design 1 1 2 Validate authorization concept 2


305

ASAP Phase 3

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e In

fras

truct

ures

and

Inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

W3.13 - Establish authorization concept 5 Design archive management strategy 1 1 1 1 4 Create archiving management 1 1 Test archive procedures 1 1 1 1 4 Review archiving 1 1 1 3 Create archiving management 6 W3.14 - Establish archiving management 6 Define integration test scope 1 1 1 1 4 Define test cases 1 1 1 3 Create final integration test plan 1 1 1 1 1 5 Determine final integration test plan 6 Verify migration of all objects to QA 1 1 Freeze system 1 1 1 1 4 Conduct final integration test 1 1 1 1 4 Finalize system 1 1 1 1 4 Review and finalize final integration test 1 1 1 3 Conduct final integration test 6 W3.15 - Final integration test 8


306

ASAP Phase 3

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e In

fras

truct

ures

and

Inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

Define end user documentation requirements 1 1 1 3 Write end user documentation development plan 1 1 1 1 1 5 Approve end user documentation development plan 1 1 1 3 Prepare end user documentation development plan 6 Conduct end user documentation and training workshop 1 1 1 3 Create end user documentation 1 1 Create end user documentation 3 Create end user training materials 1 1 Create end user training instructor guide 1 1 Develop end user training materials 1 Organize training facility, equipment and logistics 1 1 1 3 Confirm end user enrollment 1 1 1 3 Prepare end user training 3 W3.16 - End User documentation and training material 7 Conduct quality check 1 1 Sign off realization phase 1 1 1 1 4 Conduct quality check and obtain approval 4 W3.17 - Quality check realization phase 4


307

ASAP Phase 3

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e In

fras

truct

ures

and

Inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

Realization Phase total 13 16 4 8 4 63 11 52 7 3 23 34 14 41 50 6 3 20 1 35 9 53 12 Sten 5 5 4 4 4 10 4 9 4 4 6 7 5 8 9 4 4 5 3 7 4 9 5


308

4. SAP Phase 4 – Final Preparation

ASAP Phase 4

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e in

fras

truct

ure

and

inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

Prepare project review 1 1 1 1 1 1 6 Conduct project review 1 1 1 1 1 1 1 1 1 9 Follow-up on recommendations 1 1 1 1 1 1 6 Final preparation review 9 Prepare for status meeting 1 1 1 3 Attend status meetings 1 1 1 1 4 Follow up on action items 1 1 1 3 Correct project variances 1 1 1 3 Refine project plan 1 1 1 1 4 Conduct project team status meetings 7 Prepare for steering committee meeting 1 1 1 3 Attend steering committee meeting 1 1 1 1 4 Follow up on action items 1 1 1 1 4 Conduct steering committe meetings 6 Continue organizational change management processes 1 1 1 1 4 Conduct team building activity 1 1 1 1 1 1 6 General project management 6


309

ASAP Phase 4

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e in

fras

truct

ure

and

inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

W4.1 - Project management final preparation phase 13 Finalize logistics for training 1 1 1 3 Initialize end user training environment 1 1 1 3 Load training data into end user training environment 1 1 1 3 Prepare for end user training 3 Conduct end user training 1 1 2 Review end user training 1 1 1 3 Conduct end user training 3 W4.2 - End user training 3 Configure CCMS for production environment 1 1 2 Configure production printing and spool administration 1 1 2 Train system administration itself 1 1 Establish production system administration 4 Conduct volume test 1 1 1 1 1 5 Conduct stress test 1 1 1 1 1 5 Conduct system administration tests 1 1 2 Conduct disaster recovery test 1 1 1 1 4 Conduct backup and restore procedure test 1 1 1 3


310

ASAP Phase 4

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e in

fras

truct

ure

and

inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

Conduct printing and fax tests 1 1 1 1 4 Conduct going live check 1 1 1 3 Conduct technical system tests 5 W4.3 -System management 6 Review conversion timing and planning 1 1 1 1 4 Create conversion check list 1 1 1 1 4 Determine production readiness 1 1 1 3 Approval for cutover 1 1 1 1 4 Refine cutover 8 Define help desk procedures 1 1 1 3 Create help desk facility 1 1 2 Reorganize team for productive support 1 1 1 3 Staff help desk 1 1 1 3 Define long-term production support strategy 1 1 1 3 Refine production support plan 8 W4.4 - Detailed project planning 13 Transport to production environment 1 1 Perform conversions 1 1 1 3


311

ASAP Phase 4

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e in

fras

truct

ure

and

inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

Perform manual entries 1 1 1 1 1 5 Perform cut over to production system 6 Approve the production system 1 1 1 1 1 1 6 Secure production environment 1 1 2 Verify end users are ready 1 1 1 3 Final approval for going live 8 W4.5 – Cutover 10 Conduct quality check 1 1 Sign off final preparation phase 1 1 1 1 4 W4.6 - Conduct quality check and obtain approval 4 Final preparation phase 20 Total 6 4 2 1 0 14 5 28 3 3 15 11 10 14 8 4 3 0 0 10 1 9 7 Sten 5 5 4 4 3 8 5 12 4 4 8 7 6 8 6 5 4 3 3 6 4 6 6


312

5. SAP Phase 5 – Go Live & Support

ASAP Phase 5

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e In

fras

truct

ure

and

Inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

Prepare project review 1 1 1 1 1 1 6 Conduct project review 1 1 1 1 1 1 1 1 1 9 Follow-up on recommendations 1 1 1 1 1 1 6 Go Live &support Review 9 Direct problems and issues 1 1 1 3 Manage and resolve problems 1 1 1 1 1 1 6 Provide production support 6 Monitor daily and weekly transactions 1 1 1 3 Resolve issues 1 1 1 1 4 Confirm live environment 1 1 2 Validate live business process results 6 W5.1. Production support 11 Review and close open issues 1 1 2 Review business benefits 1 1 1 1 1 1 1 7 Summarize and review lessons learned from change process 1 1 Complete organizational change management processes 1 1 1 1 1 5 Sign off and close issue list 1 1 1 3


313

ASAP Phase 5

Sust

aine

d M

anag

emen

t Sup

port

Effe

ctiv

e O

rgan

izat

iona

l Cha

nge

Goo

d Pr

ojec

t Sco

pe M

anag

emen

t

Ade

quat

e Pr

ojec

t Tea

m C

ompo

sitio

n

Mea

ning

ful B

usin

ess P

roce

ss R

edes

ign

Use

r Inv

olve

men

t and

Par

ticip

atio

n

Ade

quat

e pr

ojec

t spo

nsor

Ade

quat

e pr

ojec

t man

ager

Trus

t Bet

wee

n Pa

rtner

s

Ded

icat

ed S

taff

and

Con

sulta

nts

Stro

ng C

omm

unic

atio

n In

war

ds a

nd O

utw

ards

Form

aliz

e Pr

ojec

t Pla

n/Sc

hedu

le

Ade

quat

e Tr

aini

ng P

rogr

am

Prev

entiv

e Tr

oubl

e Sh

ootin

g

Usa

ge o

f App

ropr

iate

Con

sulta

nts

Empo

wer

Dec

isio

n M

aker

s

Ade

quat

e ER

P Im

plem

enta

tion

Stra

tegy

Avo

id C

usto

miz

atio

n

Ade

quat

e ER

P V

ersi

on

Ade

quat

e In

fras

truct

ure

and

Inte

rfac

es

Ade

quat

e Le

gacy

Sys

tem

s Kno

wle

dge

Form

aliz

ed te

stin

g pl

an

Ade

quat

e da

ta m

igra

tion

proc

ess

Cou

nt

Project review 10 W.5.2. Project end 10 Go Live &support 15 Total 6 3 1 0 1 3 5 9 3 3 8 5 1 5 1 0 3 0 0 0 0 0 0 Sten 8 6 4 4 4 6 7 10 6 6 10 7 4 7 4 4 6 4 4 4 4 4 4

DEFINITION AND ANALYSIS OF CRITICAL SUCCESS FACTORS …• A CSF unified model for ERP...

Documents

Transcript of DEFINITION AND ANALYSIS OF CRITICAL SUCCESS FACTORS …• A CSF unified model for ERP...