ERP Implementation Plan

Big Bang or Phased Approach
I firmly believe in the phased in approach to implementing large software systems.

When I was working with HP, it split off part of the company to form Agilent. Part of Agilent got bought by Philips. Suddenly our group had to get off of systems run by HP because we were now competitors. We had no choice but to go big bang. Even then, the project was delayed over a month paying big bucks to HP for the privilege.

Doing everything at once meant that the new system experts were spread very thin. They were needed for all problems spread over multiple departments. If there were problems, it was more difficult to find the root cause because so many different activities were going on. It meant that the new system had to accommodate all of the new users at once, and we could never see how the system looked with fewer people.

The Plan
Now I’ve got to guide the choice on how to implement a new ERP system. The company is going to use it for accounting and manufacturing. There are 4 distinct business units in different cities. I am going to suggest going with accounting first at all locations, and then merge in manufacturing as they are ready. Much of the plan can be done in parallel because the personnel for the different functions are separate.

There are so many questions to answer in creating that plan. How much is the minimum time a phase will take? How many business units can run in parallel? How many people will we need to be systems experts at each location? If we stagger the go-lives, how quickly can we set them up? How much testing is necessary before go-live? How many people will we need for the pilot projects?

We have talked quite a bit about the possibility of running the new system in parallel with the old system. The company has a history of successfully running their upgrades in parallel until they are confident of success. The customer we visited who were already using the new ERP system told us that running parallel was key to their success. My research tells me that running parallel is no longer done.

Running in parallel is where you use both systems for production data during a specified time period. You then compare results from the new system with the old. If they match exactly then you have confidence that you can turn off the old system. If the data doesn’t match, then you have to figure out why. Running parallel is too expensive, too time consuming, and doesn’t add enough value. The results are difficult to compare for different systems. There is too much data to control, where some of the new data wasn’t used in the old or vice versa. Too many people won’t take the new system seriously if they still have the old one to use.

The project plan for the new system will include several ‘conference room pilots’. These are what will replace the process of running in parallel. Hopefully, that will be good enough for this project. It will require serious testing, and significant follow through with any issues.

Next Steps
The project manager from the vendor will be here on Wednesday. I hope that we will be able to setup a timeline then. That is when the interesting stuff begins; because it’s a global world out there and Technology makes it happen.