jump to navigation

ERP Planning – A good meeting 03/25/2009

Posted by TBoehm30 in ERP.
Tags: , , , ,

What order and what modules should we implement first so as to phase in the new system?

ERP implementation planning is still going on. We are still trying to figure out that all important question of how to phase in the ERP system. We still need to agree on our approach to implementation.

The Company needs accounting and manufacturing, that much is known. There are 4 business units, that don’t share data but need to. Our basic idea is to split accounting and manufacturing. We’ll implement accounting first, and when that is complete for the 4 business unites, we’ll come back to manufacturing.

We had a really good meeting today. In this meeting we basically agreed on that approach. Hooray.

The first hurdle was defining what constitutes accounting. It could have just been the General Ledger (GL), but that would not have done much for the Company. We also included Purchasing, Payables, and in some cases Sales Orders, and Shipping. This means that we’ll have to have some inventory functionality as well.

Having inventory means that if the business unit has a manufacturing system (not all do), then we will need an interface. Interfaces make the project more complex. We have 2 different vendors to deal with in making the systems talk to each other. Ok – we can schedule that in the plan, and go manual if we have to.

It also turns out that 1 of the business units already has an integrated manufacturing and accounting package. They were not able to easily split the 2 functions since they are joined so well today. We decided to implement that business unit as a big bang – both accounting and manufacturing. They will be the last accounting system to go-live, and the first manufacturing system.

Yes, it was a good meeting. Decisions were made. I like it when decisions are made.

ERP Implementation Plan 03/16/2009

Posted by TBoehm30 in ERP.
Tags: , , , , , , ,

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.