Determinación de la viabilidad mínima con la participación de Constellation Energy

La viabilidad mínima se refiere al conjunto más reducido de capacidades esenciales —personas, procesos y tecnología— necesarias para mantener una empresa operativa durante una interrupción grave. 

Requiere decisiones de liderazgo, coordinación entre departamentos y priorización de resultados, lo que la convierte en una disciplina empresarial estratégica más que en un mero ejercicio técnico. 

Dado que las interrupciones suelen durar semanas, la viabilidad mínima ofrece la vía más rápida para ayudar a restablecer las operaciones esenciales y reducir el impacto financiero y reputacional. 

Mediante un análisis interdepartamental de las dependencias, los flujos de trabajo y los servicios de identidad, lo que a menudo permite descubrir sistemas críticos que antes pasaban desapercibidos. 

La viabilidad mínima es una responsabilidad compartida entre los departamentos de TI, seguridad, operaciones, gestión de riesgos, finanzas y la dirección ejecutiva. 

Por favor, mira el vídeo aquí para ver la transcripción con marcas de tiempo

Hola y bienvenidos a este episodio del podcast SHIFT.

Este episodio se centra en establecer la viabilidad mínima y en convertirla en el factor más
valioso para su negocio.

Hola a todos, soy Vidya Shankaran, directora técnica de campo en Commvault, y hoy me acompañan Ha
Hoang, director de sistemas de información de Commvault Technologies, y Jay, director de sistemas de información de Constellation Energy.

Gracias por acompañarnos hoy aquí.

Gracias por invitarnos.

Gracias por invitarnos.

Por supuesto.

Normalmente, cuando hablamos de viabilidad mínima, el tiempo medio de inactividad registrado
en el sector, según las estadísticas más optimistas, es de 24 días.

Pero para la mayoría de las empresas, ese tiempo es demasiado largo como para soportarlo.

No es solo eso, sino también el impacto económico en los ingresos que puede suponer para las empresas,
por no hablar del daño a la reputación que sufre la empresa durante los 24 días de

inactividad.

Por eso, hoy en día, el sector define la viabilidad mínima como un conjunto mínimo de capacidades que
incluye al personal, los procesos y, por supuesto, la pila tecnológica que conforman ese

negocio viable.

Y alcanzar esa viabilidad mínima se convierte en el momento decisivo para determinar si la empresa
puede sobrevivir y prosperar tras un ciberataque.

Así pues, dado que la viabilidad mínima es el tema de nuestro debate de hoy, me complace que Ha

y a Jay con nosotros.

Y mi primera pregunta para Ha sería: ¿cómo definirías la viabilidad
mínima más allá de la idea errónea que probablemente tiene el sector de que se trata simplemente de una lista de comprobación de TI?

¿Cómo se aborda con una mentalidad de liderazgo?

Para mí, la viabilidad mínima tiene menos que ver con la pila tecnológica y más con la claridad en la toma de decisiones.

Se trata de preguntarse: ¿cuál es el conjunto más reducido de capacidades que necesitamos para mantener el negocio
en marcha mientras todo lo demás está inactivo?, ¿verdad?

Así que es una mentalidad que exige disciplina, que consiste en dar prioridad a los resultados y no solo
a la infraestructura, ¿verdad?

Así que creo que, cuando se aplica esa perspectiva, la planificación de Recovery se convierte en una conversación de liderazgo
sobre compensaciones y no es solo un ejercicio técnico, ¿verdad?

Y eso también ayuda a fomentar la responsabilidad compartida entre las unidades de negocio, el departamento de Risk y…
eh… TI.

Tiene mucho sentido.

Ahora bien, ya que tenemos el placer de que estés hoy aquí con nosotros, Jay, ¿qué significa la viabilidad mínima
para una empresa de infraestructuras críticas como Constellation Energy, donde

sin duda el tiempo de inactividad no es una opción?

Bueno, creo que probablemente coincidiría un poco con lo que decías.

Es el deporte de equipo por excelencia.

¿Verdad?

Quiero decir que no es un debate exclusivo del departamento de TI.

No es un debate con unidades de negocio individuales.

No es una conversación con el departamento de seguridad ni con el de TI.

En realidad, es un debate en el que deben participar todos.

Porque, en realidad, eso es precisamente lo que significa «empresa mínima viable», ¿no?

¿Qué significa para mí seguir manteniendo mi actividad principal?

¿Verdad?

¿Y cómo se traduce eso en la práctica?

Así que, para mí, creo que el mensaje más importante es que se trata de un trabajo en equipo, porque no es algo
individual

Ningún grupo puede hacerlo por sí solo.

Me encanta eso.

Y tengo que preguntaros esto a los dos.

Probablemente le daré la palabra primero a Ha.

¿Hubo algún contratiempo o sorpresa que os pillara desprevenidos mientras elaborabais la
lista de activos críticos mínimos viables?

Sí, por supuesto.

Hubo algunas.

Algunos de los sistemas o aplicaciones fundamentales

que pensábamos que eran imprescindibles, ya sabes, sin duda no estaban ahí, ¿verdad?

O no llegaron a aparecer en nuestra lista.

Y luego creo que sistemas como el de identidad, que considero más bien una cuestión secundaria, resultaron
ser bastante críticos.

Y a veces, bueno, nos centramos principalmente en lo que ve el cliente, que son las
aplicaciones, ¿verdad?

Pero si te planteas si se trata de un servicio de salto, de identidad o
simplemente de sistemas básicos de interdependencia,

esos son los que, en mi opinión, son fundamentales.

Me encanta.

Yo añadiría que todo este asunto te tiene atrapado.

Y si alguien te dice que no es así, es que se lo está inventando.

Nadie lo ha hecho antes, ¿verdad?

Es la primera vez que realmente hemos empezado a pensar en eso; siempre hemos hablado de
productos mínimos viables, pero nunca de una empresa mínima viable.

Creo que lo más importante para mí es que teníamos una visión muy tradicional del mundo, en la que había
aplicaciones de alto valor empresarial, de valor empresarial medio y de bajo valor empresarial.

Y decíamos: «Bueno, esto es fácil.

Simplemente recuperaremos las aplicaciones de alto valor empresarial y listo».

Lo que aprendimos fue que muchas de esas aplicaciones de bajo valor empresarial probablemente contribuían
de alguna manera a alimentar o a aportar algo a las de alto valor empresarial.

Así que pensar en términos que parecían muy absolutos no funciona cuando se habla de
una «empresa mínimamente viable», ¿verdad?

Porque se trata de un sistema, no de aplicaciones individuales.

Y ese fue el mayor descubrimiento para nosotros.

Y apostaría a que también lo fue para mucha gente.

Creo que es una

expresión que acaba de utilizar, que no se trata de un «producto mínimo viable», sino de un «negocio mínimo
viable» o una «empresa mínima viable».

Lo cual me lleva al siguiente punto.

En todo este proceso, ¿en qué medida has disfrutado de la colaboración con tu CISO,
especialmente a la hora de definir algunos de esos activos críticos y quién es responsable de las decisiones de Recovery?

?

Sí, has mencionado los activos críticos, pero ¿quién ayuda entonces?

a priorizar las operaciones de Recovery?

Sí.

Vaya, como he dicho, es un deporte de equipo, pero también se necesita un árbitro.

Así que creo que, en muchos sentidos, el director de sistemas de información (CIO) y el director de seguridad (CSO) actúan un poco como árbitros
en ese caso, porque cuando empiezas a simularlo y ves que tuvimos un socio estupendo que

nos ayudó en WWT y que realmente nos ayudó a analizar todo esto y a repasar
tanto el proceso técnico como los

diría «procesos procedimentales», porque lo que acabas aprendiendo es que todo el mundo cree
que lo suyo es lo más importante.

Así que creo que lo más importante en lo que deben centrarse el director de sistemas de información (CIO) y el director de seguridad de la información (CISO) es cómo desempeñar
ese papel de juez y jurado, pero también cómo asegurarse de centrarse en —como has mencionado—

en algunas tecnologías fundamentales y básicas, como la identidad y la red, ¿verdad?

Sin eso, nada funciona.

Así que también se trata de ayudar a la gente a comprender

esa pieza del rompecabezas.

Así es como creo que debe ser su función, ¿no?

Me encanta.

Te devuelvo la palabra, Ha.

En todo esto, volviendo al comentario de Jay sobre que se trata de un deporte de equipo, ¿te encontraste con algún
reto a la hora de elaborar el caso de negocio mientras lo presentabas, probablemente, al

, al equipo de riesgos o al de cumplimiento normativo?

¿Y cuáles eran algunos de los conceptos erróneos que ya se habían arraigado en esas

líneas de negocio y que tuviste que desmentir antes de poder vender el caso de uso en
torno a la viabilidad mínima?

A la hora de reunir a esos equipos, obviamente, creo que el enfoque de la viabilidad mínima tenía que
ser diferente, ¿verdad?

Tenía que expresarse en términos empresariales y no en la jerga propia de «Backup and Recovery», ¿verdad?

Así que, por ejemplo, para el departamento financiero se trata, ya sabes, de proteger la continuidad de los ingresos.

Para los equipos de riesgo, se trata de limitar la exposición.

Y para los equipos de operaciones, se trata de garantizar la satisfacción de los clientes.

Y creo que cuando los equipos y las funciones se ven reflejados en la estrategia de viabilidad mínima
, es cuando se produce la alineación.

Y en cuanto a los conceptos erróneos, creo que el mayor es pensar que la viabilidad mínima
implica un esfuerzo mínimo.

Como si se tratara de rebajar los estándares o de aceptar una recuperación parcial.

Esa es una observación muy acertada.

La realidad es que es todo lo contrario, ¿verdad?

Eh… En realidad se trata de disciplina y de, eh, centrarse en lo que realmente, eh, impulsa la continuidad y
la resiliencia cuando cada minuto cuenta, ¿verdad?

Y creo que otro error es pensar que se trata de una cuestión puramente tecnológica, ¿verdad?

Así que los consejos de administración y los directores de sistemas de información como nosotros esperamos una lista de comprobación o un diagrama arquitectónico, pero en
realidad se trata de una conversación sobre estrategia empresarial, ¿verdad?

Sobre cómo las empresas priorizan realmente el valor bajo presión, qué deciden proteger y
por qué.

Me encanta ese eslogan que acabas de mencionar: «cómo priorizar el valor
empresarial bajo presión».

Probablemente yo…

lo pondría en negrita, lo resaltaría y lo enfatizaría hasta la saciedad, porque esa es la esencia misma de la
definición de MVC.

Lo cual me lleva al siguiente punto.

Hemos hablado de estrategia.

Hemos hablado de que es un deporte de equipo.

Pero, ¿cuáles son los KPI clave?

¿Cómo se cuantifican y se miden siquiera?

No se trata de las típicas métricas tangibles, ¿verdad?

¿O es que se me escapa algo?

¿Te basas en el RPO y el RPTO?

¿Cuáles serían las unidades de medida del éxito basadas en el MVC?

Creo que, en mi caso, quizá empiece centrándome menos en las métricas y luego, ya, me centraré en ellas.

Pero para mí, se trata de asegurarme de que el sistema no se utilice solo en una crisis.

Creo que es un error común quedarse ahí sentado y decir: «Vamos a ensayar esto y
vamos a tener esto».

En nuestro caso, cambiamos

todas nuestras copias de seguridad y Backup and Recovery a Commvault porque queríamos que la gente utilizara este sistema a
diario.

Así que queríamos asegurarnos de que supieran cómo utilizar el sistema, cómo manejarlo,
cómo conocer todos sus entresijos porque, ya sabes, hablamos de estar bajo presión,

¿verdad?

Ese no es el momento para probar algo nuevo.

Así que esa es una de las cosas.

Y voy a añadir algo al último punto del que hablabas, que era otro sobre la recuperación ante desastres,
¿verdad?

Creo que otro error común es pensar que ya contamos con una estrategia de recuperación ante desastres.

¿Para qué lo necesito?

¿Verdad?

Quiero decir, ya lo tengo.

Y creo que

, de nuevo, si piensas en la recuperación ante desastres (DR), es una forma de pensar un poco anticuada, ¿no?

Tiene, a falta de un término mejor, una especie de mentalidad de «agujero en el suelo», ¿verdad?

Si no tengo esto en concreto, ¿qué pasa?

Bueno, no creo que ninguno de nuestros entornos exista en menos de otras cinco nubes u otros
cinco entornos.

Así que realmente creo que se trata, en primer lugar, de cambiar la mentalidad y, en segundo lugar, de cambiar
las operaciones para no limitarnos a actuar solo en caso de crisis.

Así es como yo lo veo.

Me encanta.

Estoy totalmente de acuerdo.

Sí, obviamente, ya sabes, analizamos métricas cuantitativas y cualitativas, ya sabes, indicadores.

Y, ya sabes, técnicamente, todo el mundo va a medir el RPO y los RTO, ¿verdad?, y
el porcentaje de datos de copia de seguridad «limpios» y cosas por el estilo.

Pero creo que en lo que yo también me centro y hago un seguimiento es en la rapidez con la que podemos tomar decisiones con seguridad
bajo presión, ¿verdad?

Porque creo que la «Readiness» no solo tiene que ver con la rapidez con la que podemos recuperar o restaurar, sino también con
la rapidez con la que podemos confiar en los datos y en el sistema que estamos restaurando.

Entonces, ¿en qué medida todo esto se reduce realmente a poner en práctica las pruebas?

Todo.

Muchísimo.

Sí.

Quiero decir, al final siempre se reduce a eso, ¿no?

Preparación, práctica.

Mira, en nuestro mundo, entrenamos mucho.

Entrenamos todo lo que hacemos.

Porque quieres asegurarte de que, cuando realmente lo necesites o estés bajo presión,
seas capaz de llevarlo a cabo.

Y creo que esto no es diferente.

Quizá la buena noticia, o la mala noticia, es que todos hemos tenido muchas oportunidades de practicar esto
últimamente, ¿verdad?

Ya sean cortes en la nube o proveedores que hacen cosas, ¿no?

Hemos tenido oportunidades para practicar esto.

Y eso es lo otro que diría: hay que aprovechar esas oportunidades para decir:
«No tengas miedo de sacar partido al sistema que tienes, ¿verdad?».

Has creado un sistema, úsalo.

¿Cómo lo utilizo

para recuperarme más rápido?

¿Cómo lo utilizo para la Recovery de una nube concreta o para un incidente que esté
ocurriendo, verdad?

Creo que se trata de mirar hacia adelante y utilizarlo, y no dejarlo de lado pensando:
«Oh, ¿tengo que ocuparme de lo de la recuperación ante desastres?».

¿Tengo que hacer eso?

Todos tenemos esa mentalidad.

No lo configures y te olvides de ello.

Exacto, precisamente.

Es decir, si está ahí, úsalo.

Sí, y sin duda es algo en lo que las organizaciones deben seguir trabajando.

No es algo

ejercicio que se hace una vez y ya está.

Es un proceso en constante evolución que hay que mejorar continuamente.

Y seamos sinceros, además no deja de crecer, ¿verdad?

Los datos y todo lo demás no están disminuyendo.

Lo más probable es que, para casi todo el mundo, el producto que lanzaste sea una mínima parte de lo que
eres ahora.

Eso sí que cambia las reglas del juego, ¿verdad?

Exactamente.

Lo cual me lleva a la siguiente pregunta clave, que fue más difícil.

¿Fue la ejecución técnica o el cambio cultural?

Yo diría que el cambio cultural, sin lugar a dudas.

El trabajo técnico es complejo, pero tiene solución.

Se puede automatizar y resolver mediante pruebas.

Pero lo más difícil es el cambio de mentalidad, creo, de considerar que Recovery es una tarea de TI a
entender que la resiliencia es, en realidad, una

capacidad empresarial compartida.

Sí.

Sí.

Quiero decir, estoy de acuerdo.

Diría que la parte técnica es fácil porque cuento con un equipo técnico increíble y hacen
que todo parezca realmente sencillo.

Pero sí creo que la tecnología es algo que se puede resolver, ¿no?

Son unos y ceros, y podemos resolverlo todo.

El problema es que esta conversación siempre ha sido: «Oye, informáticos, haced lo vuestro y avisadnos cuando
hayáis terminado», ¿verdad?

Pero esa ya no es la conversación.

Y para mí ese es el mayor cambio: ahora hay que reunir a todos los líderes empresariales en
una sala y decirles: «Oye, tenemos que hablar sobre Recovery».

Y no se trata solo de: «Oye, avisadnos cuando hayáis terminado, informáticos».

Y ese es el cambio cultural.

Estoy totalmente de acuerdo.

Creo que, en realidad, avanzar hacia la viabilidad obliga a mantener conversaciones un poco incómodas sobre
el establecimiento de prioridades, ¿verdad?

Lo que realmente hay que hacer en las primeras 24 horas frente a lo que puede esperar.

Y ahí es donde creo que

estamos pidiendo a los líderes empresariales, en esencia, que hagan concesiones en tiempo real, y esas son
las conversaciones difíciles.

Sí.

No, tiene todo el sentido del mundo.

Y, sobre todo, como tú dices, si le preguntaras a cualquier líder empresarial, te
respondería que su AppStack es importante.

Todo es importante.

«Yo soy lo más importante».

Sí, claro que sí.

Así que, tras haber pasado por

y haber trabajado en la construcción de tu MVC —y, por supuesto, como acabamos de comentar, se
trata de un proceso en constante evolución—,

Pero, ¿cuáles son las lecciones clave, esas «cicatrices de batalla», que te gustaría
compartir con tus compañeros para que no se enfrenten a los mismos retos a la hora de

desarrollar su MVC?

Yo diría que hay que practicar Recovery, como si fuera el día del partido, ¿no?

Porque no se puede desarrollar la resiliencia en plena crisis.

Se forja en los entrenamientos previos.

Perfecto.

Creo que, en mi caso —y lo has mencionado un par de veces, aunque nunca está de más insistir en ello—
, lo fundamental es la capa básica.

Creo que, tradicionalmente, simplemente no pensamos en la posibilidad de no contar con elementos fundamentales como
Active Directory, la red… Todas estas cosas están ahora definidas por software

como nunca antes.

Y creo que ese es el mayor cambio que hay que respetar y poner en práctica de verdad

y comprender: ¿cómo sería tener que recuperar mi autenticación básica antes
de que ninguno de mis empleados pueda hacer nada?

Y ahí es donde siempre nos olvidamos.

El personal de TI no puede hacer nada sin eso.

Y creo que esa es la cicatriz de batalla definitiva.

Y, sinceramente, creo que es una de las cosas que
Commvault hace mejor que nadie: esa Recovery a nivel de bosque de Active Directory, que es fundamental y fue uno de los

principales factores diferenciadores que nos llevaron a elegir el producto.

Gracias.

Gracias por compartir esa perspectiva.

Y antes de dejaros marchar a los dos, ¿qué frases lapidarias, de esas que dan en el clavo
, nos dejaríais?

Vaya, creo que ya lo he dicho.

Entrenad la Recovery como si fuera el día del partido.

Perfecto.

Me encanta.

Para mí, es un deporte de equipo.

Y no puedes limitarte a dejarlo en manos de tu equipo de TI y decir: «Oye, avísame cuando esté listo».

Esto es un deporte de equipo en el que es necesario que todos los presentes participen en la conversación.

Perfecto.

Muchísimas gracias por acompañarnos hoy aquí y por compartir tus ideas.

Han sido muy valiosas.

Y a todos nuestros espectadores que nos acompañan de forma virtual: si queréis profundizar en
los conceptos de viabilidad mínima, echad un vistazo a nuestro informe de análisis de Giga Om, que trata

más a fondo sobre la viabilidad mínima, disponible en Commvault.com.

Gracias.