Feeds:
Entradas
Comentarios

Posts Tagged ‘BIA’

Determinando el RTO – La clave para priorizar los procesos de negocio

Sin lugar a duda, el objetivo principal que persigue un BIA es entregar una manera objetiva de priorizar los procesos de una organización de cara a la continuidad de negocio. Y dicha priorización quedará definida en gran medida por dos parámetros relevantes, los cuales son los siguientes:

  • RTO (Recovery Time Objective). Corresponde al máximo tiempo admitido para resumir una actividad, recuperar recursos, o proveer servicios luego de que ocurre un evento disruptivo. Este período de tiempo objetivo debe ser lo suficientemente corto para asegurar que el impacto negativo de dicha disrupción sea inadmisible. (ISO 27031:2011, 3.45 Recovery Time Objective, RTO).
  • RPO (Recovery Point Obective). Corresponde a un objetivo de recuperación de datos. Es el punto en el cual la información o datos utilizados por una actividad deben ser restaurados luego de que ocurre un incidente disruptivo. (ISO 27031:2011, 3.44 Recovery Point Objective, RPO).

Una de las actividades que son llevadas a cabo durante la ejecución de un BIA (Business Impact Analysis) es la determinación de el RTO del proceso analizado. Y esto se puede lograr en base a la determinación del impacto que una disrupción produce en el negocio a lo largo del tiempo.

En este sentido, la primera tarea a la hora de diseñar este proceso es definir los diversos tipos de impacto que una disrupción puede causar en el negocio. Este punto dependerá de la naturaleza que tiene el negocio: posiblemente los factores que más se pueden ver impactados en una empresa del rubro financiero (como un banco) serán muy distintos a los que puedan afectar a una empresa de la educación o el gobierno. A continuación, se indican algunos de los principales tipos de impacto que pueden ser utilizados en un BIA:

  • Montos involucrados. Uno de los principales impactos que produce una disrupción en un negocio es la pérdida monetaria. Y dicha pérdida puede ser de manera directa (costo asociado a la recuperación de la operación, en horas hombre, equipamientos y otros) o indirecta (dinero no percibido por la interrupción de las actividades del negocio). El mejor ejemplo para utilizar para describir este impacto es el típico escenario de sin sistema en las cajas de un supermercado: Si las cajas quedan sin sistema, se deberá invertir en un equipo de personas que recuperen los sistemas, pero además los clientes abandonarán el supermercado sin terminar sus compras hasta que el sistema vuelva, lo cual también se transforma en pérdida. Para determinar estas pérdidas indirectas, se puede recurrir a datos estadísticos que permitan proyectar el ingreso generado por el proceso, dependiendo de la hora y fecha en la cual dicha disrupción ocurra.
  • Efecto en la imagen. Otro impacto que puede ocasionarse debido a una disrupción es el daño en la imagen corporativa de la compañía, el cual puede traducirse en pérdida de clientes actuales o alejamiento de potenciales clientes de esta. En este sentido, el auge de las redes sociales y los medios de denuncia masivos hacen de que dicho factor pueda transformarse en relevante a la hora de determinar un RTO.
  • Impacto normativo. En las compañías que están sujetas a entes reguladores, el impacto de una disrupción a nivel normativo puede traducirse en observaciones, sanciones e incluso restricciones para la operación de la compañía que se ve afectada por una disrupción.
  • Impacto a nivel operacional. Como bien es sabido, rara vez un proceso de negocio será totalmente independiente del resto de los procesos de la compañía. En este sentido, un proceso de disrupción que afecte un proceso de negocio puede terminar afectando otros procesos a nivel corporativo.
  • Masividad. El impacto que una interrupción de un proceso de negocio produce puede medirse en base a la cantidad de transacciones que se ven interrumpidas o la cantidad de clientes que se puede ver afectados.

Una vez que se definen los factores que serán medidos para determinar el RTO, se debe crear una matriz que permita determinar el nivel de impacto en base a una escala. A continuación, se presenta un ejemplo de ello.

Factores de Impacto (Ejemplo)

Durante la ejecución del BIA, se medirá el impacto de cada uno de los factores de impacto a lo largo del tiempo. En este punto, se deben definir las escalas de RTO posible (Menor a 1 hora, entre 1 y 2 horas, entre 2 a 6 horas, etc.) y se debe determinar cual será el impacto de la disrupción en los diversos factores. Una vez que se determina que el impacto global es inadmisible, se define el RTO. La definición de qué será considerado inadmisible se puede realizar dentro del diseño del BIA (puede ser, por ejemplo, la primera banda donde exista al menos un impacto en nivel catastrófico).

Ejemplo de cálculo de RTO.

El RTO, en conjunto con el RPO, se transforman en dos factores claves que permitirán definir cuales son los procesos más críticos del negocio de cara a la continuidad operativa. Una vez que el análisis BIA se ha realizado a todos los procesos relevantes de la organización, se puede determinar en que casos es relevante generar planes de continuidad del negocio (BCP). Esto lo abordaremos en un próximo capítulo. ¡Hasta entonces!

Read Full Post »

Identificando los componentes críticos del proceso

Uno de los principales objetivos que debe perseguir un análisis de impacto de negocio (BIA) es la identificación de los componentes críticos que cada proceso tiene, de cara a la continuidad del negocio. Es por esto que la ficha BIA debe contener sí o sí un conjunto de secciones que permitan identificar, para cada proceso analizado, los siguientes componentes:

Aspectos críticos del proceso de cara a la continuidad del negocio.
  • Personal crítico del proceso. Dentro de este ítem se deben identificar aquellas personas que son clave en la ejecución del proceso, dentro de los que destacan los siguientes:
    • Responsable del proceso y su respectivo backup.
    • Administradores funcionales y técnicos de las aplicaciones clave utilizadas por el proceso y sus respectivos backups.
    • Número de personas dedicadas a tiempo completo para la ejecución del proceso.
    • Número de personas que están dedicadas a otros procesos y que podrían ejecutar el proceso en modalidad de backup.
    • Número mínimo de personas necesarias para ejecutar el proceso con normalidad.
    • Detalle del personal crítico del proceso, indicando sus nombres, datos de contacto y función específica dentro del proceso.
  • Aplicaciones clave del proceso. En este punto, es importante determinar, en la medida de lo posible, los siguientes aspectos:
    • Aplicaciones indispensables para la ejecución del proceso (aplicaciones que de estar ausentes el proceso no funciona con normalidad)
    • Aplicaciones alternativas para la ejecución del proceso, en caso de ausencia de aplicaciones críticas
    • Aplicaciones relacionadas con la ejecución del proceso (por ejemplo, correo electrónico)
  • Relación entre las aplicaciones críticas y los servidores. Este punto está relacionado con los conceptos de mapa aplicativo o CMDB. En la medida de lo posible, un BIA debería permitir identificar los servidores críticos para la ejecución de los procesos analizados. Este punto es uno de los más complejos a la hora de realizar esta actividad, debido a que la generación de un mapa aplicativo, sobre todo en empresas grandes, puede ser un proceso extremadamente complejo.
  • Registros vitales. En caso de que los procesos requieran como entrada para su ejecución ciertos registros (ya sea físicos o virtuales), estos deben ser debidamente identificados. Además, es ideal determinar su ubicación y las políticas de respaldos asociados a dichos registros.
  • Ubicaciones de ejecución de los procesos. Para el caso de aquellos procesos que se realicen de forma física, se debe determinar las ubicaciones donde dichos procesos deben ser realizados, y se debe determinar la ubicación alternativa donde dichos procesos puedan ser realizados.
  • Proveedores involucrados. Para el caso de aquellos procesos que sean ejecutados parcial o totalmente por proveedores, se deben identificar los siguientes aspectos:
    • Nombre de los proveedores involucrados y su función dentro del proceso
    • Gestor de contrato responsable de los proveedores
    • Proveedores de backup para el proceso, en caso de que existan

La recopilación de estos componentes permitirá comprender la estructura del proceso de cara a la continuidad de negocio e identificar los puntos de falla que permitirán alimentar el proceso del RIA.

En el próximo capítulo de esta serie, les compartiré algunos tips para determinar el RPO y el RTO de un proceso, dentro del análisis BIA.

Read Full Post »

Afrontar el desafío de implementar un sistema de continuidad de negocio (ISO 22301:2012 – 3.5 Business Continuity Management System: BCMS) es una tarea que se puede hacer extraordinariamente compleja si no se ha definido previamente una estrategia que permita optimizar los recursos necesarios para su implementación.

Y dentro de este contexto, la ejecución de un BIA (ISO 22301:2012, 3.8 Business Impact Analysis) o Análisis de Impacto de Negocio suele ser la piedra angular que permitirá definir dicha estrategia. Debido a que las organizaciones no cuentan con recursos infinitos para invertir en personas, procesos o tecnología orientados a la Continuidad del Negocio, se hace necesario establecer una metodología que permita comparar los procesos de negocio en base a parámetros homogéneos y objetivos, a fin de establecer las prioridades a la hora de asignar estos recursos de manera eficiente.

¿Cuáles son los objetivos que persigue un BIA?

El principal objetivo de un BIA, tal como se indicó anteriormente, es priorizar los procesos de negocio desde el punto de vista de su relevancia en cuanto a la continuidad operativa. Sin embargo, el BIA tiene otros objetivos secundarios que son dignos de destacar, y que se muestran en la Figura 1.

  • Identificar componentes críticos del proceso. El BIA debe buscar descubrir y documentar todos los componentes críticos que posea el proceso que esté siendo analizado. Esta actividad comprende cuatro aspectos fundamentales:
    • Personas: Corresponden a las personas que son claves dentro de la ejecución, seguimiento y control del proceso. Estas son conocidas como personal clave, ya que su ausencia podría gatillar un incidente de continuidad del negocio.
    • Tecnología: Corresponde a aquellos sistemas que son necesarios para la ejecución, seguimiento y control del proceso. Esto además puede ser complementado con el levantamiento de los componentes a nivel de TI, seguridad y comunicaciones que soportan dichos sistemas.
    • Instalaciones: Corresponde a aquellas ubicaciones físicas donde se realizan los procesos. En el caso que los procesos sean completamente virtuales, dichas instalaciones suelen corresponder a los Datacenters.
    • Proveedores: En aquellos casos donde los procesos sean completa o parcialmente externalizados, se deben determinar los proveedores involucrados en ellos.
  • Identificar temporalidades del proceso. Debido a que la continuidad del negocio corresponde a una actividad ininterrumpida en el tiempo, el BIA debe determinar aquellos momentos clave donde el proceso se ve sobrecargado o en donde la continuidad del negocio cobre mayor relevancia. Por citar un ejemplo, en un proceso de matricula para una universidad existen dos meses en el año donde dicho proceso adquiere una mayor relevancia en cuanto a la continuidad operativa.
  • Determinar procedimientos de operación alternativa existentes. En organizaciones donde se ha implementado previamente parcial o totalmente un BCMS, es probable que ya existan procedimientos de continuidad operativa. Incluyo en aquellas organizaciones donde este concepto aún no esté desarrollado, los dueños de proceso podrían eventualmente tener planes definidos. En este sentido, el BIA debe recopilar y documentar los mecanismos existentes, a fin de poder considerarlos a futuro.
  • Determinar el RPO y el RTO del proceso. Finalmente, el BIA debe perseguir y definir dos conceptos claves en la implementación de una estrategia de continuidad del negocio: El RPO (ISO 22301:2012, 3.44 Recovery Point Objetive) y el RTO (ISO 22301:2012, 3.45 Recovery Time Objetive). El RTO o Tiempo de Recuperación Objetivo se refiere a la cantidad de tiempo máxima permitida para recuperar un proceso posterior a una disrupción (27031:2011, 3.6 Disruption).  El RPO o Punto de Recuperación Objetivo, por su parte, se refiere a un objetivo de recuperación de datos. Este es el punto en el cual la información o los datos utilizados por el proceso deben ser restaurados posterior a una disrupción. Ambos conceptos claves deben ser definidos durante la ejecución del BIA, y ambos se definen basándose en un proceso de análisis de impacto asociado a la disrupción.

Durante las próximas entregas de este artículo, se entregarán algunos aspectos claves para construir una plantilla que les permita establecer un proceso de análisis de impacto en el negocio para cualquier organización.

¡Nos vemos en una próxima oportunidad!

Read Full Post »