MANUAL DE USUARIO GESTION DE CAMBIOS
CONTENIDO 1. Introducción... 3 2. Objetivo... 3 3. Guía de uso... 3 3.1 Gestión de Cambios... 3 4. Diagrama de Flujo... 9 5. Sección de solución de problemas... 9
1. Introducción El propósito de este documento es proveer una pauta específica del cómo se realiza el paso a paso de un registro de una solicitud de cambio en la herramienta helppeople contribuyendo a que estos cambios generen trastornos y riegos mínimos. En la mayoría de las empresas creen que la gestión de cambios es demasiado rígida y que no es posible implementar los cambios rápidamente cuando se instaura un proceso prolongado pero con helppeople Service Management la gestión de Cambios no será complicada, se trata sólo de tener un plan y de organizarse para no tener sorpresas con el tiempo de inactividad. 2. Objetivo Proporcionar toda información necesaria para evaluar y planificar el proceso de cambio y así asegurar que se haga de la forma más eficiente, siguiendo las buenas prácticas y garantizando en todo momento la calidad y continuidad del servicio TI. 3. Guía de uso 3.1 Gestión de Cambios Para iniciar el proceso de atención de gestión de cambios a través de la herramienta de gestión helppeople Service Manager, se debe dar clic en el menú transición opción Gestión de Cambios ubicado en la parte superior, ver siguiente imagen: Si se desea crear solicitudes de cambio desde helppeople se debe dar clic sobre la opción Nuevo RFC, icono del más, como se aprecia en la siguiente imagen: Luego se despliega la pantalla con la información del RFC a crearse, así:
Cabe aclarar que para crear una solicitud de cambio se debe realizar con el rol de agente de mesa de servicio, dicho agente solo diligenciará la pestaña Datos Generales Paso 1: Se selecciona el usuario quien solicita el cambio Paso 2: todo RFC debe tener asociado un líder de cambio, en algunas organizaciones si se tiene definido este rol, en otros se configura un líder default, este líder de cambio es un segundo solicitante de cambio y fue quien reviso inicialmente si la solicitud calificaba como solicitud de cambio. Paso 3: Realizar una explicación detallada de la solicitud, también se pueden configurar plantillas de solicitud para agilizar esta tarea. Paso 4: Realizar una breve explicación de la solicitud, su longitud es Paso 5: Seleccionar la vía por la cual llega la solicitud, cabe aclarar al seleccionar la via mail y twitter la fecha de recepción son obligatorias Paso 6: La fecha de recepción corresponde a fecha en la que llego la solicitud, no puede ser mayor a la actual Paso 7: Realizar categorización de la solicitud, asignación de grupo y responsable En este momento de la creación de la solicitud, se debe adjuntar obligatoriamente en la herramienta un archivo que corresponda al RFC (formato propio que cada entidad conserve) Al dar clic en guardar, la herramienta indicara el número de solicitud de cambio, esta queda en estado Por revisar y le llegarán las siguientes notificaciones:
Al usuario indicando que se creó una solicitud de cambio Al rol coordinador de cambios quien deberá revisar la solicitud De acuerdo a la notificación que llega, el rol coordinador de cambios ingresa a la herramienta a revisar la creación de la solicitud de cambio, si esta correctamente categorizado según el área de servicio, servicio, categoría y actividad, en este punto se enfocaría en la pestaña RFC, donde se debe seleccionar el tipo de cambio, tipo de categorización, interrupción de servicio y la evaluación del riesgo, ver imagen adjunta.
Al dar clic en guardar, la herramienta indicara la solicitud de cambio ha sido actualizada, esta queda en estado Por Aprobar y le llegarán la siguiente notificación, como se ve en la siguiente imagen: A los aprobadores indicando que deben evaluar la solicitud de cambio
En el estado por aprobar, se lanzan las aprobaciones a cada uno de los miembros del comité, para realizar la evaluación del RFC, para ingresar a la pestaña aprobación se debe ingresar al link de la notificación, el cual es un acceso directo, como se ve en la siguiente imagen: Como se puede apreciar en la anterior imagen, el aprobador puede aprobar (aceptar el cambio) o No aprobar (rechazar el cambio), esta evaluación afecta el estado del RFC de acuerdo a lo que se haya parametrizado en la política de cambio, por ejemplo en la siguiente imagen se puede apreciar que cambia de estado con 1 sola aprobación o una sola no aprobación. Luego de cumplir con el máximo de aprobadores, envía notificación de cada uno de los evaluadores al coordinador de cambios y activa la orden de trabajo asociada a la orden de servicio, el responsable de
servicio debe ejecutar el cambio y documentar la OT, si se requiere crear más OT, se realizaran me manera manual. Al cerrar la OT asignada al responsable del cambio, el RFC cambia a estado en pruebas. Cuando se cumple con el máximo de no aprobadores, el RFC queda en estado rechazado, no se crea la OT y la OS queda en estado solucionado. Cuando el estado del RFC es en pruebas, se debe documentar la post implementación con el rol de coordinador de cambios, la post implementación también tiene dos opciones de calificación aprobado y rechazado. Cuando se aprueba la post implementación, el RFC queda en estado realizado y con esta acción queda finalizado el proceso de gestión de cambios. En cambio cuando rechaza la post implementación, el RFC queda en estado Autorizado, se reactiva la misma Orden de Trabajo para realizar el rollback, al cerrarse de nuevo la orden de trabajo el estado vuelve en estado en Pruebas hasta que se apruebe la post implementación y se finalice el proceso de cambios en la herramienta. Cabe anotar que en la pestañan de reuniones CAB y post implementación se puede adjuntar documentos para sustentar las acciones realizadas.
4. Diagrama de Flujo 5. Sección de solución de problemas Si las personas encargadas de realizar la aprobación no coinciden con los usuarios que se parametrizaron en la política de cambios, se debe verificar que el RFC haya tomado la política correcta, en caso que la política no sea se debe verificar los criterios de la política coincidan con la solicitud. Si al aprobador no le sale el botón habilitado de aprobar o no aprobar, se debe verificar que el login ingresado sea igual al login quien debe hacer la aprobación. Si el RFC no pasa por las fases de revisión, aprobación y post implementación, revisar la programación de la política de cambio que está aplicando y seleccionar las fases que se requieren. Si tiene algún otro inconveniente con el modulo por favor dirigirse al administrador de herramienta.