La gestión de cambios es una parte esencial de la gestión de servicios de IT (ITSM). Y es un andar en la cuerda floja entre la implementación del cambio lo más rápido posible y la mitigación de los riesgos. Estos últimos aumentan cuando se trata de una actualización de emergencia. A propósito de ello, según Harvard Business Review, el 70% de las iniciativas de cambio fracasan.
Pero los cambios de emergencia son importantes, esenciales para que la empresa siga fluyendo y, también, para atenuar las pérdidas. Exploremos el proceso de control de cambio de emergencia y sus cinco mejores prácticas.
El cambio en ITIL
La gestión de cambios es un proceso utilizado para garantizar que un cambio dentro de la infraestructura de IT se gestiona con la menor interrupción de los servicios informáticos y el menor impacto en los procesos de negocio. Desde la perspectiva de ITIL, el cambio puede ser cualquier cosa, desde la migración a una solución de service desk diferente o de una infraestructura on-premise a la nube.
Hay diferentes categorías de cambio con diversos pasos: comienza con la presentación, donde se hacen las solicitudes de cambio y se crean los tickets; la fase de planificación, en la que se calcula el tiempo previsto, las interrupciones del servicio, etc., y se transmite toda la información a las partes interesadas; luego se aprueba el plan por el consejo asesor de cambios; la implementación del cambio propiamente dicha; la etapa de revisión, en la que se solucionan los problemas que hayan surgido durante la aplicación; y por último, el cierre, donde el cambio se marca como exitoso, fallido o incompleto.
Desde ITIL 4, la gestión del cambio se convirtió en la habilitación del cambio. Esta denominación diferente implicaba que la responsabilidad del cambio se compartía entre todos los empleados de la organización y que, en lugar de gestionar el cambio, se facultaba a los trabajadores para que lo realizaran ellos mismos.
¿Cuándo un cambio se convierte en un cambio de emergencia?
Según ITIL, hay principalmente tres tipos de cambio: cambio estándar, cambio normal y cambio de emergencia.
El estándar es un cambio común o que ocurre con frecuencia y de forma rutinaria. No hay nada especial o específico en él y suele seguir un conjunto de pasos repetibles. Al ser de rutina, requiere una mínima planificación.
Además, es fácil de predecir y, por tanto, puede automatizarse. Rara vez presenta problemas. En todo caso, los riesgos asociados a él se calculan mucho antes de diseñar la rutina de cuestiones como actualizaciones de hardware, parches de software, etc., todos ellos denominados cambios estándar.
El normal se sitúa entre el cambio estándar y el de emergencia. No es rutinario. Requiere una cuidadosa planificación y aprobación antes de su aplicación.
Un cambio normal presenta riesgos desconocidos y no puede llevarse a cabo con pasos repetibles como un cambio estándar. Suele necesitar un plan y una implementación únicos. En función del riesgo y el impacto, los cambios normales se clasifican en mayores (alto riesgo, alto impacto) y menores (bajo riesgo, bajo impacto).
Por último, se considera un cambio de emergencia cuando debe realizarse lo antes posible, cuando los retrasos en el cambio pueden ser extremadamente costosos para la organización o crear una interrupción sostenida del servicio, un parche de seguridad contra una enorme vulnerabilidad o una interrupción del servidor.
Como el tiempo es esencial, se hacen concesiones en las pruebas y en el proceso de aprobación para que la implementación sea más rápida. Incluso a menudo se acepta un mayor nivel de riesgo.
Aunque rara vez predecibles, son cruciales para la prestación continua de servicios. La organización y su ITSM deben estar preparados para los cambios de emergencia ya que garantizarán una experiencia de usuario consistente.
¿Qué recomienda ITIL para el proceso de control del cambio de emergencia?
Según ITIL, el proceso de cambio de emergencia debe comenzar creando una solicitud de cambio. El gerente de cambios lo informará al Consejo Asesor de Cambios de Emergencia o Emergency Change Advisory Board (ECAB) -compuesto por miembros del Consejo Asesor de Cambios, que estén disponibles y tengan la experiencia y la autoridad para tomar decisiones con respecto al cambio-.
Los miembros del ECAB son responsables de sopesar los riesgos de aplicar el cambio propuesto como cambio de emergencia y los riesgos de retrasarlo e implementarlo como normal. En algunos casos, si los riesgos superan a los beneficios, el ECAB puede decidir proceder a un cambio normal.
Si el ECAB aprueba el cambio, el propietario lo planificará y diseñará. También es responsable de construir y probarlo si es necesario. Luego coordinará su aplicación. La base de datos de gestión de la configuración se actualizará para reflejar los cambios durante la fase de implementación.
Una vez implementado, el propietario del cambio lo revisará para marcarlo como un éxito o un fracaso.
En el caso de este último, iniciará el proceso de retirada, un elemento bastante exclusivo de los cambios de emergencia que se utiliza para devolver los sistemas al estado inicial si el cambio falla, o si presenta nuevos riesgos o problemas.
En la práctica, esto significa que el cambio de emergencia se maneja como una versión acelerada de uno normal. Como no será algo esperado o rutinario, se necesitarán enfoques únicos para abordarlo. Pero debido a la variable tiempo, la aprobación y las pruebas serán limitadas. Y, a menudo, el ECAB aceptará un mayor nivel de riesgo, ya que los retrasos pueden resultar costosos.
Mejores prácticas para gestionar un proceso de control del cambio de emergencia
Establece normas para clasificar los cambios como de emergencia o normales
Uno de los puntos más discutidos sobre la gestión del cambio es decidir si debe ser tratado como normal o de emergencia. Es fácil clasificar los extremos de ambos: la mitigación de un ciberataque sería un cambio de emergencia, mientras que una actualización se ubicaría como uno normal.
Pero los límites a menudo se difuminan, por ejemplo, cuando una actualización bloquea procesos empresariales clave. O, incluso, la organización puede hacer que los solicitantes traten todos los cambios como emergencias. Por ejemplo, si el consejo consultivo sólo se reúne cada dos meses, no será posible esperar tanto tiempo para que se apruebe el cambio, por lo que lo presentan como una emergencia.
Pero hay que tener en cuenta que los cambios de emergencia involucran grandes riesgos para la organización, ya que la prioridad es la rapidez. Por eso es importante establecer normas para clasificarlos como de emergencia o normales.
Si hay demasiados cambios de emergencia, debes entender por qué
Como se ha mencionado anteriormente, demasiados cambios de emergencia pueden añadir riesgos innecesarios a la organización. Y en algún momento, estos riesgos superarán los beneficios. Por lo tanto, hay que seguir monitoreando el panorama general en lo que respecta a los cambios en toda la organización.
Analiza el número de cambios normales, estándar y de emergencia, cuántos de ellos tuvieron éxito, cuántos de los considerados de emergencia fueron realmente así y si los riesgos valieron la pena. Esto debería ayudarte a entender si tienes demasiados cambios de emergencia.
Si es así, intenta entender por qué. Tal vez se trata de una cultura organizacional que fomenta un comportamiento de alto riesgo a cambio de rapidez. O podría tratarse de una tendencia pasajera: probablemente te estés defendiendo de una serie de ciberataques.
En cualquier caso, hay que centrarse en reducir los cambios de emergencia a largo plazo. Se trata de un delicado equilibrio; si se inculca la cultura de tratar todos los cambios como algo normal, es posible que tengas que hacer frente a costos significativos cuando los servicios no están operativos durante mucho tiempo.
Asegúrate de que el equipo del ECAB tiene la experiencia y la autoridad para aprobar el cambio
Es relativamente fácil crear un Consejo Asesor de Cambios con miembros que tengan la experiencia y la autoridad necesarias para el cambio, pero requiere un poco más de esfuerzo el ECAB. Cuando la variable tiempo es importante, no es fácil conseguir que todos los miembros discutan y aprueben el cambio, por eso existe el ECAB. Pero esto no significa que personas sin experiencia deban tomar la decisión.
Es una buena idea conocer la cadena de mando y el campo de experiencia del Consejo Asesor de Cambios para saber quién podría formar el ECAB. Por ejemplo, en el caso de aislar una red para mitigar un ciberataque, los ingenieros de redes serán fundamentales.
Y al mismo tiempo, sería prudente no depender de una sola persona por su experiencia en un tema. Los cambios de emergencia no deberían retrasarse sólo por la ausencia de un individuo.
Arregla primero, (pero definitivamente) documenta después
Como los retrasos en los cambios son costosos, hay que idear soluciones rápidas y desplegarlas en el menor tiempo posible. Y aunque documentar los cambios y su impacto es importante, la prioridad debe ser la implementación. Entonces, concéntrate en el diseño de la solución y en la planificación de su puesta en marcha.
Pero una vez aplicado, el cambio y los componentes afectados deben ser rastreados y documentados, tanto para el soporte posterior como para la claridad del equipo de IT.
No olvides la comunicación
Cuando los cambios se implementan rápidamente, la comunicación suele pasar a un segundo plano; y es razonable. Utilicemos la analogía del avión: cuando un avión se cae en picada, el primer trabajo de los pilotos no es anunciar a los pasajeros que los motores están en llamas o que hay humo en la cabina.
Pero una vez que los cambios se aplican y el humo se disipa, es importante informar a las partes interesadas, a los empleados y a los usuarios de la necesidad del cambio, de qué ha cambiado y cómo los afectará. Para utilizar de nuevo la analogía de la aviación, es una buena idea tener en mente el acrónimo ANC: Aviate, Navigate, Communicate. Haz que tu avión vuelva a volar, dirígelo en la dirección correcta y comunícalo a los actores afectados.
|
|
"Tu enfoque para gestionar el cambio no debería ser drásticamente diferente al típico proceso de gestión del cambio. La principal diferencia es la rapidez con la que se debe comunicar el cambio. Ema Roloff |
Preguntas frecuentes
¿Cuáles son los diferentes tipos de cambio en ITIL?
Los tres tipos de cambios son normales, estándar y de emergencia. Los estándar se llevan a cabo con frecuencia, son predecibles y suelen seguir una serie de pasos repetibles. Los normales son planificados, pero requieren un enfoque específico y único, y no son rutinarios. Los de emergencia son similares a los normales, pero responden a algo que requiere atención inmediata, como los problemas de seguridad. Suelen ejecutarse en un plazo más corto que los demás cambios.
¿Cuándo un cambio se convierte en un cambio de emergencia?
Cuando un cambio tiene que ejecutarse en un plazo corto y cuando los retrasos pueden ser costosos para la empresa, el cambio se vuelve de emergencia. Son necesarios para garantizar la continuidad del servicio y su prestación ininterrumpida.
