BIA Alignment? We Don’t Need NO Stinking BIA Alignment!

Michael Herrera

Industry best practices recommend that the BCM Office align its organizations Business Impact Analysis (BIA) derived Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) with Information Technology Disaster Recovery (DR) capabilities on a regular basis.  So, here is what are we finding in the industry:  

  • Management does not understand the alignment process and does not recognize its value.
  • The business and IT have different RTOs and RPOs matrices so the alignment process can be somewhat difficult to accomplish.
  • IT does not provide Recovery Time Actuals (RTAs) or Recovery Point Actuals (RPAs) for the critical systems and applications.
  • BIAs are conducted and RTOs / RPOs defined by the business but IT still sets its own timeframes for recovery based on what it can do versus what is needed.
  • The business will reset the RTOs and RPOs to what they can achieve versus what the business BIA derived demands are to continue operations.  They don’t understand that these are objectives and are different than actuals.
  • In limited instances, IT can exceed the RTOs and RPOs but does not communicate it to the business.  They don’t want to be held to it.  

In a perfect world, you should have an alignment meeting at a regularly planned interval (e.g., annually) to identify successes and gaps in business expectations and IT delivery capabilities.  A simple table should be constructed to show alignment and gaps:

Application RTO RTA RPO RPA
System A RTO = 12 Hours RTA = 24 Hours RPO = 4 Hours RPA = 12 Hours
System B RTO = 48 Hours RTA = 24 Hours RPO = 24 Hours RPA = 24 Hours
System C RTO = 5 Days RTA = 5 Days RPO = 4 Hours RPA = 12 Hours

The BIA is conducted for a number of reasons and ensuring alignment across the organization is one of them.    So, get out there and get your systems aligned.

Showing 0 comments
  • joe zammit

    With the advent of, and process/data interdependecies dictated by, large ERP applications (SAP, Oracle/PeopleSoft, ….), how can there be different RPOs? Intuitively, the data in the ERP has to be consistent for all applications for it to recover successfully, which means any RPO must be a very short period of time. Thoughts?

    • Michael Herrera
      Michael Herrera

      Joe,
      In tightly coupled ERP systems, I would agree that RPOs could be be same and not different. But in moderately to loosely coupled systems, there will be different RPOs based on what the business needs and can do to replace lost data. We have seen clients attempt to provide one single RPO across all systems/applications; this is not an effective use of IT resources and technology. You may find yourself providing an RPO that is either not enough or too much, you need to know what the business can tolerate.