Written by Debbie Karcher
The replacement of a legacy system can result in great excitement and energy in an organization. People enter these projects with intentions of moving the organization forward, saving time and money by becoming more efficient thereby making them more competitive. Not too long after the project is started, organizations will begin to experience problems not considered, or more likely ignored, when implementing ERP systems. Most of these problems have occurred before in other organizations which is the reason, they are called are unforced errors. Unforced errors are only prevented by knowing the cause and making the corrections needed to avoid them. Organizations have been implementing ERP systems long enough to identify common pitfalls and should use best practices to avoid failure. Below are some of the unforced errors that I have personally experienced and the methods used to avoid or mitigate their damage.
- Expecting existing resources to implement the new system without having replacement resources – Six months prior to implementation hire a new resource (s) either as a contractor or district employee, to learn and assume the old position. This person needs to maintain the legacy system giving the current support personnel the time and opportunity to provide requirements, test, and support the new system.
- Not installing and using the vanilla system – Use the system first using your current data and processes before or during the blueprint phase. This will require you to convert required data from the legacy system to the new system, but it is not time wasted: you need to do this at some point in the process. Some systems are so old that much of the functionality they once had have been dropped or replaced with other systems. For example, while implementing a new Plant Maintenance System it was discovered that the materials kitting process was no longer used. Since this was a function of the new system, new processes had to be established to take full advantage of the new system. This would have been missed if only reviewing current processes. Having people use the new system that know the current process will quickly identify the functions that are missing and any new requirements. This will help streamline the building of the business process blueprint.
- Spending countless hours in building the blueprint – this exercise, if not controlled, can easily cause you to go overbudget. Many implementors do a time and material charge for this phase because there are too many variables for estimating the activity. Your in-house expert can articulate the system requirements and workflows, but they may not know all the processes requiring input from others or there may not be anyone who fully understands the old or new system. Instead, use the parking lot method to acknowledge the issue to test or resolve this in the vanilla system mentioned above.
- Customizing the system – By now the short and long-term impact of changing system code should be enough of an argument for refraining from this. But often an organization believes that their reasons for changing code is different and unique. Under no circumstances should customizing the underlying code be allowed. This is the quickest path to a non-supported system. Instead develop processes, either manual or automated to accomplish the task. Keep in mind that one system will probably not meet 100% of your needs and take advantage of the 80% or more that will. Users, who hated your current systems, will, suddenly, have an affinity for the legacy system as soon as the new system cannot provide immediate solutions.
- Forgetting the shadow systems – As the name may suggest these are systems that sit outside the direct control of the legacy system’s owner. They are created out of necessity when the need for functionality is not available in the organization’s-controlled system or a new process was mandated that could not be implemented quickly enough. Either way these systems become an important part of a workflow. The way to uncover these systems is to have your users take you through their entire process; not only what is entered into the documented system.
- Not paying attention to the small print – Software companies and implementors write contracts all the time. It is part of their core business. School districts will do this once every 10 or 20 years. The companies have the advantage. Consider the time and material example above. Even if a fixed price is negotiated the vendors will add language that will limit the number of changes before there are additional costs. Good partner relationships are important, but it is important to remember that they too, have goals. Before signing, do a walkthrough of each contractual requirement to make sure you understand the consequences of not meeting the contract terms and understand the reasons for penalties and additional cost.
ERP implementations have not become any easier to implement and there are always new challenges. Today’s ERP systems are cloud-based, offloading some of the on-premises activities such as hardware, backups and updates to the vendor. However, there are new considerations such as security, data privacy, support limits, data location and loss of control. Worldgate, a technology consulting firm, that specializes in K12 ERP implementations, can help school districts navigate these complex projects while allowing districts to focus on their core technology; student achievement.