5 Phase ERP Implementation Process
A Conference Room Pilot (CRP), often just referred to as a 'Pilot', is a measured approach to trial the anticipated operation of the accounting software system or enterprise resource planning (ERP) application in order to understand how the information system works or should work, and determine how to best configure the application for the planned objectives – prior to the go-live cut-over.
Pilots often begin with a structured accounting software or ERP software training course which illustrates the core capabilities of the application software. The Pilot phase can then be used to configure, manipulate, test and validate the company's business processes within the new ERP software system. The Pilot should conclude with measured results illustrating functional fit or identifying the gaps and areas requiring a more detailed design effort prior to full implementation. Several Pilot goals are highlighted below.
- To explore business process and procedure alternatives and evaluate business process improvements
- To train project team members in the new ERP system (minimal training should include software configuration, setup parameters, transaction flow procedures, internal controls, modification capabilities and standard reports)
- To gain a more practical understanding of the strengths and weaknesses of the business software application
- To evaluate the ERP or accounting software for fit and optimize the system where possible
- To test and confirm business process design alternatives for fit and impact
- To help develop the plan for data conversion and system integration
A number of primary decisions must be made when implementing ERP software modules. For each business software application, there should be a responsible subject matter expert (SME) or business sponsor who will assume accountability for the configured application and its operational utilization. Typically, the software manufacturer or third party consultant will provide software implementation consulting to facilitate the project team in making these key decisions while setting up the Pilot environment. The Pilot configuration will require a balance between the company's operational desires and the software's capabilities. Additional tasks incorporated into most Pilots include the following:
- Identification, evaluation and confirmation of all material end to end business process transaction flows
- Adoption of new optimized or streamlined procedures and TFR’s (transaction flow reviews); this task is often facilitated with the application software's work-flow design tool(s)
- Exploration and confirmation of primary key designs (such as chart of account configuration or intelligent schemas for Customer ID, Item SKU, Vendor ID, Territory Keys, etc.)
- Consider building intelligence into primary key schemas where it makes sense - you may want to segment these keys or force certain types of characters or values in order to simplify data entry and reduce transposition errors
- Also recognize the permanence of most primary key values - more often than not these data values are not easily changed as the history must also be updated for analysis and comparative reporting (thereby requiring a data conversion of the historical data)
- Mapping the electronic data conversion process. It's important to sample and verify the cleanliness of the historical data; scrub the data as necessary, and then perform another sampling before beginning the actual conversion and reconciliation. Do not make the mistake of converting dirty data with the intention of cleaning it up after it is in the new information system
- Exploration of the setup and file maintenance software parameters; configuration options can also generally be manipulated to achieve business process work-around's (which is an alternative to software customization)
- Documentation of user profiles and system security permissions; be sure to also confirm integration and back door access and security tests
- Tailoring and simplification of (transaction entry) forms; if you modify forms do it by user role or class and not by individual users; test and verify the anticipated data entry and user experience efficiencies with actual users performing actual tasks
- Documenting your reporting and information analysis requirements (report formats, content, production frequency, distribution, etc.)
- Development of integration points and data transfer design documents; plan for thorough (unit and regression) system integration testing
- Evaluation and development of software enhancements or productivity aides which will promote user adoption and generate measurable payback
- Completion of multiple project team and user testing scenarios; business process configurations should be tested first by project team members and then by random actual users
Business Process Automation (BPA)
ERP application implementations offer an ideal time to review, revamp and re-engineer business processes. Although business process reengineering (BPR) exercises do inject additional change (which therefore requires additional change management), they also offer increased efficiencies in parallel to the new application software for a more synergistic and powerful result. The below diagram illustrates a common approach to business process improvement.
As-Is Process Review: In this phase the existing business processes are scrutinized with the objective of identifying improved process activities, workflow patterns, decision points and measurable end results. The current (‘As-Is’) processes provide the base line in order that the future (“To-Be”) processes can be measured and refined.
Develop To-Be Processes: In this phase, the proposed business processes are mapped and defined. In addition to the As-Is analysis, the key inputs to this stage include streamlined business process cycles and recognized best practices which may be linked to the functionality of the software application being implemented. These core inputs provide the basis for creating the “To-Be” business process. These processes are normally documented in the form of visual diagrams called process maps.
Identify Application Gaps: Functional gaps between the To-Be process and the application software product will be identified in the prior activity. During this task, the To-Be processes are compared directly against the business software functionality.
Categorize Gaps: In this activity each of the gaps are segmented, weighted or prioritized into a measurement method such as Regulatory Requirement, Company Requirement, Line of Business Requirement, Desirable and/or Non-Essential. Based on the importance of the gap, alternative methods to meet the process requirement are evaluated. The options for remediation generally include the following:
- Software re-configuration. This action suggests that the functional gap can be resolved by making a change to the application software configuration or setup parameters. This can also be accomplished suing the software manufacturer's modification toolkit(s) and typically does not require the software to incur source code modification.
- Business process workaround. Many times an acceptable business process work-around can be identified in order to meet a process requirement. This usually entails a minimal change to a business process schema.
- Software customization. ERP software customization is the most expensive and high risk alternative to meet software gaps or business process requirements. It is important to recognize that software customization is a recurring expense as it must be upgraded with each new software version release.
A Pilot analysis and implementation phase will complete an initial review of all material business processes, map revised or upgraded processes, possibly incorporate best practices within the context of the ERP software, take advantage of new functionality and ultimately identify the specific methods in which the ERP system or accounting software will be deployed to meet clear and measurable objectives.
While new ERP or accounting software offers exciting and rewarding opportunities for the company, application software doesn't remedy all of the company's automation challenges. For many software implementations, managing the change of both the business processes and information systems in parallel can be the greatest challenge. Any implementation approach must consider and plan for change obstacles and include a formal change management mitigation strategy.
Pilots and information system prototyping are proven to work. Modeling the ERP software system through a series of iterative prototypes, whereby each iteration more closely aligns the business requirements and stakeholder vision to the capabilities of the application software will ultimately maximize software fit and directly increase the likelihood that business objectives will be achieved. Equally important, by seeking early and frequent input and feedback of the user communities during each phase, the information system will both adapt to user requirements and steadily earn the buy-in of the user communities.
Good Pilots also accelerate project team learning, identify issues and opportunities early in the project life cycle, set realistic expectations for project team and incur far less risk than a live pilot or big bang software implementation.