1
F
ACOLTÀ DII
NGEGNERIARELAZIONE PER IL CONSEGUIMENTO DELLA LAUREA SPECIALISTICA IN INGEGNERIA GESTIONALE
A Maturity Model for an ERP Implementation
RELATORI IL CANDIDATO
_________________________
___________________
Prof. Ing. Riccardo Dulmin Andrea Scanzo
Dipartimento di Ingegneria dell’Energia e dei Sistemi
_________________________
Prof. Ing. Valeria Mininno
Dipartimento di Ingegneria dell’Energia e dei Sistemi
_________________________
Ing. Davide Aloini
Dipartimento di Ingegneria dell’Energia e dei Sistemi
Sessione di Laurea del 04/05/2011 Anno Accademico 2009/2010
2 A Risk Management Maturity Model for a ERP project
Andrea Scanzo
Abstract
In recent years the ERP project implementation has become one of the most investments in IT for firms. Given its complexity and the massive use of resources needed, the ERP implementation project is subject to a high risk of failure. Therefore the adoption of an approach based on risk management appears to be essential, but considerably difficult and uncertain.
The general objective of this study was to develop a model that aims to assess the readiness of organization to implement the ERP system. Based on articles collected from the main trends of literature, it was possible to identify the key dimensions of analysis and create a simple framework for evaluating companies. Measuring their current level of maturity, the model provides information about their strengths and weaknesses and encourage them to implement actions to raise their degree of maturity and thus to increase the probability of success of ERP.
Sommario
Negli ultimi anni l’introduzione dei sistemi ERP sta diventando uno dei maggiori investimenti in IT per le aziende. Data la complessità e il gravoso impiego di risorse, il progetto di implementazione di un sistema ERP è soggetto ad un elevato rischio di fallimento. Di conseguenza l’adozione di un approccio basato sul Risk Management risulta essere indispensabile, ma notevolmente difficile e incerto.
L’obiettivo generale di questo studio è sviluppare un modello per valutare quanto un’azienda, definito il project scope, è in grado di affrontare tale progetto di introduzione. Basandosi su articoli raccolti dai principali filoni della letteratura, è stato possibile individuare le dimensioni chiave di analisi e creare un semplice frame work per la valutazione delle aziende. Misurando il loro livello di maturità attuale, il modello fornisce informazioni circa i loro punti di forza e di debolezza, incoraggiandoli ad attuare azioni per incrementare il loro grado di maturità e aumentare così la probabilità di successo del progetto ERP.
3
Index
A Risk Management Maturity Model for a ERP project ... 2
Sommario ... 2
0. Introduction ... 6
1. Enterprise Resource Planning ... 9
1.1 What Is an ERP ... 9
1.2 ERP History ... 10
1.3 Market of ERP System ... 13
1.4 The Characteristics of an ERP System ... 14
1.4.1 Client / Server Architecture ... 14
1.4.2 Database ... 14
1.4.3 Modular System ... 15
1.4.4 Integrated System ... 16
1.4.5 Standardization and Customization ... 17
1.5 Reason for Adopting an ERP System ... 17
2. Risk Approach to ERP Implementation ... 21
2.1 ERP Implementation Phases ... 21
2.2 Risk Management ... 24
2.2.1 Introduction to Risk Management ... 24
2.2.2 Risk Management Phases ... 25
2.3 Risk Factor in an ERP Implementation ... 29
2.4 Project Success or Failure ... 34
4
3.1 Research Objective and Methodology ... 36
3.2 Introduction to Maturity Model ... 37
3.2.1 Capability Maturity Model ... 38
3.2.2 Risk Management Maturity Model ... 40
3.3 The ERP Maturity Model ... 42
3.3.1 Model Structure... 42
3.3.2 Model Definitions ... 43
3.3.3 Maturity Matrix ... 43
3.4 Individuation of key Maturity Areas ... 44
3.5 Key Area: Project ... 45
3.5.1 Implementation Strategy ... 46
3.5.2 Project Dimension ... 48
3.5.3 Project Impact ... 49
3.6 Key Area: Organization Context ... 50
3.6.1 Organizational Culture ... 50
3.6.2 ICT Governance... 53
3.6.3 Organization Structure ... 55
3.6.4 Technology ... 57
3.6.5 Financial ... 58
3.7 Key Area: ERP Implementation Process ... 60
3.7.1 Skills ... 63
3.7.2 Resources ... 64
3.7.3 Methods... 67
5
3.8.1 Skills ... 71
3.8.2 Resources ... 72
3.8.3 Methods... 72
3.9 Evaluation Method ... 76
3.9.1 How to Use the Model ... 77
3.9.2 Cluster D ... 77
3.9.3 Cluster C ... 79
3.9.4 Cluster B ... 81
3.9.5 Cluster A ... 82
4.Case Study ... 83
4.1 Case Study Overview ... 83
4.1.1 The ERP Project Overview ... 83
4.2 Case Study Results and analysis ... 84
5. Conclusion ... 87
6. Acknowledgements ... 89
7. Bibliography ... 90
6
0. Introduction
In today’s dynamic and unpredictable business environment, companies face the tremendous challenge of expanding markets and rising customer expectations. This necessitates to lower total costs in the entire supply chain, shorten throughput times, reduce inventories, expand product choice, provide more reliable delivery dates and better customer service, improve quality, and coordinate global demand with supply and production more efficiently. In order to accomplish these objectives, more and more companies are turning to the enterprise resource planning (ERP) systems.
The integrated ERP systems are programs that have a unified architecture and allow an integrated management of various business processes, from the order-cycle to the logistics across multiple applicative modules which are interfaced and related to a single shared database. The prerogatives of such systems, however, are process-oriented organizations and the sharing of the whole information meant as global asset of the company and not as the exclusive patrimony of each unit. In fact, when a company decides to invest in these systems, undergoes a series of problems that may hinder the achievement of those desired goals. Problems not assignable to the chosen technology but to methodological choices and planning. Issues ranging from technology alone are not attributable to the choice, but to the methodological choices and design. As a matter of fact, the ERP technology is neutral, but its implementation involves a complexity’s shift from technological aspects to managerial and organizational.
The introduction of an ERP system, in fact, deeply impacts on activities, roles and responsibilities of all people involved, although often is considered as a simple change from a technological standpoint, that requires a training activity and a change-management . This evaluation’s error of the companies results in a lack of attention in the management of the implementation process in its entirety, from communication to the selection of resources that have to be allocated to the project, to the lack of a strategy that guides the re-design of the processes.
7
The analysis of the literature has allowed from one hand to understand which are the logical and basic strategies, secondly, on the other side, to identify the more common risk factors and to catch a series of steps for a successful implementation.
In this context, Risk Management appears to be the best approach to a successful implementation of an ERP project, mitigating and eliminating the risk factors that arise and thus increasing the probability of project success.
Due to the low rate of project success and the common mistake in the approach to the implementation process this work is conceived to develop a model to evaluate the organizational readiness for an ERP implementation project.
Despite the extensive theoretical and practical presence of risk management methods and models in ERP implementation projects, there has been no development of assessment framework for evaluating the organizational attitude to support these processes. The aim of this work is to design a clear guide for all companies that want to undertake an ERP project to develop or improve their approach to ERP implementation. The model purpose is to help the organizations, allowing them to assess their current level of maturity and develop action plans for increasing their efficiency and the likelihood of project success.
Maturity assessments provide organizations with the necessary information to understand their processes and skills and enable them to identify the weaknesses and limits of their business management, encouraging to improvement.
Chapter 1 provides an overview of ERP systems, illustrating the evolutionary context, the main characteristics, the current target market and why an organization should or should not invest on ERP system.
Chapter 2 introduces the Risk Management and refers to the implementation issues related to the adoption of such systems. Steps leading to the completion of the project are explained, with a description on the methods of implementation, the critical success factors and risk factors that incur in an ERP project.
8
Chapter 3 introduces the Maturity Model and their use, and designs the frame work of the Maturity Model for ERP systems, describing the dimensions and variables of reference and indicating the description of the evaluation model.
Chapter 4 shows the description of one case study and the application of the model to this company, reporting the results and the consequent considerations.
9
1. Enterprise Resource Planning
1.1 What Is an ERP
ERP is the acronym of Enterprise Resource Planning and indicate an integrated software solution used to manage any organization’s resource.
Watson and Schneider (1998) describe ERP system as a generic term for an integrated enterprise computing system; they define it as an integrated, customized, packaged software-based system that handles the majority of an enterprise’s system requirements in all functional areas such as finance, human resources, manufacturing, sales and marketing. Klaus (2000) defines it as packaged software solutions seek to integrate the complete range of a business's processes and functions in order to present a holistic view of the business from a single information and IT architecture. Rosemann (1999) defines the ERP system as a customizable, standard application software which includes integrated business solutions for the core processes and the main administrative functions of an enterprise. Finally, Umble et al (2002) emphases its unified enterprise view of the business and its enterprise database where all business transaction are entered, recorded, processed, monitored and reported, increasing the interdepartmental cooperation and coordination.
According to Davenport (1998), the business world’s embrace of enterprise systems may in fact be the most important development in the corporate use of information technology in the 1990s. ERP packages, supporting the business integration, represent much more than a change in terms of technological infrastructure: the main benefit of the ERP implementation can derive from the change of the business processes, organizational structure, roles and knowledge of the management of the activities. Installing an ERP systems the organization want to follow strategies to improve the efficiency, reduce the costs and increase the flexibility. There is the passage from traditional Legacy Systems, focusing on the single business areas, to Information System that aspire to integration, where the Information Technology assumes a decisive role
10
within the information system. The competitive vantage offered by ERP systems than the traditional Legacy System stay in the possibility to give a single vision of the business management and can to control the evolution with integration and update information. Though each ERP vendors characterize its product with a specific architecture, the commune aspect is the central database, in which are memorized all the transactions effectuated by the system. The database role is to memorize the data of each modules and make them available to all other modules. This architecture streamlines a company's data flows and provides management with direct access to a wealth of real-time operating information. For many companies, these benefits have translated into dramatic gains in productivity and speed (Devenport, 1998).
1.2 ERP History
The needs of businesses are continually change. In the 1960's when the focus was just on producing as much as possible without considering the exact demand, software packages were being designed for handling inventory (Gumaer, 1996). Consequently, techniques of those days were focused on the most efficient way to manage large inventories (Umble et al., 2003).
In 1970's, companies could no longer afford the luxury of maintaining large quantities of inventory (Umble et al., 2003). Due to the need for software designed specifically for manufacturing operations, Materials Requirement Planning (MRP) systems, which were planning the product or part requirements according to the master production schedule, were introduced (Gumaer, 1996; Rashid et al., 2002; Umble et al., 2003). MRP represented a huge step forward in the materials planning process. For the first time, a master production schedule, supported by bill of material files that identified the specific materials needed to produce each finished item, was used. Moreover, a computer could be used to calculate gross material requirements.
With the beginning of 1980's, the MRP system has been extended from a simple MRP tool to the standard manufacturing resource planning (MRPII) (Chung & Snyder, 1999). MRPII systems were introduced with an emphasis on optimizing manufacturing processes by
11
synchronizing the materials with production requirements. MRPII included areas such as shop floor, distribution management, project management, finance, human resource and engineering (Rashid et al., 2002). These systems incorporated the financial accounting system and the financial management system along with the manufacturing and materials management systems (Umble et al., 2003). However, the shortcomings of MRPII in managing a production facility's orders, production plans, and inventories, and the need to integrate new techniques led together to the development of a rather more integrated solution called ERP (Chung & Snyder, 1999). See Fig. 1 and Table 1for viewing historical evolution of ERP systems in detail. It is clear that the ERP applications of today have evolved from MRP and MRPII systems.
The concept posited to integrate software applications of manufacturing beyond MRPII to other functions such as finance and human resources. Russell and Taylor (1995)described ERP as an updated MRPII with relational database management, graphical user interface, and client-server architecture. In addition to that Markus, Tanis, and Fenema (2000) claimed that ERP systems work essentially at integrating inventory data with financial, sales, and human resources data, allowing organizations to price their products, produce financial statements, and manage effectively their resources of people, materials, and money.
It is not so hard to understand why ERP systems gained so much importance in the market. In the very beginning of the 1990's, when the business world moved ever closer to a completely collaborative model, there was a high level of competition in the market and competitor organizations looked for ways of gaining competitive advantage against their opponents. However, it was not easy. They needed to upgrade their capabilities, improve their own business practices and procedures. Under that pressure, to deal with this radically changing environment, many organizations had changed their Information System (IS) strategies by adopting ERP software packages rather than doing in-house development (Holland & Light, 1999; Laudon & Laudon, 1996). At that time, as Davenport (1998) suggested, the organizations needed to make sound and timely business decisions and ERP systems offered this to them. These systems provided integration and optimization of various business processes and this was what the companies looked for
12
(Mabert, Soni, & Venkataramanan, 2003). It is not wrong to say that ERP systems gained importance as they arrived at a time when process improvement and accuracy of information became critical strategic issues (Yen & Sheu, 2004).
ERP systems are being developed continuously and nowadays they can encompass all integrated information systems that can be used across any organization (Kumar et al., 2003). As Lawton (2000)claimed the improvement of the internet has shown tremendous impact on every aspect of the IT sector including the ERP systems. This environment of accessing systems resources from anywhere anytime has helped ERP vendors extend their ERP systems to integrate with newer external business modules such as Supply Chain Management (SCM), Customer Relationship Management (CRM), Sales Force Automation (SFA), Advanced Planning and Scheduling (APS), Business Intelligence (BI), and e-business capabilities (Rashid et al., 2002). This proves that borders of ERP systems are being extended continuously [2].
The ERP systems evolution is shown in table 1.
Table 1: Historical evolution of ERP systems
Timeline System Description
1960s Inventory
management and control
It is the combination of information technology and business process of maintaining the appropriate level of stock in warehouse. The activities of inventory management include: identifying inventory requirements, setting targets, providing replenishment techniques and options, monitoring item usages, reconciling the inventory balances, and reporting inventory status. Focus on cost.
1970s Material Requirement Planning (MRP)
MRP utilizes software applications for scheduling production processes. It generates schedules for the operation and raw material purchases based on production requirements of finished goods, the structure of the production system, the current inventory levels and the lot sizing procedure for each operation. Focus on marketing. 1980s Manufacturing
Resource Planning (MRPII)
MRPII utilizes software application for coordinating manufacturing processes, from product planning, parts purchasing, inventory control to product distribution. Focus on quality
1990s Enterprise
Resource Planning (ERP)
ERP uses multi-module application software for improving the performance of the internal business processes. ERP system often integrates business activities across functional departments, from product planning, parts purchasing, inventory control, product distribution, fulfillment, to order tracking. ERP system may include application modules for supporting marketing, finance, accounting and human resource.
13
1.3 Market of ERP System
When ERP system systems first emerged in the early 1990’s, manufacturers in a wide variety of industries enthusiastically adopted them. The last ten years have seen a dramatic growth in the use or ERP systems. The key drivers of this trend can be summarized as globalization of business, acquisition consolidation, process standardization, and changes in customer expectations, increasing the importance of ERP systems in the market from day to day.
A recent AMR Research’s report, titled “The ERP Market Sizing report, 2006-2011”, affirmed that the market of ERP software grew by 14% in 2006 and became $28.8 billion business, whit a much more penetration in large business segments.
AMR's numbers affirm that with the focus on standardizing IT architectures across the entire company, centralized ERP systems that are extended to the entire corporation are replacing many of the midmarket plant applications. The traditional large enterprise vendors have started to attack the market perception that their products are too big and complex, and they’re making inroads into the small and midmarket through rapidly growing reseller channels. The midmarket is one of the key areas where the larger enterprise vendors believe they have an opportunity to sustain or accelerate growth, even as ERP opportunities at the higher end of the market decline. ARM Research supposed that the sector will see a 6% to 7% grow rate in the next years.
In the 2009 the largest ERP vendors were SAP, Microsoft Dynamics, Oracle eBusiness Suite, Epicor, Infor. In Figure 1 is illustrated the ERP market share of principal vendor
14
1.4 The Characteristics of an ERP System
The mainly characteristics of ERP systems can be summarized below. 1.4.1 Client / Server Architecture
The ERP system uses a Client/Server architecture. Some systems are three-layers (Figure 2) and some of them are two-layers. Both of them have a “Presentation Layer”. This layer is the user interface or browser for data entry. Other two-layers are named “Application Layer” and “Database Layer”. Two-layers system combine these layers on one layer and three-layers systems have these layers separately. “Application layer” is the layer where business rules, functions, logic, and programs are located. It continuously communicated with the database is run. This model provides a convenient way to interconnect programs that are distributed efficiently across different locations.
Figure 2: Three-layers architecture
1.4.2 Database
ERP system is characterized by a single central database. The vantages are: synchronization, reduction of data, uniqueness and real-time upload. It is used a relational database, a collection of data items organized as a set of formally-described tables from which data can be accessed or reassembled in many different ways without having to reorganize the database tables. The operational or transactional data are managed by Structured Query Language (SQL).
15
1.4.3 Modular System
An ERP system is an integrated suite of modules supporting core business processes. ERP modules are software packages that perform a set of functions to support the major functional areas of business processes. Because the systems are modular, companies can decide to install implement only those modules that are most appropriate to their business. The suite of modules can be classified in three categories:
Cross industry modules: these modules help manage the business processes of
organizations as well as support functions such as human resources and finance. They are unlikely to vary much across industry verticals, and hence are the only common denominator among ERP solutions for all kind of industries and companies. Cross-industry ERP modules comprise the following:
o Human Capital Management (HCM): The ERP HCM module manages and automates HR activities that have been developed around the HR functionalities of payroll management, time and labor management and human resources management.
o Financial Management: The Finance module deals with accounting and financial transactions. It helps businesses prepare financial reports and maintain books of account electronically. Most of the finance modules perform the following set of functions: General Ledger, Accounts Receivable, Accounts Payable, Time and Billing, Cash Management, Expense Management, Compliance Management
Industry modules: these modules cater to the core operations of an organization.
Almost every vendor tends to package its ERP offering with industry-specific functionalities tailored to the needs of that particular industry segment and based on the vendor’s area of expertise. Therefore, major product differentiation occurs in these industry-specific ERP modules. For instance, Manufacturing and Project Management are two common ERP modules that may vary dramatically depending on the target vertical industry of a particular ERP solution.
Extended modules: New ERP modules have emerged as organizational processes
16
functionalities, and have evolved as a part of the broader enterprise world. Currently, most of these modules are packaged with core modules in ERP suites, but they may also be offered as stand-alone business applications. These modules mainly include Supply Chain Management, Customer Relationship Management, Supplier Relationship Management and Product Lifecycle Management
The figure below (Figure 3) shows a possible configuration of a modular system ERP.
Figure 3: Modular configuration of ERP
1.4.4 Integrated System
Integration is an exceptionally significant ingredient to ERP systems. The integration between business processes helps develop communication and information distribution, leading to remarkable increase in productivity, speed and performance.
The key objective of an ERP system is to integrate information and processes from all functional divisions of an organization and merge it for effortless access and structured workflow. The integration is typically accomplished by constructing a single database
17
repository that communicates with multiple software applications providing different divisions of an organization with various business statistics and information.
Although the perfect configuration would be a single ERP system for an entire organization, but many larger organizations usually deploy a single functional system and slowly interface it with other functional divisions. This type of deployment can really be time-consuming and expensive.
1.4.5 Standardization and Customization
ERP are based on so called best practices, procedures that the vendor considers the most efficiency and efficacy to perform a determined activity, adapting them to the specific needs of the organization. This standardization doesn’t constrain the organization to adequate itself, because it is possible personalize them. Exist a trade-off between the level of customization and the cost of the project: in particular, major is the personalization of the procedures of the ERP system, major are the costs that the organization must incur due to the change of the best practices.
1.5 Reason for Adopting an ERP System
Given the richness of enterprise systems in terms of functionality and potential benefits to adopting organizations, it should not be surprising that companies are adopting these systems for many different reasons (Ross, 1999). Some companies have largely technical reasons for investing in enterprise systems. Examples are the desire to reduce mainframe system operating costs, the need to solve the Y2K and similar problems, the need for increased systems capacity to handle growth, or the need to solve the maintenance headaches associated with aging legacy systems. Other companies give largely business reasons for adopting enterprise systems. For example, the company may need but not have, due to limitations in its legacy systems, the ability to present “one face to the customer” or to know whether it has finished goods inventory or planned production capacity “available to promise” to the customer on a regional or global basis. Many companies have both technical and business reasons for adopting enterprise software. Both small and large companies can benefit both technically and strategically from
18
investments in enterprise systems. Generally, the needs and opportunities of small companies are a subset of those facing large companies. (See Table 2 for a summary of reasons that companies give for adopting enterprise systems.)
Small company / Simple structure Large company / complex structure
Business advantage
• Accommodate business growth • Acquire multilanguage and reasons multicurrency IT support
• Improve informal and/or inefficient business processes
• Clean up data and records coding schemes through standardization
• Reduce business operating and administrative cost • Reduce inventory carrying
costs and stockouts
• Eliminate delays and errors in filling customers’ orders
Most small/simple company plus
• Provide integrated IT support • Standardize different numbering, naming, and schemes
• Standardize procedures across different locations
• Present a single face to the customer
• Acquire worldwide “available to promise” capability
• Streamline financial consolidations • Improve companywide decision support Technical
advantage
• Solve Y2K and similar problems
• Integrate applications cross- reasons plus functionally • Replace hard-to-maintain interfaces
• Reduce software maintenance burden through outsourcing
• Eliminate redundant data entry and concomitant errors and difficulty analyzing data
• Improve IT architecture
• Ease technology capacity constraints • Decrease computer operating costs
Most small/simple reasons plus: • Consolidate multiple different Systems of the same type (e.g. general ledger packages)
Table 2: Reasons for adopting an ERP system
Shang and Seddon (2000) have developed a framework, compiling an ERP benefits list from ERP vendor success stories published on the Web. They classified the different types of ERP benefits as:
Operational benefits: Cost reduction, cycle time reduction, productivity improvement, quality improvement, customer service improvement.
Managerial benefits: Better resource management, improved decision making and planning, performance improvement.
Strategic benefits: Support business growth, support business alliance, build business innovation, build cost leadership, Generate product differentiation (including customization), build external linkage (customer and supplier).
19 IT infrastructure benefits: Build business flexibility for current and future change,
IT cost reduction, Increased IT infrastructure capabilities.
Organizational benefit: Support organizational change, facilitate business learning, empowerment and build common vision.
It is important to take into account these wide variations in motivation to adopt enterprise systems when attempting to assess or explain their impacts and downstream consequences. Some goals are much more ambitious than others; if companies are like people, those with more ambitious goals are likely to achieve more than companies with less ambitious goals, but they are less likely to realize their full aspirations, and they may encounter many more difficulties along the way. Furthermore, enterprise systems may be better suited to realizing some goals than others. For example, the largest companies may face technical capacity constraints that prevent full data integration. Clearly, what companies think they are about when they adopt enterprise systems must figure somehow in the ways they approach the enterprise system experience and in the outcomes they achieve.
Of course, not all organizations adopt enterprise systems, even when they have some or all of the listed motivations for adopting. Some who do adopt enterprise system choose to use only certain modules, relying on legacy systems or new custom development for their remaining needs. And some who do adopt discontinue implementing or using these systems for a variety of reasons. One reason for non-adoption, partial adoption, or discontinuance is lack of “feature function fit” between the company’s needs and the packages available in the marketplace. “There are very few companies that don’t have specialized processes dictated by their industry,” according to one consultant (Slater, 1999).
When organizational size and scale of operations are taken into account, there simply may be no commercially available package suitable for a particular organization. More commonly, the organization may choose to adopt only certain parts of an enterprise system or may modify the system to improve feature-function fit.
20
In addition to the lack of feature-function fit, a second major set of reasons for non-adoption, partial non-adoption, or discontinuance of enterprise systems concerns company growth, strategic flexibility, and decentralized decision-making style. Companies that continually change their organizational structures and business model and particularly those that are not run “in a very top-down manner” may find enterprise systems unsuitable as a corporate solution.
A third factor in the non-adoption of enterprise systems is the availability of alternatives for increasing the level of systems integration. Data warehousing, a bundle of technologies that integrates data from multiple source systems for query and analysis, provides what some describe as the “poor man’s ERP.” The usefulness of data warehousing as an integration strategy is limited by the quality of the source systems. Nevertheless, it can provide enormous relief for some organizations suffering from some of the technical problems (shown in Table 2).
Discussions of reasons for not adopting enterprise systems usually conflate the issues just mentioned above with three other issues—cost, competitive advantage, and resistance to change.
Some analysts have cited competitive advantage as a major reason for not implementing enterprise software (Davenport, 1998). Here, too, it is difficult to disentangle competitive advantage from explanations based in fit. If a company claims it will lose competitive advantage from adopting an enterprise system, it is also saying that it does things differently than the enterprise system does. The question here is whether lack of fit reflects an organization’s “value-adding best practice” (albeit different from best practices in the software) or a costly inefficiency that the organization is culturally unwilling to give up. Not surprising, vendors are more likely to cite “resistance to change” (or “lack of top management commitment”) than they are to cite “competitive advantage” or “lack of feature-function fit” as a major reason for non-adoption of enterprise systems. In practice, careful analysis is necessary to determine whether or not an enterprise system is a good solution in a particular situation—and what the scope of the implementation project should be [3].
21
2. Risk Approach to ERP Implementation
2.1 ERP Implementation Phases
Before to describe the mayor risk factors that rise during an ERP project, it is important analyzing in detail the phases of ERP implementation project. ERP system can be complex and difficult to implement but a structured and disciplined approach can greatly facilitate the implementation, allowing to manage the numerous complexity connected to this projects.
In literature are present two main approach of ERP system’s implementation: the Big Bang approach and the incremental approach (O'Leary 2000; Davenport, 2000).
Regarding Serial Implementation projects, also called step-by-step projects, they may indicate a sort of implementation of continuous type in which single modules of an ERP system are installed at a later stage, from the module considered more important by the company for its working. Such implementation causes an ease of management, reflected in the gradual involvement of the various business functions, aimed at the change and distribution of the implementing costs for the new system over a longer period time. But it is clear that this type of implementation involves some disadvantages for an integrated information system ERP. In fact, a step-by-step, can only be seen as a temporary solution that, has to manage numerous interfaces between the modules gradually installed and the pre-existing information systems still working. Moreover, a project like this will significantly reduce the benefits tied to the logic of a unified vision of an ERP system. Also a Big Bang implementation, a project doable in short time, presents itself, along with clear opportunities and advantages, also considerable disadvantages and risks. The opportunities and advantages consist of a shorter project time and low level of interfaces to manage, whereas risks and disadvantages of this type of project relate to an increased workload for both the project management group and for all business organization, and to the need of having to deal simultaneously with inevitable difficulties of integration between people from different areas. For these reasons, it is therefore essential that a Big
22
Bang-like project had full support of corporate management, from the top to the managers of different sectors and functions of the organization.
Researchers have described ERP life cycle using different models, in this study is described the methodology adopted by Markus and Tanis (2000), a four stage model (Figure 4).
The “Chartering Phase” is characterized by the decisions leading up to the funding an enterprise system. The key activities include building a business case for enterprise system, selecting a software package, identify a project manager and approving a budget and schedule. Key players in this phase include vendors, consultants, company executives and IT specialist. A large number of errors or problem can arise during this phase. The business case for investing in an enterprise system can be incomplete or faulty; the organization may seriously underestimate the need for business and organizational change in conjunction with the software implementation; objectives and metrics for the initiative may be left undefined. The outcomes of this phase may be a decision not to proceed whit the enterprise system or a decision to proceed.
The “Project Phase” comprises activities intended to get the system up and running in one or more organizational units. The key activities include software configuration, system integration, testing, data conversion, training, and roll out. Key actors are the project manager, project team members (often nontechnical members of various business units and functional areas), internal IT specialists, vendors and consultants. A large numbers of errors and problems can occur. Project team may be staffed with inadequate representation; teams may lack requisite knowledge and skills; data clean up, testing or training may be inadequate.
The “Shakedown Phase” is the organization’s coming to grips whit the enterprise system. The phase con be said to end “normal operations” have been achieved. The project team may continue its involvement or may pass control to operational managers and end users and whatever technical support it can muster. Activities include bug fixing and rework, system performance tuning, retraining and staffing up to handle temporary inefficiencies. This is the phase in which the errors of prior phases are felt but new errors can arise too.
23
The final phase is “Onward and Upward Phase”, that continues from normal operation until the system is replaced with an upgrade or a different system. It is during this phase that the organization is finally able to ascertain the benefits of its investment. Key players include operational managers, end users and IT support personnel. Characteristic activities are continuous business improvement, additional users’ skill building, and post-implementation benefit assessment. A common problem of this phase is the loss of knowledgeable personnel who understand the rationales for prior configuration choices and how to improve the business process through the use of the system. Several ultimate outcomes are possible: the organization may be unwilling to undertake further improvements or upgrades. The organization may decide that its investment has been unsuccessful in meeting goals or business needs. Or the organization may decide its experience has been a success.
24
2.2 Risk Management
2.2.1 Introduction to Risk Management
The generally used risk definition, expressed by the Royal Society Group from British Standard 4778 is: Risk: "a combination of the probability of occurrence of a problem (an undesirable state of affairs) for the corresponding value (impact) of the damage caused". The risk is the product of two factors:
Probability of occurrence factor (P)
Factors affecting the extent of damage (E)
The first factor is a series of probabilities that can occur and trigger a dangerous event. The second concerns the evaluation and the extent of damage.
A risk factor can be calculated using the following report:
i i i P E
RF
So a risk is an undesired event can change the results on planned targets or even derail the project.
Managing risk of a project means actively engaged in its success, namely to achieve the objectives of the project schedule. A project is an innovative commitment by its very, complex, interdisciplinary, unusual and sometimes unique nature, such as implementing an ERP system.To manage risk, the first aspect to analyze is the context in which they work to identify, understand and predict the various risk events and their interactions that may hinder the achievement of objectives. After that, the organization need to design and put into action a security plan to intervene in the most appropriate way with prevention activities, monitoring and recovery of individual risk factors. Finally, an effectiveness action plan has to be assessed in advance and during the executive phases in order to make the appropriate changes to the project system[4].
The phase of risk management should be an integral part of project planning and should not end with it. It is composed of a series of iterative activities that must align with the
25
evolution of the project; changes to budget, time, resources plan and project objectives should be coupled with possible changes to the plan of risk management such as:
Change in the methods of prevention, control, monitoring of risk sources
Development of new RF that may arise along the life cycle of the project
Redefining the relative importance of factors and planning new strategies for risk treatment
2.2.2 Risk Management Phases
To make a valid risk management on any kind of project companies can work systematically through several stages (figure 5). In literature there are several breakdowns in the process of risk management, but all refer to the same model and have a cyclic structure, since it does not run out during the planning phase but it is developed in an iterative manner over the period of the project.
Risk Analysis Communication and Consulting Context Analysis Monitoring and Review Risk Treatment Risk Identification Risk Evaluation Risk assessment Risk management
Figure 5: Risk management stages context analysis risk identifacation risk analysis risk evaluation risk treatment
monitoring and review
comunication and consulting
26 Context Analysis
The first phase of risk management includes a thorough analysis of the context in which companies operate, the boundaries of the project are defined; the phases, sequences and relationships are analyzed.
The analysis of context in the process of risk management can be integrated with a representation of the project units (functions, processes, data) and their interrelationships. This allows to represent the status of the project according to different points of view: for example in resources used, requirements of personnel, budget, involvement of stakeholders and more, depending on the aspects that organizations want to investigate.
There are several computerized tools for presenting projects, which may be useful in defining the context and analyze the possible sources of risk on the project.
Examples of these techniques are [4]:
Project network diagram
Precedence diagram method
Design structure matrices
IDEF techniques
Moreover, at this stage, companies must try to consider all possible situations that may threaten the achievement of project objectives.
Risk Identification
At this stage organization proceed to identify all those "threats" that may occur at the application, organizational and inter-organizational level which may impede the progress and success of the project [6,7]. Furthermore the possible consequences of the emergence of risk must be defined.
This part of the process has a rather subjective nature; the main actors are industry experts who analyze the various hazards using their perceptions and insights.
27
Despite the qualitative nature of this stage have developed different techniques to assist practitioners to define and identify sources of risk and effects associated with them [4]; examples of these techniques are
Checklist
Cause-effect diagram
Failure Mode and Effect Analysis (FMEA)
Fault trees
Montecarlo simulation
Risk Analysis
The function of the risk analysis is to determine the influence of risk factors on the entire system being evaluated. Once companies have identified possible risk factors, it is necessary to analyze the nature and causes of each and find the right information to monitor and control the sources of risk; after that organizations decide whether to use quantitative or qualitative methodologies and the metrics are by which the various factors will be compared; the latter choice is crucial to the success of a good risk management plan and it is often cause of errors (especially on qualitative factors, such as the implementation of an ERP system), because there is great difficulty in returning to the same metric values of the occurrence probability and the effect of individual factors. Examples of risk analysis techniques are:
Probabilty and impact grids
Estimation of system reliability
Fault Tree Analysis (FTA)
Event Tree Analysis (ETA)
Sensitivity analysis and simulation
Risk Evaluation
This is the phase in which the factors are quantified. For each risk factor is assigned a value comparable with others. The purpose of this phase is to determine which factors are most dangerous to implement appropriate strategies for the treatment of risk.
28
It is important to note that, depending on the scope of the analysis, the measurement of risk factors may have a different nature:
Quantitative: when it is reasonable to objectively and scientifically determine the probability distributions of the various factors and the damage caused by them. This is the case of purely technical projects in which each factor is measured on a deterministic or stochastic basis.
Qualitative: when it is not reasonable to define probability distributions and its effects, it is the case of situations where you can’t find metrics necessary to carry out objective measures of risk. In this case the measure depends on the subjective evaluations of the decision maker. This is the case in which factors come into play in nature and managerial factors governed by the high uncertainty of their causes and their effects.
Hybrid: when a factor has both the features outlined above
Depending on the nature of a risk factor, this step can be supported by a wide variety of techniques that can be classified into three families [4]
Qualitative techniques
Quantitative techniques
Hybrid techniques
Examples of these techniques may be the follows:
Decision tree analysis
Multiple criteria decision-making method
Markov modeling
Dynamic event logic analytical methodolgy
Dynamic event tree analysis method
Risk Treatment
After analyzing the influence of risk factor, there is a phase where activities are planned for the treatment of risk, with the goal of keeping under control the project activities by
29
monitoring the main risk factors or developing recovery strategies in response to the appearance of them [5].
At this stage it is essential to take into account the trade-offs that occur, especially comparing the costs of possible treatment strategies of risk against the potential loss that may be caused by an occurrence of a given factor.
Monitoring and Review
During the life cycle of a project the activity are monitored continuously. Appropriate reviews of the risk management planning and a system of indicators should be implemented to prevent and control risk factors [8]
In addition, is necessary to conduct testing of risk treatment strategies planned during the previous phases at regular intervals during the project life-cycle.
This can lead to a change on the evaluation of the factors or the inclusion of new one that have occurred with the evolution of the project; furthermore indicators, monitoring system, treatment strategy can also be re-defined.
Communication and Consulting
Within the organization all the strategies planned and the situation of the monitoring should be reported and discussed by all relevant stakeholders of the project; this is a critical step to ensure that risk management is developed as a process approach and not as a series of independent activities; the achievement of local objectives often differ with the general objectives of the organization.
2.3 Risk Factor in an ERP Implementation
One of the major challenges that IT management has to face on to determinate the success of the implementation process is represented by the ability to know, recognize and deal with risk factors affecting ERP implementation. This has encouraged researchers to try, through empirical studies and analyzing cases, to identify the risk factors that insert during an ERP implementation.
30 Project phases Activity Problems or Errors
Strategic planning Analysis of business scenarios I.T. strategic planning
Idea of adopting enterprise systems surfaced
Failure to link technology plan to business strategic plan
Inadequate IT governance
The ERP is not the best IT solution for the organization
Inefficient process of recognize the organization’s needs for ERP systems requirements
Project preparation
Project scope definition
Business case for investment developed (may be highly informal)
Definition of key performance indicators and process of measurement
Current state analysis (may be deferred or not done)
Selection of software, hardware platform, networking, database, implementation partner, project manager (may be partially or totally deferred to project phase)
Initial plans for how system will be rolled out, supported, and maintained, upgraded, etc. (may be deferred)
Communication to Organization
Organizational changes and/or incentives related to enterprise system and/or organizational Performance improvement, if any may be deferred)
Decision to proceed, approval of project plan
Overselling by software vendors and implementation consultants
Unrealistic business case and project parameters
Key performance indicators not or poorly defined, including the measurement process and ownership of this
Selection of inappropriate software, hardware, integrator, and/or project manager; inadequate contracting with external parties
Inadequate contracting with vendors and consultants
Lack of long-term support and migration strategy
Failure to recognize need for business change; underestimating change management difficulty
Misunderstanding organizational requirements, particularly as related to need for data access and reporting
Risk management Risk planning Risk identification Risk analysis Risk evaluation Risk treatment
Risk monitoring & control
Inefficient risk planning
Not all risks are identified in ERP implementation project
Underestimate or overestimate the probability/effects of Risk factors
Inadequate strategy of risk treatment
Lack of monitoring and control the risks that affect the project
The project (business blueprint)
Development of detailed project plan
Ongoing project management
Selection and assignment of project team members
Training of project team members and acquisition of supportive skills
Current and/or future business process
Modeling and reengineering, if any
Execution of change management plan, if any
Gap analysis
Staffing project sub teams without appropriate cross functional representation
Difficulty acquiring adequate knowledge and skill in software configuration (especially cross module integration), integration of bolt-ones or legacy systems, and a variety of platform technologies
Lack of project mangment skills
Gap analysis problem
Failure to manage project scope, schedule budget
The project (realization)
Software configuration
Software customization, if any
System integration
Integration of software bolt-ones and/or legacy systems, if any
Data clean up and conversion
Documentation
Poor-quality software, documentation, raining materials
Inadequate knowledge on part of consultants and vendor personnel
Configuring software for multiple units on the basis of analyzing only one unit
Assuming that end-user training should be funded from operations budgets
Configuration errors that require rework if caught
Customizations that do Inadequate attention to data clean-up
Wrong data migration strategy
The project (final preparation)
Testing, bug fixing, and re work
Executive and end-user Training
Rollout and startup
Go-live data decision
Long time re-work caused by customization
Resistance to change by the users
End- user training based on budget operation Phase contraction
Shakedown (go-live & support)
Turnover of project personnel
Bug fixing and rework
System performance tuning
Adding hardware capacity
Problem resolution
Process and procedure changes
Retraining, additional training
Adding people to accommodate learning and shakedown needs
Business disruption
Difficulty diagnosing and solving performance problems
Excessive dependence on “key users” (project team members) and/or IT specialists
Maintenance of old procedures or manual workarounds in lieu of learning the relevant system capabilities
Data input errors
Poor software ease of use
No growth of end-user skills after initial training
Underuse / nonuse of system
Failure to achieve normal operations (“system” never stabilizes)
Inadequate attention to reporting
Short-cutting testing and/or training when schedule gets tight
Lack of technology transfer from external consultants
Vendor delivery and software performance problems
Operation
The new process and procedure became normal
No more problems for the end users
All functions of system run as a routine
Software upgrade
Evaluation of the benefit of the ERP system
Software upgrades problem caused by customization
Vendor dependency
Wrong evaluation of the benefit of the ERP systems
Problem in the mainteinance of the system
31
Table 3, presented above, shows the problems and the errors in a typical ERP implementation process.
In this section is reported the analysis delivered by Aloini et al. (2007) that we had reviewed the literature to identify the relevant risk factors. First of all, the authors have identified the main risk effects: budged exceed, time exceed, project stop, poor business performances, inadequate system reliability and stability, low organizational process fitting, low user friendliness, low degree of integration and flexibility, low strategic goals fitting and bad financial/economic performance. Then the authors have individualized the 19 risk factors that are described below.
1) Inadequate selection: a incorrect selection could cause it to fail or weaken it sufficiently to affect the company’s performance
2) Poor project team skills: it is necessary to form a skill-balanced project team having both internal and external experts, managerial competencies, deep knowledge of the processes and IT skill, this will contribute to the ERP’s implementation success or failure, especially during the pre-installation phase.
3) Low top management involvement: participation, direct top management support and commitment, are expected to influence the success of ERP adoption.
4) Ineffective communication system: communication is a necessary in an ERP implementation project, because it provides an appropriate flow of the information for all actors.
5) Low key users involvement: user involvement is important in meeting expectations. Key users should be of the system utility. They are useful in the early stages of the project and during the implementation phase.
6) Inadequate training and instruction: the role of the training in the implementation is fundamental; lack of user and team training is responsible for many ERP implementation problems.
7) Complex architecture and high number of implementation modules: the number of implementation modules increases project complexity.
8) Inadequate Business Process Reengineering: the restructuring of the organization’s business process is a critical aspect. An incorrect BPR can be a risk for the project.
32
9) Bad managerial conduct: effective project implementation requires a well articulated business vision that establishes the goals and the business model behind the project. Good management improves user expectations and helps in planning the training of people in the use of the finished system
10) Ineffective project management techniques: the inadequate use of project management techniques significantly effects ERP project success.
11) Inadequate change management: an ERP project is complex and it modifies the way that the organization operates. A change management is a strategy that the organization must implement.
12) Inadequate legacy system management: the old information system should be removed; this transition phase is a critical passage
13) Ineffective consulting service: the use of outside consultants is common for ERP projects. Their technical and organizational experience and knowledge play an important role in the project.
14) Poor leadership: to contribute to ERP success is necessary a strong leadership, an open communication, and a balanced and empowered implementation team. If project managers and steering committee do not commit to solving problems and providing direct to the project team, the risk of failure is greater.
15) Inadequate IT system issue: technical software capabilities must be studied before implementation matters and their impacts on business processes assessed. The essential technical aspects are: user friendliness, portability, scalability, modularity, simple upgradeability, flexibility, security, and data accuracy.
16) Inadequate IT system maintainability: maintainability is the ability of equipment to meet operational objectives with a minimum expenditure of maintenance effort under operational environmental conditions in which scheduled and unscheduled maintenance is performed. ERP maintenance and upgrade activities are very important in ERP-using organizations.
17) Inadequate IT supplier stability and performance: ERP systems require continuous investment in new modules and upgrades to add functionality, achieve a better fit between business and system, etc. so vendor support is an important risk factor.
33
18) Ineffective strategic thinking and planning: the IT strategy must be alignment with the organization’s strategy. If an organization tries to install a system without establishing a clear vision, every effort can turn in a disaster.
19) Inadequate financial management: ERP are expensive systems. It is necessary an economic and financial strategy prior to installation, because a wrong cost analysis has a negative impact on ERP adoption.
The link between risk factors, their effects and the level of failure are show in the next figure (figure 6).
34
2.4 Project Success or Failure
“Success (or failure) of enterprise system is not a monolithic concept. Rather, it is a multidimensional and relative” (Markus and Tanis, 2000). It is relative, first, to the time at which it is assessed; second, success is often judged relative to the organization’s unique goals for the system (Capaldo and Rippa, 2008). Klaus et al., 2000 defined the success is differently by different stakeholders involved:
From an implementer’s prospective, it entails adherence to projected resource commitments and developing specifications for particular functional objectives;
From a vendor’s perspective, the implementer must carefully consider follow-up investments;
From an end-user’s perspective, the ERP system should improve job performance while being usable and satisfying;
From a manager’s perspective, it should be effective and efficient in supporting business objectives.
Umble et al. (2002) defined that a successful ERP project can cut the fat out operating cost, generate more accurate demand forecasts, speed production cycles and greatly enhance customer service, all of which can save a company millions of dollars over the long run. The organizations implementing an ERP system want to obtain benefits like quicker information response time, increased interaction across the enterprise, improved interaction whit customers, fast decision-making, lower inventory costs, shorter cycle times and global control over distributed business operations (Devenport, 1998; Aladwani, 2001; Umble et al. 2002). It is interesting that the companies are implementing ERP systems with these expectations, but this result do not come true most of the time. In fact, in spite the high expectations of the organizations, most of ERP projects became over budget, late and eve fail. A recent Panorama Consulting Report (2010) on ERP implementation process asserted that 57% of these projects take longer than expected, 54% go over budget, and 41% of companies surveyed fail to realize at least half of the business benefits they expected from their ERP systems.
35
Process failure, when the project is not completed within the time and budget;
Expectation failure, when the IT systems do not match user expectation;
Interaction failure, when users attitudes towards IT are negative;
Correspondence failure, when there are no match between IT systems and the
planned objectives.
The top three reasons for the failure of IT-related projects, as cited by IT managers surveyed by Information Week (1998), were poor planning or poor management (cited by 77%), change in business goals during the project (75%), and lack of business management support (73%).
36
3. Developing the ERP Maturity Model
3.1 Research Objective and Methodology
As described in the previous chapter, undertaking an ERP implementation project is particularly difficult and risky because of numerous risk factors that can exist during the lifecycle of the project. It is clear that it is fundamental to adopt an approach based on a Risk Management, concept shared by numerous studies present in literature.
Objective of this study is to develop a model to evaluate the maturity of the firm that wont to embark on ERP implementation project. This model aims to help the organizations, allowing them to assess their current level of maturity and develops action plans for increasing their readiness to an ERP implementation and the likelihood of project success.
The model will provide the following output:
Indication of the probability of success in relation to the level of maturity reached by the organization
Evidence of the strengths and weaknesses of the organizational areas that affect the implementation process
Provides suggestions and indications on how to tackle the implementation process in relation to the level of maturity and the weaknesses highlighted.
Clear guidance to evaluate all organizational issues that may hinder the project success and to indicate any necessary actions for improving organizational attitude to ERP implementation project. The model is a Project strategic tool for top management and is used after defined the project scope.
In order to develop this framework, it was necessary to make an accurate review of literature for comprehending the characteristics of an ERP system and the dynamics that guide an ERP implementation project.
37
The research is based on the analysis of articles collected from the main scientific editors:
Emerald, which publishes a wide range of management titles and library-and-information services titles by publishers world-wide. Subjects covered included management, HRM, Marketing, Librarianship, Mechanical engineering, electronic and electrical engineering. Emerald contains 42,000 searchable articles from over 100 of its journals.
Science Direct (Elsevier), the electronic collection of science, technology, and medicine full text and bibliographic information.
IEEE-Xplore, providing online delivery systems with full text access to high quality technical literature in electrical engineering, computer science, and electronics. The research questions of this work are:
- What aspects can enable the ERP project organization to be more effective in dealing with the implementation process?
- What aspect can influence the likelihood of ERP implementation process success? - How can a maturity model help to identify the factors that influencing the
implementation process in an effective and measurable way? - What are the characteristics of different levels of maturity model?
This study attempts to investigate these questions through developing a maturity model for ERP implementation.
3.2 Introduction to Maturity Model
In the literature there is no agreed definition of Maturity Model. It can be defined an instrument used by organizations to evaluate their maturity level in a specific business area.
The Maturity Model method has its origin in the Capability Maturity Model (CMM) developed by Software Engineering Institute of the Carnegie-Mellon University (USA) in November 1986. The Capability Maturity Model for Software provides software organizations with guidance on how to gain control of their process for developing
38
and maintaining software and how to evolve toward a culture of software engineering and management excellence.
3.2.1 Capability Maturity Model
The CMM was designed to guide software organizations in selecting process improvement strategies by determining current process maturity and identifying the few issues most critical to software quality and process improvement.
The CMM is divided in five maturity levels that represent a different stage of maturity; each maturity level is composed of several key process areas. Each key process areas is organized into five sections called common features and this common features specify key practices, which, when collectively addressed, accomplish the goals of the key process area (Figure 7). (SEI, Capability Maturity Model for Software, Version 1.1, February 1993).
