A frog put in boiling water will jump out. But if the frog is placed in cold water that is gradually heated, it will not understand the danger, adapt, become complacent, and cook to death. This metaphorical story is often used as an example of how adapting to small changes over time, without understanding the big picture, has significant consequences in the end.
Unfortunately, it's common for ERP implementation teams to suffer the same fate as the frog. Teams may feel confident throughout a project because of a focus on managing big items (enhancements, specialized configurations, and bolt-on applications) while little things fall through the cracks. But it's not unusual for ERP teams to feel as if they are in boiling water as go-live approaches. The system is not completely configured, reports aren't written, interfaces have errors, technology environments are not stable, critical data is not loaded, and end users aren't prepared.
How can the ERP project team avoid being boiled? It's all about managing the little things throughout the implementation to prevent a disastrous go live. The most successful ERP teams do (or avoid) the following during implementation:
A reporting strategy with a supporting data model should be developed in advance of an ERP implementation. The reporting strategy not only defines the information and reports required to run the business but determines critical configuration needs. Key attributes such as the chart of account structure, item categories, and customer attributes are determined. The reporting strategy can be used to develop the reports earlier in the project to be tested along with the configuration.
It's difficult to impossible to convert detailed transaction data into a new ERP. Data quality is typically bad in the old system and the chart of accounts will be redesigned. Cleansing the data is a full-time job for more than one person and is never really complete. Additionally, developing a crosswalk translator from the old system’s master data to the new will rarely map correctly. Converting the history will cause the team to focus more on reconciliation and less on testing the system’s ability to support new and more efficient processes. It's best to convert and rationalize master data and keep the old system running to research history.
Software vendors will state that their solutions will seamlessly integrate with payroll services, major banks, and benefit providers. This simply is not the case. These interfaces should be treated no differently than an interface to a non-standard system. Pushing off developing and testing these interfaces will invariably lead to project delays.
It's surprisingly easy to allow critical milestones to slip. Planned configurations, interfaces, enhancements, and reports are not ready for testing. However, the team is pressured to meet the milestone, so testing is started with the justification and assurances that the unfinished objects will be included in the next round. This slippery slope can create significant issues later in the project. Key components from one milestone get pushed to the next milestone. Every milestone. Good project managers create pre-milestone checkpoints to ensure the associated project tasks will be completed before a key milestone is achieved. Surprises are eliminated because adjustments can be made earlier.
System integrators are human and enjoy their fair share of staffing issues. Staff can get sick, quit, or become otherwise unavailable to the project during critical times. Making sure the system integrator addresses these situations immediately is important. Don't wait beyond a short, set time to determine whether the individual needs to be replaced. A two or three-week delay early in the project has significant ripple effects that are magnified by the end of the project.
