Paso a Paso
Gestión de Cambios de Emergencia
Service Transition
Es un resumen de cómo crear un cambio de emergencia. Este resumen va dirigido a personas que
ya han recibido el curso introductorio de gestión de cambios o quienes ya tengan experiencia
creando cambios y utilicen este paso a paso rápido como refrescamiento del proceso.
Si no has utilizado el proceso de gestión de cambios primero debes completar el curso en la
universidad GBM al que puedes auto matricularte en el siguiente link:
https://universidad.gbm.net/cms/course/view.php?id=67
Cualquier consulta por favor comunicarse con los gestores de cambios directamente o al correo de
changemanagement@gbm.net.
Para saber quiénes deben ser los responsables de las actividades dentro del proceso deben validar
la matriz que se encuentra en el procedimiento de Gestión de Cambios en QDoc, las personas
varían según la torre y el servicio. Ver el siguiente link:
https://qdoc.gbm.net/ControlDocumental/Documento.aspx?Id=756
Gestión de Cambios de Emergencia
Solicitante del cambio:
Se detecta la necesidad de crear un cambio de emergencia cuando: se cuenta con un incidente; se
detecta un evento que va a generar afectación de servicio si no se atiende pronto; se cuenta con la
necesidad de realizar un cambio y el cliente tiene un SLA muy agresivo de resolución.
Es necesario validar la matriz de roles responsables dentro de este proceso ubicada en la
instrucción de gestión de cambios de emergencia en QDoc, ahí se especifica quienes participan de
los comités de emergencia que aprueban la implementación de cambios sin una documentación
previa debo a la urgencia en la atención, el quien participa de cada rol varía según el servicio.
En horario de oficina se debe contactar al gestor de cambios para que convoque vía conferencia
telefónica al comité de cambios de emergencia, este comité realizaría el análisis y autorización de
la realización del cambio y un día hábil después como máximo el ingeniero responsable debe
documentar el RFC en la herramienta. Una vez finalizada la conferencia el que convocó la
conferencia debe enviar un correo de según lo conversado copiando a los interesados.
En horario fuera de oficina se debe contactar al responsable administrativo del servicio quien
convocaría al comité de cambios de emergencia con el mismo objetivo anterior.
1.
2.
3.
4.
5.
6.
7.
8.
9.
Selecciona el Job Plan de emergencias y validar que el cambio sea tipo emergencia
Complete todos los cambios marcados con asterisco ya que son obligatorios.
Asigne un autorizador.
Seleccione la fecha en la que se realizó el cambio.
Asigne las personas para las tareas de implementación.
Adjunte el correo de la sesión del ECAB.
Adjunte las evidencias del cambio realizado.
Incluya un dueño de cambio e inicie el proceso de cambios.
Confirme la documentación del RFC.
Change Manager:
1. Validará que el RFC esté bien documentado, si se detecta alguna inconsistencia puede
asignar el RFC al responsable para su corrección.
Autorizador del cambio:
1. Solo debe tocar la tarea de asignación que está en la pestaña principal del cambio e indicar
si autoriza el cambio, cancelarlo o devolverlo al solicitante del cambio para que documente
información faltante.
Cuando la autorización sea satisfactoria el estado del RFC pasa a “Closed” y de esta forma se finaliza
el flujo del proceso.
Conocimiento de Interés
✓ Comunicados internos en el RFC
✓ Auto asignación del rol “Dueño de cambio”
✓ Ver quién tiene tareas pendientes en el RFC
✓ Generación de reportes de cambios
En las siguientes páginas se verán los pasos mencionados anteriormente con apoyo gráfico de cómo
se ve en la herramienta IBM Control Desk.
Solicitante del cambio:
1. Seleccione el Job Plan y verifique que el cambio sea de tipo emergencia.
Presione el botón de las flechas y luego donde indica Select Value, ahí aparecerá otra pantalla donde
se puede buscar el Job Plan por medio de palabras claves como: Disco, en caso de que estemos
buscando un plan de trabajo que sea para cambio de disco duro. Si no encontramos un plan de
trabajo que se realizó se debe utilizar el Job Plan IBMCHGEM.
Recordar validar que el cambio sea de tipo emergencia.
2. Complete todos los cambios marcados con asterisco ya que son obligatorios.
Se va a explicar en qué consiste cada campo separado uno de otro por una coma.
Summary: Título descriptivo, Details: de dónde nace el cambio, Class Description: clasificación del
cambio por la actividad que se vaya a realizar (este campo llena automáticamente el siguiente de
Classification), Change Type: tipo de cambio, Impact: nivel de afectación de servicio, Urgency:
tiempo prioritario en el que se debe restablecer el servicio, Priority: prioridad de ejecución del
cambio, Change Category: Mayor en caso que haya afectación de servicios críticos o Menor en caso
contrario, Reason for Change: razón del cambio, Back Out Plan: indicar que no aplica, Verification:
pruebas que se realizaron para validar la funcionabilidad del servicio, Effect Of Not Implementing:
efecto de no implementar el cambio.
Configuration Item: se busca el CI en caso de exista una CMDB | Se selecciona el CI “NUEVOCI” en
caso que se requiera crear un nuevo CI | Se selecciona NOADM.CI en caso que no se cuente con
CMDB, Asset: no se llena, Location: Se busca la ubicación en la que se encuentra el CI en caso que
la ubicación no exista se utiliza GBMHQ, Outage: es la interrupción que va a sufrir el CI a la hora de
ejecutar el cambio.
Name: Nombre del solicitante del cambio, Datos de Contacto: información del cliente externo,
Customer: se selecciona el cliente, Service Group: grupo de servicio al que pertenece el cambio,
Service: servicio específico al que pertenece el cambio.
3. Se debe incluir un autorizador.
Pasamos a la pestaña de Authorization
Presione el botón de New Row para agregar un autorizador y complete el campo de Approver
cuando elija a una persona como autorizadora o Approver Group cuando se deba elegir un grupo
de autorizadores, se selecciona el grupo IBM CAB (para autorizaciones de clientes externos).
4. Indique la fecha en la que se realizó el cambio.
Ir a la pestaña de Schedule
Seleccione la fecha propuesta de realizar el cambio en Actual Start y Actual Finish, a esto se le conoce
como la ventana del cambio. Se debe incluir el tiempo en horas de la ventana del cambio en donde
dice “Estimated Duration”.
5. Asignar a las personas para las tareas de implementación.
Si se seleccionó al inicio del RFC un Job Plan que se apegara al cambio realizado entonces acá
vendrían ya cargadas las tareas de implementación y solo sería necesario que las leas y las
modifiques en caso de que sea necesario y posteriormente agregarle una persona a cada tarea, en
caso de haber utilizado el Job Plan de IBMCHGEM debes presionar el botón de New Task y
documentar las tareas implementadas e especificar las horas dedicas a la tareas y la persona
responsable de haberla ejecutado.
6. Adjunte el correo de la sesión del ECAB.
Adjuntar el correo enviado como evidencia de que se realizó el ECAB, en las pestañas del cambio
aparece la opción de “Attachments” desde cualquier pestaña del cambio se puede realizar esta
acción, se presiona el ícono que aparece en esta sección y se elije la opción de “Add New
Attachments” -> “Add New File”, luego se busca el documento guardado previamente en los
archivos de la computadora y se selecciona
Luego de haber seleccionado el archivo se presiona el botón de OK.
7. Adjunte las evidencias del cambio realizado.
La documentación de un cambio de emergencia se caracteriza por documentar lo ya realizado, por
lo que además de haber indicado cuales fueron las actividades realizadas hay que adjuntar las
evidencias de lo realizado, esto se hace en la pestaña de “Shedule” en la sección de “Work
Evidence”, acá se pueden pegar y copiar imágenes siempre y cuando se use el explorador de
“Firefox” o se pude evidenciar con comandos o alguna ingeniería realizada.
8. Incluir un dueño de cambio e iniciar el proceso de cambios.
Luego de documentar todos los pasos anteriores se debe guardar el cambio y aparecería un mensaje
como el siguiente
Luego se presiona el botón de continuar con el flujo y nos saldrá el mensaje de que debemos
seleccionar un dueño de cambio y luego volver a presionar este mismo botón para iniciar el
proceso de cambios.
Cerramos esta ventana y nos vamos al panel izquierdo en “Common Actions” y seleccionamos
“Select Owner”, ahí buscamos a la persona que sería la dueña del cambio.
Presionamos donde dice “Filter” a la par de Persons y ahí podemos buscar a la persona por el correo
electrónico.
Luego como se mencionó anteriormente se vuelve a presionar el botón de continuar el flujo y
aparece el siguiente mensaje:
Cerramos la ventana y volvemos a presionar el botón de continuar el flujo y aparecerá el siguiente
mensaje y se habrán realizado las asignaciones a los responsables que agregaste a este cambio.
9. Confirme la documentación del RFC.
La primera tarea que se asigna es al creado del cambio o solicitante del cambio y lo que indica la
tarea es confirmar si ya todo está documentado con evidencias y demás para enviarlo a revisión al
gestor de cambios o si aún tenemos pendientes alguna documentación:
Gestor de cambios
Luego de este paso el gestor de cambios validará si la documentación está completa y de ser así lo
envía al autorizador que estuvo presente en el ECAB para que confirme lo documentado, en caso
de que el gestor observe que tiene pendiente alguna documentación solicitará completar lo
pendiente.
Autorizador del cambio:
1. Solo debe tocar la tarea de asignación que está en la pestaña principal del
cambio e indicar si autoriza o rechaza el cambio, puede indicar detalles en
donde dice “Memo”.
El objetivo de este rol es aprobar de forma definitiva el plan de trabajo que se propuso y que se
evaluó por algún especialista, por lo tanto, lo primero que debe hacer es leer todo el RFC, todas las
pestañas y autorizar tanto el plan de trabajo como el horario en el que se ejecutarán los trabajos.
Una vez leído todo en la pestaña de Change presiona la tarea asignada con el ícono con la persona
con un rayo amarillo y ahí le aparecerá la opción de rechazar el cambio, autorizarlo o cancelarlo,
una vez elegida la opción correspondiente presiona OK y listo.
Cuando se deba elegir la opción de rechazarlo o cancelarlo la herramienta le solicitará crear un
comunicado en la pestaña de “Log” indicando el motivo.
<
Una vez autorizado el cambio se procede a cerrar automáticamente.
Detalles de interés:
Comunicados internos en el RFC
En la pestaña de “Log” podemos incluir notas de seguimiento del RFC, pueden ser comunicados al
cliente, actualizaciones del caso, o incluir justificaciones para la cancelación de un RFC. Se presiona
el botón de “New Row” y elije el tipo de nota según corresponda.
<
Auto asignación del rol “Dueño de cambio”
En el panel izquierdo en “Common Actions” elegimos la opción de “Take Ownership” y esto nos
evita un par de pasos a la hora de elegir este rol.
Ver quién tiene tareas pendientes en el RFC
Buscamos el RFC en la herramienta y en la primera pestaña de “Change” en la sección de “Current
Work Items” presionamos la tarea de la primer línea y podemos ver a quien está asignada la tarea.
Generación de reportes de cambios
Estando en el módulo de cambios en el panel izquierdo encontraremos la sección de “Available
Queries” y seleccionamos la opción de All Records.
Luego en la barra superior donde está la lupa elegimos “More Search Fields” que es para realizar
una búsqueda avanzada de los RFCs
Acá buscamos los RFCs que queremos en nuestro reporte según los criterios seleccionados, puede
ser rango de fecha, cliente, ubicación, servicio, dueño de RFC, entre otros y presionamos el botón
de “Find”
Por último, presionamos el botón de descarga y ya tenemos nuestro reporte.
<