While success metrics associated with the launch and implementation of enterprise ERP systems have gone up over the last 10 years, up to 40% of ERP system operators continue to experience schedule delays when trying to get a resources-based platform online. While market complexity and rapid technical demands have caused some of these delays, there are hosts of well-understood errors that continue to lurk within the bowels of after-action reports.
Here are four of the more glaring weaknesses leading to ERP schedule delays:
As the old saying goes; ‘measure twice, cut once’, but regardless of the sophistication of maturing ERP systems, many enterprise folks still don’t seem to be interested in understanding their own needs.
This is particularly true when it comes to the development of necessary business requirements, which guide and measure activities during an ERP launch.
This guidepost document defines and validates practical responses regarding ‘how’, ‘what’, ‘when’, and ‘where’ business weaknesses may exist, and where a new ERP platform is supposed to marginalize that pain. However, if your plan is poorly executed, it’s likely that your schedule will be badly skewed and failure-prone as well; causing lost time, increased frustration, and ultimately wasted money.
ERP platforms are expensive.
To make a point, let’s be redundant for a moment when I re-assert that ‘ERP platforms are expensive.’
Consequently, if you are unable, or unwilling to establish a set of proper budgetary requirements at each stage of an implementation, it is likely that you’re going to run out of money sooner rather than later.
This is not meant to be as a criticism, but as a cautionary component that all enterprise managers should be mindful of when considering an ERP launch. Again, if the enterprise doesn’t have the money to do the job the right way, don’t play the game at all; otherwise, all you’re doing is causing a larger and potentially scarier problem downstream.
I grant that training may seem to be the poor stepchild of all tasks relating to an ERP implementation, but ignore it at your own peril. The reason for this admonition is simple: if you short-shrift your workforce in terms of time and/or educational attention, you’re simply asking for trouble when you try to turn the lights on.
Among the ‘usual suspects’ relating to schedule delays, this one causes the most trouble, since people aren’t machines, and harbour all kinds of problems that are not necessarily obvious until it’s too late. So, take your time, and ensure that your training schedule is well padded.
This failure is another of those ‘soft errors’ that looks like nothing until it blows up in your face. Senior managers are funny animals. Some come from well-papered academic backgrounds, while others come ‘up’ from the ranks, but they all want the same thing; confidence in an expected outcome, and particularly when an enterprise is executing a risky, and costly, business endeavour.
In this context, selecting, installing, and launching a complex ERP platform falls under a management ‘risk rule’ entitled; “I’m going to lose leadership credibility if my decision is wrong.’
Consequently, if a senior manager is a couple of levels above the technical team, regular status will be necessary; as in daily; and sometimes, hourly; depending on the schedule situation.
Ultimately, if a hard-stop emerges, then it behoves the technical team to get that information up the chain immediately, while not dawdling, otherwise, bad things begin to happen. From a senior management perspective, the latter event falls under the management ‘risk rule’ entitled; ‘Whose head is going to roll first, but it sure isn’t going to be mine.’
Sometimes this question also falls under an overarching risk rule entitled; ‘covering one’s rear end’. Either way though, it’s always better to deliver bad news regularly and immediately, rather than allowing a potential situation to spiral out of control, particularly if you’re the poor guy who failed to send the memo up in the first place.
Neil ran his first SAP transformation programme in his early twenties. He spent the next 16 years working both client side and for various consultancies running numerous SAP programmes. After successfully completing over 15 full lifecycles he took a senior leadership/board position and his work moved onto creating the same success for others.