The importance of a cloud ERP recovery plan

Cloud ERP systems are both powerful and flexible, however, there is a fly in the ointment associated with this particular delivery platform. Many enterprises believe that SaaS products take the ‘worry out of worrying’ since the enterprise itself is ultimately positioned downstream within the overall ERP process dependency chain. Consequently, many believe that with all of the data processing work taking place in the cloud, a company can divest itself of responsibility for premise-based systems concerns, particularly if something goes wrong or a cloud ERP recovery exercise is needed.

While this may be true in some of the “all-inclusive” SaaS pricing packages, the fact is that cloud ERP should provoke more concern within ERP managers rather than less. With data servers located miles away, it is difficult to take direct control of any irregular systems event other than what one can observe on a monitor, or communicate with a disembodied voice on the phone. To make things worse, due to the grandeur of the 21st Century, that voice may not even be in the same country/timezone as the one your enterprise operates in.

Disaster recovery beyond your control

So let’s consider the implications of these practical potentials for a moment. Before you down your entire tallboy of Jack Daniels in one gulp, you should begin to think about cloud ERP disaster recovery; ‘what would happen in the event, and how would one continue to operate until one’s systems problems are resolved?’

Recommended reading: ERP implementation - 11 steps to success

With on-premise systems, traditional sets of recovery solutions are tried and tested; starting with getting hold of your IT team (or screaming for help down the hall), followed by asking how recent your ERP backups are. However, with cloud ERP systems, aside from yelling on the phone at ‘someone somewhere’, most system fixes are beyond the control of the enterprise team itself; which is where the crux of the matter known as disaster recovery testing comes in.

Measure twice, cut once

As the hoary old saying goes, “measure twice; cut once,’ and in the event of a failing cloud ERP system an understanding of that homily could not be more crucial. Take a minute and think about what one ‘might be able to do’ in that event, but more importantly what one ‘might not be able to do’.

For example, if your entire enterprise revenue stream is cloud-managed by an ERP raw-materials-to-finished-goods manufacturing system, and each link in that chain is dependant on all other processes from input to output; when one’s cloud ERP goes dark, one’s business is dead.

Once you are happy with your cloud ERP recovery plan, it is important to run through failure scenarios on a regular basis

Granted, there are ways to manually break the integrated systems chain apart and function in a limited fashion until whatever issue can be resolved. But this can only be achieved ‘if’ (and this is the big ‘if’) you have previously tested one or more failure scenarios with your cloud provider. Understanding the process of disaster recovery with external processes and input is essential for developing a cloud ERP recovery plan.

So, at the end of the day, the only way to be sure of your response to a Category 10 technological calamity is to test with input from your cloud ERP vendor, and test again, and then test once more. Once you are happy with your cloud ERP recovery plan, it is important to run through failure scenarios on a regular basis because if the balloon goes up, you are likely to only get one chance to respond correctly before the enterprise implodes. Think of it this way; it's your business riding on one failed virtual ERP module, fully-corrupt distributed database, DDOS hack, power surge, WAN router/gateway failure, CLEC crash, snow storm, hurricane, mudslide, tornado, flood etc. so why worry, right?