Gestión de Cambios

La gestión de cambios en IT es un proceso esencial para garantizar que las modificaciones en la infraestructura tecnológica, software, procesos y sistemas de información sean planificadas, controladas y ejecutadas de manera estructurada. Su principal objetivo es minimizar los riesgos e impactos negativos en los servicios de la organización.

Con esta sección en Pandora ITSM se pueden gestionar todos los cambios de la organización con la potencia que dan las tareas y tickets y donde van a poder intervenir equipos de cambio en el mismo.

• Standard Change: Cambios preautorizados y de bajo riesgo (tal como el reinicio de un servidor).
• Normal Change: Cambios planificados que requieren aprobación (por ejemplo la actualización de software).
• Emergency Change: Cambios críticos que deben implementarse de inmediato (como ejemplo: la aplicación de un parche de seguridad).

• Change Initiator: Persona que propone un cambio.
• Change Manager: Responsable de supervisar el cambio y su impacto. Suele ser el Manager del Team asignado.
• Change Team: Grupo encargado de implementar los cambios aprobados.

Cualquier usuario con acceso a Cambios puede puede proponer un cambio mediante una Solicitud de Cambio.

El usuario al crear el cambio podrá configurar los siguientes elementos:

• Nombre (requerido).
• Plantilla de cambio.
• Estado de cambio: En la creación este campo está deshabilitado y se configura automática al estado inicial (New).
• Equipo de cambio (requerido).
• Tipo de cambio.
• Prioridad.
• Nivel de riesgo.
• Impacto.
• Administrador (requerido).

Una solicitud de cambio se verá similar a:

Podrán asignarse al Cambio, objetos de inventario o los ficheros adjuntos que se necesiten. Los objetos de inventario se corresponden a los elementos afectados en el cambio y podrán añadirse nuevos objetos de inventario en el futuro que se consideren.

De igual manera sucede con los ficheros adjuntos:

Para el correcto seguimiento del cambio se podrán añadir Notas que no contabilizarán tiempos en la resolución del mismo.

El seguimiento de cada uno de los cambios que se realicen en el Change se mostrarán sobre la sección Tracker.

El Manager del Cambio se encargará de aprobar que el cambio se pueda llevar a cabo.

Se podrá aprobar el cambio indicando una pequeña valoración sobre el motivo por el que se Aprueba el cambio.

También existe la opción de denegar el cambio. Si esto es así el cambio se cierra de inmediato.

Una vez aprobado el Cambio, el estado del Cambio pasará a Scheduled. Se podrán configurar las Tareas y subtareas que se necesiten llevar a cabo para el cambio solicitado.

En la generación de la tarea se puede definir un nombre, Manager, Team, Inicio/Fin, horas estimadas, si tiene tarea padre o no, la descripción y la prioridad, el riesgo y el impacto de la misma.

Si existe una tarea padre, se visualiza de la siguiente manera:

Podrán a su vez abrirse tickets para completar estas tareas. Las horas computadas en los tickets se sumarán a las tareas.

Para asociar el ticket a la tarea, se debe hacer desde las opciones avanzadas del ticket:

Una vez asociado se visualizará en la sección de tickets asociados dentro del Cambio:

Los tiempos computados en el ticket, se contabilizarán como tiempos para completar la tarea.

El progreso de la tarea se completará cuando el Manager de cada una de las tareas marque como cada una de ellas como estado Completado. Dentro de las tareas y de los tickets asociados a las tareas se computarán a través de Workunits los tiempos que se ha dedicado para realizar las mismas.

La suma de estos tiempos, se contabilizará sobre el total del tiempo estimado en cada tarea y al finalizar la misma el Manager editará la tarea a estado Completado habiendo llegado o superado el tiempo estimado, para visualizar su 100 %.

Una vez están todas las tareas en estado Completado, el Cambio pasa a estado Review.

Cuando el estado del Cambio está en Review, significa que todas las tareas están completadas y pendientes de validar. Para ello el Manager de la tarea podrá validar las mismas cambiando su estado a Verificado.

Si todas las tareas están Verificadas, aparecerá la opción de Aprobar el cambio en la pestaña Closure Information.

En ese momento el Manager del Cambio podrá cerrar el mismo indicando un epílogo.

Se pueden tener distintas plantillas de Cambio preconfiguradas para que a la hora de solicitar un cambio, si está relacionado con una de las plantillas, se configure en el cambio por defecto los siguientes parámetros (exceptuando los campos Nombre y Descripción):

Las Plantillas de Cambio pueden ser creadas desde la sección Changes → Management → Templates. Una vez creada, aparecerán como opción en el campo Templates al generar un nuevo cambio.

Por defecto están disponibles siguientes Estados de Cambio:

Se pueden editar sus nombres desde la sección Changes → Management → Statuses sin cambiar el orden de los mismos. Los estados vienen definidos por las siguientes condiciones:

• New: Estado recién abierto, pendiente de Autorizar por el Manager del Cambio.
• Authorized: Estado que ha sido autorizado por el Manager del Cambio, aún no tiene ninguna Tarea generada. Si es denegado pasará al último estado de esta lista.
• Scheduled: Estado programado, tiene todas sus tareas pendientes y sin iniciar.
• Implement: En cuanto se comienza con alguna de las tareas automáticamente pasará a este estado.
• Review: Todas las tareas están finalizadas y el estado está pendiente de revisar.
• Closed: Cambio finalizado y cerrado. Puede ser por haber sido desautorizado o bien por haber finalizado correctamente tras pasar todo el proceso y completarse así como validarse todas las tareas pendientes.

Descritos anteriormente: Standard, Normal, Emergency. Desde el menú Changes → Management → Types podrán editarse sus nombres.

Como comportamiento específico, el tipo Standard está preautorizado y cuando se seleccione en cambio pasará a estado Authorized. Es importante que este tipo solamente se pueda configurar desde plantilla preautorizada.

Por defecto tres tipos de cada uno: Bajo, Medio y Alto. Al hacer clic en sus nombres se podrán editar sus nombres y colores característicos.

Por defecto los siguientes estados:

Se pueden editar sus nombres sin cambiar orden. Pending es el estado en el que la tarea aún no ha comenzado a realizarse, In process cuando se inicia, Completed cuando ha finalizado y Verified cuando una vez el Manager cerciora que se ha realizado correctamente y completado en su totalidad.

Hasta que todas las tareas asignadas al Cambio no están en estado Verified, el cambio no se puede Validar y Cerrar.

Son los Grupos de usuarios que se encargarán de gestionar un cambio. Dentro del Equipo del cambio debe existir un Manager ( que en la mayoría de ocasiones coincidirá con el Manager del Cambio que se haya asignado al Team).

Dentro de la sección Change → Teams se podrán crear todos los Equipos necesarios para gestionar todas las solicitudes de Cambio. Tendrán asociados cambios y tareas de cambio. Servirán para gestionar el ACL de los mismos.

A excepción del campo de descripción, los demás campos son obligatorios. A destacar entre ellos el campo Email donde normalmente se definirá un buzón de correo de grupo para que reciban las notificaciones de cambio todo el equipo al generarse los mismos.

Se pueden agregar y/o editar los usuarios del Equipo al acceder pulsando el icono Add users. Aparecerá automáticamente el Manager seleccionado dentro de esta vista y será el único usuario fijo del equipo.

En el menú Setup → Setup → Changes setup se pueden definir las notificaciones a recibir ante los cambios que se produzcan en la sección del Cambio:

En la sección Setup → Setup → Email template setup , se pueden configurar todas las plantillas de email que se utilizan en la gestión de cambio.

• Change Read: Bit de acceso de lectura para un perfil que permite que el usuario con este perfil visualice los Cambios del equipo o equipos a los cuales pertenezca.
• Change Write: Podrá crear nuevas solicitudes de Cambio y tendrá acceso solamente a visualizar las configuraciones del menú Changes → Management. También podrá agregar ciertos usuarios al equipo al cual pertenezca o retirarse del mismo. En este último caso solamente un superadmin o un usuario con bit Change Management podrá reintegrarlo al equipo.
• Change Management: Podrá ver todos los cambios abiertos y cerrados y editar los cambios que su rol dentro del Cambio le permitan.

• Usuario superadmin:

Podrá ver todos los cambios generados en ITSM así como gestionar los mismos como si tuviese el perfil Manager del mismo. En una instalación nueva de PITSM el usuario llamado admin es creado por defecto como superadmin.

• Usuario Manager del Cambio o con perfil Team Manager:

Podrá gestionar todos los Changes con permisos de Manager de los que sea manager o Team Manager. Podrá validar y aprobar estos cambios así como editar todos los elementos pertenecientes al mismo y gestionar por completo sus Tareas.

• Usuario perteneciente al Team asignado, sin perfil Manager:

Tendrá acceso a todos los changes asociados a su Team, así como a los que haya abierto él mismo. Podrá gestionar todos los Cambios con permisos de Manager en los que sea manager del mismo. En el resto de Cambios podrá añadir Workunits a las tareas, cambiar estado de las tareas, añadir notas y otros elementos para el correcto seguimiento del Cambio.

• Usuario lectura perteneciente a Team:

Solamente tendrá acceso a todos los Cambios asociados a su Team, así como a los que haya abierto el mismo usuario. En los Cambios que haya abierto el mismo usuario tendrá permisos de edición; sobre el resto que pueda visualizar en modo de lectura y únicamente podrá añadir Workunits, notas, ficheros, etcétera, sin poder modificar elementos importantes del mismo.

Volver al índice de documentación de Pandora ITSM