Alineándome con una idea de la entrada anterior, donde toda definición de proceso y sus métricas asociadas deben realizarse al mismo tiempo, siendo el objetivo de ambos conceptos - su medida - estar únicamente relacionada por y para el negocio, establezcamos un ejemplo con el proceso de Gestión de Cambios.
La Gestión de Cambios es el proceso que “Supervisa” la implementación de los cambios de la infraestructura (servicios y los componentes que los soportan) para promover beneficios para el negocio así como de causar el menor impacto posible al negocio. El proceso que ejecuta - brazo ejecutor del cambio - dicha implementación es la Gestión de la Entrega.
Creo que este aspecto puede ocasionar bastante confusión y espero intentar paliar o eliminar dichas dudas sobre la misma (si las hubiere) con el siguiente párrafo.
La Gestión de Cambios evalúa el impacto del cambio (Assess: evalúa el desempeño previsto), aprueba/deniega el cambio, autoriza el cambio, por último Evalúa la post-implementación (Review: evalúa el desempeño real) y muy importante, el responsable o gestor del proceso cierra el cambio (O DEBERÍA HACERLO, por una vital cuestión: es la única manera de supervisar y tener todo bajo control de principio a fin).
Mientras que la Gestión de la Entrega, se encarga de construir el cambio, controla la implementación, informa y controla el lanzamiento y pone el cambio en producción. Así como ejecuta el PIR – realiza el estudio de la revisión post-implementación - facilitando su resultado a la Gestión de Cambios y/o Problemas dependiendo de su origen.
Gráficamente no serían dos proceso separados si no que la Gestión de la Entrega estaría “como” incrustada dentro de la Gestión de Cambios.
Su alcance debería ser definido dependiendo del ámbito de nuestra definición de infraestructura (a qué llamamos servicio y sus componentes que lo soportan) que nuestro proceso pretende supervisar su alteración de un estado a otro (posible definición de cambio). De forma genérica, está claro, que nos aparecen de forma rápida en nuestra conciencia, las categorías de HW y SW.
Y me pregunto, ¿Por qué no añadir en este punto la documentación? Cuántos problemas hay en las organizaciones, con la documentación, su generación, aprobación, versionado, su mantenimiento y revisión. Si de esta categoría se encargara el proceso de Cambios, ¿cuánto ahorraríamos en re-trabajos (dedicando nuestros recursos a otro menester o tarea, a esto se llama eficiencia) y costes en nuestro día a día, el tomar dicha decisión? Si compráramos una hucha e insertáramos el dinero de lo comentado, creo estar en disposición que el ROI de la inclusión de la documentación como elemento a supervisar por Cambios retornaría en menos de lo que estimaríamos, en un principio.
Otro ejemplo; imaginemos que nos hemos certificado en una norma. Aunque cada documento tenga o deba tener un responsable, el control de dicho documento sería supervisado de forma transversal a toda la organización, por el proceso en cuestión. Otra cosa sería su ubicación (red, intranet, CMDB, gestor documental, etc), o el apunte de dónde está ubicado (CMDB). El apunte es sencillo. Por supuesto. El realizarlo tiene bastante trabajo. Por supuesto. Estaría alineado con los objetivos de la organización, de tener un control de la documentación y que esté disponible en cualquier momento, para cualquier individuo con los correspondientes permisos y aparte sirva de evidencia para nuevas auditorías. Es obvio, que sí.
¿Qué objetivos relacionados por y para el negocio presenta dicho proceso de Cambios? Considero que para que el negocio tenga el mínimo impacto al llevar a cabo la adopción de un cambio para satisfacer una necesidad de nuevas prestaciones o por falta de capacidad en su infraestructura, es condición necesaria y suficiente, el asegurar para dicha SUPERVISIÓN que se utilizan métodos y procedimiento estándares para manejar eficiente y rápidamente dicha adopción o cambio. Y se tenga de la autoridad pertinente para su cumplimiento.
Si se dispongo de este rigor y de una cultura suficientemente implantada en la organización, las actividades del propio proceso tendrían un grado de eficacia y eficiencia bastante alto, eliminando las tales consabidas incidencias acaecidas por no disponer del rigor y procedimiento evaluador antes de realizar dicho cambio, en nuestro entorno de producción. La optimización de los recursos sería estratosférica, la priorización y calendario establecido y publicado a todos los niveles que intervinieran en este proceso o el de la entrega, recortaría y nos daría otro gran objetivo ansiado por el negocio. Entregar cambios de acuerdo a los tiempos que el negocio necesita.
Y por último si partimos con la premisa (si es de interés para la organización en la que se defina este proceso) que el responsable o gestor de cambios es el que cierra el cambio. Es el proceso de gestión de cambios el que indica cuándo se da por terminado el mismo (o incide en su marcha atrás, por no conseguir el desempeño o la razón por la cual se ha llevado a efecto en dicho instante o pasado un tiempo tras evaluar el informe del PIR realizado por la Entrega) y por tanto antes de su cierre, es el que promueve la veracidad de la información actual de nuestro infraestructura, proporcionando a la gestión de configuración, su aprobación para que establezca las nuevas propiedades, valores o atributos de sus CI´s o las modificaciones acontecidas por la adopción de un cambio.
En la siguiente entrada hablaré de las métricas asociadas a dicho proceso y cómo éstas así con la definición del proceso están alineadas como objetivo fundamental y único con el negocio.
Definición del Proceso de Gestión de Cambios y sus métricas asociadas. Parte I
