Download - Gestión de Cambios VUCE - Argentina
1
Proceso Gestión de Implementación de Cambios de
IT&S en VUCE
IT-OPs-02
Process Owner
Operaciones IT / Leandro Cinti
Registro de Cambios
Versión Descripción Autor Área Fecha de
creación
Revisado
por
1.0 Versión Inicial Paula Sajoux Dirección IT&S 28/2/19 Leandro Cinti
Aprobación Leandro Cinti
Dirección IT&S 4/4/2019
2
Contenido Objetivo ............................................................................................................................................... 4
Alcance ................................................................................................................................................ 4
Situación actual ................................................................................................................................... 4
Definiciones ......................................................................................................................................... 4
Cambio ............................................................................................................................................ 4
Tipos de Cambio .............................................................................................................................. 5
Categorías de Cambio ..................................................................................................................... 5
Subcategorías de Cambio ................................................................................................................ 5
Motivos de Cambio ......................................................................................................................... 7
Códigos de Cierre de los Cambios ................................................................................................... 7
Gestión de Implementación de Cambios de Tecnologías y Sistemas ................................................. 8
Actores / Roles ................................................................................................................................ 8
Dueño del Proceso Gestión de Cambios ..................................................................................... 8
Administrador de Cambios .......................................................................................................... 9
Aprobador del Cambio no Programado .................................................................................... 10
Coordinador del Cambio ........................................................................................................... 11
Implementador del Cambio ...................................................................................................... 11
Solicitante del Cambio ............................................................................................................... 12
Comité de Cambios (CAB – Change Advisory Board) ................................................................ 13
Comité de Emergencias (ECAB – Change Emergency Advisory Board) ..................................... 15
Pre-Condiciones ............................................................................................................................ 15
Flujo de Proceso ............................................................................................................................ 16
Descripción detallada de tareas .................................................................................................... 17
Matriz RACI .................................................................................................................................... 21
Métricas......................................................................................................................................... 23
Normativa Asociada .......................................................................................................................... 23
Anexo I - Prioridad de los Cambios ................................................................................................... 24
Anexo II – Solicitud de Cambio .......................................................................................................... 27
3
Anexo III – Bitácora de Cambios ........................................................................................................ 28
4
Objetivo El presente documento tiene como finalidad detallar el Proceso de Gestión Implementación de Cambios de la Dirección de Tecnología y Sistemas de VUCE.
Los objetivos del proceso son:
• Asegurar que todos los cambios son registrados, y luego evaluados, autorizados, priorizados, planificados, testeados, implementados, documentados y revisados en forma controlada.
• Utilizar métodos y procedimientos estándares para un eficiente manejo de los cambios y su vuelta atrás.
Alcance Comprende las actividades que están vinculadas al proceso de Gestión de Implementación de
Cambios de la Dirección de Tecnología y Sistemas de VUCE.
Situación actual N/A
Definiciones
Cambio
Un cambio es todo aquello que altera el estado de un ítem de configuración (IC). Esto incluye a
todo lo que se añade, se elimina, o se modifica en el entorno de IT.
A los efectos de este proceso, se define como cambio a la adición, modificación o eliminación de
hardware, redes, software, aplicaciones, ambientes de tecnología de información y sistemas.
Una Solicitud de Cambio es el medio para documentar los cambios propuestos y la actividad de
cambios en curso sobre los recursos y capacidades de tecnología de información. Las Solicitudes
de Cambio pueden originarse por una amplia variedad de razones y desde una amplia variedad de
5
fuentes; y pueden estar relacionados con una parte de la infraestructura, un servicio o una
actividad.
Tipos de Cambio
Cambio Normal: es un cambio que está categorizado, priorizado, planificado y que sigue todas las
aprobaciones requeridas antes del despliegue. Podría ser planificado o no planificado, donde
planificado es cuando va al CAB y no planificado es cuando no puede esperar el CAB pero no es
una emergencia.
Cambio de Emergencia: aplica al entorno de producción durante las situaciones de emergencia,
por ejemplo, ante una interrupción de servicio o un incidente crítico.
Cambio Estándar: es un cambio pre-aprobado, de bajo riesgo, que es relativamente común. Suele
ser una acción repetitiva y sigue un procedimiento estándar. Un ejemplo es la solicitud de
ejecución de Jobs no planificados, pedido de alta de alarmas en el entorno productivo.
Categorías de Cambio
Las categorías definidas son:
• Mayor: son los que introducen modificaciones importantes en la funcionalidad,
características técnicas, etc. Ejemplo: un cambio en la versión de la base de datos
productiva, un cambio de funcionalidad muy significativo.
• Menor: son los que introducen cambios de menor envergadura. Por ejemplo: un cambio
de funcionalidad o agregar una funcionalidad.
Subcategorías de Cambio
Para las categorías de cambios anteriormente definidas, se establecen los siguientes tipos de
cambios. Los mismos aplican para todas las categorías.
Sub Categorías de Cambios
Sub Categorías Descripción
6
Sub Categorías de Cambios
Sub Categorías Descripción
Software Aplicativo Cambios evolutivos que introducen funcionalidades o modifican
funcionalidades existentes o cambios correctivos orientados a solucionar
los errores identificados por el diagnóstico de un incidente sobre un
aplicativo informático.
Software de Base Implementación o cambio de configuración sobre SW de base de los
servidores o PC´s.
Arquitectura
Tecnológica
Implementación o cambio de configuración de la estructura lógica o
física de un aplicativo.
Base de Datos Implementación o cambio de configuración sobre la parametrización de
los motores de BD.
Infraestructura Implementación o cambio de configuración sobre los componentes
físicos que atienden a un aplicativo.
Monitoreo Implementación o cambio de configuración de reglas de disponibilidad
del aplicativo.
Automatización Implementación o cambio en el scheduler de tareas.
Política de Backup Cambio de la política de backup y/o del cronograma del mismo.
Restore/backup Recuperación o una ejecución de un backup.
Seguridad
Informática
Solicitud de cambio generada por temas de seguridad: asignación de
permisos, ABM de usuarios, ABM de roles, etc.
7
Motivos de Cambio
Se definieron los siguientes motivos de cambio:
Motivos de Cambios
Motivos Descripción
Resolución de
Incidentes/Problemas Cambios que introducen modificaciones con el objetivo de resolver un incidente o problema.
Mantenimiento Preventivo Es el destinado a la conservación de equipos o instalaciones mediante la realización de revisión y reparación que garanticen su buen funcionamiento y fiabilidad.
Actualización HW/SW Cambios vinculados a la actualización de hardware o software.
Requerimiento del Negocio Cambios que solicita el negocio.
Normativas/legislación Cambios que deben realizarse debido a un cambio en las normativas o legislación.
Cambio o recomendación de
servicio/producto del
proveedor
Cambios que se realizan debido a un cambio del servicio o producto del proveedor o a una recomendación del proveedor.
Códigos de Cierre de los Cambios
De la misma manera que se clasifican los cambios cuando son registrados, existe una clasificación
al cierre de los mismos. El código de cierre se establece para identificar el motivo del cierre del
cambio, este código establece estadísticas correspondientes a la gestión de cambios.
Código de Cierre de Cambios
Código Descripción
8
Código de Cierre de Cambios
Código Descripción
Implementado/
Exitoso
El cambio ha sido implementado exitosamente, a partir de la fecha
planificada y dentro de la ventana de mantenimiento.
Implementado
(con problemas)
El cambio ha sido implementado, pero con dificultades o problemas. (Ej.:
fuera de la ventana de mantenimiento)
Cancelado El cambio ha sido cancelado (Ej.: porque no se aprobó su implementación).
Rechazado El cambio ha sido rechazado, por algún motivo. (Ej.: técnico o seguridad)
Fallido Es un cambio que no ha sido implementado. (Ej.: El cambio ha sido
implementado, pero al no ser exitoso se ha vuelto atrás).
Prioridad
Secuencia en la que un Cambio debe ser resuelto en relación al resto de los Cambios pendientes, teniendo en cuenta la urgencia con que deben ser atendidos y el impacto a los Servicios. En el Anexo I se describe el cálculo de la prioridad en base a la Urgencia y al Impacto del Cambio.
Gestión de Implementación de Cambios de Tecnologías y Sistemas
Actores / Roles
Dueño del Proceso Gestión de Cambios
El Propietario del Proceso Administración de Cambios tiene la responsabilidad sobre el resultado y la calidad del proceso. Es responsable del diseño adecuado, ejecución y la adecuada mejora del proceso. Controla que el proceso sea llevado a cabo, pero no ejecuta la operación del día a día. Es quien recibe las mediciones/controles de la operatoria diaria. Sus responsabilidades incluyen:
9
• Ser el dueño del Proceso a nivel ejecutivo o gerencial.
• Asegurar el funcionamiento y resultados del proceso.
• Identificar y manejar los factores críticos del proceso.
• Controlar, liderar, revisar y aprobar las mejoras al proceso.
• Reportar el estado y progreso del proceso.
• Facilitar, resolver o escalar desvíos que involucren a distintas áreas.
• Verificar la integridad, validez y auditabilidad del proceso.
• Representar el proceso frente a los grupos externos.
• Implementar el proceso, incluyendo la capacitación a los usuarios del proceso.
• Brindar capacitación a los usuarios cuando las circunstancias indiquen que de esta manera se mejora la ejecución del mismo.
Administrador de Cambios
Asegurar que se cumplan el Proceso y las políticas de la Gestión de Cambios, coordinar todos los cambios en el ambiente de IT&S y liderar el CAB. El Administrador de Cambios es el responsable principal de la calidad con que se gestione el cambio, debe asegurar que el mismo sea comunicado en tiempo y forma correcta. Es el principal coordinador de este proceso y el punto de contacto en relación a cambios. Administra y Coordina todas las actividades para identificar, controlar, planificar, Implementar, dar seguimiento y auditar todos los Cambios al ambiente productivo del área de IT&S. Sus responsabilidades incluyen:
• Construir y mantener el Calendario de Cambios - Integrar nuevos cambios en el calendario - Facilitar / asistir a resolver conflictos con las fechas planificadas y negociar los ajustes
que sean necesarios con las partes involucradas
• Liderar las reuniones de Comité de Cambios (CAB). Asegurar que todo ha sido preparado para la reunión de Comité de Cambios incluyendo la agenda, invitación a los participantes, y el envío de las Solicitudes de Cambio a ser consideradas.
• Revisar todos los cambios planificados.
• Revisar cambios fallidos y cancelados para asegurar que el Coordinador del Cambio identifique la causa del fallo o de la cancelacion, controlando que toda la información correspondiente a la falla o la cancelacion sea volcada en el registro del cambio.
• Garantizar que la información de la Evaluación Técnica y de negocio se encuentre documentada en el registro de los cambios críticos y mayores o que se indique el lugar donde la misma se encuentra, con su correspondiente fecha y hora.
10
• Garantizar la revisión posterior a la implementación de cambios de emergencia para determinar si fueron clasificados correctamente.
• Utilizar métricas y reportes para hacer seguimiento a los cambios.
• Comunicar deficiencias y desvíos al coordinador del proceso.
• Identificar cambios que no han sido requeridos a tiempo y tomar las medidas adecuadas.
• Asistir en la resolución de un cambio por errores de asignación.
• Monitorear que los cambios han sido cerrados según los criterios establecidos.
• Monitorear que los desvios encontrados durante la implementación estén apropiadamente documentados en el registro de cambio.
• Capacitar a los usuarios reforzando conocimientos para evitar futuros errores.
• Ejecutar los puntos de control del proceso para verificar la adherencia al mismo.
• Crear y distribuir reportes, métricas y tendencias.
• Negociar el tiempo de ventana sin servicio por la implementación del cambio.
Aprobador del Cambio no Programado
El Aprobador del Cambio es responsable de evaluar una solicitud de cambio y de determinar su
aprobación o rechazo. Representa a un grupo directamente involucrado o impactado por el
cambio.
Sus responsabilidades incluyen:
• Evaluar el contenido del cambio, su factibilidad e impacto de acuerdo a las responsabilidades
relativas a su función.
• Revisar la evaluación de negocio incluyendo: - Análisis de riesgo - Conformidad con los objetivos de negocio - Impacto al negocio y su calendario - Impacto sobre los niveles de servicio acordados
• Revisar la evaluación técnica incluyendo: - Análisis de riesgo - Conformidad a los estándares técnicos - Completitud del Plan de Implementación - Corte de servicio estimado o impacto sobre los niveles de servicio acordados
• Asegurar que toda la documentación en el registro de cambio esté completa.
• Negociar la resolución de cualquier desvío o inquietud con el Solicitante o Coordinador del Cambio, según corresponda.
• Obtener información adicional cuando sea necesario.
• Documentar la aprobación o rechazo en el registro de cambio antes que se cumpla la fecha planificada.
11
• Notificar al gestor de cambios del rechazo u aprobación del cambio.
Coordinador del Cambio
El coordinador del cambio es responsable por un cambio en forma individual. El coordinador del cambio lo sigue desde su inicio hasta su fin reuniendo analistas y especialistas según sea necesario para completarlo y que el cambio logre su cierre en forma satisfactoria. Sus responsabilidades incluyen:
• Verificar que toda la documentación necesaria esté registrada en el cambio. Si hay documentación faltante, es responsable por obtenerla y modificar el registro de cambio incluyendo:
- Descripción detallada - Riesgo - Plan de implementación, prueba y vuelta atrás - Impacto - Sistemas afectados
• Modificar si corresponde el riesgo técnico del cambio.
• Identificar los grupos que contribuyan a la implementación del cambio.
• Preparar el cambio brindando información detallada.
• Conducir una revisión posterior a la implementación del cambio.
• Monitorear el progreso de los cambios de emergencia.
• Identificar los aprobadores del cambio de acuerdo a los CI’s afectados.
Implementador del Cambio
El Implementador del Cambio implementa los cambios que se encuentran autorizados. Sus responsabilidades incluyen:
• Brindar información detallada del cambio, al momento de implementar el cambio.
• Asistir en la planificación técnica del cambio.
• Verificar que el cambio esté totalmente aprobado, antes de la fecha de inicio de implementación del cambio.
• Implementar sólo los cambios completamente aprobados.
• Asegurar la implementación del cambio en el tiempo requerido.
• Gestionar la resolución de cualquier inconveniente con la implementación.
• Ejecutar las pruebas necesarias para revisar los resultados de la implementación. Y además, aquellas pruebas requeridas por el solicitante, en el caso que se indiquen.
• Verificar el funcionamiento técnico del cambio luego de la implementación, cuando esto sea
12
posible.
• Documentar cualquier desvío de la implementacion original en el registro de cambio.
• Modificar manuales y/o instrucciones operativas cuando esto aplique.
• Abrir un registro de incidente por cualquier impacto o corte de servicio no planificado, que haya ocurrido debido a una falla en la implementacion del cambio.
• Identificar tareas sin completar para luego escalarlas a a quien corresponda.
• Actualizar el estado del registro de cambio, incluyendo la documentación del resultado del cambio.
• Verificar que toda la documentación asociada con el cambio esté completa.
• Monitorear la implementación del cambio.
• Ejecutar la vuelta atrás de un cambio fallido, siguiendo las instrucciones consignadas a tal fin.
• Asegurar la actualización en los items de configuración que hayan sido impactados con la implementacion del Cambio.
Solicitante del Cambio
Es la persona que representa la necesidad de Servicio/Técnica para el cambio. Sus responsabilidades incluyen:
• Crear y registrar un cambio.
• Asegurar que el registro de cambio está dentro del alcance del servicio cubierto por este proceso.
• Definir el alcance del cambio.
• Obtener la información adicional que sea requerida por el Coordinador o Administrador de Cambios.
• Asegurar que un requerimiento de cambio esté completo con la adecuada y suficiente información y nivel de detalle para una implementación exitosa.
• Trabajar con el Coordinador del cambio para resolver cualquier inconsistencia en el registro de cambio.
• Ejecutar la evaluación técnica de la Solicitud de Cambio incluyendo: - Análisis de riesgo - Conformidad a los estándares técnicos, según se defina en los procesos de cada grupo
de soporte - Completitud del Plan de Implementación y de Reversión - Brindar recomendaciones a los Aprobadores del Cambio - Corte de servicio estimado o impacto sobre los niveles de servicio acordados
Nota: Si los resultados de la evaluación son documentados y almacenados fuera del registro de cambio, entonces la ubicación específica donde reside dicha documentación debe ser incluida en el registro del cambio.
• Ejecutar la evaluación de negocio de la Solicitud de Cambio incluyendo:
13
- Análisis de riesgo. - Conformidad a los objetivos de negocio y su calendario. - Corte de servicio estimado o impacto sobre los niveles de servicio acordados.
• Ejecutar una evaluación preliminar de negocio.
• Brindar información de entrada para el plan de implementación y reversión del cambio.
• Elaborar el Plan de Pruebas post implementación y designar el responsable de las mismas.
• Solicitar o identificar las ventanas de servicio.
• Evaluar la necesidad de realizar un corte de servicio y el impacto sobre la disponibilidad del servicio.
• En los casos que corresponda, identificar las personas a ser notificadas luego de la implementación del cambio y definir cuándo y cómo deben recibir dicha notificación.
• Verificar si el cambio fue implementado.
• Actualizar el registro de cambio con los resultados de la evaluación técnica y de negocio, lo cual podría incluir:
- Sugerir aprobaciones adicionales y modificaciones en las fechas y horarios de las tareas planificadas, en el caso que se identifique sea necesario.
- Representar al Cambio en la reunión de Comité de Cambios (CAB), si es requerido. - Garantizar que cualquier desvío o preocupación resultante de la reunión CAB sea
gestionado.
• Grabar todas las acciones tomadas durante la implementación de un cambio de emergencia.
• Modificar manuales o instructivos operativos cuando se requiera.
• Cerrar los cambios, asegurando que todos los desvíos encontrados durante la implementación sean documentados, incluyendo razones de las fallas o las cancelaciones.
Comité de Cambios (CAB – Change Advisory Board)
Es responsabilidad del CAB evaluar cada cambio desde un punto de vista comercial, técnico y
financiero y hacer recomendaciones sobre el impacto, la planificación y la aprobación. Los
miembros de CAB son flexibles e incluye a personas de operaciones, desarrollo y negocios de TI
para garantizar que todos los ángulos estén representados cuando se discute la implementación
de un cambio individual. El administrador de cambios decidirá qué miembros del CAB asistirán a
una reunión dependiendo de la naturaleza del cambio (o cambios) en cuestión. Las reuniones de
CAB sobre cambios individuales se pueden realizar virtualmente, pero un equipo central de CAB
también debe reunirse periódicamente para revisar las políticas y los procedimientos, los cambios
en curso y la acumulación de cambios.
Modo de sesionar:
Reunion de
comité
14
1. Reuniones:
• La reunión del CAB se realizar semanalmente con una duración aproximada de 30 minutos.
• Se recomienda realizar reuniones regulares del CAB cada seis meses para la revisión del proceso de Gestión de Implementación de Cambios.
• Todas las reuniones del CAB representan una sobrecarga de tiempo para sus miembros. Por lo tanto, se debe facilitar con anticipación todas las RFC, junto con el Cronograma de Cambios y toda información relevante, para que las personas requeridas puedan realizar estudios de impacto y recursos necesarios.
• Se analizarán los RFC recibidos hasta el mediodía del día anterior a la reunión del CAB.
• En la aprobación del cambio se contemplará la mayoría de los votos y esto será suficiente
para Aprobar el Cambio solicitado.
2. Agenda típica de las reuniones regulares del CAB:
El Administrador de Cambios definirá la agenda de las reuniones. Normalmente se incluyen
algunos de los siguientes temas:
• Revisión de Cambios que fallaron.
• Revisión de Cambios que tuvieron que deshacerse.
• Discusión de los cambios por aprobar.
• Revisiones de Cambios ya implantados.
• Revisiones de planes de prueba.
• Revisión del proceso de Gestión de Implementación de Cambios, incluyendo cualquier modificación que se le haya realizado durante el último periodo (en la reunión periódica semestral).
• Revisión de los logros y métricas (KPI) de la Gestión de Cambios del período, por ejemplo, beneficios logrados por la utilización del proceso (en la reunión periódica semestral).
3. Resultados esperados de las reuniones de revisión de cambios:
• RFC aprobados.
• RFC rechazados.
• RFC revisados.
• Acta, compromisos.
• Agenda de la próxima reunión del CAB.
• Cambios revisados según las normas de calidad.
• Actualización de la CMDB.
• Actualización del cronograma de cambios
• Comentarios de mejora continua para el proceso de Gestión de Cambios.
15
Comité de Emergencias (ECAB – Change Emergency Advisory Board)
Es un grupo más pequeño de miembros del CAB que está disponible para responder a los cambios
de emergencia que deben realizarse en un breve aviso (quizás también fuera de horas de trabajo
normales) para remediar un problema urgente. La ECAB es la autoridad de cambio para los
cambios de emergencia y debe tener el poder de tomar decisiones en una emergencia.
El Coordinador de Cambios es el responsable de convocar a los miembros del ECAB para la
aprobación de un Cambio de Emergencia. La reunión se puede realizar virtualmente.
Pre-Condiciones
Del proceso
• Necesidad de realizar un cambio de Sistemas y Tecnología en el entorno productivo de
VUCE.
17 17
Descripción detallada de tareas El Proceso incluye las siguientes actividades:
1. Registra Solicitud de Cambio (RFC)
El objetivo es registrar el cambio, categorizar y priorizar. Esta registración se realiza completando
una planilla de Cambios según el modelo del Anexo II – Solicitud de Cambio.
2. Análisis de riesgo e impacto
Se evalúa riesgo e impacto en los servicios de TI que soportan los procesos de negocio, de manera
de tener información suficiente como para aprobar o no el cambio.
3. Planifica la fecha de implementación
Define la fecha de implementación deseada de acuerdo a las ventanas de implementación
definidas para ese servicio. De no existir la ventana definirá la misma con el Gestor de Cambio.
4. Revisa el Cambio solicitado
El referente del área de incumbencia del cambio verifica que el cambio contenga la información
necesaria, tanto los pasos de implementación cómo el riesgo y la fecha deseada de
implementación. Si se requiere agregar información adicional o no aprueba el mismo, continúa
con la actividad “Corrige el Cambio”.
Si el cambio es aprobado continúa con la actividad siguiente.
5. Valida si es Emergencia
Si es una Emergencia, es decir que hay un incidente crítico que requiere resolución, continúa con
el proceso “Gestión de Implementación de Cambios de Emergencia IT&S”. Si no es una emergencia
continúa con la actividad siguiente.
18 18
6. Envía a Gestor de Cambio el cambio completo
Al estar aprobado el cambio, se envía el mismo a Gestión de cambio por mail a
[email protected] indicando que el mismo fue aprobado.
7. Controla solicitud
El gestor de cambio controla la solicitud y la incorpora a la planilla que se analizará en la reunión
del comité (CAB).
8. Verifica si es “Cambio Programado”
Verifica si es un cambio programado, es decir si puede esperar la reunión del CAB. De ser así
continua con la actividad “Convoca al CAB”.
Si no puede esperar la reunión del CAB porque requiere que se implemente antes continua con la
actividad “Aprueba No Prog.”.
9. Convoca al CAB
Define los integrantes del próximo comité de acuerdo a los cambios que se van a analizar.
Envía la convocatoria a la reunión del comité semanal con el detalle de los cambios que se
considerarán.
10. Aprueba No Prog.
Si no aprueba el cambio no programado continua con la actividad “Corrige el cambio”.
Si aprueba el cambio no programado continua con la actividad “Implementa lo solicitado”.
Los aprobadores de un cambio programado son el director de IT&S y el gerente a cargo del CI
afectado.
19 19
Reunión del Comité:
11. Revisa el calendario de Cambio y realiza las modificaciones necesarias
Durante la reunión del comité se revisan todos los cambios programados para la semana siguiente,
se dará conformidad o se solicitará la modificación de la fecha de implementación de acuerdo a lo
que el comité considere conveniente.
Al finalizar la reunión quedará definido el Calendario de Cambios aprobados que se
implementarán la semana siguiente.
12. Envía Observaciones
Si el CAB no aprobó la implementación envía la o las observaciones al solicitante.
13. Da conformidad
Aprueba la implementación del cambio.
14. Corrige el cambio
Realiza las correcciones en el cambio en base a las observaciones recibidas.
15. Informa el Ok para implementación
Informa el Calendario de Cambios aprobados para la semana siguiente.
Implementación
16. Implementa lo solicitado
Implementa el cambio de acuerdo al plan de implementación contenido en el mismo.
Durante la misma se realizarán las pruebas Post-implementación detalladas en el cambio.
20 20
17. Rollback
Si la implementación no fue exitosa realiza el Rollback o la Vuelta Atrás siguiendo el Plan de
Reversión indicado en el cambio.
18. Revisión Post
Se realiza la revisión post implementación, tanto si la misma fue exitosa como si se realizó el
Rollback.
El objetivo es analizar la implementación de un cambio, verificar la causa de una implementación
no exitosa, Identificar efecto y posibles causas.
Documentar los resultados de la implementación y definir si se reintenta un cambio fallido en
función del análisis realizado.
19. Cierre
Se realizan las actividades de cierre del cambio.
21 21
Matriz RACI
En esta matriz se asignan los roles que un recurso debe ejecutar, para cada actividad dada.
A continuación, se describe la representación de cada una de las letras asignadas.
R - Responsible (responsable de la ejecución)
Alguien que desempeña una tarea determinada. Para cada tarea en un proceso ITIL existe
normalmente un rol ITIL responsable de su ejecución.
A - Accountable (responsable del proceso en conjunto)
Alguien que asume la responsabilidad conjunta final por la correcta y completa ejecución de un
proceso y que recibe las informaciones de los responsables de la ejecución del proceso.
Normalmente, el Responsable de Proceso asume la responsabilidad conjunta de un proceso y para
cada proceso existe un Responsable de Proceso.
C - Consulted (consultado)
Alguien que no está implicado directamente en la ejecución de un proceso pero que brinda algún
tipo de input para el proceso y/o al cual se pide su consejo y opinión.
I - Informed (a informar)
Alguien que recibe las salidas (outputs) de un proceso o a quien se informa de los avances del
proceso.
22 22
Ges
tor
de
Cam
bio
s
Ap
rob
ado
r N
o
Pro
g.
Co
ord
inad
or
de
Cam
bio
Solic
itan
te d
e
Cam
bio
s
CA
B
Imp
lem
enta
do
r
Registra Solicitud de CambioInformación de Cambio
CompletaCambio regis trado A R
Análsis de Riesgo e Impacto Cambio completo Cambio anal izado A C R
Planifica la fecha de implementación Cambio anal izado Cambio plani ficado A IC R
Corrije el Cambio Cambio a modificar Cambio actual izado A R
Revisa el Cambio solicitado Información del Cambio Cambio revisado A R C
Aprueba Cambio revisadoCambio revisado y va l idado
aprobadoAI R I
Valida si Es Emergencia Cambio revisado aprobadoCambio revisado y va l idado
aprobadoA R C
Envía a Gestor de Cambio el cambio completoInformación de Cambio
Completa aprobado
Información de Cambio Completa
aprobado y enviadaA R
Controla solicitudInformación de Cambio
Completa aprobado
Información de Cambio Completa
aprobado controladoRA I I
Verifica si es "Cambio Programado"Información de Cambio
Completa aprobado controlado
Información de Cambio Completa
aprobado controlado y veri ficadoRA I I
Convoca al CABCambios completos aprobados
y controlados
Plani l la de Cambios Aprobados y
Rechazados CABRA I I I
Revisa el calendario de Cambio y realiza las
modificaciones necesarias
Plani l la de cambios para CAB
Calendario de Cambios
Cambios aprobados por CAB
Cambios rechazados por CAB con
observaciones
Calendario de Cambios
actual izado
A R
Envía Observación Cambios rechazados por CAB Observaciones enviadas RA I I I I
Informa el Ok para implementaciónCalendario de Cambios
actual izado
Comunicación de Calendario de
Cambios actual izadosRA I I I I
Aprueba No Prog.Información de Cambio
Completa aprobado controlado
y veri ficado
Cambio No Prog. Aprobado
Cambio No Prog. RechazadoAI R I I I
Implementa lo solicitadoRFC aprobado a implementar
Plan de Implementación
Plan de Revers ión
RFC Implementado
Pruebas post-implementación
rea l izadas
AI IC R
RollbackCambio implementado con
problemas
Plan de Revers ión
RFC revertida o vuelta atrás AI IC R
Revisión PostRFC implementada
Plan de Implementación
Plan de Revers ión
RFC evaluada
Documento de Conclus iones ,
acciones y recomendacionesAI R I I
Cierra Cambio Cambio rea l izado actual izado RFC cerrada AI R I I
TAREAS Entradas Salidas
ROLES Y RESPONSABILIDADES
23 23
Métricas
La siguiente lista muestra los Indicadores Clave de Rendimiento (KPI / key performance indicators)
que deben considerarse para monitorear el desempeño de la Gestión de Incidentes.
Reporte Frecuencia
Cantidad de Cambios RFC del período Mensual % de cambios no Planificados Mensual Cantidad de Cambios por categoría Mensual % de cambios que se ha realizado Rollback Mensual % de cambios generados por incidentes Mensual Cantidad de cambios que han generado Incidencias, Problemas, u otro cambio como consecuencia de su implementación.
Mensual
Normativa Asociada N/A
24
Anexo I - Prioridad de los Cambios La prioridad de los cambios se define en base a la Urgencia y el Impacto.
En la siguiente tabla se establece la prioridad del cambio en función de la urgencia y el impacto. En
la tabla hay cuatro niveles de prioridad, la prioridad 1 es la más crítica del negocio.
Prioridad de un Cambio
IMPACTO
Alto Medio Bajo
URGENCIA
Alta Crítica Alta Media
Media Alta Media Bajo
Baja Media Bajo Bajo
La prioridad se utiliza para determinar el orden en que los cambios deben ser abordados.
Tabla de Prioridad
Código Descripción Tiempo de resolución
1 Crítica Los tiempos especificados
dependerán de la criticidad de los
sistemas que soportan a los
procesos de negocio. Podrá estar
definida en el SLA.
2 Alta
3 Media
4 Baja
Definición de impacto
Medida de la criticidad de un Cambio para el Negocio o Servicio. A veces es equivalente a la
medida en que la no solución del Cambio lleva a la distorsión de los niveles de servicio esperados o
acordados.
Está expresado en función de la complejidad técnica requerida para la solución del Cambio.
25
A continuación, se definen los niveles de impacto que puede tener un Cambio, para poder así
evaluar mejor su programación:
Tabla de Impacto
Impacto Criterio
Alto Bloqueante.
El servicio está afectado y requiere la realización del cambio
Medio No Bloqueante.
El servicio podría verse afectado si no se implementa el cambio. Esta afectada
la funcionalidad parcial de un servicio.
Bajo No bloqueante. El servicio no se ve afectado.
Definición de urgencia
Determina el momento en que un Cambio debe ser resuelto en relación al resto de los Cambios
pendientes, teniendo en cuenta cómo afectan la operación del negocio y el fundamento de su
solicitud.
A continuación, definir los distintos tipos de Urgencia.
26
Tabla de Urgencia
Urgencia Definición
Crítico1
Son aquellos cambios que por su naturaleza no pueden preverse o planificarse, y que de
no implementarse se causarán o pondrán en riesgo de interrupción la operatoria normal
del usuario, del procesamiento batch o bien se generará información errónea.
Este nivel de urgencia sólo aplica para servicios esenciales2 de acuerdo a la información
disponible en la CMDB.
Alta3 Son aquellos cambios que por su naturaleza no pueden preverse o planificarse, y que de
no implementarse se causarán degradación en la operatoria normal del usuario, del
procesamiento batch o bien se generará información errónea, pero no afecta servicios
esenciales.
Media4 Son aquellos cambios que pueden planificarse, y que de no implementarse podrán causar
degradación en la operatoria normal del usuario, del procesamiento batch o bien se
generará información errónea, ni se afectarán servicios esenciales. Sin embargo, estos
cambios no deben posponerse para no afectar planificaciones ni acuerdos de alcance
establecidos.
Baja Cambio que puede posponerse hasta el siguiente release o mantenimiento programado ya
que no tiene impacto crítico en el negocio, ni afecta planificaciones comprometidas.
1 Requiere invocar inmediatamente al Comité Asesor de Cambios de Emergencia (ECAB). Estos cambios podrán ser implementados fuera de la ventana de mantenimiento establecida. 2 Se denominan servicios esenciales a aquellos servicios de tecnología informática que apoyan procesos críticos de negocio, es decir, procesos cuya interrupción o degradación causará un impacto negativo directo en el resultado operativo del negocio. 3 Requiere ser tratado en el ámbito del CAB. Estos cambios podrán ser implementados fuera de la ventana de mantenimiento establecida. 4 Estos cambios deberán ser implementados dentro de la ventana de mantenimiento establecida.
27
Anexo II – Solicitud de Cambio
Formulario de
Cambio.xlsx
Ambiente PRODUCCION Número Cambio XXXX
Tipo de Cambio Prioridad
Categoría de Cambio Evaluación de Riesgo
Subcategoría de Cambio Referencia Origen
Motivo del Cambio Ref. Origen Nro. Ticket
Fecha/hora de Inicio Programada Probado en HML/Test
Fecha/hora de Fin Programada Solicitado por
Servicio Afectado Requiere baja de Servicio?
Aprobado por Fecha Aprobación
Implementador
Responsable:
Fecha/hora de Inicio Real
Fecha/hora de Fin Real
Observaciones
Resultado de Implementación
Implementación
Plan de Pruebas Post implementación
Detalle:
Aprobación
Plan de Reversión
Plan de Implementación
SOLICITUD DE CAMBIO
Datos Generales del Cambio
Descripción
Elementos de Configuración afectados
28
Anexo III – Bitácora de Cambios
Número de
CambioTipo Categoría Subcategoria Prioridad Riesgo Descripción Solicitado por Revisado por Motivo
Referencia
Origen
Ref. Origen
Nro. Ticket
Fecha/hora de
Inicio Progr.
Fecha/hora de
Fin Progr.Implementador
Servicio
AfectadoCI's afectados Aprobado por
Fecha
Aprobación
Fecha/hora de
Inicio Real
Fecha/hora de
Fin Real
Código de
CierreObservaciones
1 Normal MenorAplicacion/Servicios de
NegocioMedia Medio
Puesta en produccion
de funcionalidad XXXXJuan
Alejandro G.
CalderónRequerimiento del Negocio Jira Evolutivo Jira XXXX 12/2/2019 22:00
12/2/2019
23:30:00 PM VUCE YYY
2 Emergencias MenorAplicacion/Servicios de
NegocioBaja Bajo
Resolución de
IncidentePedro
Alejandro G.
Calderón
Resolución de
Incidentes/ProblemasIncidente Incidente 2313
CICE XXX
1001 Normal Mayor Infraestructura Media BajoActualización RedHat
de 7.5 a 7.6Hernan Chao Hernan Chao Actualización HW/SW No Aplica N/A
1002 Normal Mayor Infraestructura Media BajoActualización RedHat
de 7.5 a 7.6Hernan Chao Hernan Chao Actualización HW/SW Cambio 1001