Explicaciones muy resumidas sobre el change management process, en 5 etapas.
Comentarios
La idea básica es: no haría falta un proceso de gestión de cambios si cada vez que una modificación en la infraestructura (u otro componente de la organización IT), se hiciera, se lo manejara ordenadamente, sabiendo qué se va a cambiar, por qué, donde se va a cambiar algo, cual es el plan y fecha para ello, quien va a hacer el cambio, los pasos para verificar el que cambio funcionó, y cual es el procedimiento para retroceder los cambios y dejar todo exactamente como estaba antes, documentar todo y archivar.
Como ese orden no suele darse en gral. por varios motivos, culturales-humanos-organizacionales típicamente, un proceso formal de gestión de cambios ayuda a crear la estructura organizacional pertinente para hacer cambios en IT que funcionen. En la práctica, le brinda a los gestores IT (managers, administradores, etc.), la posibilidad de decirle a la organización "este cambio lo estamos analizando", en vez de tener que salir corriendo como chico de los mandados, cuando altas autoridades organizativas exigen inmediatez en algo que no se puede hacer - bien - de inmediato (y que en gral. es muy difícil explicarles y que lo entiendan cada vez que lo piden).
1) Filtrar los Pedidos de Cambio (Request for Change - RFC)
Especificar detalles del cambio necesario y enviarlos al Grupo de Asesoría de Cambios (Change Advisory Board - CAB). El CAB es una entidad que incluye representantes de varias áreas, como servidores y networking, seguridad, desarrollo y adm. de bases de datos. Otros miembros pueden representar áreas legales, administrativas y de operación de la organización. El cambio debe ser evaluado y estudiado en sus efectos prácticos y en la factibilidad de evitar duplicación de esfuerzos o implementaciones no funcionales.
2) Asesorar el Impacto del Cambio
Luego de tener una lista de los cambios requeridos, necesitamos priorizar el cambio asesorando respecto del costo involucrado, beneficios, riesgos percibidos y posibles impactos del cambio pedido.
3) Autorizar el Cambio
Típicamente hay terceros involucrados en el cambio, debemos usar su expertise en la evaluación del impacto total del cambio. El CAB debe proveer detalles minuciosos al Administrador del Cambio antes de que el Cambio se aprobado y agendado.
4) Revisión del Cambio
Podemos revisar el proceso completo para señalar aquellas cosas bien hechas y las que no fueron bien hechas luego de que el cambio fue implementado. Esta práctica nos ayuda a mejorar el proceso de gestión de cambios. El procedimiento de retroceso del cambio siempre se necesita si los cambios realizados no funcionan como se esperaba y crearon resultados negativos.
5) Cerrar el Pedido de Cambio
Finalmente, el cambio es revisado y por el usuario que ha pedido el cambio en la RFC, y ésta debería ser cerrada formalmente. Todas las configuraciones cambiadas deberían ser apropiada y sistemáticamente documentadas, aprobadas, comentadas; planes de testing de esos cambios y de retroceso para deshacer el cambio, además de otra documentación técnica accesoria deberían ser archivados de acuerdo a la política de la organización.
Documentación y Links
Una introducción para comenzar (español):
Gestión de servicios de tecnologías de la información
Cambios, explicado por extensión, detalle por detalle (excelente resumen y explicación):
Change Management: Best Practices
Y en "jerga" ITIL para los entusiastas (casi sin detalles útiles):
No hay comentarios:
Publicar un comentario