And then someone gets fired: IBM i ERP Implementations Gone Bad

I was reading Dan Burger’s IT Jungle article called Fear or Freedom: IBM i ERP Upgrades about the fears and opportunities involved in upgrading old ERP systems and how many ERP vendors are seeing 2014 as the “year of the ERP upgrade”. And that got me thinking of the times I’ve been involved in IBM i ERP upgrades in the past, and some of the traumatic experiences and management lessons that came out of those upgrades.

To talk about some of the pitfalls of ERP migration, here’s two cautionary tales I’ve run into when migrating to a new ERP system where things didn’t quite work out as promised…and the IT management techniques that rose from their ashes.

The President Who Couldn’t Fire His Programmers

One time, we migrated a production application from a mainframe to an AS/400 (as it was known then). After migration, we discovered two things:

1. The company president was disappointed because he believed the vendor who had said that “…this software was so good, you could run it straight out of the box and never, ever, have to modify it. You can do everything you want and cut costs by getting rid of your programming staff.” When we cut over and the software couldn’t produce orders as it could before, the President took to wandering around the company fuming that he couldn’t fire those damn programmers. Morale: always assume you will have to customize the software, no matter what the vendor says or how smoothly she says it.

2. The business partner had undersized the machine so that production work crawled along during the day, holding up our factory workers. Almost immediately, we had to upgrade the machine and the search for the scapegoat had started.

Morale: Always buy more capacity than you think you need, no matter what the vendor says (a little room to grow). Some IBM i business partners like to make those add-on sales a year or two after the original sale (or sooner, in this case). They look at you as a revenue stream they can cash in on before the machine’s usual life-span ends runs out (usually three years).

In the IBM i world, I always contact Midrange Performance Group (MPG) when I’m involved in an upgrade. MPG offers a service where it looks at your performance data and helps you size your new machine, complete with projections for growth. And MPG is pretty objective about it, as they don’t make any money if you buy more hardware. Once you get MPG’s recommendation, you can compare it against what the business partner is telling you and ask intelligent questions.

And since it’s difficult to get competitive quotes on IBM power systems, it’s worthwhile and not that expensive to bring in an outside source like MPG to do a once-over on your proposed machine to make sure that you’re not over- or under-buying hardware. I highly recommend you bring in that second set of eyes before you sign on the bottom line. The small amount you pay someone now can save you thousands of dollars down the road.

Getting back to my first example with the undersized box and the sad president who couldn’t fire his programmers, somebody did indeed get fired: the person who handled the purchase. Luckily, it wasn’t me.

The case of the bonus-blinded vice-president

A second case occurred when we were migrating our ERP software from an old no-longer-in-production system to a new shiny ERP implementation from one of the big ERP vendors. We hired an “expert” who was supposed to get us through the implementation, especially preparing the company to handle the new slicked-up software. As we were approaching the planned January 1st cut over, the managers involved in the project became increasingly vocal that we just weren’t ready and (as was their duty) proclaimed that we were in for serious problems if we cut over as planned.

The Senior VP in charge brought us all in a room, screamed at everyone, and threatened to fire the next person who said we weren’t ready and wanted to postpone. We cut over on January 1st and it was a disaster. We couldn’t ship product, we had trouble billing and posting orders, and it took three months to straighten everything out.

The rumor was the Senior VP had his yearly bonus riding on cutting over on January 1st, which prompted the ultimatum. As expected, a number of somebodies (but not the VP) got fired. Along with some of the other dissenting staff, I got a layoff notice three months after the go-live date.

Morale: be careful when dealing with deliverables that occur on a fiscal year-end or quarter-end date. There may be a personal agenda item interfering with the project deliverable. And even when you’re not ready, if the boss says you’ve got to deploy, you’re probably going to deploy.

Blunting the damage

The important things in these situations are the following:

• Make sure management knows what they are getting into. It may get you into hot water to speak the truth but if you know a disaster is about to occur, as a manager you have a duty to speak up about it and let others know. Document what’s coming so those who have to deal with it are prepared and upper management will at least have a heads up.
• Find your plan b – Come up with your contingency plans for what ifs. What’s your disaster recovery plan. Who are the people who are going to have to deal with an implementation gone bad and what workarounds can you offer? Be prepared.
• You may not have caused the ERP disaster but you may get blamed for it. This gets back to your fiduciary duty to speak up when things are going bad. If a management-induced disaster is about to come down on your head, at the very least you should document it and your role in trying to avert it. It may be helpful when the search for scapegoats commences.

All is not lost, however

All of which brings me back to Dan’s article. Yes, putting in a new ERP system is a scary proposition. But it can’t be postponed forever and it should be approached as a company opportunity, not a hair-raising event.

Saying that, ERP system migrations are extremely difficult because a) the old system has been in place for a long, long time; b) the old system has been modified with thousands of custom modifications, in effect making it a killer application that has been tuned to the company; and c) it will be extremely difficult to recreate all the procedures that the old system employed on new software on day one. Item c) is the one that will get you.

There are some things I believe you can do to soften the blow. One is to consider a slow migration to the new ERP system rather than a hard cut-over. In your project plan, you can consider migrating certain sections of the software over to the new hardware first before you take everyone over. Maybe you can do your financials first and then provide links to pull data out of your old system over to your new system. Ask yourself and management, which departments/functions can function as the trailblazers that can go first and if there’s a failure, will limit the damage a botched implementation will cause?

Once your trailblazers are migrated, you might consider doing another self-contained area and then another until everyone is migrated over. The issue you will run into is that you’ll have to write put in data interfaces to the old system one at a time, but you’d have to do that anyway to get all your data to the new system.

Doing a migration one department at a time is what I call an “ooching” implementation: where you “ooch” (ease) into the new system a little at a time. By not providing a big bang cut over, you can concentrate just on the areas that are going live now, and work on the other areas later.

As my examples show, you have to be careful with vendor promises and executive overreach because the reality may not match the expectations. And many times after that, somebody gets fired. The best defense is to work with management to come up with a reasonable plan for an orderly migration, keep all management (not just the sponsors) appraised of what’s happening, plan for both the best and the worse, and then let the chips fall where they may.

Take what vendor says in stride, and try to temper management expectations on oversells and rushed implementations. Consider other alternatives because the job you save can be your own.

(First published February 2012. Updated and expanded February 2014)