“The issues we’ve run across so far make this ERP selection/implementation look ridiculous. Does everyone go through this? What are we doing wrong?” You’re probably doing nothing wrong at this point but had you done it “right” from the beginning chances are those questions wouldn’t be asked.
Why are we talking about Risk Mitigation and Issue Mgmt? Because going all the way back to our first post on ERP replacement and beyond, we discussed the risks inherently involved in a selection and implementation and now we’re looking at those potential risks and issues in a little more detail.
So what’s the difference between an issue and risk? Risk is a known possible problem and we’ve identified corrective action if/when it occurs. An issue is an unexpected problem that comes to light during the selection/implementation. Therefore an issue pops up along the way and there’s no identified corrective action step until it arises. Once it arises, then of course it must be addressed.
There’s four steps to employ when an issue is raised:
- Define the issue – people, process, technology or 3rd party
- Prioritize and assign – When does it need resolution? Who is assigned to resolve?
- Analyze – Possible solutions? How important is it to the affected process?
- Resolve & Integrate – Install/implement the fix.
By having a methodology on issues and risks, it provides people with the assurance that when problems occur, the project will stay on task and on target. At the same time, many projects turn into a constant battle of risks & issues. Obviously this statement is a “hindsight” type comment, but if this occurs, the project was messed up from the beginning.
People often want to hire “consultants, experts, etc.” AFTER it gets messy. Quite frankly, it is much better to hire expertise sooner than later. You can always let them go if the project is going well. But once it’s messy, the “experts” SHOULD go back to the beginning and re-trace the steps and processes. If they don’t that’s a clear indication of just taking your money and continuing a bad selection/implementation.
They’re called many different things by different groups but a “process optimization review, operational assessment, business process optimization, etc.” would virtually eliminate much of the headaches during the selection/implementation. We’ll look at it in more detail in upcoming posts.