Abstract
Enterprise Resources Planning (ERP) systems are large and complex IT products designed to support and help to manage virtually every area of a firm and, in many cases, integrate the firm's internal processes with business planning and execution activities of customers and vendors. The performance record of implementing these systems shows less than desired results in term of project cost overruns, serious business disruption, poor functionality use, process inefficiencies or all of the above. This paper looks at the typical methodologies used to implement ERP systems, as one of the main sources of project failure and compares them with the principles and practices A Guide to the Project Management Body of Knowledge (PMBOK® Guide) to determine their “PMBOK® Guide compliance”. Secondly, the paper introduces the component of ERP implementation methodology that follows PMBOK® Guide but also addresses the uniqueness of these projects, in term of technology to be deployed and the business processes to be improved and supported. The author extensive experience and some published articles are used as the main basis for the suggestions and methods put forward.
Introduction
ERP systems are used worldwide, regardless of company size; in fact a measure of their presence suggested that by 2004 the ERP market was going to reached $78 Billion in sales (AMR Research Centre, 2000) and all of it requires implementation. Furthermore those who have already implemented ERP report that 70% of their implementations have failed, have come over budget or have been seriously postponed (Roman, 2005 p. 1). So why don't ERP systems deliver what they promise? More often than not, the problem lies in project management and implementation methodologies, rather than in the IT technology or ERP software package itself (Diaz, 1996, p. 24). The reality is that many of the available implementation methodologies are not robust enough to deliver the goods; whether they are ERP vendor supplied, “home made” or suggested in the literature, these approaches incorporate project management knowledge areas as defined in PMBOK but most of them limit their scope to the traditional project management processes of executing, monitoring and closing; paying less attention to initiating and planning.
Some of the critical issues point to the definition of the project itself: is it an IT project, a Business Re-engineering Project or a new technology deployment project? What type of tool is it?
Clearly, the answer to these questions would affect and shape the approach taken to carry out the implementation.
A review of the technology.
The ERP Technology Selection.
The acquisition of an ERP package, the decision to deploy one already owned into a different division/plant of a firm or, as in Product Life Cycle, the need to upgrade function, form or fitness of an existing package in use, is the typical initial phase of these projects’ life cycle.
This phase is a project in itself, it is often assumed to be the first phase in the overall implementation and its main deliverable is the selection of the “best” ERP package to be implemented.
But what is the best package?
Most ERP technology embodies a proven set of Logistics, Manufacturing, Customer Relations and Financial practices, therefore when you embark in an ERP system purchase you are implicitly and explicitly accepting those practices as the business process framework for your firm. The packages, of course, are not all alike; the set of available proven practices varies according to the size (scale) of the firm and most packages offered less functionalities for small firm (less than 50 employees) versus a full set of functionalities for a larger one (more than 500 employees) and the cost of ownership varies accordingly. Furthermore there are packages that focus on a particular industry sector (textiles, automotive, electronics, etc.) and hence the practices they support are very specific to the sector in question and may not be universally applicable to others.
If there is a scale or industry focus mismatch (although it does not happens that often) your implementation project will suffer and you are almost guaranteed to be over budget by trying to retrofit the package and eliminate the mismatch with functionality's modifications and, what is worse, still deploy a tool that does not serve the needs of the business.
Although the “best” package may have been selected, why is that we still have implementation problems?
The answer to this question lies within the PMBOK® Guide definition of Project Life Cycle and Organization; namely in the definition of Project Stakeholder who are “individual and organizations that are actively involved in the project, or whose interest may be affected as a result of project execution […]. The project management team must identify the stakeholders, determine their requirements and expectations and, to the extend possible, manage their influence in relation to the requirements to ensure a successful project” (PMI, 2004, p. 24).
The problem is that, in most cases, those stakeholders who have responsibility and authority in selecting the “best” package are not the ones with responsibility and authority in using it. Most methodologies correctly identify the former group but tend to ignore the latter one.
As we all know, the influence of stakeholder is high at the project initiation as it is low the cost of changes; unfortunately the “using” stakeholders come to exert their influence in the intermediate phases of the project life cycle (such as in Conference Room Pilot mode), when satisfying it is significantly more costly; hence the implementation project is guaranteed to run into problem unless this fundamental issue is addressed.
The role of the ERP technology in the company.
Although ERP technology is expected to deliver positive results once implemented, it is not the technology itself the “deliverer”, rather the results are delivered by processes executed by individuals who may or may not use the technology to carry their processes out, therefore the scope of the project must include a phase to define the “things” (processes) that the company must do extremely well to be successful and carry out their business strategy, i.e. deliver product, implement price changes, collect receivables, manage warranties, measure employee performance, etc., etc., and the manner in which the new ERP technology is going to help these processes. In other words, the implementation project must look at the world through the eyes of the company's essential processes and not just through the eyes of the ERP system practices and functionalities.
The traditional methodologies have unsuccessfully tried to address this issue; most have not selected or included the appropriate mix of processes from the Project Management groups to accomplish the task. Traditional methodologies tend to emphasize “executing” and “monitoring and controlling” process groups in detriment of “planning” and, more importantly, “initiating” process groups.
When the project scope and deliverables are defined, one needs tools to ensure and verify that the right scope and deliverables are included and that the appropriate stakeholders have been identified and included in the project management plan.
How do most methodologies address this point?
First, most methodologies are ERP vendor driven and therefore tend to see the project deliverable as “implementing the package” instead of dealing with business processes.
Secondly, and in line with their emphasis on “executing” and “monitoring and controlling” project management processes, they are rich on certain Project Management Knowledge areas but weak in others. Let us review them.
A review of existing methodologies.
This list of generic methodologies has been compiled by the author after more than 30 years of experience with several ERP vendors and many implementation projects. The names have been changed to protect the innocent.
- “Information Technology (IT) will do it”
- – Generic education for IT personnel with technical biased instead of functionality applicability
- – Current processes mechanics (as IT understands them today) are programmed into the new ERP package
- – IT educates users
- – Limited involvement of the real process owners
- – Scope focuses on completion of programs and not on process improvement and strategic match.
- – Overall project deliverable is technical in nature
- – Go live with programmers making sure that the system (and their programs) “works”.
- – Programming and education budget may not be overrun but expect low system utilization and inefficient business process execution
- “Most Common”
- – Generic Package Education for project team and others key users.
- – Some form of Process Simulation (Conference Room Pilot) to identify gaps between package and “as-is” version of business processes.
- – Identified gaps (as the selected group understands them) are programmed into the new ERP package.
- – More education to those users identified as “super users” who, in theory, are the people owning and keeping the system current (T. H. Willis, p. 37)
- – Scope focuses on reproducing the existing current state of business processes and not on process improvement and strategic match
- – Go live with programmers making sure that the system (and their programs) “works”.
- – Expect budget overruns and very little process improvement (but things look like before)
- “Don't worry about it (or do it yourself)”
- – Generic education
- – Technical set up and system configuration done by vendor or third party.
- – Budget may have been met but your investment is significantly underutilized.
- “Consultants' dream”
- – Discovery (lots of it)
- – Massive documenting of current practices without any benchmarking (non value added process mapping)
- – Generic System Education for project team and others (lots of it)
- – Pre-configured Conference Room Pilot to sort out issues (still too many modifications)
- – Some refresher education
- – Huge budget to begin with
- – Go live (lots of consultants)
Practical example.
Effort and “methodologies” (as identified in the vendor's marketing literature).
| Fast Path | Full Assist | Standard | Business Process Improvement | |
| Education Days | 35 | 20 | 45 | 45 |
| Consulting Days | 100 | 150 | 75 | 200 |
| Total Days | 135 | 170 | 120 | 245 |
Key Elements (as identified in the vendor's marketing literature).
Fast Path: $25M plus company, limited number of resources, project team does system configuration in Conference Room Pilot (CRP) setting.
Full Assist: $20 to $25M company, limited number of resources, limited time line, consultants do discovery and system configuration in CRP setting.
Standard: $25 to $150M company, implementation teams for key functional area, project team members do system configuration in CRP setting.
Business Process Improvement: $50M plus company. Top Management directs improvement focus, functional teams from each department to re-evaluate business processes, business process ownership has been established, CRP setting is used to map ERP system into improved business processes (or vice-versa).
This example shows that “improved business processes” is not necessary a deliverable of all methodologies and even if it were the effort is deployed in the wrong place.
“As good as this strategy may look on the surface, it is doomed for failure because all the stages occur after the client purchased the software. Buying software before you analyze the business situation is putting the proverbial cart before the horse” (Roman, 2005, p. 2).
Furthermore, these methodologies do two thing (wrongly) in relationship to scope definition and project initiation. First they look at using the ERP technology through the glass of existing company functions and business processes, instead of facilitating process improvement and re-alignment vis-à-vis such factors as the firm's marketing and manufacturing strategies, market place demands the achievement of goals and objectives not currently being attained. Secondly, they provide generally good answers to project structure, organization and progress control but still see the project main objective as the implementation of the package without major business disruptions.
Required Steps for a Better Methodology
The challenge of a successful implementation methodology is to implement a set of improved and re-aligned business processes supported by the ERP technology tool within budget and timeline. In order to meet this challenge the project methodology must include the following generic steps:
- Business definition
- Logical system design
- Package Selection
- Essential Processes Model
- Process validation and training
- Final deployment and Go-live
The presence of these steps in any methodology ensures that the project management processes of initiating, planning executing, monitoring and closing are properly addressed.
PMBOK® Guide (PMI, 2004 p. 43 &44) states that “initiating processes are normally done external to the project's scope of control by the organization […], before beginning the Initiating Process Group activities, the organization's requirements and business needs are documented […]. The relationship of the project to the organization's strategic plan identifies the management responsibilities within the organization. In multi-phased projects initiating processes are carried out during subsequent phases to validate the assumptions and decisions made the original Develop Project Charter and Develop Preliminary Scope Statement processes”.
Thus by adding a Business Definition phase to the ERP acquisition and implementation project, one can ensure that all business needs and required critical processes (things that the company must do extremely well) are aligned to the organization's strategy. Hence this phase includes a review of existing business practices (logistics, procurement, production scheduling, quality assurance, etc.) and their current (as-is) role in supporting and executing the organization's strategy. In most cases, a series of opportunities for functional re-alignment can be identified.
Logical System Design is a logical (technology independent) view of the organization, including its strategy and current processes and practices. It includes a clear description of the required re-alignment of processes and practices, which in turn defines the critical functionalities of the ERP system. This is the raw material for the request for quotation (RFQ).
Package selection is the search, discovery and rating of commercial solution vis-à-vis the Logical System Design.
Essential Processes Model is the fully re-aligned view of the organization. It identifies specific details of the enabling and supporting role of the new ERP technology at the business process level, and defines the project execution scope, the users/stakeholders education and a benchmarking model to measure implementation progress.
The Process validation and training phase allows those process owners/stakeholders to simulate their processes using the new technology, learn its functionalities in a systematic way and fully test the integration of the package with any other software tools that they use to carry out their processes. This validation and simulation exercise is can be normally accomplished by using Conference Room Pilot (CRP) techniques complemented by focused education (focused on the Essential Processes Mode) before the CRP sessions. Non PMBOK® Guide complaint methodologies use the CRP sessions to identify mismatches and discrepancies between the ERP system and the “as-is” vision of business processes as understood by those stakeholders performing them; a different scope begins to “creep up” (hence the term “scope creeping”), the result is an expensive retrofitting exercise that ends up consuming most of the implementation resources and the ERP project's success is seriously compromised.
In the proposed methodology, the ERP system was selected based on a Logical System Design, that included a view of the organization, its strategy and current processes and practices and a clear description of the required realignment of processes and practices, therefore the risk of extensive and expensive late modifications of the package have been minimized.
Final deployment and Go-live marks the completion of all procedures, process' realignment and other improvements. It includes testing and data transfer from existing systems, manual or otherwise, and more hands-on training for users of the new processes supported by the new technology.
Conclusion
ERP system implementation projects’ success rate can be improved by consistently applying a PMBOK® Guide compliant methodology that recognizes the need to include the appropriate mix of processes from the Project Management groups to accomplish the implementation task. Traditional methodologies tend to emphasize “executing” and ‘monitoring and controlling” process groups in detriment of “planning” and, more importantly, “initiating” process groups.
Furthermore, they lack mechanisms to ensure that the right scope and deliverables are included and that the appropriate stakeholders have been identified and included in the project management plan. Because the “state of the art” in ERP implementation methodologies are ERP vendor driven, they tend to see the project deliverable as “implementing the package” instead of dealing with business processes (which is what the company does day in and day out); this package view contribute further to the weakness in initiating and planning, typically found in failed implementations.
The challenge of a successful implementation methodology is to implement a set of improved and re-aligned business processes supported by the ERP technology tool within budget and timeline. A methodology following the steps suggested in this paper will answer that challenge.
