Overview
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.
Going Parallel
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.
Preparation
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.
Conclusion
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.
We used parallel because we didn’t have confidence in the build quality our consultants did on business central. I agree it caused a lot of problems and work for everyone.
But seeing as to how much worse our work would have been if we stuck with only BC.
Reports were not printing correctly, the invoices were working but spitting out rounded numbers by line which would charge customers a extra thousand per invoice. Top it of with hour long talks with our consulting group to fix said problems only to see them searching for answers via online forums and charging high fees for it.
This is the result of poor preparation for the implementation from the consultant. If there’s no confidence from the build your consultants gave you, it would’ve been better if the project is delayed until you have that confidence.
Agree that fully parallel go-live is a disaster waiting to happen in ERP (may have it’s place in much less complex but more safety critical systems)
However, something very similar is sometimes very useful in ERP. Basically you parallel run for a day with the ‘new system’ but in a test environment. (kind of like an enhanced UAT)
It’s especially useful in production or warehousing environments where there currently isn’t a computer system in place at all, it serves to prove the system really is up to the pace, complexity and physical constraints of real operations and provides real-world training for the people who are actually going to use it. It’s a limited amount of time so you can put up with the extra work for a day or two.
The key thing is that the database they’re ‘parallel running’ in gets thrown away at the end of the test, and there is still a real go-live where the old ‘system’ is turned off completely!