- Prioritizing Processes Effectively
- Defining the Recovery Time Objective
- Understanding Recovery Dependencies
- Dependencies
- Resource requirements
Welcome back to our series on business continuity.
In this blog, we’re diving into the key understandings we need to build around our processes to be able to formulate an effective business continuity plan (while wishing never to have to use it).
Let’s have a look at the logical process needed to formulate a business continuity plan.
Essentially, you need to think of the set of requirements for your business continuity plan. You’ll start by looking at the work that needs to be done. Then, you’ll break that work down into individual processes — automated or otherwise.
Once you have that overview ready, the first thing to do is to look at how critical each of those processes is and put them in some sort of priority order.
Prioritizing Processes Effectively
Various factors can be considered in the prioritization exercise. We could have commercially agreed SLAs with severe penalties attached, regulatory SLAs or dependencies of events.
You’ll want to make sure you have a clear view of:
- What is all the work that the organization is accomplishing or automating?
- Are we clear on the priority order for those things and how long can we go without them?
That is what the Recovery Time Objective (RTO) is.
Defining the Recovery Time Objective
An RTO of one hour means we’re experiencing unacceptable consequences if, after an hour, we’re unavailable to perform a process.
This tool can be useful when having conversations with business leaders.
Often, someone might say, "We have 75 FTEs worth of work going through SS&C Blue Prism." This can make people nervous, thinking, "What if we have a problem? We don't have 75 spare people to pick this work up."
Of course, you don't, or you wouldn't have realized any benefits. There would be no utility in automating anything if all you did was move work around and incur additional costs from technology.
Talking about workload in terms of recovery time objectives helps facilitate recovery.
Example scenario
You have 75 FTEs worth of work being done by your digital workers. Ask yourself: Is all that work of equal value, priority, or weight?
You might need process one within two hours, process one and three within eight hours, but not all processes back online until 24 hours.
This exercise helps plan for keeping the lights on rather than achieving the optimal outcome, providing some wiggle room.
Understanding Recovery Dependencies
Recovery dependencies consist of two things:
- Dependencies
- Resource requirements
Dependencies
Dependencies include the minimum technical requirements to perform the work, such as, but not necessarily limited to, data accessibility (digitally or as a backup in paper format) and access to systems or locations where the work needs to be performed.
There could be several ways to handle dependencies, from optimal to acceptable:
- Do you have data accessible digitally?
- Do you have data accessible as a backup in paper format or similar?
- Have you got access to the systems or locations where the work needs to be performed?
The optimal way might be to have digital data access and systems access. An acceptable way might be using paper data if digital access fails.
Systems and data are recurring themes to consider.
Example scenario
If process one is all about entering data from a CRM to a mainframe system, you need access to that data in whatever format it is available.
If the CRM isn’t available, you may be able to fall back on paper data (if available), which, while not optimal, is acceptable.
Of course, systems and data access are not the only dependencies you’ll ever encounter, but they’re recurring themes you’ll need to consider across most processes.
Resource requirements
On the other side, you also need to consider resource requirements.
Resource requirements involve ensuring you have the means to perform the process. In our context, the means will be your digital workers.
However, the business event you’re facing may mean they’re not available or may not be available soon enough to meet your SLAs.
That’s why you also need to determine the number of FTEs needed to perform the work within the SLA, leveraging internal staff or subcontractors.
In short, you’ll need to answer the following questions:
- Can you put your digital workers back online soon enough to meet your SLAs?
- And if not, what other alternatives do you have and how many people does that represent?
i. Do you have internal people that you can spare for that?
ii. Do you have subcontractors or freelancers?
At this stage, we now understand the nature of the individual processes to consider in our business continuity plan. We also understand the critical order and the maximum recovery times around them and we know what things need to be true to get us back operational.
That’s your business continuity framework.
And since we need to get a little bit more granular to formulate our detailed business continuity plan, we’ll dive deeper into formulating the complete business continuity plan and enacting it in our next blogs.
