Cómo desarrollar un programa de administración de cambio de IT

Consigue aceptación al cambio en la empresa: La decisión de hacer un cambio es típicamente una decisión de negocio donde costos vs beneficios son comparados. Incluso en situaciones donde el cambio es estrictamente infraestructural (componente ó de fallo de sistema) la decisión de invertir dinero reside en el negocio, no en el departamento de TI. Hay ocasiones en las que cuando los procedimientos son desarrollados por adelantado a los cambios preautorizados tales como mantenimiento de sistema de emergencia, pero independientemente de la fecha de la autorización, aún así la decisión recae sobre los administradores del negocio.

Inicia el Desarrollo del Proyecto: Desarrollar el cambio (incluyendo las pruebas) es una función guiada por TI. En caso de un cambio de emergencia (servidor no funciona) esas funciones son típicamente predeterminadas. Cuando un nuevo sistema debe ser desarrollado, ahí hay esfuerzo colaborativo entre los usuarios del negocio y el equipo de TI. Los sistemas son diseñados por por TI, el dise-o es aprobado por los socios del negocio (usuarios), desarrollado por TI, puesto a prueba por una combinación TI y usuarios, y el producto final es aprobado por ambos. Debe prestarse atención a efectos secundarios que el sistema nuevo pueda tener en sistemas existentes.

Pasa la Puerta del Cambio Administrativo: El Consejo Asesor de cambios (por sus siglas en inglés CAB) revisa todos los cambios antes de que puedan ser puestos en producción. Normalmente el CAB consiste de un grupo de personas con diferentes perspectivas, antecedentes y áreas de experiencia. Su función es revisar el cambio desde un punto de vista de proceso y forma para asegurar que todos los riesgos previsibles han sido identificados y mitigados, y que técnicas compensatorias están en su lugar para cualquier elemento que se exponga (cosas que puedan salir mal). El equipo de desarrollo y el patrocinador de cambio presentarán el cambio a el CAB. La evaluación del riesgo será el punto clave. Estrategias de implementación, comunicación a los interesados afectados, planes de retroceso y monitoreo posterior a la implementación son elementos en los que el CAB requiere concentrarse. El CAB no es responsable de determinar si el cambio es apropiado, esa decisión ya fue hecha. El CAB tampoco es responsable de determinar si el cambio es rentable. Otra vez, esa decisión es estrictamente de administración.

Implementa el Cambio: Si el CAB no aprueba el cambio, se listarán razones (esto es porque siempre ciertos riesgos no son mitigados ó comunicaciones no han sido planeadas) y a el equipo de desarrollo se le dará tiempo para solucionar esos problemas y se programará una nueva reunión antes de el CAB. Si el cambio es aprobado, se programará la implementación. No es el caso normalmente que el CAB sea representado en la implementación aunque es posible que algunos de los miembros del CAB Tienen conocimientos que son necesarios durante la implementación, pero no serán presentados como representantes del CAB, si no como expertos en la materia (por sus siglas en inglés SME). Como se implementa el cambio, la lista y los pasos, están predefinidas y fueron presentadas y aprobadas por el CAB. El proceso completo debe estar debidamente documentado y el proceso aprobado debe ser seguido precisamente.

Reporta los Resultados: Si el cambio se implementó correctamente sin contratiempos, ó el cambio se implementó con problemas que fueron corregidos durante la implementación, o el cambio se implementó con problemas que se consideran aceptables, ó los problemas que surgieron eran inaceptables y se regreso, o en el peor de los casos el cambio se implementó con problemas inaceptables y no se puede regresar. Cualquier resultado, será documentado y regresado a el CAB.El CAB es ahora responsable de distribuir esa información a las partes interesadas y de guardar y mantener esos resultados en el Sistema Administrador de Cambios (esto puede ser en una base de datos automatizada ó en un sistema de llenado en papel, pero los documentos se deben mantener para propósitos de auditoría).

Problemas de Enlace en la Administración de Cambios: Problemas que surjan comparadas con la documentación de cambios del CAB para que cualquier efecto adverso al cambio que no se anticipe pueda ser aislado. Es un caso muy común que efectos no deseables al cambio no sean notados inmediatamente, pero son identificados al surgir el problema en sistemas auxiliares. Por ejemplo, la adición de muchos campos a una base de datos puede no tener un efecto negativo directo en los usuarios pero puede impactar el rendimiento de la red que será notado para otros usuarios que no están relacionados directamente con el sistema modificado.