Más de 100 millones de estadounidenses viajaron durante la temporada navideña de Diciembre de 2022. Para aquellos que tomaron uno de los 15,000 vuelos cancelados de Southwest Airlines (SWA), fue un momento miserable. Parece que el clima severo abrumó la tecnología antigua y creó un desastre en cascada que tardó días en solucionarse. Ahora vienen las consecuencias: reparar el daño sustancial que SWA le hizo a su marca.
Si es un CXO o un director de la junta, probablemente se esté preguntando: “¿Podría pasarnos esto?” Me temo que la respuesta es que “Sí”. Considere la vergüenza pública de SWA como una llamada de atención para revisar su supervisión tecnológica. En este análisis, exploraremos cuatro áreas: riesgo de capacidad , riesgo de proyecto, riesgo de desastre y deuda técnica, todas las cuales deben revisarse para evitar que su negocio sufra su propio colapso público.
Riesgo de Capacidad
¿Su industria tiene tiempos sobre-ocupados? Tal vez sea un viaje de vacaciones; subidas de tensión en pleno verano; picos periódicos (como “día de pago tardío”, el día 10 de cada mes en el negocio hipotecario); o eventos especiales (la Copa del Mundo viene a Dallas). ¿Sus sistemas y procesos están dimensionados para manejar estos tiempos sobre-ocupados?
¿Qué pasa si estás en un momento pico y la gripe tiene al 10% de tu equipo enfermo? ¿O si un evento meteorológico extraño agrega complejidad adicional a sus operaciones? ¿Qué sucede si se encuentra en medio de una adquisición o una actualización importante del sistema cuando llega un evento de máxima actividad?
Sugerencia de supervisión de TI n.º 1: comprender los picos de la industria y someter a prueba los sistemas/procesos para manejar las expectativas, además del “margen”.
Riesgo del proyecto
¿Puede su organización manejar actualizaciones importantes de sistemas/procesos? Es relativamente fácil planificar y presupuestar la instalación/actualización de un sistema de tecnología: si se trata de un producto de tecnología comprado, el proveedor entregará al equipo de Tecnología de la Información (TI) un “plan de proyecto de muestra”. ¿Pero adivina que? Las “cosas técnicas” en las que se enfocan la mayoría de los departamentos de TI representan menos de la mitad del trabajo/tiempo/costo/riesgo de un verdadero proyecto de “lograr que todos usen los nuevos procesos/herramientas tecnológicas de manera efectiva (y dejar de usar la forma antigua)”.
Las fallas en la implementación del proyecto van desde “simplemente” costosas (p. ej., el ERP que cuesta el doble y demora el doble de lo presupuestado) hasta existenciales (p. ej., la quiebra de FoxMeyer Drugs).
¿Por qué ocurren estas fallas? Podría escribir 10.000 palabras catalogando todas las formas en que mis clientes han fallado. A un alto nivel, lo que más he visto a lo largo de 30 años y numerosas industrias es que los departamentos de TI están bajo presión para ofrecer soluciones a bajo costo y que las unidades de negocios, también bajo presión, abdican la responsabilidad del cambio de procesos de negocios a TI.
Consejo de supervisión de TI n.° 2: Asegúrese de que los principales proyectos de tecnología tengan el alcance y los recursos necesarios como proyectos de gestión de cambios organizacionales en lugar de proyectos de tecnología, y que los costos de contingencia adecuados sean parte del presupuesto. Asigne a un ejecutivo sénior o consultor experimentado como propietario del proyecto e incentive al C-suite a mantenerse comprometido con el proceso y el resultado.
Riesgo de desastres
Cada organización mediana y grande tiene un “plan de desastre” que pretende ayudar a la organización a recuperarse de una serie de calamidades. Verificación de la realidad: la mayoría de estos planes existen en carpetas polvorientas diseñadas para satisfacer a los auditores y no funcionarán cuando sea necesario.
Los cuatro problemas principales que he visto son”
- Falta de imaginación al definir los tipos o el alcance de los “desastres”
Todo el mundo sabe acerca de incendios, inundaciones, cortes de energía o cortes en la red. ¿Qué pasa con un vagón lleno de cloro que se descarrila junto a una ubicación comercial crítica? ¿Qué tal 10,000 galones de jarabe de azúcar cayendo en cascada desde el techo? (Historia real: mi papá dirigía una fábrica de dulces que almacenaba azúcar líquida en un tanque de techo. Cuando el camión de la bomba del proveedor llenó el tanque en exceso, un jarabe altamente corrosivo corrió por las escaleras y las paredes internas, lo que hizo que la fábrica quedara inutilizable durante dos años mientras se destruía y reconstruía…) ¿Qué pasa con el alcance? Una instalación es fácil de planificar. ¿Qué pasa con un desastre regional (huracán/terremoto/tormenta de nieve) que afecta a su organización junto con las familias de los empleados además de su cadena de suministro regional? ¿O una pandemia global, para el caso?- Ver la planificación de desastres como un problema de TI
Las interrupciones en las operaciones son un problema organizacional, no un problema departamental o tecnológico. Cuando llega un huracán y los empleados intentan llevar a las familias a un lugar seguro, ¡no vienen a trabajar! - Cambios en el stack tecnológico
Suponga que mantiene un “sitio de desastre” (una noción obsoleta). Descubrirá que ponerlo en marcha cuando ocurre un desastre (en medio de la noche en un fin de semana festivo mientras hay una tormenta) no será fácil porque faltarán piezas o se romperán, y los cambios en su entorno de “producción” son necesarios y que no se refleja en su sitio de riesgo de desastres (DR). - Restauración
Incluso las organizaciones que se toman en serio la recuperación ante desastres a menudo olvidan que regresar a los sitios primarios cuando termina el desastre puede ser bastante complejo, con la necesidad de sincronizar los datos y que los sistemas funcionen normalmente.
- Ver la planificación de desastres como un problema de TI
Consejo de supervisión de TI n.º 3: Pase de una mentalidad de “planificación ante desastres” a una mentalidad de “disponibilidad distribuida continua”, en la que cualquier desastre local o regional desplaza el trabajo de los sitios afectados a otros sitios en áreas no afectadas. Si no puede adoptar ese enfoque, haga una prueba de estrés de sus planes de desastre utilizando resultados comerciales (por ejemplo, procesar pedidos de clientes) en lugar de objetivos de TI, como “Poner en funcionamiento el servidor ‘x'”.
Deuda técnica
La historia de SWA está llena de referencias a la “deuda técnica”, aldo de lo que recientemente hablé en profundidad con Bob Evans. Definámoslo: la deuda técnica es la suma total del mantenimiento de los componentes de TI (hardware, software, red) que debería haberse realizado pero que no se realizó nunca. Como cualquier máquina compleja, un automóvil o una fábrica de automóviles, su “stack” de hardware y software de TI necesita mantenimiento. Los dispositivos físicos se rompen o desgastan; los cables se deshilachan; los socios comerciales cambian sus sistemas de manera que deben ser acomodados a dichos cambios; los ciber-atacantes descubren debilidades que requieren parches; los proveedores actualizan su software para corregir errores y agregar funciones.
Puede ser tentador aplazar el mantenimiento de TI para ofrecer nuevas capacidades, lo que genera buena voluntad y bonificaciones para el equipo de TI. Después de todo, nadie recibe elogios por actualizar cosas que parecen estar funcionando, especialmente cuando algunas de esas actualizaciones causan problemas a los empleados y clientes. Pero, si está bien administrar la acumulación de proyectos de mantenimiento de TI para minimizar las interrupciones y favorecer nuevas funciones interesantes, posponer el mantenimiento durante meses o años tiene consecuencias nefastas, como lo vio el mundo recientemente con Southwest Airlines.
El aumento de la deuda técnica debilita el stack de TI lentamente, pero la manifestación de esa debilidad ocurre repentinamente y con frecuencia cuando la organización está estresada por el volumen adicional (consulte “Riesgo de capacidad” más arriba), por la implementación de nuevos sistemas (consulte “Riesgo del proyecto”) o por presiones externas (consulte “Riesgo de desastres”), es decir, cuando la organización es más vulnerable y los recursos se estiran al límite.
El mayor problema con la deuda técnica es que, por lo general, no está documentada ni administrada: TI rara vez mantiene una lista de tareas de mantenimiento que no se están realizando; ni GAAP (principios de contabilidad generalmente aceptados) ni IFRS (Normas Internacionales de Información Financiera) requieren ninguna documentación; los líderes empresariales no han sido capacitados para preguntar al respecto. Nadie está realmente incentivado a arreglarlo. Pienso en la deuda técnica como un “pasivo fuera de balance” que deberá pagarse algún día.
Consejo de supervisión de TI n.° 4: los ejecutivos comerciales deben considerar la deuda técnica al tomar decisiones comerciales, incluidas las decisiones de fusiones y adquisiciones. Los proyectos deben presupuestarse en función de los “costos totales del ciclo de vida” en lugar de solo los costos iniciales de implementación (CFO , les estoy mirando directamente a ustedes). Los CIO deben ser lo suficientemente valientes como para resistir la presión de “hacer más con menos” cuando presupuestan proyectos, especialmente cuando están sacando un agujero de la deuda técnica (¿Cuál es el primer paso para llenar un agujero? ¡Deje de cavar!).
Y alguien con las conexiones adecuadas, que convenza a FASB (Junta de Normas de Contabilidad Financiera) y PCAOB (Junta de Supervisión de Contabilidad de Empresas Públicas) para que incluyan la deuda técnica en los balances de las empresas; de ese modo los inversores puedan obtener una imagen más clara del riesgo cada vez mayor que enfrentan las empresas como ¡La automatización se vuelve más generalizada!
Pensamientos finales
¿Qué significa todo esto para la alta dirección y los ejecutivos de gobierno de una organización?
- Comprenda todos sus riesgos tecnológicos, no solo la ciberseguridad
- Comprenda su deuda técnica y cómo se alinea con su tolerancia al riesgo
- Reclutar a un director experto en tecnología calificado (QTE) para la junta para fortalecer la supervisión de los riesgos y oportunidades tecnológicos
Autor: Wayne Sadin
Artículo original aquí
