次の方法で共有

People Make ERP Projects

  • [アーティクル]

 

As part of my job I work with customers and help them with their ERP project implementations around Dynamics AX. An ERP project is a complex project. You have so many different dynamics (excuse the pun) that you need to manage. Business needs, regulations, training and understanding software, resource management, corporate politics, and probably the biggest being communication and change management.

Some of the projects I enjoy working on happen to be the biggest and most complex and if the project is run right can actually be a fairly peaceful and enjoyable experience. I'm not saying trouble free, all projects have un-expected issues. But with the right planning and management the troubles will be small detours as opposed to road blocks.

I thought I would start to share my thoughts and observations on running and ERP projects in a series of blogs posts. Now I'm not saying that I'm going to write out a manual but provide some insight if you are looking to embark on an ERP implementation project.

First and foremost an ERP system is a system that collects operational data in the course of executing business processes, data collected is used for decisions support. There would be no need to implement an ERP system if people didn't need the data, it's a tool and you have to keep that in mind.

People implement ERP applications. The effective relationship between management, system consumers, project team, external software consultants, external business consultants and software vendor is what makes a project successful.

The Need

If you are going to implement a new ERP system then someone has made a decision to do that. It might be one person, the CEO, CIO, CFO. Sometimes these are some of the best projects as you have exec involvement form the beginning. Usually the exec doesn't decide on their own, there would have been an initial instigator maybe from operations, maybe from finance, maybe from sales. Someone would have been fed up enough with dealing with inadequate data that hindered their role that they raised the need and probably got support from other department leads.

This is an important success factor "Why are we implementing a new system?". It's important to keep clear goals. If the decision to push a system through comes via someone thinking it's a good career move just to change systems, usually the project doesn't go well. There needs to be clear and agreed motives for improvement that the whole organization supports. Without that you shouldn't embark on an ERP project.

Projects that don't go well come from organizational conflict before the decisions is made. For example operations needing new systems but finance is happy with their systems so don't want to change, or vice versa. If the groups don't agree from the beginning then the implementation team is not going to get the right level of support.

Let's start from the beginning and I'll break these down in latter posts.

Requirements Gathering Before Sourcing Software

You need to be clear on what you want. Often the timeline determines if you rush this step or skip it all together but in my opinion you need to be very clear on what it is you really want to do before any thought of software selection. This is consumer behavior mixed with organization behavior.

Think about yourself buying at that new tablet computer. You might spend a while thinking you need one because you commute to work a long distance. You spend some time and understand their features and realize additional tasks you could do with it. Once you understand what you will do with the device you starting comparing options based on what your needs are. On the other hand you might just say I saw Steffan with a new TabletXY I'm going to get one of those. Once you get it you realize that it doesn't have a good book library and that was what you really needed.

Organization behavior follows the same pattern but you just need to involve a lot more people to understand needs. When it's yourself you can make a decision quickly. In an organization that is too bureaucratic this could be a hindrance to making a fast decision.

The point being, don't go looking at software until you are sure of what you need and that you can manage the organization efficiently to understand the needs. Now I've certainly seen examples where the impulse decision was made to buy a software package before any requirements gathering was really done. But this only works if there is a really strong and cohesive management team with very strong IT development and support skills in-house.

Additionally by gathering initial requirements before any software evaluation will put you in a better place to plan the implementation project, define scope, timelines, resourcing etc. During this phase you should also do an assessment of your organizational capabilities. Some things you might want to ask:

  • How fast do we make decisions as an organization.
  • How well do we deal with organization conflicts.
  • How well do we deal with cross-organization decisions making.
  • Do we have the project management skills in-house.
  • Do we have development resources in-house.
  • Will the systems stay on premise, or will you engage a hosting company to handle the infrastructure.
  • Do we have enough business capacity from functional domain experts from finance, operations, sales etc. can they be dedicated to the project for an effective amount of time.
  • Do we have change management skills in-house.
  • Who manages our existing systems? Will they help move to a new system, usually not without a cost.
  • Is their management or board level support for the project.
  • Are their trading partners (suppliers/vendors) going to be affected by a new system.
  • Is there an appropriate business cycle/timeframe that will cause the least disruption.
  • Is there organization change coming. Mergers/Acquisitions, new product lines, geographic expansion.
  • Do we need to downsize operations, do we need to upsize.
  • Do we need to move resources because of changing business environment.
  • Will the decision to move to a new system cause people to leave the organization. Is there a need and a plan to keep that knowledge.

Now a word of caution. Don't spend too long on this. I've seen projects that had a real need for a new system but they spent so long detailing requirements, the organization collapsed under the weight of legacy systems the company was merged/acquired or management changed and the project was stopped. It's a balance which you need to work out for your circumstances.

Software Selection

So you have a basic need and you have some knowledge of what that system should do. They next step is to find the right tool. Now this could be a book in itself of process or large system selection and I'm sure there are good books out there. For the purposes of what I set out to do here I just wanted to touch on a few points.

When you talked to the software provider understand if they are selling the software directly (they developed the software) or are they are a services/distribution company for the software. They key here is you are going to have to A. buy software from someone. B. Lear and Implement the software. C. Support the software.

So while features and functionality are important, equally important is the organization supporting the software. Their software might be the best in the world but if you can't get someone to come and help you implement it's not going to be helpful. Vice versa if the software doesn't have all the features you need but the software provider is willing to work with you then you can overcome these.

The point being, the two go hand in hand. You need to know where the balance is in the software you have selected and if you can structure your implementation team to overcome which ever imbalance you perceive for your organization. Some things to consider :

  • Will we resource the project internally, if so how can we get training on the software.
  • Can the software be customized and does it have development tools.
  • Do we have development resources internally, can they get training.
  • Who will manage the infrastructure, do we have to manage it or will the software provider.
  • If there are features we want improved will we take them on with our development resources.
  • If there are features we want, will be software vendor add them for us.
  • How long do you think your project will run, how long will the software provider support a specific version. Is that longer then you think it will take to implement and roll-out
  • If the software provider is selling direct do they have implementation resources. Do they have a support desk.
  • If the software provider is selling in-direct do they have support/implementation resources, are they supported by the software vendor. Can you get direct support from the software vendor.
  • Will we staff the project internally but augment the staff with external independent consultants. If we do this can we get review services from the software provider.

Decision Made

You made a decision on software now what? Now you have to build the project plan and start to look at resourcing. In the next blog I'll start there by describing the different actors and project phases.

Cheers

Lachlan

(Original blog https://blogs.msdn.com/lcash)