You did it! Breathe a sigh of relief — you made it through go-live, and your new ERP system is up and running. Now it’s time to tackle what to do after go-live. Even though you may want to call this project “done” and move on, the work isn’t over. The first few weeks after going live, it’s critical that you stay vigilant and nip any issues in the bud. Let’s walk through the hyper care process and document some things you should expect…
Data migration issues — the first wave
People are surprised at how quiet the first week after go-live can be. If you did all your testing and gave yourself plenty of time and CRPs, transactions should be flowing through your system without a hitch. The first thing you might encounter are data migration errors. These usually happen because business users have only interacted with the old, migrated data before, and any issues that existed could throw errors in the new system. It’s important to clear out these data migration errors first, before too many pile up.
It’s impossible to test every possible scenario prior to go-live. The second wave of issues you might encounter are the outliers — one-off scenarios you didn’t have time to test. These are to be expected (after all, you have to go-live at some point, right?) As users start adding new master and transactional data, these corner cases become obvious. The intersection of data and business processes can create unique, unexpected situations. If your project team handles these cases as they appear, you should be fine.
Helping new users
You’ve conquered any migration problems and taken care of the corner cases. The last thing to look out for are user errors. We consider these issues the most dangerous because if they aren’t dealt with swiftly, user errors can snowball into an avalanche of problems that affect the whole organization. For example, an employee from merchandising might forget to associate the cost for a new product. The warehouse then receives the product at zero cost, and now the fix requires several financial transactions and lots of time. During this time, speed of resolution is key. If errors are being created faster than resolutions, that’s a problem. Your project team and your organization’s power users should work on clearing out these errors and reinforcing best practices among the rest of organization.
Avoid the “Valley of Despair”
The Valley of Despair is when your ERP’s performance drops dramatically, shortly after going live. Users might get frustrated, disappointed, and wonder if the project was even worth it. Guiding users around this metaphorical valley of despair is why your project team should stick around a little longer. The real benchmark people should focus on is closing the first financial period in the new system.
Frequently asked questions
Data migration errors, followed by special cases regarding business processes, and user errors are most common.
Closing the first financial period in your new ERP system is a common benchmark to use.
Assessing go-live readiness is an art and a science. Businesses are complex—and it’s impossible to test every single scenario and stay on schedule. It’s to be expected that some special cases will reveal themselves in the first few weeks after go-live.