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.