El mundo de los negocios es notorio por el uso de confusas palabras de moda y jerga de la industria. Este es el caso cuando se trata de diferenciar entre Cambio Estándar y Cambio Normal.
No es de extrañar que mucha gente se pregunte: «¿Cuál es la diferencia entre cambio normal y estándar?» Esto es especialmente cierto dado el hecho de que estándar y normal son sinónimos que son relativamente intercambiables en la mayoría de las circunstancias.
Antes de seguir avanzando en la madriguera del cambio, vamos a asegurarnos de que estamos en la misma página de lo que queremos decir cuando decimos «cambio» en primer lugar.
¿Qué es el cambio?
En el contexto del mundo empresarial de TI y, más concretamente, del mundo de la gestión de ITIL, el cambio se refiere a las modificaciones de las aplicaciones de software de la organización, ya sean aplicaciones internas o productos orientados al cliente. El cambio en este contexto incluye las actualizaciones del código y los sistemas existentes que se prueban y se implementan en entornos vivos.
Este proceso de gestión del cambio es manejado por el Gestor de Cambios y los Consejos Asesores de Cambios (CAB). El CAB generalmente maneja dos tipos principales de cambios sobre los que recopilan información antes de dar el visto bueno final para que se produzca la implementación:
- Cambio estándar
- Cambio normal
- Sustitución del ciclo de vida del hardware
- Parches y actualizaciones de software
- Cambios de cortafuegos
- Nuevas entradas DNS
- Implementar un parche de seguridad a un exploit de día cero
- Aislamiento de la red de un ataque de Denegación de Servicio Distribuido (DDoS) a gran escala
- BMC Service Management Blog
- Tipos & Niveles de gestión del cambio
- Gestión del cambio en la nube
- Gestión del cambio organizativo (OCM): A Template for Reorganizing IT
- Facilitating Change through Effective Communication
Estas definiciones y designaciones específicas podrían cambiar de una organización a otra dependiendo de sus necesidades, pero hay algunas reglas generales bajo las que tienden a operar. Comencemos a explorar estos procesos examinando un cambio estándar.
(Los cambios de emergencia, que repasaremos más adelante, son cambios que son más urgentes y delicados, manejados por la Junta Asesora de Cambios de Emergencia o ECAB, que suele ser un subconjunto del CAB.)
¿Qué es un cambio estándar?
Los cambios estándar, a veces llamados cambios de rutina, tienden a ser cambios preautorizados que se considera que tienen poco o ningún riesgo asociado. Son ocurrencias bastante comunes que tienen directrices y procedimientos específicos que siguen. Los cambios estándar se aplican a menudo con pasos repetibles que rara vez requieren modificaciones. El CAC no suele revisar cada caso de cambio estándar y, en su lugar, establece un protocolo y una visión general de las directrices para promulgar los cambios estándar.
Los cambios estándar suelen ser áreas en las que se puede implementar la automatización para ayudar a acelerar el proceso y aumentar la eficiencia. Estos cambios se han perfeccionado en un enfoque sistemático limpio y ordenado que da lugar al éxito de forma fiable. La automatización de aspectos de estos cambios Estándar puede reducir drásticamente el tiempo perdido en el proceso y liberar horas de trabajo para el trabajo que requiere un poco de ingenio humano.
La gestión de cambios ITIL define el Cambio Estándar como:
«Un cambio pre-autorizado que es de bajo riesgo, relativamente común y sigue un procedimiento o instrucción de trabajo».
Considere estándar como los servicios que TI ofrece a sus usuarios finales. Servicios como:
Todos ellos son ejemplos de tareas preautorizadas que TI puede seguir de forma inmediata una vez que surja una solicitud de cambio o un requisito. Tras la autorización de estos cambios, se requiere una planificación mínima para llevar a cabo el cumplimiento de una solicitud de cambio. Estos cambios suelen surgir como solicitudes de servicio por parte de los usuarios finales y se anticipan bien por adelantado, no necesariamente en términos de un plazo específico.
Los cambios estándar también pueden incluir cambios operativos que siguen un calendario específico, como los ciclos de actualización de las impresoras, las estaciones de trabajo y los dispositivos de red.
El procedimiento de implementación de cambios es sencillo y rara vez introduce un problema o riesgo. Antes de autorizar los cambios estándar, se ejecuta un procedimiento exhaustivo de evaluación de riesgos. Sólo un cambio de negocio o un incidente de TI requeriría una reevaluación de los riesgos asociados a los cambios estándar.
Se describe como un cambio estándar ya que la aprobación y autorización previa queda a discreción de la organización o del proveedor de servicios. El procedimiento implicado en la implementación del cambio está bien documentado. Los riesgos asociados se calculan y se contabilizan con suficiente antelación. Las medidas de mitigación de riesgos necesarias se adoptan como parte del procedimiento de implantación de cambios. Una vez que se recibe la solicitud de cambio, no se requiere ninguna aprobación adicional por parte de los responsables de la toma de decisiones o de la Junta Consultiva de Cambios (CAB).
Tener una solicitud de servicio de TI como un Cambio Estándar tiene sus ventajas desde la perspectiva de la Gestión de Servicios de TI (ITSM). El proceso de cambio fluye con una fricción mínima, especialmente cuando la información y los silos departamentales pueden causar retrasos y limitaciones innecesarias en la implementación del cambio. El hecho de contar con una autorización previa, un procedimiento de implementación documentado y una amplia evaluación de riesgos ya en marcha permite al departamento de TI prestar el servicio solicitado de forma eficiente y eficaz, que es exactamente el objetivo del marco ITIL asociado a la gestión de cambios.
Hay ocasiones en las que el CAC interviene y se da cuenta de que hay que añadir o eliminar elementos de la lista de cambios Estándar que requieren muy poca supervisión. Por lo general, un cambio Estándar se lleva a cabo sin problemas durante una ventana de mantenimiento programada y tiene poco, o ningún, impacto en los servicios en vivo. Esto contrasta directamente con los cambios de emergencia, que requieren una supervisión directa y una cuidadosa consideración.
¿Qué es un cambio de emergencia?
Los cambios de emergencia son básicamente lo opuesto a los cambios estándar. ITIL define el Cambio de Emergencia como:
«Un cambio que debe ser introducido lo antes posible».
Ejemplos de Cambio de Emergencia incluyen:
Estos cambios suelen representar una crisis o una oportunidad que debe ser abordada sin riesgo indebido. Por lo tanto, se espera un nivel de riesgo aceptable y se siguen procedimientos específicos como estrategia de mitigación de riesgos. También se requieren aprobaciones y autorizaciones específicas antes de implementar un cambio de emergencia.
Esto no significa largas reuniones entre los miembros del CAC, sino una supervisión de alto nivel sobre el proceso de gestión de cambios. El proceso debe seguir una acción rápida de todas las partes interesadas en cada etapa del proceso de gestión de cambios. Como resultado, los Cambios de Emergencia no se prueban a fondo y se toman las decisiones apropiadas como una compensación equilibrada entre el riesgo y la recompensa.
La agilidad de la organización determina lo bien que puede gestionar los Cambios de Emergencia. Sigue un flujo de proceso de gestión de cambios similar al de los Cambios Normales, pero en una escala de tiempo acelerada según las directrices de ITIL. La gestión exitosa de un Cambio de Emergencia determina la estabilidad de los servicios de TI proporcionados a los usuarios finales. Por lo tanto, el impacto de un Cambio de Emergencia debe ser documentado y evaluado para futuras mejoras en el proceso de gestión de cambios.
También debe incluir un proceso de remediación o back-out en los protocolos de gestión de Cambios de Emergencia. Esto es para que pueda restaurar el estado original cuando las actividades de implementación del cambio introduzcan riesgos y problemas adicionales.
No se producen en los momentos esperados y son cualquier cosa menos corrientes. Los cambios de emergencia se producen como respuesta a obstáculos imprevistos, como fallos de seguridad y exploits. Los cambios de emergencia se comunican inmediatamente a un gestor de cambios y luego se envían a la ECAB para su análisis. El deber de la ECAB es evaluar el riesgo de los cambios de emergencia propuestos y sopesar el peligro que el problema subyacente supone para la organización y sus servicios.
La ECAB trata de encontrar un remedio rápido pero eficaz para el problema recién descubierto y trabaja con un plazo ajustado que no deja espacio para la típica burocracia que conllevan la mayoría de las operaciones de cambio. Hay que recopilar y analizar rápidamente la información para decidir cuál es la mejor forma de solucionar el problema. Los cambios de emergencia se prueban rápidamente y se aplican de inmediato cuando son necesarios. El objetivo de los cambios de emergencia es afectar lo menos posible a los servicios activos y detener la hemorragia lo antes posible. Esto deja poca oportunidad para los procedimientos estándar, ya que la mayoría de las veces se requieren soluciones fuera de la caja.
Lo que queda en algún lugar en el medio del cambio de Emergencia y el cambio Estándar es el cambio Normal.
¿Qué es un cambio normal?
La mayoría de las organizaciones definen los cambios Normales como cualquier cambio que NO es un cambio de Emergencia o un cambio Estándar. Los cambios normales no están preautorizados como los cambios estándar, pero tampoco operan con el calendario más estricto y la naturaleza más salvaje de los cambios de emergencia que requieren la libertad de la burocracia y las directrices restrictivas. Los cambios normales pasan por el proceso del CAC para cada cambio que se realiza.
Esto permite la supervisión de los cambios y proporciona al CAC la oportunidad de evaluar si este cambio normal se produce con la suficiente frecuencia como para que se le puedan dar directrices repetibles que podrían convertirlo en un cambio estándar. Cada cambio normal se procesa como una solicitud de cambio (RFC), que se transmite al CAC y, en última instancia, es aprobada o rechazada por el gestor de cambios.
Los cambios normales son bastante comunes, pero suelen requerir enfoques algo únicos o novedosos, a diferencia de los cambios estándar, que generalmente pueden llevarse a cabo mediante el uso de guías paso a paso o algunos esquemas básicos. Los cambios normales se someten a una autoevaluación en la que el equipo analiza el cambio dentro del ámbito de la asignación y evalúa su viabilidad antes de presentarlo al CAC. El CAB revisa entonces el cambio propuesto y se asegura de que cumple con los protocolos de cumplimiento y seguridad antes de entregarlo finalmente al Gestor de Cambios para su aprobación final.
La ITIL define el Cambio Normal como:
«Un cambio que no es un cambio de emergencia o un cambio estándar. Los cambios normales siguen los pasos definidos del proceso de gestión de cambios».
Son los cambios que deben ser evaluados, autorizados y luego programados según un proceso estandarizado. Estos cambios se anticipan y se planifican con antelación y se pueden idear controles de gestión de cambios estandarizados adecuados en consecuencia. Sin embargo, el cambio normal se implementa sólo después de recibir la autorización y aprobación formal. Los cambios de bajo riesgo pueden requerir la autorización de los equipos locales de TI, mientras que los cambios de alto riesgo pueden requerir la aprobación del CAC o de los altos ejecutivos de la empresa y de TI. Todas las actividades dentro de los controles del proceso de gestión de cambios se practican para los Cambios Normales.
Los ejemplos pueden incluir la migración de los recursos de información críticos, las aplicaciones y las cargas de trabajo de los servidores locales a los centros de datos en la nube.
Definir los cambios como Normales reduce el riesgo para la organización y los proveedores de servicios de TI, ya que la planificación de cada cambio garantiza que los riesgos se mitigan cuidadosamente y las solicitudes de cambio producen los resultados deseados. Sin embargo, la implementación de los Cambios Normales también es un proceso largo y que requiere mucho tiempo. Además del proceso de aprobación y autorización, el proveedor de servicios necesita una fuerte visibilidad y control sobre el proceso de cambio, los sistemas sometidos y las dependencias asociadas.
La gestión e implementación de los Cambios Normales requiere, por tanto, de tecnologías ITSM avanzadas para analizar, probar, gestionar y ejecutar cuidadosamente el proceso y los sistemas de cambio. Una vez implementado el Cambio Normal, TI evalúa el éxito de la implementación y los requisitos futuros de cambios similares. Lo ideal es que TI madure su proceso de gestión de cambios, sus herramientas y sus capacidades para transformar un cambio normal en un cambio estándar. Esto reduce la carga de TI y de los proveedores de servicios para gestionar los cambios, a la vez que se gana control sobre el proceso de gestión de cambios como se consigue para los Cambios Normales.
Resumen
Este proceso de gestión de cambios ayuda a aumentar el éxito de las implementaciones a la vez que reduce el riesgo y minimiza el tiempo de inactividad. Los diferentes tipos de cambio y su categorización ayudan al buen funcionamiento de todo el proceso de cambio. Los cambios estándar se realizan con poca o ninguna supervisión, mientras que los cambios de emergencia requieren una gestión cuidadosa y un análisis detallado. Los cambios normales se sitúan felizmente entre estos dos extremos.
La distinción entre cambio estándar, normal y de emergencia debe observarse desde una perspectiva conceptual, más allá de las diferencias en la convención de nombres. Los términos Estándar y Normal pueden parecer sinónimos, pero las diferencias subyacentes representan la eficacia de los procedimientos y controles de gestión del cambio. Por lo tanto, es importante contar con una sólida práctica de habilitación de cambios para discriminar entre los tres tipos de cambio a través de una evaluación cuidadosa de las solicitudes de cambio y los incidentes que conducen a un requisito de cambio.
Estos tres tipos de cambio ayudan a las organizaciones a abordar los problemas a medida que ocurren mientras mantienen el ritmo constante que se espera de las organizaciones modernas de DevOps.