How to Develop an ERP Failure and Recovery Plan

ERP failure recovery plans are just that; sets of tasks that turn a system around when something goes wrong. While there are templates available that are useful as baseline plans, each enterprise and each ERP implementation is different, so your own plan will require a fair degree of subjective thinking. When looking at what ‘may’ go wrong, it’s useful to operate on the basis of preparedness driven by a worst case scenario first, and work backwards.

Define the Threat

Define your worst ERP failure nightmare, i.e. the entire system has dropped offline, but production must continue to function; then step through the various tasks necessary to re-light, or reload data in order to cover production first. Then step back to ancillary processing like invoicing and accounting, then extend further into other administrative systems.

Be critical of your thinking and make sure you make the right decision when prioritizing business functions

As I said, each enterprise is different, so perhaps, if this scenario occurred in your business, invoicing would be the crucial first-step instead. Be critical of your thinking and make sure you make the right decision when prioritizing business functions, otherwise you’ll be looking at the wrong thing at the wrong time.

Create a Failure Tree

As a practical matter, creating a recovery failure tree is essentially driven by the specifics defined in the previous section of this article. But in general, your business should follow these steps:

• Define a communication plan
• List the people who must be contacted if a problem occurs
• Create instructions for responding to the problem based on resources associated with each effected impact area
• Create instructions regarding who will administer each part of the each recovery task/area
• Develop specific task checklists for every scenario
• Insure that responsible managers or workers review each task/area, and sign off on each checklist as it is completed

Granular Is Better

In the case of most ERP failures requiring a recovery process, time is the enemy. Consequently, the aforementioned failure tree should be as detailed as possible insuring that any/all impacted processes/systems/people are identified, and what your employees are supposed to do in the event.

Build a Practical Response List

This section is really the heart of a recovery plan, since the systems are unlikely to fix themselves without human interaction. Consequently, when it comes to stepping into the breech between an ERP systems meltdown, and safety, the best part of valor is to ensure everyone on the team is identified and notified. The same sentiment covered in the previous section, where granularity is king, applies here. If you ‘think’ an employee should be on the list, make sure by checking the response list twice, then review the list on a regular basis to ensure relevancy and accuracy.

Fight Like You Train

The military offers a number of useful axioms that can be leveraged when in dire straits. One of my favorites is ‘You Fight Like You Train,’ meaning that you can learn a lot by repeatedly testing your recovery plan ‘just in case.’ Executing this kind of evolution offers at least two bits of highly practical knowledge.

Recommended Reading: ERP Implementation - 11 Steps to Success

Firstly, in testing the plan throughout one or more emergency scenarios, the ERP team will become desensitized to the deep nature of the task list, and if/when the balloon goes up, it will respond much more efficiently than it might be if it had never seen the worked through plan before.

Secondly, as my Southern descendants used to say, the team would also afford the ability to ‘lose its scared’ before the actual event, making for calm decision-making under tremendous pressure. I have used both of these elements in my own actual recovery experiences, and they work.