Monday, January 3, 2011

2010 Year End - ERP failures

At the end of a year, all sorts of lists pop up. The media bombs us with top selling albums of the year, the world's richest billionaires and ... the biggest ERP failures of 2010.
Yes, it 's true. Now and then, an ERP implementation fails. Sure, most IT projects end up being late and over budget. But when its by a factor 4 or 5, it fails. Big time.
Sometimes the GO LIVE milestone is even never reached. Or only when the original scope was changed so badly, the customer, vendor or integrator could not recognize it any longer.

I can't help but notice that the name SAP comes up more then once in this story. But no chuckles from me, a Dynamics Ax fan.
When the new accouting software of your uncle's Bob grocery store isn't quite what was expected, that's not big news. But when the city of New York is modernizing it's payroll system, where talking different numbers and headline news.
SAP is simply more active on the upside of the market, aiming for bigger customers. When those kind of projects are not a success, it's news. Simple as that. As a defense, one can argue that the mentioned failed projects are not all 2010 based, some are "old news" to say the least. But is there something we can learn from the article, even for people with no connection to SAP whatsoever?

Some highlights from the original article on ComputerWorld:

Customers have to plan well, budget enough money for training and evolve their usual way of working.

No arguing there. This goes for all customers: small, medium, large and very large.

XYZ used the project as "a trial-and-error training ground" for inexperienced employees.

Haven't we seen this happen before, where a rookie employee of the integrator is sent out to the customer to get results. Just to make sure the new guys hours are billable from day 1 on the job.

As a customer, ask for references before you start the project. Get the team member list of your integrator, with the years of experience of each consultant noted before you sign the contract.

XYZ used a "fake" product demonstration to trick it into believing its software was a good fit.

How many customers still buy a product (or software for that matter) based on a Powerpoint presentation? If needed, involve a third party to help you judge product demo's. Make sure the demo is customized to your business, your processes.

The customer didn't "timely and accurately define its business requirements" or provide "sufficient, knowledgeable, decision-empowered users and managers" to the implementation.


When things do go wrong, how many customers are up for self-criticism? Did they do everything within their might in order for a successful implementation? There are two sides to every story...





The article made me remember this other news headline from last year, the lawsuit Oracle filed against TomorrowNow. After the ruling everyone agreed the 1.3 billion dollar awarded was out of proportion. Did it make other parties in IT nervous as well? Because when an IT project fails and the partner is fired, someone else has to step in. Giving the new partner access to the original documentation, or even maybe the original code. When only the partner is replaced, not the product.
Wait and see if 2011 brings more of the same.

No comments:

Post a Comment