Within the business continuity management lifecycle, a business impact analysis is a fundamental and important activity for a business continuity professional to carry out at defined intervals. But before jumping into a business impact analysis, one of the most important steps is to determine the level at which one will identify business processes, capture data, and engage subject matter experts of a business processes. This is a challenge for many practitioners performing a BIA for the first time or after a significant organizational change. Let’s explore what the optimal business process level to approach BIA and how to gather meaningful data that will bring value to the management.
First, let’s start with a few definitions:
- Business Impact Analysis: Process of analyzing business processes and the effect that a business disruption might have on them. A BIA helps practitioners to identify critical business processes for their organization.
- Business Process: A set of interrelated or interacting activities which transforms inputs to outputs. In other words, a description of work that is performed to accomplish the specific business requirements of the organization.
- Critical Business Processes: Activities and operations or a set of activities that cannot be disrupted or be down for more than the tolerable and agreed-upon timeframe.
- Business Unit: A logical higher segment of a company (such as human resources, finance, research and development, manufacturing, etc.) representing multiple business functions.
- Business Department: Specialized functional area within a business unit, such as treasury, tax, accounting, information security, risk management, etc.
There is a danger to approach a BIA at a department level as it is too high of a level to capture criticality and measure the impact if the department was disrupted or lost. With this approach, important data such as critical dependencies might not be captured fully because the subject matter expert for this level is too high for a manager or above compared to the subject matter expert performing day to day activities. Also, impacts would be incorrectly measured with no way of knowing what order processes within that department need to be recovered first, if at all, in case of disruption as data would be too vague.
There is also a risk of approaching a BIA in a granular approach where the process is being broken out to activities or tasks. In this scenario instead of performing a BIA for one business process, there are 5 activities or tasks captured for a BIA. This approach can lead to capturing too many details which would be repetitive for all 5 activities or tasks, overwhelming and exhausting to the subject matter expert, which can lead the interviewee to associate business continuity with a negative experience.
It is best to approach a BIA at a process level as shown below.
This graphic shows the appropriate level to do a BIA targeting level 3 – business process, which represents inputs transforming to outputs. For example, in the finance business unit there might be multiple departments such as controller, treasury, financial planning, and analysis, and within each department there might be one or more business processes, and within each process, there will be activities and tasks that process will have to perform to complete its job. For this example, let’s focus on controller department, within which business processes that could be included are accounts payable, accounts receivable, indirect purchasing support, accounting, and payroll. A BIA is performed for each of those business processes and not their activities or tasks.
Performing a BIA on the third level provides an opportunity to identify enterprise processes, measure impacts at critical points in time, capture the criticality of the profile, perform operational risk assessment, and capture all the required resources needed for the recovery of this process, including but not limited to applications, vendors, internal process interdependencies, equipment, and resources.
Results from this level of BIA reporting will produce meaningful data such as uncovering process recovery time objective, stack ranking most critical to below average processes that can be deferred during a disruption, the basis to perform gap analysis, and base to develop an appropriate recovery strategy for a specific process. Sometimes there is an opportunity to consolidate a few business processes into one business process if those processes are:
- Similar in nature and executed by the same subject matter expert or team AND
- Perform interchangeably with the same impact to the organization, same recovery time objective if disrupted, and the same resources required (such as equipment, applications, etc.)
Otherwise, business processes should be addressed with a BIA individually.
3 ways to identify processes on level 3 are:
- Ask the process excellence group that might have started the process already.
- Work with human resources to utilize the organizational chart.
- Perform a process discovery and become the source of enterprise process data.
Once the process level at which the BIA will be performed is identified, the next step is to identify actual business processes and carry out a BIA questionnaire with subject matter experts. To improve your data quality and user experience, learn more about redefining your BIA questionnaire.
If you would like help with identification of processes for BIA, or performing BIA activity for this year, Fusion can help you. Learn more about our advisory committee, Fuel.