The conventional approach to implementing major enterprise software is to create a set of high-level business requirements and then go to market to select a technology and/or vendor. This is not necessarily the best approach.
Invariably, one or more of the following happens:
- Potential customers are wowed by the size of the vendor's customer base – the majority are never wrong, right? If it works for all these organisations, how can we go wrong?
- Vendors then offer a cheap entry price into the world of ERP / CRM and make various claims about the superiority of their software and the impact on your business,
- The executive, although somewhat jaded by the IT department's continued troubles in delivering technology that works, engages the vendor thinking it will be different this time,
- The vendor starts work and swarms of 'consultants', still quite wet behind the ears, are poking around in your business, saying you need to change this and change that,
- You have regular meetings with the vendor where you argue, negotiate and then resign yourself to the sacrifices you need to make because their software 'doesn't work that way', You also need to change your processes to suit, otherwise they say 'Sure we can do that, but it's a change request', and 'ka-ching ka-ching' goes the cash register,
- You review and sign-off large lists of 'change requests', thinking that there's something funny with the pricing in relation to the original quote given way back during the tender process,
- Years after the project was supposed to finish, the same consultants are now getting married and having kids, all toasting you for making it possible.
While a combination of all of the preceding represents an extreme case, it can be reflective of the common experience of companies that implement large scale enterprise applications.
Importantly, I haven't even mentioned the problems with the user interface. The reality is that the success of a given technology is not dependant so much on issues of technical elegance as it is on user acceptance. That is, when staff have to figure out how to relate the different business processes in an ERP system to the way they're used to doing things.
Faced with a need to 'learn' new screens that bear little or no resemblance to the applications they've used before, they invariably have a better idea for what to use -- spreadsheets and access databases (also known as corporate chewing gum). Think of the implications -- your ERP / CRM integration strategy has just been defeated by a basic spreadsheet.
I'm not saying that all enterprise software is destined to fail, or that you shouldn't (or can't) use it to run your business. Indeed, there are probably many successful cases. What I am stating is that success can be achieved with a far greater degree of certainty and a much smaller price. It all has to do with the way you engage a vendor and their technology. The traditional approach invariably leads to a greatly diminished return on investment.
Before I go any further in describing how to greatly reduce the risks associated with introducing packaged enterprise applications in any business, let's take a step back and absorb the lessons of history. Winston Churchill once said that those who didn't learn from history were doomed to repeat its mistakes.
Unfortunately, this has been the case with enterprise applications, and not just packages. The tidal wave of packaged software take-up, starting in the early '90s, was a knee-jerk reaction to failed custom system development projects. For example, in the banking sector, multi-hundred-million dollar system disasters are the stuff of legend. They caused the affected management of these organisations to lose their appetites for more of the same. The thinking then became "We would have to be better off with packages because a high degree of what we need already exists".
This really appealed to the systems integration community, for obvious reasons, and many of them experienced explosive periods of growth. However, retrofitting a major application actually amounts to a more complex exercise than developing one from scratch, as many organisations have discovered.
So, what was the lesson that needed to be learned? What was the factor common to both approaches that caused the grief? There was no blueprint or master road map that fully defined requirements and created a clear line of sight between strategy, application behaviour and application code. No matter whether it was custom or off-the-shelf software, the method of engagement caused the problem.
Please sir my comments is to ask you that using a computer for long hours can cause brain or eye problem?