ERP deniers their own worst enemy
If only we could start again
Workshop As new ideas and technologies emerge and develop in IT, we typically go through a maturity curve. Lots of problems are reported in the early days as a result of unproven products and lack of market ‘know how’ which gradually disappear over time as offerings become more robust, experience is gained, and best practices are defined.
Why then, even after a couple of decades, do we still hear so many horror stories about ERP – overruns, escalating costs, even outright failures?
Now to put this into perspective, we should be careful not to fall into the trap of concluding that all ERP implementations are disaster areas, which is an impression you could easily get if you took your lead purely from the media. The fact is that every week, organisations are successfully delivering ERP solutions that never get reported. After all, “Acme Corporation implements ERP to plan” is hardly an engaging headline.
Nevertheless, many do run into problems, not just with the initial ERP implementation, but with cost and inflexibility thereafter, and a big contributor to this is denial. When we wrote about the importance of challenging some of the accepted ERP wisdom recently one of the points we made was that an insistence on regarding your own business processes as sacred can lead to excessive amounts of customisation, which in turn translates to cost and rigidity.
We had a little bit of push back from readers on this during our current online workshop, for example:
Funny, I read some time ago a study by some MIT researchers that in fact there is nothing like ‘industry accepted best practices’ and that companies should rather try to figure out their own practices based on their own needs and contexts. For sure, it didn't say that they shouldn't look at what is done around, but still it was about adapting and not just copy/pasting. Meaning that something working for some companies could very well fail for other companies in the same ballpark, depending on the context.
It has to be said though that the general thrust of comments and experience coming back was more along the lines of:
Our company went 450% over budget in year 2 due to an upgrade gone bad. Too many parts of our extensions were not easily upgradable and we were not notified by the implementer that this would be an issue. Always ask your supplier how changes affect upgrade!
ERP solution massively customised around existing processes - now in a position where we have a rats nest of customised bits and are continually asking 'Why is it doing that' as we try and integrate new bits. What is worse is that the 'processes' turned out to be more about custom and practice.
Extensive customization in the warehouse and shipping processes must be tested extensively and remediation taken with almost every patch or upgrade. This makes keeping the technology up to date more expensive.
These are just examples of general sentiment that was echoed over and over again – alternative wisdom that is actually pretty well known in ERP circles, but is so often ignored or dismissed. At the root of this denial problem is perhaps a bit of stubbornness or failure to accept such real-world reality ‘on principle’, as hinted at in this comment:
Can be difficult to get the business stakeholders to agree to change their processes - they (probably rightly) believe that if they're paying for some IT, it should work with them.
The same reader goes on to point out the importance of flushing out this assumption early on and dealing with it up front:
The reality is of course much different to this, so early expectation setting that the business will have to compromise on some of its processes needs to be set otherwise it's a very painful journey.
Perhaps a bit of education and ‘tough love’ is in order to help the deniers overcome their tendency to focus on the way the world should be, so they can better come to terms with the way things really are.
So what is the extent of the problem?
The results of our poll illustrate that significant customisation has historically been the norm rather than the exception. Indeed, around 40 per cent seemed to prefer paying consultants to cut code by default to avoid making adjustments to the way they work (Figure 1).
Sponsored: DevOps: Download the Dummies Guide