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.

16

Flujo de Proceso

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

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.

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