[et_pb_section fb_built=\u00bb1″ admin_label=\u00bbSection\u00bb _builder_version=\u00bb4.22.0″ _module_preset=\u00bbdefault\u00bb custom_margin=\u00bb0px||0px||false|false\u00bb custom_padding=\u00bb0px||0px||false|false\u00bb locked=\u00bboff\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_row column_structure=\u00bb1_4,3_4″ _builder_version=\u00bb4.27.0″ _module_preset=\u00bbdefault\u00bb custom_padding=\u00bb50px||||false|false\u00bb custom_css_main_element=\u00bbz-index:0!important;\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_column type=\u00bb1_4″ disabled_on=\u00bbon|on|off\u00bb _builder_version=\u00bb4.22.0″ _module_preset=\u00bbdefault\u00bb custom_padding=\u00bb||||false|false\u00bb sticky_position=\u00bbtop\u00bb sticky_offset_top=\u00bb100px\u00bb sticky_limit_bottom=\u00bbsection\u00bb motion_trigger_start=\u00bbtop\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_text admin_label=\u00bbindice\u00bb _builder_version=\u00bb4.27.0″ _module_preset=\u00bbdefault\u00bb custom_margin=\u00bb||0px||false|false\u00bb custom_padding=\u00bb||14px||false|false\u00bb link_option_url=\u00bb#1″ global_colors_info=\u00bb{}\u00bb]<\/p>\n
Secciones<\/strong><\/p>\n [\/et_pb_text][\/et_pb_column][et_pb_column type=\u00bb3_4″ _builder_version=\u00bb4.27.0″ _module_preset=\u00bbdefault\u00bb custom_css_main_element=\u00bbz-index:0!important;\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_text admin_label=\u00bbseccion\u00bb module_id=\u00bb1″ module_class=\u00bbittopicscontent\u00bb _builder_version=\u00bb4.27.0″ _module_preset=\u00bbdefault\u00bb z_index=\u00bb0″ custom_margin=\u00bb0px||0px||true|false\u00bb custom_padding=\u00bb0px||0px||false|false\u00bb custom_css_main_element=\u00bbfont-family:%22Pandora-Light%22;\u00bb locked=\u00bboff\u00bb global_colors_info=\u00bb{}\u00bb]Her\u00e1clito dijo que nunca te ba\u00f1as dos veces en el mismo r\u00edo, dejando claro que el cambio es lo \u00fanico que existe… Y lo que m\u00e1s sudores fr\u00edos provoca en tecnolog\u00eda. La diferencia entre que esas transformaciones nos acerquen a nuestros objetivos, o nos arrastren como un caballo sin riendas, es una adecuada gesti\u00f3n del cambio en IT<\/a>. Por eso, he aqu\u00ed una gu\u00eda completa. \u00bfQu\u00e9 es m\u00e1s veloz, la luz o los cambios en tecnolog\u00eda? Ya sea por seguridad o competitividad, el cambio en IT es constante y vertiginoso. Y su gesti\u00f3n se refiere a c\u00f3mo las organizaciones planifican, implementan y controlan dichos cambios en sus sistemas, procesos, tecnolog\u00edas o infraestructuras de TI. <\/strong> Un inciso para matizar la diferencia entre IT Change Management y Release Management. El cambio en IT es un concepto amplio que abarca:<\/p>\n As\u00ed los gestores del cambio se enfrentan a dos aspectos muy diferentes.<\/p>\n Como vemos, estamos abriendo un abanico m\u00e1s complejo de lo que parece. Por eso, mejor que lo hagamos met\u00f3dicamente.<\/p>\n El 1 agosto de 2012 amaneci\u00f3 como cualquier otro d\u00eda perezoso de verano. Knight Capital, el mayor trader de valores estadounidenses, se preparaba para mover sus m\u00e1s 21.000 millones de d\u00f3lares diarios en los mercados… Todo empieza por un motivo, como la mejora continua de procesos y que, por ejemplo, el equipo de desarrollo pida migrar a la nube. O que se produzca un requerimiento externo, como cumplir la ISO 27001<\/a> de ciberseguridad.<\/p>\n Aqu\u00ed entran en juego conceptos clave de la gesti\u00f3n del cambio en IT como es el CAB (Change Advisory Board), el comit\u00e9 asesor en la gesti\u00f3n del cambio en IT<\/strong>, que eval\u00faa, prioriza y aprueba esos cambios y est\u00e1 formado por:<\/p>\n As\u00ed, el CAB identifica riesgos (latencia, costos, procesos afectados…) y metas deseadas.<\/p>\n Si se aprueba, este cambio puede ser total, parcial y\/o con condiciones (como que se hagan una serie de pruebas previas y en ellas se alcancen determinados objetivos, por ejemplo).<\/p>\n Esta detalla las tareas a realizar, fechas y responsables, as\u00ed como las mejores pr\u00e1cticas para asegurar la menor disrupci\u00f3n <\/Strong>de los procesos de la empresa. Que no es m\u00e1s que llevar lo planificado a la realidad.<\/p>\n Cuando Napole\u00f3n dijo que ning\u00fan plan aguantaba el contacto con la realidad, no hablaba de IT, pero podr\u00eda haberlo hecho, de ah\u00ed la necesidad de:<\/p>\n Si ha salido bien, documentamos y, por ejemplo, si hemos trasladado servicios a la nube, actualizamos la CMDB (Configuration Management Database) con la informaci\u00f3n pertinente.<\/p>\n Visto el ciclo de vida, debemos tener en cuenta que gran parte de la vertiente \u00abexterna\u00bb de cambios vendr\u00e1 de los usuarios, mediante incidencias y peticiones<\/Strong>. La gesti\u00f3n del cambio en IT es un core process del ITSM<\/A> (Gesti\u00f3n de Servicios de TI), adem\u00e1s de jugar un papel cr\u00edtico en el Service Desk, el punto de contacto con el usuario y puerta de entrada de muchos cambios<\/Strong>, motivados por subsanaciones de errores o peticiones de mejora de procesos. Dado que muchos cambios provendr\u00e1n de los usuarios, es fundamental automatizar en lo posible, integrando con herramientas de gesti\u00f3n de tickets, que agilicen y tracen esos cambios.<\/p>\n El avance de nuestros proyectos IT tambi\u00e9n motivar\u00e1 cambios. De ah\u00ed la importancia de integrar tambi\u00e9n un control de cambios en gesti\u00f3n de proyectos En tecnolog\u00eda, tenemos que atender a muchos amos. Por eso, la gesti\u00f3n del cambio no tiene en cuenta solo lo que surge de usuarios, proyectos o motivos externos (nueva legislaci\u00f3n, por ejemplo), sino que tambi\u00e9n es necesario considerar estos desaf\u00edos adicionales:<\/p>\n Estas m\u00e9tricas variar\u00e1n seg\u00fan el cambio concreto, pero abarcan dos \u00e1mbitos.<\/p>\n Nosotros quer\u00edamos ser tecn\u00f3logos y acabamos siendo malabaristas, con demasiadas cosas en el aire que parecen a punto de caer. Esa sensaci\u00f3n es habitual en la gesti\u00f3n de cambios<\/strong>, por eso la importancia de aplicar metodolog\u00edas probadas.<\/p>\n Estas recogen las mejores pr\u00e1cticas de gesti\u00f3n del cambio en IT y las principales son:<\/p>\n Es decir, Information Technology Infrastructure Library o Biblioteca de Infraestructura de Tecnolog\u00edas de Informaci\u00f3n. Un modelo desarrollado por Prosci<\/A> y centrado en el factor humano<\/Strong>. De ah\u00ed que el acr\u00f3nimo haga referencia a las 5 etapas que define para la adopci\u00f3n del cambio: Awareness, Desire, Knowledge, Ability, Reinforcement (Conciencia, Deseo, Conocimiento, Habilidad, Refuerzo). Desarrollado por John P. Kotter, propone 8 pasos para un cambio exitoso, desde establecer un sentido de urgencia, hasta la comunicaci\u00f3n y el empoderamiento. Creado por Kurt Lewin, solo tiene 3 etapas<\/strong>: Descongelaci\u00f3n (preparar cambio), el cambio en s\u00ed y la Recongelaci\u00f3n o estabilizaci\u00f3n del cambio.<\/p>\n La tecnolog\u00eda hace que los cambios sean complejos, pero tambi\u00e9n viene en nuestra ayuda. Por eso, la implementaci\u00f3n de procesos estructurados de cambio dentro de un marco de gobernanza IT precisa herramientas especializadas, como Pandora ITSM<\/a>. Pandora ITSM permite un control total del cambio durante todo su ciclo de vida, pudiendo gestionar:<\/p>\n Las mejores herramientas son reflejo de las mejores pr\u00e1cticas, y Pandora ITSM recoge los m\u00e9todos probados m\u00e1s exitosos en cada paso.\n
\nEn ella veremos el ciclo de vida de esa gesti\u00f3n, metodolog\u00edas, ejemplos y herramientas para navegar un r\u00edo lleno de r\u00e1pidos y rocas.<\/p>\nQu\u00e9 es la gesti\u00f3n del cambio en IT<\/h2>\n
\nEl objetivo es minimizar riesgos y asegurar que los cambios se realicen de manera eficiente, sin afectar negativamente a los SLAs.
\nDicho de otra manera, es un proceso estructurado<\/strong> que asegura que cualquier modificaci\u00f3n tecnol\u00f3gica (nuevo software, actualizaciones, cambios de configuraci\u00f3n, etc.) se haga de manera controlada y documentada para que:<\/p>\n\n
La diferencia entre la gesti\u00f3n del cambio y el Release Management<\/h2>\n
\nEl Release Management se enfoca en planificar, programar y controlar el despliegue de nuevas versiones de software, hardware o servicios<\/strong>. Por tanto, es solo una parte de la gesti\u00f3n del cambio en IT.
\nEste se enfoca en controlar y supervisar cualquier modificaci\u00f3n en los sistemas, procesos o infraestructuras de IT<\/strong>, no solamente nuevas versiones.<\/p>\n\u00bfC\u00f3mo funciona la gesti\u00f3n del cambio en IT?<\/h2>\n
\n
\n
El ciclo de vida de la gesti\u00f3n del cambio en IT<\/h2>\n
\nPero todo cambi\u00f3 con un clic.
\nAquella ma\u00f1ana implementaron un cambio en el software de compraventa, aplic\u00e1ndolo en sus 8 servidores. Sin embargo, no hab\u00eda plan, proceso escrito o gesti\u00f3n de cambios en IT. El despliegue fue a mano y el ingeniero encargado no copi\u00f3 el nuevo c\u00f3digo en uno de los servidores.
\nTampoco hab\u00eda un segundo ingeniero que revisara lo hecho, ni un sistema de alertas que hubiera detectado la discrepancia entre servidores. Y cuando abrieron los mercados, tambi\u00e9n lo hicieron las puertas del desastre.
\nEl software comenz\u00f3 a realizar compras y ventas fren\u00e9ticas que causaban p\u00e9rdidas millonarias cada segundo.
\nUn clic, una ma\u00f1ana, un cambio que termin\u00f3 con la compra de Knight Capital<\/a> a precio de saldo<\/strong> por un competidor.
\nEsas son las consecuencias de no gestionar los cambios en IT siguiendo las mejores pr\u00e1cticas. Y aunque existen varios marcos de trabajo, que veremos m\u00e1s adelante, este es el ciclo de vida natural de un cambio.<\/p>\nSolicitud del cambio<\/h3>\n
Evaluaci\u00f3n del cambio y sus alternativas<\/h3>\n
\n
Aprobaci\u00f3n o rechazo del cambio<\/h3>\n
Planificaci\u00f3n del cambio<\/h3>\n
\nPor ejemplo, aqu\u00ed se establecer\u00eda la ventana de cambio, como un s\u00e1bado a la una de la madrugada, porque es cuando menos se visita la web a modificar. O bien, si se trata de algo que afecta a \u00e1reas cr\u00edticas, se planean pruebas en un entorno de staging o se usan otras pr\u00e1cticas emergentes en gesti\u00f3n de cambios, como un gemelo virtual.
\nAs\u00ed, construir\u00edamos un gemelo de nuestros sistemas de manera virtual, implementando primero el cambio en \u00e9l y comprobando qu\u00e9 ocurre. Del mismo modo, planteamos un plan de rollback para que, si sale mal, \u00abpulsemos Ctrl+Z\u00bb.
\nLa metodolog\u00eda ITIL<\/a> engloba estas fases de evaluaci\u00f3n, aprobaci\u00f3n y planificaci\u00f3n en una sola (llamada \u00abEvaluaci\u00f3n y planificaci\u00f3n\u00bb). Aunque sigo este marco de referencia, he desglosado sus tres principales componentes para verlos m\u00e1s claramente.<\/p>\nImplementaci\u00f3n del cambio<\/h3>\n
Revisi\u00f3n del cambio<\/h3>\n
\n
Documentaci\u00f3n<\/h3>\n
Las dos vertientes del cambio en IT<\/h2>\n
\nPor otro lado, gran parte de la vertiente \u00abinterna\u00bb vendr\u00e1 del desarrollo de nuestros propios proyectos.
\nPor eso, es fundamental integrar y automatizar en lo posible ambas cosas. Ah\u00ed es donde entran el Service Desk, que traer\u00e1 muchos cambios externos, y las herramientas de gesti\u00f3n de proyectos y procesos empresariales<\/a>, que motivar\u00e1n buena parte de los internos.
\nVeamos estos dos aspectos m\u00e1s a fondo.<\/p>\nGesti\u00f3n del cambio en ITSM y Service Desk<\/h2>\n
\nSeg\u00fan la metodolog\u00eda ITIL, los cambios pueden ser:<\/p>\n\n
Gesti\u00f3n del cambio en Project Management<\/h2>\n
\nEl manifiesto Agile establece que: \u00abLos cambios en requerimientos son bienvenidos\u00bb (no s\u00e9 si ese es el sentimiento real en el d\u00eda a d\u00eda, pero bueno), y en Scrum, el backlog de producto define esos cambios, que deben priorizarse por importancia y dividirse en cambios m\u00e1s peque\u00f1os cuando este es muy grande<\/strong>.
\nSin embargo, en la gesti\u00f3n \u00e1gil del cambio tambi\u00e9n existe el principio de \u00abproteger el sprint\u00bb, de modo que, cuando en el backlog del sprint aparece un cambio, no corremos a implementarlo. Analizamos y, muchas veces, solo implementaremos cambios de emergencia, especialmente cuando los no urgentes comprometen el sprint actual, integr\u00e1ndolos ya en el siguiente.
\nEn este contexto, DevOps y la automatizaci\u00f3n son aliados clave. Los pipelines de CI\/CD (como Jenkins o GitLab CI) permiten implementar cambios en c\u00f3digo de forma \u00e1gil. Mientras, herramientas de infraestructura como c\u00f3digo (Terraform, Ansible) garantizan que cada modificaci\u00f3n en servidores o redes sea trazable y reversible. As\u00ed, incluso cambios complejos se gestionan con la agilidad que exigen metodolog\u00edas como Scrum.
\nAl final, proyectos de TI y reformas en casa se parecen demasiado. Esas \u00abpeque\u00f1as modificaciones\u00bb que surgen multiplican tiempos y presupuestos. Si no queremos que el cronograma se estire m\u00e1s all\u00e1 del universo conocido, debemos controlar bien ese flujo de cambios.<\/p>\nSeguridad, cumplimiento y desaf\u00edos en la gesti\u00f3n del cambio en IT<\/h2>\n
\n
KPIs y m\u00e9tricas para evaluar la efectividad de los cambios<\/h3>\n
\n
\n
Metodolog\u00edas para gesti\u00f3n del cambio IT<\/h2>\n
ITIL<\/h3>\n
\nEs el marco de trabajo de referencia<\/strong> y el que permea toda esta gu\u00eda. Contiene un conjunto de mejores pr\u00e1cticas para la gesti\u00f3n de servicios de TI, definiendo procesos estandarizados para evaluar, aprobar e implementar cambios.<\/p>\nADKAR<\/h3>\n
\nCuando se trata de cambios que requieren adopci\u00f3n de nuevas tecnolog\u00edas o formas de trabajo<\/strong>, puede ser el m\u00e1s adecuado.<\/p>\nKotter<\/h3>\n
\nDe nuevo, es un marco de trabajo que enfatiza la importancia de las personas<\/strong>, el factor m\u00e1s complejo en muchas ocasiones.<\/p>\nLewin<\/h3>\n
La gesti\u00f3n del cambio en entornos IT modernos<\/h2>\n
\nLa herramienta entiende que los cambios son un core process cr\u00edtico en ITSM<\/a> y aplica las mejores pr\u00e1cticas para crear, aprobar, implementar y auditar dichos cambios en IT de manera estructurada y automatizada<\/strong>.
\nAs\u00ed no seremos el siguiente Knight Capital que alguien cite de ejemplo sobre c\u00f3mo no gestionar el cambio en IT.<\/p>\nEl flujo del proceso de cambio en Pandora ITSM<\/h3>\n
\n
\nDel mismo modo, integra la capacidad de definir esos cambios como est\u00e1ndar, normal y de emergencia (siguiendo el marco ITIL) y controlarlos.
\nLos cambios son como ni\u00f1os peque\u00f1os, los pierdes de vista un instante y enseguida huele a quemado. La trazabilidad con Pandora ITSM permite saber siempre en qu\u00e9 punto est\u00e1n y recoger toda la informaci\u00f3n<\/strong> para posibles auditor\u00edas internas o externas.
\nAdem\u00e1s, implementa caracter\u00edsticas que hacen la gesti\u00f3n y el control de cambios en ITSM lo m\u00e1s f\u00e1cil e indoloro posible, como:<\/p>\n