No todos saben dónde y cuándo comenzar a implementar planes de continuidad comercial. Normalmente digo esto: cuando las posibles pérdidas son más altas que los costos de contrarrestar la amenaza, es hora de tomar medidas, los costos serán adecuados. Y viceversa. Si el costo de contrarrestar es más o menos claro, entonces estimar pérdidas es una tarea no trivial. Los invito al backstage de un proyecto de evaluación de impacto empresarial (Business Impact Analysis - BIA) y al desarrollo de una estrategia de continuidad de TI utilizando un minorista importante como ejemplo. Entonces vamos.
Inicio
Participamos en el proyecto de X5 Retail Group, el minorista más grande de Rusia. La compañía gestiona las redes de Pyaterochka, Carrusel y Crossroads.
Ella ya tenía su propia política de gestión de riesgos de interrupción, que incluía:
- seguro de riesgo;
- formación de gestión de crisis;
- minimización de riesgos para la vida y la salud de las personas;
- control de riesgos de gestión empresarial;
- Preparación de planes de recuperación de emergencia para sistemas informáticos.
De acuerdo con esta política, la infraestructura de TI centralizada requería el desarrollo de la continuidad del servicio de TI y los planes de recuperación ante desastres. La solución ideal sería construir un centro de datos de respaldo, configurar la replicación síncrona, configurar la automatización de transferencia de emergencia y ver "H" en una hora en la pantalla cómo los sistemas de TI se mueven al centro de datos de respaldo y se encienden las luces verdes, lo que indica que no hay peligro para el negocio.
Pero dada la economía del proceso, la compañía sugirió que reservar solo los sistemas de TI más críticos sería una medida de emergencia adecuada, sin la cual las tiendas no podrían operar y comenzarían pérdidas financieras significativas en la compañía. Surge una pregunta importante: ¿qué sistemas y por cuánto tiempo deben restaurarse?
El departamento de TI del cliente determinó la clasificación de los sistemas de TI y el tiempo de recuperación aceptable para cada sistema. Sin embargo, más tarde se decidió realizar una evaluación completa del impacto de las emergencias en el negocio de la compañía (BIA) de acuerdo con ISO 22301 y las mejores prácticas.
Volumen y límites
El teatro comienza con una percha, y el BIA comienza con la definición del alcance del trabajo. Para hacer esto, debe examinar los procesos comerciales de la compañía, sus servicios, estados financieros, relaciones con socios, clientes y contratistas. Luego, identifique y coordine los procesos y servicios comerciales clave que se encontrarán dentro de los límites del proyecto. La duración y el costo del BIA dependen del volumen. Además, nuestra experiencia sugiere que no debe estirar el proyecto durante más de 9 meses.
En nuestro caso, el cliente ya ha determinado los límites al elegir los procesos comerciales más importantes para las actividades comerciales.
La entrevista
Una vez que se fijan los límites y el marco de BIA, se determina una lista de partes interesadas de la empresa y otros departamentos con los que desea realizar una entrevista. Es muy importante recopilar información de diferentes departamentos para obtener una imagen objetiva de los procesos en la empresa, comprender cómo funcionan y obtener una evaluación de "qué sucederá si ...". En esta etapa, obtenemos información sobre cómo dependen exactamente los procesos comerciales de TI y construimos una matriz de estas dependencias. Además, los representantes comerciales y las partes interesadas en el proceso comercial evalúan las consecuencias, posibles daños y posibles escenarios. Para esto, desarrollamos un cuestionario especial y entrevistamos a unos 50 encuestados (presentamos 50 presentaciones sobre el proyecto en sí, realizamos, recibimos y procesamos todos los cuestionarios completados).
Procesos de negocio
Paralelamente a las entrevistas, describimos los procesos comerciales, teniendo en cuenta el tiempo necesario para completar las operaciones individuales y la profundidad de elaboración, suficiente para un análisis más detallado. Es necesario particionar un proceso en componentes más pequeños y operaciones específicas para comprender cómo un sistema de TI afecta un proceso particular en diferentes momentos del día y en diferentes momentos del año. En esta etapa, es importante comprender que no describimos los procesos comerciales de acuerdo con GOST u otra metodología. No optimizamos los procesos comerciales y, en general, no damos recomendaciones para mejorar los procesos comerciales, al menos dentro del BIA. Describimos los procesos comerciales con tal detalle que nos permite justificar la metodología para calcular pérdidas y evaluar pérdidas de acuerdo con varios criterios. Para una descripción gráfica, la notación EPC, ARIS y MS Visio se utilizaron como herramientas.
Umbrales
Para determinar el tiempo objetivo de recuperación del objetivo, es necesario acordar en la costa los criterios por los cuales evaluaremos el daño y sus valores umbral. Si se exceden estos umbrales, consideraremos que el daño es crítico, y el intervalo de tiempo en el que se alcanza el valor umbral se convertirá en el tiempo de recuperación objetivo. Se sugirieron dos opciones:
- determinar RTO por un criterio: pérdidas financieras;
- determine el RTO por tres criterios: pérdida financiera, pérdida de reputación, pérdida de capacidad de control de los procesos comerciales.
La primera opción con un criterio parece preferible, ya que cualquier pérdida puede convertirse condicionalmente en dinero; lo principal es acordar una fórmula de recálculo. Pero, como muestra la práctica, nadie relata específicamente las pérdidas de reputación en pérdidas financieras, y la aprobación de dicha fórmula puede llevar un tiempo indefinido. Se decidió considerar el tiempo de recuperación para ambas opciones, y en la etapa de presentación de los resultados, el propio cliente determinará cuál refleja la realidad de manera más objetiva.
Mirando hacia el futuro, diré que cuando se usa la primera opción con un criterio, resultó que el RTO en el proceso de "fijación de precios", por ejemplo, puede llegar a 10 días. Al calcular la segunda opción, el RTO no excedió las 24 horas. En cualquier caso, la decisión de la administración, qué pérdidas considerar y cuáles no, permanece con el cliente.
Los riesgos
Junto con el cliente, determinamos la lista de riesgos operativos. Es decir, los que afectan a TI, y los que a su vez afectan los procesos de negocio que ... bueno, ya entiendes. Esta etapa es importante porque una emergencia no se considera un caballo esférico en el vacío, dicen lo que sucederá con la Patria y con nosotros si la perdemos. Los riesgos se dividieron en globales y locales. Para cada uno de ellos, se determinó un escenario de desarrollo y el impacto en los procesos de la compañía teniendo en cuenta los resultados de la entrevista. Obviamente, el mismo sistema de TI en caso de falla puede afectar varios procesos comerciales, pero estábamos terriblemente preocupados por solo dos procesos en el proyecto. Luego evaluamos los reclamos de acuerdo con los siguientes parámetros:
- propagación de amenazas;
- la habilidad de alertar;
- duración de la exposición;
- probabilidad de ocurrencia;
- daño estimado
Como resultado, dibujaron un mapa de calor donde cada aplicación recibió una evaluación de qué tan caliente podría quemarse el negocio durante su tiempo de inactividad. Por ejemplo, durante 4 horas de tiempo de inactividad de módulos SAP individuales, la compañía aún no recibe problemas serios, pero incluso las primeras horas de tiempo de inactividad del software de la caja registradora en el mapa de calor están marcadas en rojo intenso.
Es necesario aclarar que la evaluación de riesgos y la clasificación adicional se forman con la ayuda de un grupo de expertos y son necesarios para determinar las situaciones más críticas para el cliente.
Riesgo contingente y escenario. Incendio en el centro de datos: la sala del servidor se ha quemado por completo, el módulo SAP involucrado en el proceso de "Reposición" no está disponible. Esto significa que todos los días, hasta que se restaure el módulo SAP quemado, se reduce el rango de productos. En primer lugar, esto se refiere a productos perecederos, en segundo lugar, productos que tienen una gran demanda (por ejemplo, cereales y pan), y en tercer lugar, productos químicos domésticos. Obviamente, esta situación conducirá a una disminución de los ingresos en las tiendas. Pero esto no es del todo obvio: el comprador que vino por cerveza y cigarrillos, en ausencia de uno de los productos, probablemente no pueda comprar nada. Del mismo modo para el proceso de fijación de precios. Si un cliente condicional que se enteró de los descuentos el miércoles a las 12:00 p.m. llega a la tienda por la tarde y el proceso de "fijación de precios" no funciona (es decir, precios sin descuentos), entonces él:
A) no compra nada (= pérdida financiera);
B) acusará a la tienda de fraude (= pérdida de reputación)
B) se queja al regulador (= penalización por publicidad desleal).
Técnica de estimación de pérdidas
Como probablemente haya entendido de lo anterior, para calcular incluso las pérdidas financieras, es necesario desarrollar una metodología y fórmulas para calcularlas, que tengan en cuenta los descuentos, las promociones, la hora del día, la temporada alta (por ejemplo, la emoción a fines de diciembre). La metodología debe contener una parte descriptiva (de dónde proviene y por qué se multiplica por pesos), así como tablas y gráficos para mayor claridad de percepción.
La técnica también describe:
- Cómo se determina el tiempo de recuperación para un proceso de negocio
- Cómo el tiempo de recuperación para un proceso de negocio se traduce en RTO / RPO para sistemas de TI
- Clases de criticidad y clases de recuperación: ¿por qué es necesario?
Vamos más lejos
Cálculo RTO
Después de realizar todas las entrevistas, se describen los procesos comerciales, se evalúan los riesgos, se define y aprueba una metodología y se calculan las pérdidas. Dado que el negocio de Pyaterochka, Carrusel y Crossroads difiere al menos en escala, para cada red hemos desarrollado nuestras propias tablas, nuestros propios horarios y cálculos de pérdidas.
Para el proceso comercial en su conjunto, se determina el tiempo de recuperación (ver la metodología), cuando las pérdidas exceden el valor umbral (ver umbrales). Este tiempo de recuperación se asigna a aquellos sistemas de TI que están involucrados en el proceso de negocios (ver entrevista y matriz de dependencia). Parece que los parámetros de continuidad están definidos: el proyecto se ha completado (ver límites y marco). Pero no es suficiente decir "el proceso debería restaurarse en 12 horas". Es importante determinar cómo funciona esto ahora. ¿Cuántas horas se puede reanimar un sistema de TI hoy? ¿Y qué pasa si el tiempo de recuperación actual es más largo o significativamente más largo que el objetivo? Para aquellos que aún mantienen la razón y la concentración, ¡bienvenidos al GAP!
Análisis de GAP y plan de acción
Como resultado de los pasos anteriores, determinamos el estado de los procesos y los sistemas TO TO, es decir, como debería ser idealmente. En la etapa actual, determinamos el estado de "TAL CUAL". Al mismo tiempo, tocamos los procesos comerciales en menor medida y nos centramos en el componente de TI. Para el cliente, evaluamos sus soluciones actuales en términos de recuperación de una emergencia. Además, en este caso, no fue necesario realizar una recuperación real con un temporizador. Fue suficiente para profundizar en los detalles y suficientes pruebas de escritorio para comprender que el RTO objetivo es inalcanzable.
Después de eso, desarrollamos una serie de recomendaciones, tanto de carácter general (para garantizar la continuidad de TI), como directamente relacionadas con los sistemas de TI y su arquitectura. Estos son bocetos de soluciones técnicas y una estimación aproximada del costo de su implementación. De hecho, ahora hay una base para una decisión. Por un lado de la escala - pérdidas, y por el otro - el costo de las medidas.
Si algunos sistemas de TI no se someten a un análisis GAP, o más bien, su tiempo de recuperación es más largo que el objetivo, creamos un programa de proyectos para alcanzar el estado objetivo o, si lo desea, una hoja de ruta con justificación de la secuencia de proyectos y una evaluación intermedia para mejorar la sostenibilidad de la organización.
Además, para el cliente hemos desarrollado materiales metodológicos y plantillas para la formación de planes de continuidad y planes de recuperación ante desastres.
Estrategia
Espera, espera, ya casi termino.
Con base en los resultados de BIA, desarrollamos una estrategia de continuidad de TI. La estrategia de continuidad describió dos puntos clave.
- Se toman en cuenta qué riesgos de TI afectan las actividades de la empresa y cuáles no (es decir, a qué tememos y decidiremos en el marco de la continuidad, y a qué no le tememos, y para esto tenemos gestión de incidentes).
- ¿Qué soluciones organizativas, arquitectónicas, de infraestructura y de otro tipo defenderemos contra las amenazas?
Por estrategia matamos dos pájaros de un tiro. En primer lugar, todos en la empresa entienden cómo y de qué nos protegeremos. En segundo lugar, para los no especialistas en TI (por ejemplo, financieros), el proceso de presupuestación de soluciones de recuperación ante desastres de TI parece más transparente. Y no importa cuán patético pueda sonar, la estrategia ayuda a tomar las decisiones administrativas correctas (siempre existe la opción de no gastar dinero en RD, y ahora sabemos exactamente cómo afectará esto a la compañía en caso de un accidente).
Que sigue Implementación adicional de la estrategia de continuidad y el análisis del impacto comercial para otros procesos comerciales y sistemas de TI. Desarrollo de planes de continuidad, pruebas periódicas de estos planes, pero esta es una historia completamente diferente.
Igor Tyukachev, Consultor, Centro de Diseño de Jet Infosystems