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 Revisado
creación por

1.0 Versión Inicial Paula Sajoux Dirección IT&S 28/2/19 Leandro

Cinti

Aprobación Leandro Dirección IT&S 4/4/2019

Cinti

1
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

2
Anexo III – Bitácora de Cambios........................................................................................................ 28

3
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

4
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

5
 Sub Categorías de Cambios

Sub Categorías Descripción

Cambios evolutivos que introducen funcionalidades o modifican

Software Aplicativo funcionalidades existentes o cambios correctivos orientados a solucionar
los errores identificados por el diagnóstico de un incidente sobre un
aplicativo informático.
Implementación o cambio de configuración sobre SW de base de los
Software de Base
servidores o PC´s.

Arquitectura Implementación o cambio de configuración de la estructura lógica o

Tecnológica física de un aplicativo.

Implementación o cambio de configuración sobre la parametrización de

Base de Datos
los motores de BD.

Implementación o cambio de configuración sobre los componentes

Infraestructura
físicos que atienden a un aplicativo.

Implementación o cambio de configuración de reglas de disponibilidad

Monitoreo
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 Solicitud de cambio generada por temas de seguridad: asignación de

Informática permisos, ABM de usuarios, ABM de roles, etc.

6
 Motivos de Cambio
Se definieron los siguientes motivos de cambio:

Motivos de Cambios

Motivos Descripción

Resolución de Cambios que introducen modificaciones con el objetivo de resolver

Incidentes/Problemas
Mantenimiento Preventivo
Actualización HW/SW
un incidente o problema.
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.
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 Cambios que se realizan debido a un cambio del servicio o producto
proveedor 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

7
 Código de Cierre de Cambios

Código Descripción

Implementado/ El cambio ha sido implementado exitosamente, a partir de la fecha

Exitoso planificada y dentro de la ventana de mantenimiento.

Implementado El cambio ha sido implementado, pero con dificultades o problemas. (Ej.:

(con problemas) 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)

Es un cambio que no ha sido implementado. (Ej.: El cambio ha sido

Fallido
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:

8
• 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.

9
• 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.

10
• 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

11
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:

12
 - 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.

Reunion de
Comité de Cambios (CAB – Change Advisory Board) comité
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:

13
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.

14
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.

15
Flujo de Proceso
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.

17
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

gestiondecambioITS@vuce.gob.ar 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.

18
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.

19
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.

20
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.

21
 ROLES Y RESPONSABILIDADES

Coordinador de

Implementador
Aprobador No

Solicitante de
Gestor de
Cambios

Cambios
Cambio
TAREAS Entradas Salidas

Prog.

CAB
Informa ci ón de Ca mbi o
Registra Solicitud de Cambio
Compl eta
Ca mbi o regi s tra do A R
Análsis de Riesgo e Impacto Ca mbi o compl eto Ca mbi o a na l i za do A C R
Planifica la fecha de implementación Ca mbi o a na l i za do Ca mbi o pl a ni fi ca do A IC R
Corrije el Cambio Ca mbi o a modi fi ca r Ca mbi o a ctua l i za do A R
Revisa el Cambio solicitado Informa ci ón del Ca mbi o Ca mbi o revi s a do A R C
Ca mbi o revi s a do y va l i da do
Aprueba Ca mbi o revi s a do
a proba do
AI R I
Ca mbi o revi s a do y va l i da do
Valida si Es Emergencia Ca mbi o revi s a do a proba do
a proba do
A R C
Informa ci ón de Ca mbi o Informa ci ón de Ca mbi o Compl eta
Envía a Gestor de Cambio el cambio completo
Compl eta a proba do a proba do y envi a da
A R
Informa ci ón de Ca mbi o Informa ci ón de Ca mbi o Compl eta
Controla solicitud
Compl eta a proba do a proba do control a do
RA I I

Informa ci ón de Ca mbi o Informa ci ón de Ca mbi o Compl eta

Verifica si es "Cambio Programado"
Compl eta a proba do control a do a proba do control a do y veri fi ca do
RA I I

Ca mbi os compl etos a proba dos Pl a ni l l a de Ca mbi os Aproba dos y

Convoca al CAB
y control a dos Recha za dos CAB
RA I I I
Ca mbi os a proba dos por CAB
Ca mbi os recha za dos por CAB con
Revisa el calendario de Cambio y realiza las Pl a ni l l a de ca mbi os pa ra CAB
Ca l enda ri o de Ca mbi os
obs erva ci ones A R
modificaciones necesarias
Ca l enda ri o de Ca mbi os
a ctua l i za do
Envía Observación Ca mbi os recha za dos por CAB Obs erva ci ones envi a da s RA I I I I
Ca l enda ri o de Ca mbi os Comuni ca ci ón de Ca l enda ri o de
Informa el Ok para implementación
a ctua l i za do Ca mbi os a ctua l i za dos
RA I I I I
Informa ci ón de Ca mbi o
Ca mbi o No Prog. Aproba do
Aprueba No Prog. Compl eta a proba do control a do
Ca mbi o No Prog. Recha za do
AI R I I I
y veri fi ca do
RFC a proba do a i mpl ementa r RFC Impl ementa do
Implementa lo solicitado Pl a n de Impl ementa ci ón Prueba s pos t-i mpl ementa ci ón AI IC R
Pl a n de Revers i ón rea l i za da s
Ca mbi o i mpl ementa do con
Rollback probl ema s RFC reverti da o vuel ta a trá s AI IC R
Pl a n de Revers i ón
RFC eva l ua da
RFC i mpl ementa da
Documento de Concl us i ones ,
Revisión Post Pl a n de Impl ementa ci ón
a cci ones y recomenda ci ones
AI R I I
Pl a n de Revers i ón

Cierra Cambio Ca mbi o rea l i za do a ctua l i za do RFC cerra da AI R I I

22
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 Mensual
Incidencias, Problemas, u otro cambio como
consecuencia de su implementación.

Normativa Asociada
N/A

23
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.

IMPACTO
Prioridad de un Cambio
Alto Medio Bajo

Alta Crítica Alta Media

URGENCIA 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
2 Alta dependerán de la criticidad de los
sistemas que soportan a los
3 Media procesos de negocio. Podrá estar
definida en el SLA.
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.

24
 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
No Bloqueante.
Medio 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.

25
 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.

26
Anexo II – Solicitud de Cambio

SOLICITUD DE CAMBIO
Ambiente PRODUCCION Número Cambio XXXX

Datos Generales del Cambio

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?
Descripción

Elementos de Configuración afectados

Aprobación
Aprobado por Fecha Aprobación
Plan de Implementación
Implementador

Plan de Reversión

Plan de Pruebas Post implementación

Responsable:
Detalle:

Implementación
Fecha/hora de Inicio Real
Resultado de Implementación
Fecha/hora de Fin Real

Observaciones

Formulario de
Cambio.xlsx

27
Anexo III – Bitácora de Cambios
Número de Referencia Ref. Origen Fecha/hora de Fecha/hora de Servicio Fecha Fecha/hora de Fecha/hora de Código de
Tipo Categoría Subcategoria Prioridad Riesgo Descripción Solicitado por Revisado por Motivo Implementador CI's afectados Aprobado por Observaciones
Cambio Origen Nro. Ticket Inicio Progr. Fin Progr. Afectado Aprobación Inicio Real Fin Real Cierre
Aplicacion/Servicios de Puesta en produccion Alejandro G. 12/2/2019
1 Normal Menor Media Medio Juan Requerimiento del Negocio Jira Evolutivo Jira XXXX 12/2/2019 22:00
Negocio de funcionalidad XXXX Calderón 23:30:00 PM VUCE YYY
Aplicacion/Servicios de Resolución de Alejandro G. Resolución de
2 Emergencias Menor Baja Bajo Pedro Incidente Incidente 2313
Negocio Incidente Calderón Incidentes/Problemas CICE XXX
Actualización RedHat
1001 Normal Mayor Infraestructura Media Bajo Hernan Chao Hernan Chao Actualización HW/SW No Aplica N/A
de 7.5 a 7.6
Actualización RedHat
1002 Normal Mayor Infraestructura Media Bajo Hernan Chao Hernan Chao Actualización HW/SW Cambio 1001
de 7.5 a 7.6

28