Phased Methodology for Implementing ERP Systems
by Michael Doheny for KCP Dynamics
There is much which can go wrong with Enterprise Resource Planning (ERP), so it helps to have a clear plan of how one navigates the deployment. An ERP implementation methodology provides a road map of sorts that will see you through the steps of a project in a coherent fashion. Vendors, consultants, and Value Added Resellers (VARs) use different approaches to the ERP deployment task.
The phased approach is one in which the ERP system rolls out in stages. An implementation might begin with the ERP module most important to a manufacturer and continue on in a step-wise progression from there. The phased method provides the benefit of ironing out issues with the first module before moving on to additional software components. Users are cutover gradually as well, so phased rollouts typically involve less organizational disruption. The approach involves less risk, but requires a greater investment in total deployment time. Within the phased roll-out are specific steps or sub-phases which enable the project team to plan and organize.
The first phase of an ERP implementation is the diagnostic phase. The purpose of the diagnostic phase is to gather information at a high level from the client. This is the starting point for defining the scope of the project. Based on the initial findings in the diagnostic phase a rough timeline for the project can be compiled. From the “Diagnostic” a proposal can be presented to the client for review and approval. Common deliverables of the Diagnostic Phase include the scope or Statement of Work (SoW) and the project budget relative to software and resource costs.
Prior to moving on to the next phase, the Analysis Phase, it is critical to determine and agree on what the measurements of success are going to be. It is at this point where many clients will decide to Phase their projects, to define milestones or success fences as a method to mitigate project fatigue, to openly discuss project risks including vacation schedules, and to assign team and leadership roles.
The Analysis Phase is the official commencement of the project. It is during this phase the implementation team works with the client to determine key decision points, to review the current business processes, the ‘as-is’, in order to document the ‘to-be’ processes within the ERP, to define Business Process Improvements (BPI) and Key Performance Indicators (KPI), and to detail, at a high level, which parts of the system require modification if the business cannot adapt to the software.
Training requirements are also considered during analysis that define the users within the project team and end users who will require training or even whether a train-the-trainer model will be the optimal training process. Sometimes the analysis phase is called a Gap-Fit Analysis because it seeks to identify and document gaps between the software and the customer’s current business processes. The key deliverable(s) for this phase of the project is sometimes referred to as a Functional Requirements Document (FRD). For some this phase of the implementation begins the project lifecycle. The process of gathering requirements is usually more than simply asking the users what they need and writing their answers down. Depending on the complexity of the application, the process for gathering requirements has a clearly defined process of its own. This process consists of a group of repeatable processes that utilize certain techniques to capture, document, communicate, and manage requirements.
Dependent on the findings from the Analysis Phase, the Design Phase creates a set of documents with specific customized software modifications and data migration mapping and planning. The project deliverable from this phase is a design and data migration specification document(s). These documents are required by utilized by development team\programmers to modify\customize they ERP system for the specific needs of the Client. Similarly, the data migration document specifies which and how data will be migrated from the legacy system to the new or, in the case of a new system, how data will be initiated.
The included in this level is the Functional Design Document (FDD) in which the configuration settings for the system are documented as well as any process fits discovered from standard functionality. A Technical Design Document (TDD) is also created which details the business processes, and the specific modification requirements which are then forwarded to the development team.
The function of the Development Phase is for the development team to modify the software to conform to the business needs of the client. At the completion of this particular phase, the system should be configured and modified to suit the business, data migration from the legacy system to the new is complete, and reports and interfaces are working as defined. Toward the end of the development phase end-users engage in Business Process testing.
Some ERP Projects will break out testing and acceptance as separate phases although it is generally considered an extension or sub-phase. Unit and functional testing is conducted to ensure the standard software and custom code satisfies the requirements set out by the client. Business Process testing is conducted to ensure the system can perform as expected. Many ERP implementation teams will call this a Readiness Review, Business Process certification, or Conference Room Pilot. Generally, key users will work together and to perform the functional roles of the end users from start to finish – handing off to another key user as the process progresses.
The deployment phase marks the planning and execution of the delivery of the ERP system. Final testing and end-user training are conducted; performance load testing is conducted to ensure the system is configured to handle the volume of daily transactions, and to ensure the financial data and reporting aligns with the legacy system.
Operational or Post-Go-Live Phase
Usually, a three month period is defined as Post-Go-Live; where system support is provided, and any ‘misses’ are identified and either corrected or collected and added to a subsequent stage. In some larger ERP implementation, the end of the Post-Go-Live phase includes transitioning the users to a support team or center. This usually enlists the lead implementers and\or key users to conduct in-person or virtual training sessions.
A well designed and practically scheduled phased implementation approach will benefit both the client and the implementation team. With clear timelines and deliverables the process is designed to give both teams the ability to agree on scope and when to proceed to the next step.