Step One

Step One

Organizations often make a false assumption as they approach the start of a Business Impact Analysis (BIA) or recovery plan building: they assume that staff members can define the business processes that they are engaged in as part of normal operations.  The truth is that many people struggle to define the processes that they are regularly engaged in at the proper level, despite being part of an organization for many years and performing in the same role for a long period of time.  A process inventory is an essential prerequisite for a BIA or for plan building.   Failing to define processes at the appropriate level will yield inaccurate BIA results and could result in the creation of ineffective recovery plans.

The most common error in defining processes is the elevation of the individual tasks that are involved in performing a process to the level of a process.  If tasks are defined as processes, subject matter experts will have challenges identifying impacts at such a micro level of activity.  When processes are defined at excessively high levels of operation, the impact of a disruption can be exaggerated as all activity at such elevated levels is inflated.

Plan building is similarly problematic when processes are not properly defined.  Plans scoped at task level may fail to account for the complexity of operations and risk not identifying critical aspects of the recovery.   Planning at upper levels of the organization can result in over-sized plans that are difficult to execute and impossible to exercise effectively.

Prior to the start of a BIA or recovery plan building, business continuity leaders need to provide guidance to those identifying processes.  It’s more than just providing a working definition.  A means of comparing activities thought to be processes to the known attributes of a process is needed to establish a method of validation.  The activities being evaluated need to find similarity with what we know to be true for all business processes.  If there are difficulties in identifying the aspects of a process in evaluating an activity, it is unlikely that the activity is truly a process.

Providing BIA participants or planners a real-life example may help to simplify things.  Consider relating a familiar life experience to process identification.  Most people have spent time shopping online for auto insurance.   We go to websites for insurance companies, complete a request for a quote, and compare.  Providing auto insurance quotes is a business process.  The process is triggered when we complete and submit the online request form.  A series of coordinated activities follows:  Our data is compared to risk rating information.  A driver’s license history is reviewed.  A credit report may be run.  Our address and contact information may be validated against known sources.  A quality assurance check may be conducted.  All these activities are standardized and documented.  The result is the value item – the thing we as potential customers of this process desire – the quote.  Analyzing this example helps us to catalog the attributes of a process:

  • Processes are triggered by an event or action.
  • A process is a coordinated series of actions.
  • Processes have inputs in the form of resources such as data or work effort by staff members
  • Processes have standard procedures that are followed to ensure that they are properly performed. There is often training required to properly perform processes.
  • Processes create a something of value for a customer/client.

The coordinated activities typically result in a transformation.  The transformation may be to a tangible product or to data/information.  The result is the value desired by a customer/client.  As we assist in identifying processes properly, it is typically the inability to pinpoint the customer/client and the value generated by an activity that will effectively separate processes from tasks or procedures within the scope of a process.   The trigger/event that directly initiates the process will be particularly difficult to isolate in instances where a ‘process’ has been defined at too high a level of operation.

Adding process identification to the start of the BIA or to plan building will increase the time required for the project, but it is a prerequisite.  The time spent to properly define processes is still shorter than the time it takes to redo the BIA or to restructure the scope of recovery plans.   Taking the time to inventory processes properly is the business continuity equivalent of measuring twice to cut once.