El responsable del proceso de gestión de Cambios debe definir las métricas de su proceso alineadas con los objetivos del negocio; debe modelar la tipología de cambios; debe definir el impacto y la prioridad; debe establecer los parámetros de la RFC; debe supervisar el CAB; debe hacer seguimiento de los cambios; debe cerrarlos; debe supervisar aquellos que requieran la realización del PIR; debe establecer informes de gestión y métricas para indicar el grado de madurez del proceso y su alineación con el negocio.
Por tanto, debe ser un rol con autoridad, independiente y cercano al CIO, que le informe del estado de los cambios que se realicen sobre la infraestructura (servicios y componentes que los soporta), de sus beneficios hacia el negocio y de minimizar el riesgo o el impacto sobre los cambios realizados por y para el negocio.
Todo cambio debería disponer de una RFC con una serie de campos que hagan y sirvan para valorar la viabilidad y autorización del cambio y haga de ayuda para supervisar cualquier mínimo detalle de un cambio a realizar, para minimizar cualquier tipo de impacto hacia el negocio.
¿Qué campos debería estar incluidos en la RFC?
¿Cuál es la razón del cambio; su beneficio y resultado que se espera al realizarlo?
Descripción de los pasos o proceso a realizar en el cambio.
¿Cuándo debería realizarse, indicando diferentes fechas alternativas?
¿Qué sistemas, servicios y en definitiva que CI´s se van a ver afectados por el cambio?
¿Quién es el coordinador del cambio y a quién debe ser informado por el mismo?
¿Va a ser necesario realizar un PIR una vez realizado el cambio?
¿Qué riesgos se pueden producir por la realización del cambio?
¿Qué riesgos se puede producir si no se lleva a cabo dicho cambio?
¿Requiere la actualización de la CMDB o de cualquier tipo de documentación?
Grupos de soporte necesarios para la realización del cambio.
¿Tiempo estimado para la realización del cambio?
¿Tiempo estimado en realizar la marcha atrás del cambio?
¿Bajo qué circunstancias se debe activar la marcha atrás?
Establecida la RFC, debemos indicar que los cambios estándar son las peticiones de servicio, que identifica la operativa diaria de tareas predefinidas que se realizan de la misma forma y por tanto, están pre autorizadas.
Los cambios normales son aquellos que deben ser analizados en el CAB (junta asesora de cambios) para su aprobación o rechazo. El objetivo fundamental ¿Cuál es la razón del cambio? Siempre interpretada y enfocada a proporcionar valor al negocio. FUNDAMENTAL, estudiar la planificación y grupos intervinientes. También debe analizarse los riesgos, la marcha atrás, cosa que con excepciones nunca se realiza. En definitiva, por cada cambio ver la viabilidad de dar respuesta a las preguntas antes mencionadas que debe contener una RFC como dios manda.
Tengamos presente en la definición y adopción de las métricas un hecho fundamental y alineado con toda el sistema de gestión de IT. La relación con los otros procesos. Les remito un gráfico ejemplo de ello.
No hay comentarios:
Publicar un comentario