¡Esta es una revisión vieja del documento!


2. Gestión de tickets (Ticketing)

Integria IMS implementa un sistema de gestión de tickets o ticketing. Se puede utilizar en proyectos de desarrollo de software, como herramienta de helpdesk o adaptado a sus necesidades para atender cualquier necesidad de interacción con clientes o usuarios. Una serie de elementos comunes unen a todas esas actividades, para Integria IMS esos elementos comunes son las referencias a otros tickets, las referencias a uno o varios objetos del inventario y la vinculación única de un usuario con un ticket.

Un ejemplo del flujo de ticketing con Integria IMS

Nuestro equipo de soporte, está formado por tres personas (Tomás, Javi, Luis) y un “jefe” de equipo (Ramón). Tenemos varios tipos de clientes. Los que trabajan en equipo y los que van “por libre”. Los que operan también en “equipo”, es decir, un cliente que tiene a varias personas trabajando simultáneamente, y que pueden 'ver' los tickets de sus compañeros, o bien para aportar algo, o bien para hacerse cargo de ellos. Los que van por libre, solo ven lo suyo, y son la única persona que puede verlo. El primer tipo de cliente, tendrá un grupo propio, y usuarios asignados a ese grupo. Mientras que el segundo tipo de cliente, pertenecerá a un grupo “general” y tendrá el bit de “modo externo” activado, de forma que aunque pertenece a un grupo solo podrá ver “lo suyo”. Cuando un cliente de los que trabajan en grupo, abre un ticket. Automáticamente, ya que ese grupo está definido así, se asigna a una cuenta genérica de integria llamada “Support”. Generando un email que va a “[email protected]”.

Esa cuenta de email, automáticamente envía una copia a cada uno de los miembros del equipo de soporte. Esa semana, está de “guardia” Javi, quien ve el correo y pincha en el enlace para ir a Integria. Vería algo como lo siguiente:

En integria IMS ve un ticket nuevo, en color rojo. Se puede ver el usuario creador así como otros datos. Ante un ticket nuevo, como el que está en rojo, podemos añadir la primera respuesta. Cuando a un ticket nuevo se le añade una Unidad de Trabajo (o nota), ésta automáticamente se le asigna al usuario que escribe la unidad de trabajo, se le cambio a estado “Asignado”. Haciendo clic en el ticket que está en rojo entramos en la pantalla principal de gestión del ticket. Podemos cambiar su estado, o navegar por las solapas del ticket para ver su histórico, notas asociadas a el ticket (workunits), ficheros, etc. Nos interesa dar la primera respuesta al problema, ya que desde que se abre, se calcula cuanto tiempo pasa sin respuesta. Si pasa el margen de tiempo establecido por la SLA asociada al grupo de esa ticket, saltará una alarma. Cuando se añade una Unidad de trabajo (una nota) o un fichero o se cambia su estado, se le envía una notificación por email a todos los usuarios “suscritos” a ese ticket. En este caso, Javi va a poner una nota que dice “Veo lo que me cuentas y voy a intentar reproducirlo para determinar el origen del problema”.

Al crear la WU, mi ticket ha cambiado de estado. Al autor del ticket le llegará la nota que Javi ha metido en el sistema.

Pasan los días y el problema no se soluciona. Julio, el cliente que creó el ticket, vuelve a preguntar por el tema. Pero ese dia Javi no está en la oficina. Un compañero suyo, Luis, al cargo de los tickets, ve que el ticket está actualizada por el cliente, y le contesta, añadiendo una Unidad de Trabajo él mismo. A partir de ese momento, queda suscrito a el ticket, recibiendo todas las notificaciones sobre cambios en el ticket. Podemos ver en el menú de la izquierda, los usuarios que participan en el ticket: el creador, el usuario “dueño” del ticket (javi), y los que han participado en ella.

Un usuario sin permisos de “Gestión” en el sistema de tickets, pero con permisos de escritura, puede añadir unidades de trabajo, pero no puede “cambiar” al dueño del ticket, ni cerrarlo, si no es suyo. Si es un “gestor” de tickets, puede cambiar el dueño del ticket. Si el usuario es dueño del ticket, puede “reasignarsela” a otra persona. Este proceso se conoce como escalar un ticket. Finalmente, Javi pudo cerrar el ticket, puso en el campo “Epilogo” el resumen de la solución al problema, y cambia el ticket a estado “Resolved”. De esta forma, los tickets “resueltos” o “cerrados” ya no se ven en la vista por defecto de tickets, aunque por supuesto, se pueden buscar si se desean.

Usuarios y permisos en un ticket

Es muy importante primero conocer que permisos disponemos para los tickets. Existen varios roles diferentes en un ticket:

  • Creador del ticket

Es el autor original del ticket. Es quien establece el responsable de ese ticket (a no ser que esto se haga automáticamente), el grupo al que pertenece el ticket (idem) y otros parámetros como su criticidad, nivel de resolución, descripción, elementos de inventario a los que está vinculado, etc. El autor original una vez que crea un ticket, ya no puede “gobernarlo”, es decir, no podrá cerrarlo hasta que usuario responsable del ticket no lo decida. Tampoco podrá reabrirlo. Como cualquier usuario con acceso a el ticket, el usuario creador puede añadir ficheros y unidades de trabajo (UT o WU en inglés).

  • Propietario del ticket

Es el usuario asignado al ticket, también llamado “dueño” del ticket (owner). En la definición de grupos se asigna un usuario predeterminado, que será el usuario asignado por defecto, en función del grupo seleccionado por el usuario creador del ticket. El creador del ticket puede cambiar este usuario y seleccionar otro perteneciente al grupo al que asigna el ticket. El usuario responsable del ticket es el único que puede actualizar sus detalles y cambiar su estado. Cuando un “gestor” cambia el responsable del ticket decimos que hay un “escalado manual” del ticket.

  • Usuario con acceso de escritura al ticket

El ticket siempre pertenece a un grupo. Todos los usuarios con el flag de acceso “IW” pueden escribir UT (Unidades de Trabajo o Workunit en ingles) sobre un ticket. Estas UT son como “notas” que se van quedando adjuntas a el ticket. Este tipo de usuario no puede modificar ningún otro detalle del ticket, tal como estado o criticidad, ni alterar la descripción principal del ticket.

  • Usuario con acceso de lectura al ticket

Cualquier usuario que pertenezca al grupo de trabajo de un ticket y tenga el flag de acceso “IR” podrá leer los detalles del ticket, aunque no podrá modificar nada, ni agregar una UT o fichero.

  • Usuario con acceso de gestión al ticket

Un usuario con el bit de acceso IM sobre el grupo al que pertenece un ticket puede operar con el como si fuera el propietario del mismo. Esto implica que puede «escalar» el ticket apropiándoselo o traspasar la responsabilidad del mismo a otro usuario. Por supuesto puede agregar UT o ficheros e incluso cerrar el ticket.

  • Usuario que cierra el ticket

Es el responsable del cierre del ticket, que puede no ser el mismo que ejecuta la acción. Por ejemplo, el usuario 'tecnico' cierra un ticket por orden del usuario 'admin'. En este caso, el usuario que cierra el ticket sería el usuario 'admin'.

  • Usuario adscrito a un ticket

Es cualquier persona “externa” al sistema. Se pone su email en el campo avanzado “Direcciones de email adicionales”, si hay varios, se separan por comas. Si dicho email es parte del sistema (en el sistema de contactos) se visualizarán algunos de sus datos, como nombre y empresa, sino simplemente su email. En la solapa “Contactos” podemos ver la lista completa de las personas que participan en un ticket.

A continuación vamos a ver las opciones principales que podemos hacer con los tickets de Integria.

Creando un Tipo de ticket

Antes de crear un ticket es muy importante definir los tipos. A un ticket se le puede asignar un tipo. Cada tipo de ticket puede tener asociados campos personalizados según convenga. Estos campos puede ser de varios tipos: texto, combo, área de texto, numérico o linkados. Si se elige el tipo combo o linkado, habrá que especificar los valores que tendrán éstos controles. A continuación, vemos un ejemplo de creación de tipo combo:

Ahora creamos un campo personalizado asociado al tipo anterior:

Los campos linkados están relacionados entre sí. Los vamos a explicar con un ejemplo:

TIPO,VEHICULO,MARCA,MODELO,MOTOR

Primero crearemos el campo TIPO. En este caso, no seleccionamos campo padre porque es el primero en nuestra jerarquía. Los valores irán separados por coma.

Después crearemos el campo MARCA. Habrá que seleccionar el campo padre TIPO. Después rellenaremos el campo con los valores separados por coma como en el caso anterior. Como este campo sí tiene un padre, habrá que asociar los valores. Para ello, pondremos delante el valor del campo padre separado por |

El siguiente campo que vamos a crear es MODELO. Se selecciona el padre MARCA y se ponen los valores.

Por último, creamos el campo MOTOR.

Los campos marcados con el check “Mostrar en la vista general” son campos que se pueden usar en búsquedas y que se muestran en la visualización de lista. En los campos de tipo textarea no se puede usar esta casilla. Vista general:

Creando un ticket


Documentación de Integria