3 Reasons Your ERP Conversion is Going to Fail

Regardless of today’s hyperbole associated with ‘cloud this’ and ‘cloud that’, when it comes to establishing an efficient plan to trigger a large-scale ERP conversion, old school principals still apply. Among this group of relevant fundamentals perhaps the most important are critical attention to strategic planning, followed by effective and measurable tactical task management, lest the evolution falls off the rails resulting in a next-gen version of the venerable ‘Garbage In Garbage Out.’

Successful systems conversions are largely dependent on well-measured upstream decision-making, followed by the introduction of useful and well-understood data elements. Nevertheless, if one has checked all the right boxes, and followed best practices to a fault, red flags still appear and in those cases it’s not how hard you fall, but how high you bounce that counts.

Consequently, in order to enhance the bounce cycle, whenever a manager ‘feels like’ there might be something going sideways with an ERP conversion, early awareness of the mechanics of the effort can save a lot of time and pain. With that in mind, here are some common issues that ERP conversion projects face along with solutions to these problems.

1. An Ill-Formed ERP Conversion Schedule

ERP conversion, whether it is based on a single module conversion, or a complete migration from one system to the other, requires deliberate and prudent planning, that in turn leads to accurate scheduling. In my consulting career I have dealt with this problem many times, since enterprises have a tendency to get wrapped around the axle over the details of the cart, without first considering how fast the horse can run.

Consequently, if you find yourself expecting a month-long ERP conversion schedule that immediately begins to slip, you’re likely to end up very late, or worse facing the potential of losing project momentum that causes a conversion to fail entirely. So, when planning a conversion schedule a good rule of thumb is to extend the project timeline driven by what is ideally expected, then add 30% to the overall schedule track. At best, you’ll finish early leading everyone to think that you’re brilliant, but if not, you’ll at least have a fighting chance to finish the project closer to the original deadline.

2. The Enterprise Bought The Wrong System For The Wrong Reason

Given the depth and complexity of today’s ERP systems, this problem isn’t atypical. Many enterprises fail to understand how one ERP module depends upon another in order to create a desired operational reporting condition. This situation usually appears when procurement and accounting get involved by filtering and limiting the specifications of a final systems purchase. On one hand enterprise procurement people are primarily interested in buying ‘something requested’ quickly in order to meet their own goals, while accounting folks operate on the basis of decision drivers that usually relate to saving, not spending money.

Operationally, I have seen procurement and accounting departments vet a well-conformed ERP requirement, then simply decide that the original spec was either too complex or too expensive, then suggest, or even buy one or more system modules that have little to do with what the original requirement called for. In this event, if you’re the person who is going to have to deal with the impacts of a poor ERP purchase the best course is to announce and push the weakness up the reporting tree quickly, otherwise any attempt to tweak a square peg into a round hole will only make an original operational problem much, much worse during ERP conversion.

3. Silly Cost Cutting

This issue typically appears once a purchase has been executed and an ERP conversion is well-underway. Many large-scale manufacturing enterprises see ERP as a mis-perceived silver bullet that can resolve one or more thin operational cash-flow situations. Consequently, these companies try to cut implementation costs by attempting to mount several interrelated modules at multiple locations simultaneously, all the while hoping that simply getting an entire system ‘up and running’ sooner will save cost money now, in order to make more money on the backend. The unfortunate truth, however, is that this decision rarely works if ever, and instead runs a serious chance of blowing the operation up entirely, rather than saving it in the end.

In this case, the rule is simple; slow and steady wins the race. So, if you find yourself in a situation where senior management wants you to do a dumb thing on purpose, in a similar vein with the previous section, call the weakness out early and often. If not, you won’t be the only person who is out of a job but the entire enterprise workforce will be in line with you - the unemployment line that is.

Obviously these weakness scenarios relate to a specific cause/effect evolution, but there are a host of others to worry about as well. Therefore, as the old saying goes, “plan for success while preparing for failure”, since that sensitivity may be the only protection you have if things go south on your ERP conversion.