A continuation of an article published last time.
This is another one of the biggest causes of the owners/management causing the demise of their own ERP projects.
Most proponents will state that going parallel is the safest way to ensure that if the new system doesn’t work, you can safely go back to the old system and not have any loss of data.
This sounds really good on paper, it’s actually abominable in practice!
Here are a couple of reasons why:
- Not enough time in the work day for the user to do twice the work. Imagine your work day, now do it twice with the same amount of time. Notwithstanding the time restriction, you’ll also be bored as out of your mind. Twice.
- The process is different from the new system vs the old system. When you implement a new system, processes will change. Keeping 2 separate processes using 2 different software systems will confuse the crap out of anyone.
- If anything is missed, which there always will be, reconciliation is a nightmare. Oh your number is off by $89.42? Good luck finding that.
- People will always work in an environment where they feel safe. Not because the old system is better, but because it’s familiar.
From my experience, when companies go parallel, they fail.
BURN THE SHIPS
In 1519, Captain Cortes told him men to “Burn the Ships” after he landed in North America. He knew that if his men (and himself probably) had a means to go back, they would not be committed on giving their all to survive in the new land.
The same thought can be applied to your ERP implementation. Telling your people that implementing a new ERP is important, but give them an option to do things the way they did before, they will always go back and do things they feel more comfortable.
Now you may be asking “but Alex, what if the new system doesn’t work?” The answer is simple, don’t go live until you’re ready. If your preparation is crap, you will fail anyway.
The next question you may be asking is “but Alex, what if we encounter problems with the new system?” There’s no instance where there are not problems when you go live. As long as you make proper preparation, the problems that arise should not be major. Any competent Dynamics 365 Business Central (AKA Dynamics NAV) partner or developer should be able to knock them out quickly.
Before you burn the ship, it’s your job to ensure every business process can be, at the very least, replicated in the new system. This is part of your preparation before going live.
Having a smooth transition to a new ERP software can’t be completed with just thoughts and prayers, it needs meticulous testing, simulations, and feedbacks.
Be aware that it’s not going to be 100% smooth when you cut over to the new system. There will always be problems after go live. The important things are the major known kinks are resolved.
There shouldn’t be an instance where major problems that comes up when you turn on the switch, then someone seriously messed up.
Take the page out of Cortes’ playbook. Burn the Ships. Have your people focus all of their attention and resource into making the new software work in your organization.