ERP deniers their own worst enemy

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).

While the number of data points here is obviously limited, meaning we can’t take these numbers too literally, the picture painted does gel with our general observations and experience of the ERP space over the years. And despite the statistical limitations, the following charts are also consistent with what we are seeing across the general market (Figures 2 and 3).

Put simply, the majority of those in our poll who originally put the emphasis on tailoring the package when it didn’t fit current processes would, based on the lessons learned, take the opposite approach if they could start over.

This whole discussion, of course, highlights the importance of considering the ‘out of the box’ fit of the package during the evaluation and decision making cycle. Participants in the poll from larger organisations, for example, stressed the importance of the product being designed to handle the scale, complexity and diversity of a large group environment. This is undoubtedly because smaller footprint solutions are more likely to give rise to gaps that need custom development work to fill, though see here for a discussion of so called ‘2 Tier ERP’, based on the principle of surrounding a corporate system with more lightweight packages installed in individual operating companies.

Coming back to the poll, those from smaller organisations highlighted alignment with their industry as important, which is understandable given that unlike their larger cousins with different shapes of business across different subsidiaries and divisions, they are more likely to fit into a single industry category. In practice, such industry alignment will be a function of the experience of the consulting firm or reseller assisting with the implementation, as well as the design or templating of the package itself.

Not surprisingly, when looking at solution fundamentals, the most frequently highlighted attributes were a modern (open, scalable, extendable) architecture and a good level of out of the box integration with third-party products. The logic here is clearly that where gaps or mismatches exist, they can be dealt with through a combination of soft configuration and the use of complementary products, rather than hard core development work.

Based on the above, the bottom line advice for anyone embarking on an ERP project is to accept the realities we have outlined as early in the process as possible. We are not saying customisations should never be carried out – it’s more a case of acknowledging the really quite serious implications of implementing them in terms of ongoing cost, disruption and inflexibility down the line.

Dale Vile

Click here for more posts from this author

Dale is a co-founder of Freeform Dynamics, and today runs the company. As part of this, he oversees the organisation’s industry coverage and research agenda, which tracks technology trends and developments, along with IT-related buying behaviour among mainstream enterprises, SMBs and public sector organisations.