Integria IMS propone una visión de la gestión de tickets adaptable a diferentes necesidades: se puede entender un ticket como un problema técnico, el resultado de una intervención planificada, un bug de software o una hoja de trabajo sobre un problema más complejo.

Los tickets tienen una serie de características básicas, que responden a las necesidades de entornos de trabajo con tickets habituales, tales como la gestión mediante grupos de trabajo, usuarios creadores y propietarios, comentarios y seguimiento, asociación a objetos de inventario, SLA, etc.

Caso práctico de flujo de ticketing con Integria

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 actúan de forma independiente. Los que operan en equipo, tendrán a varias personas trabajando simultáneamente que podrán visualizar los tickets de sus compañeros, o bien para aportar algo, o bien para hacerse cargo de ellos. Los clientes o usuarios independientes sólo pueden ver sus propios tickets, y nadie más tiene acceso a éstos.

El primer tipo de cliente tendrá un grupo propio y varios usuarios asignados a ese grupo, los usuarios de este grupo serán de tipo “agrupado”, y sus privilegios se basarán en el perfil que tengan asociado para su grupo de trabajo. Mientras que el segundo tipo de cliente actuará de forma individual y su usuario será de tipo “independiente”, de forma que únicamente visualizará su propio contenido.

En nuestro entorno piloto, cuando un cliente de tipo agrupado abre un ticket, se asigna a un usuario genérico de Integria llamado “Soporte”, generando un email que va a “[email protected]”. Tanto el usuario por defecto como la dirección de correo se especifican en la sección de configuración de su grupo.

Esa cuenta de email es una lista de distribución que envía una copia a cada uno de los miembros del equipo de soporte. Al recibir el correo y acceder al enlace adjunto, accediendo a la herramienta se visualizará un ticket nuevo resaltado en color rojo, de esta forma:

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 al ticket (workunits), ficheros, etc. Generalmente 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 el SLA asociado al grupo de ese ticket, aparecerá un warning junto al nombre del ticket, además de enviarse un mail de forma automática.

Sobre un ticket nuevo puede añadirse una primera respuesta en forma de unidad de trabajo o comentario. El ticket entonces será asignado automáticamente al usuario que escribe la unidad de trabajo, modificando el estado del ticket de “Nuevo” a “Asignado”.

Cuando se añade una Unidad de trabajo (comentario) o un fichero o se cambia su estado, se envía una notificación por email a todos los usuarios “suscritos” a ese ticket. En este caso, un usuario de soporte 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, el ticket ha cambiado de estado a “Asignado”, y al autor del ticket le llegará un email con el comentario añadido.

En cualquier momento de la vida del ticket, si un nuevo usuario añade un comentario o realiza alguna modificación en el ticket, quedará suscrito al ticket, recibiendo todas las notificaciones sobre cambios en el ticket. En la sección “seguimiento” del ticket puede verse un registro de todos los usuarios que han participado en el ticket en algún momento.

Dependiendo del nivel de privilegios del usuario podrá símplemente visualizar tickets, añadir comentarios o incluso modificar el propietario, el tipo, etc. Finalmente cuando un ticket queda resuelto, un usuario con permisos puede cambiar el estado a “Cerrado”, desapareciendo así de la vista por defecto de tickets. Naturalmente quedará en estado cerrado para poder consultarlo en cualquier momento.

Los tipos de tickets nos permiten crear tickets con campos personalizados para diferentes grupos, además de poder añadirle partes de trabajo específicos.

Veamos un ejemplo:

Como vemos en el ejemplo anterior:

• example pertenece a los grupos Customer #A, Customer #B, Engineering.
• example1 pertenece a Customer #A.
• example3 pertenece Customer #B.

Para crear un tipo de ticket tenemos dos opciones:

• El botón que aparece debajo de la lista de tipos de tickets.

• La opcion crear tipo de ticket del menú lateral.

Campos que se pueden definir en la creación/edición de un tipo de ticket:

• Nombre: es obligatorio y debe ser único, es decir, no puede coincidir con el nombre de otro tipo existente. Este campo es el que se mostrará en el formulario de creación/edición de tickets para poder seleccionar el tipo.
• Descripción: es opcional.
• Plantilla de partes de trabajo: es opcional y nos permite añadir una plantilla de parte de trabajo.
• Grupos: es opcional y nos permite relacionar el tipo a uno o varios grupos. Si lo dejamos vacío, se podrá asignar este tipo de ticket a cualquier grupo.

Las acciones que se pueden aplicar a un tipo son:

• Añadir campos personalizados.
• Actualizar los datos (nombre, descripción, plantilla, grupos).
• Borrado.

A continuación vemos un ejemplo

Para actualizar, se hace click en el icono llave inglesa que nos llevará a la vista de edición. Una vez aquí, podremos modificar cualquier apartado.

Para borrar, se hace click en el icono papelera. Esta acción nos pedirá confirmación. Una vez aceptado, el borrado será definitivo y no se podrá deshacer esta acción.

Para añadir campos personalizados, se hace click en el icono suma.

• Nombre: es obligatorio y puede no ser único.
• Mostrar en la lista de ticket: al marcar esta opción, aparecerá como columna en el listado de tickets.
• Campo global: al marcar esta opción, aparecerá en el formulario de búsqueda de tickets dentro de las opciones avanzadas.
• Tipo de campo:
  • Tipo texto: Se mostrará en el formulario de creación/edición de tickets un campo de tipo input.

• Textarea: Se mostrará en el formulario de creación/edición de tickets un campo de tipo textarea.

• Combo: Se mostrará en el formulario de creación/edición de tickets un campo de tipo select con todas las opciones disponibles.

• Lincado: Son campos personalizados relacionados entre sí. Los vamos a explicar con un ejemplo:
  • TIPO,VEHÍCULO,MARCA,MODELO,MOTOR
    • Primero se crea el campo TIPO. En este caso, no se selecciona un campo padre porque es el primero en la jerarquía. Los valores irán separados por coma.

• Después se creará el campo MARCA. En este caso, se selecciona el campo padre TIPO. Después se rellenará 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, se pondrá delante el valor del campo padre separado de |

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

• Por último, se crea el campo MOTOR.

• Numérico: Se mostrará en el formulario de creación/edición de tickets un campo de tipo numérico.

• Fecha: Se mostrará en el formulario de creación/edición de tickets un campo de tipo fecha.

A continuación se muestra el listado con todos los campos que se han creado.

Las columnas que componen este listado son:

• Nombre del campo.
• Tipo del campo.
• Padre: Es exclusivo de los tipo lincados ya que estos pueden hacer referencia a un padre.
• Valor: Es exclusivo de los tipo combo y lincados ya que estos tienen un valor por defecto para seleccionar.
• Acciones: Permiten la edición o borrado del campo.
• Ordenar: permite asignar el orden en que serán mostrados.

Ejemplo de ordenación: Se quiere que los campos TIPO, MARCA, MODELO, MOTOR se vean los primeros, habría que seleccionar los cuatro campos en la lista y en el menú de ordenación seleccionamos la opción “antes de” y la posición que en este caso seria el primero.

Como se puede ver, ahora aparecen los campos lincados al comienzo de la lista.

La asignación de grupo a un tipo de ticket es opcional y nos permite relacionar el tipo a uno o varios grupos. Si lo dejamos vacío, este tipo de ticket se podrá asignar a cualquier grupo.

Un ticket podrá tener asociado uno o varios partes de trabajo. Un parte de trabajo es un documento que se podrá descargar para su posterior validación. Para facilitar la creación de este documento de forma sencilla y flexible, tenemos las plantillas. Un tipo de ticket sólo podrá tener asociada una única plantilla.

Creación de plantilla

• Opción 'Crear' que aparece debajo del listado.
• Opción 'Crear plantilla de parte de trabajo' que se muestra en el menú lateral.

Elementos que forman la plantilla:

• Nombre de la plantilla.
• Descripción: es opcional.
• Asignar a: aquí se podrán elegir los tipos de ticket que van a tener asociada esa plantilla.
• Contenido: puede ser texto plano o texto html. Para elegir la opción html, habrá que seleccionar el icono HTML en la barra de herramientas.

Se pueden añadir imágenes de forma sencilla seleccionando el siguiente icono:

El siguiente paso sería añadir la url de la imagen.

También podremos Utilizar macros: Las siguientes palabras serán reemplazadas por el valor real en las plantillas que las usen:

• _sitename_: Nombre de la página, tal y como está definido en la configuración.
• _incident_title_: Título del incidente.
• _username_: Nombre del usuario.
• _fullname_: Nombre completo del usuario.
• _incident_id_: ID del incidente.
• _url_: URL del incidente.
• _creation_timestamp_: Fecha/Hora de la creación del incidente.
• _update_timestamp_: Última vez que el incidente fue actualizado.
• _owner_: Usuario que gestiona el incidente.
• _group_: Grupo asignado al incidente.
• _author_: Creador del incidente.
• _type_tickets_: Tipo de tickets.
• _priority_: Prioridad del incidente.
• _status_: Estado del incidente.
• _resolution_: Resolución del incidente.
• _time_used_: Tiempo total usado en el incidente.
• _incident_main_text_: Descripción del incidente.
• Plantillas de campos personalizados: Esto permite que al crear un tipo de objeto el nombre de los campos que agregas puedes incluirlos como una macro la cual mostrara el valor de dicho campo: _nombre del campo personalizado_.

Estas macros podrán ser utilizadas en código html:

A continuación, tenemos el listado con todas las plantillas que se han generado. En esta vista se muestra: nombre, descripción, a qué tipo de ticket está asignada, borrado y edición.

¿Qué utilidad tienen los tipos de ticket? Los tipos de ticket nos van a permitir crear tickets de una forma flexible, es decir, al seleccionar un tipo, nos van a aparecer sus campos personalizados y podremos generar partes de trabajo utilizando su plantilla. Lo vemos con un ejemplo:

Seleccionamos el tipo de ticket:

Y vemos que aparecen todos nuestros campos personalizados:

Rellenamos los campos y creamos el ticket:

Se puede encontrar un resumen con los campos personalizados asociados a un ticket en su vista general (dashboard).

Partes de trabajo asignados a un tipo de ticket

La gestión de partes de trabajo dentro de un ticket se hará en la pestaña Partes de Trabajo

Para crear un parte de trabajo simplemente clickamos en nuevo y se creará un parte de trabajo que podremos descargar, validar o borrar.

Hay que tener en cuenta que un parte de trabajo validado ya no se podrá borrar ni descargar. La única acción posible asociada a este parte será la descarga de su validación.

Uno de los campos más importantes de los tickets es el estado. Mediante este campo podremos hacer un seguimiento preciso del momento de su vida en que se encuentra el ticket, bien si es algo reciente, si está se encuentra a la espera de agentes externos, pendiente de cierre o cerrado. Este ciclo está abierto al usuario y se puede pasar de uno a otro sin restricción por defecto.

Es posible definir un flujo controlado para restringir el orden de los estados por los que un ticket puede pasar mediante la característica del Mapeo de estados. Haciendo uso del mapeo de estados podemos definir si un ticket debe pasar por diferentes fases antes de ser cerrado.

Un Ejemplo de diferentes estados de un ticket

Ejemplo práctico: tenemos un equipo de operadores responsables de la gestión de incidencias de clientes. Para asegurarnos de que el orden de resolución es respetado y garantizar una calidad de servicio al cliente, mediante el mapeo de estados indicaremos que un ticket con estado “Nuevo” únicamente puede pasar a los estados “Asignado” o “Pendiente de tercera persona”; de cualquiera de estos tres estados únicamente podrá pasar a “Pendiente de ser cierrado”, y será desde éste desde el que pueda quedar finalmente “Cerrado”. Además, desde “Cerrado” la única posibilidad será volver a “Re-abierto”. La configuración para este caso sería como esta:

Existen determinadas circunstancias que actúan automáticamente cuando pasamos de un estado a otro. Al pasar de cualquier estado, al estado «cerrado», automáticamente se activará una casilla de texto que antes no estaba accesible llamada «epílogo» que sirve para explicar cuál fué el resultado de la intervención o cambio o cual fué -en suma- la causa del problema y su solución. Como se verá más adelante, un ticket solucionado es la base para generar un artículo en la base de conocimiento que sirva para en posteriores ocasiones, solucionar un problema de forma rápida y documentada.

Existen cinco roles diferentes en un ticket:

1. Creador del ticket.
2. Propietario del ticket.
3. Usuario con acceso de escritura (IW)
4. Usuario con acceso de lectura (IR)
5. Usuario con acceso de gestión (IM)
6. Usuario que cierra el ticket.
7. Usuarios suscritos a un ticket.

Es el autor original del ticket. Es quien establece el responsable de ese ticket (a no ser que esto se haga automáticamente, como veremos más adelante), el grupo al que pertenece el ticket (idem) y otros parámetros como su criticidad, descripción, elementos de inventario a los que está vinculado, etc.

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).

Usuario asignado al ticket. Habitualmente en la definición de grupos se asigna un usuario predeterminado, que será el usuario al cual se le asignará el ticket por defecto, en función del grupo seleccionado por el usuario creador del ticket. Los privilegios que tendrá dependerán de su nivel de perfil para el grupo del ticket, puede ser simple lectura (usuario genérico) o permisos de gestión.

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 comentarios que quedan reflejados en el ticket a modo de seguimiento personal, indicando acciones realizadas o facilitando datos. 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.

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 comentarios o fichero.

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.

Puede ser cualquier usuario con permisos de gestión sobre el ticket. A la hora de cerrar un ticket aparece un nuevo campo “Cerrado por”, pudiendo elegir cualquier usuario del grupo; naturalmente por defecto será el usuario que lleve a cabo la acción de cerrar el ticket.

Cualquier persona que haya participado en algún momento durante la vida del ticket, realizando modificaciones o añadiendo comentarios. También recibirá notificaciones con las actualizaciones que se produzcan en el ticket. En la solapa “Contactos” podemos ver la lista completa de las personas que participan en un ticket.

A la hora de crear y rellenar correctamente un ticket es importante tener claros los siguientes conceptos:

• Qué es un usuario en Integria.
  • Tipos de usuarios (agrupados, independientes)
• Qué es un grupo en Integria
  • Qué relación hay entre el grupo, el perfil de acceso del usuario y el tipo de usuario que es (externo, normal)
• El inventario

Es fundamental entender la diferencia entre usuarios agrupados e independientes, sus visibilidades y contabilizaciones a la hora de calcular el total de tickets (soft limit y hard limit):

• Usuario independiente: sólo podrán ver sus propios tickets, el concepto de grupo y perfil no tiene relevancia para este tipo de usuarios. Los usuarios independientes no pueden modificar algunas de las propiedades del ticket por defecto, tales como usuario asignado u objeto por defecto, ya que van asociados al grupo.

• Usuario agrupado: nivel de visibilidad y permisos sobre el ticket dependiente de su configuración de grupos-perfiles.

Al crear un ticket por defecto su estado será “Nuevo”.

Existen dos valores definidos en los grupos, como se vio en la sección correspondiente, que permiten definir el límite de tickets por grupo, tanto a nivel informativo (soft limit) como restrictivo (hard limit):

Si se sobrepasan el soft limit, aparecerá una ventana de advertencia, pero podremos continuar abriendo tickets (salvo que se encuentre marcada la opción “Forzar soft limit”). Si se sobrepasa el hard limit no será posible abrir nuevos tickets asociados al grupo en cuestión:

El límite de tickets se calcula contando el número de tickets del último año a partir de la fecha actual. 
El soft limit cuenta los tickets en estado abierto creados en el último año. 
El hard limit cuenta los tickets en cualquier estado creados en el último año. 

Bien, el ticket ha sido creado por un usuario (llamémosle A) y asignado a otro usuario (llamémosle B). ¿Ahora qué?

Al crear el ticket, el sistema habrá enviado un email al usuario A y otro al usuario B, informando sobre la creación del ticket. Al usuario A, este mensaje le sirve como confirmación de que el ticket ha sido correctamente registrado en el sistema.

El usuario B también recibirá un correo, al que puede contestar para añadir la primera UT (Unidad de Trabajo). También puede conectarse al sistema a través de la URL proporcionada en el mail para poder agregar manualmente la UT a el ticket.

En el momento que el ticket en estado “Nuevo” recibe una UT, automáticamente se cambia su estado a “Asignado”, indicando que ha entrado en un proceso de trabajo.

Una vez abierto el ticket, podremos operar bien con las solapas superiores o las inferiores. Las solapas superiores dan acceso a la edición del ticket, o ver/añadir adjuntos o notas. También podemos volver a la búsqueda.

En la parte inferior, podemos navegar por las solapas que presentan las notas del ticket, los ficheros, las estadísticas de esta ticket, el tracking detallado y los contactos del ticket activo.

En la sección tickets asociados vemos las relaciones entre tickets, es decir tickets relacionados (hijos) con el ticket actual (padre). Hay que tener en cuenta que al cerrar el ticket padre se cerrarán todos los tickets hijos asociados.

En la sección de comentarios o workunits veremos las notas agregadas manualmente por los usuarios, y podremos añadir nuevas unidades de trabajo.

En esta sección de archivos se pueden ver, descargar y adjuntar ficheros al ticket.

En la vista de detalle del ticket o seguimiento se muestran los tiempos totales, los tiempos que ha pasado en cada estado y los tiempos dedicados por cada persona implicada en el ticket, además de un histórico de las intervenciones de usuarios sobre el ticket.

En esta sección podremos ver los objetos de inventario asociados al ticket.

En contactos podemos ver las personas que se encuentran suscritas al ticket por haber participado en algún momento.

Las medallas sirven para controlar la calidad de nuestro servicio. Para ello podremos usar las medallas doradas cuando el nivel de soporte ha sido bueno y medallas negras para indicar que no estamos satisfechos con la resolución de la incidencia.

Para poder usar las medallas tenemos que tener habilitado el modo de edición rápida desde el setup.

Los usuarios con el permiso de Control de calidad (QA) podrán añadir o quitar medallas en los tickets en la sección de Edición rápida:

Así mismo en el listado de tickets se puede ver en la columna de Estado el número de medallas de cada tipo así como filtrar en el listado por los diferentes tipos de medallas.

En el informe mensual, sección Personas, podremos ver el número de medallas que tiene cada usuario de Integria.

Además en las reglas de workflow es posible añadir medallas automáticamente, por ejemplo se puede añadir una medalla negra al ticket que lleva una semana sin actualizarse.

Se puede usar la vista de búsqueda básica para visualizar el listado de tickets, acceder directamente al número de ticket en el menú de la izquierda o modificar opciones de filtrado. Las búsquedas por defecto muestran todos los tickets no cerrados y no solucionados.

Cualquier combinación de opciones de filtrado que utilicemos se puede guardar como búsqueda personalizada para utilizar posteriormente. Las búsquedas personalizadas son diferentes para cada usuario. También serán utilizadas en los informes de tickets.

Haciendo click sobre un ticket accederemos a los detalles y todas las secciones específicas, pudiendo añadir archivos, unidades de trabajo, etc.

Información que muestra cada columna de la lista de tickets:

• ID: código numérico del ticket, se puede utilizar para acceder directamente a el ticket en cuestión.

• SLA: advertencia en caso de incumplimiento.

• Ticket: nombre del ticket, también se muestra el tipo de ticket, y entre corchetes los campos personalizados del tipo de ticket marcados para ser mostrados en la vista principal.

• Grupo: grupo asignado al ticket, también muestra la empresa (si existe esa información) del usuario que creó el ticket.

• Estado / Resolución : el estado (cerrada, asignada, pendiente de cerrar, nuevo, solucionado y sin confirmar) y la resolución (Solucionado, Incompleto, “a mí me funciona”, expirado, etc.) actuales del ticket.

• Prioridad: color en función de la criticidad del ticket. También puede aparecer un icono de diálogo debajo del color. Esto indica que el ticket tiene una última UT por parte del creador original del ticket.

• Actualizado / Iniciado: tiempo desde última actualización y desde creación.

• Creador

• Propietario: usuario asignado a el ticket.

Un ticket puede referirse a un fallo de software, un problema de comunicaciones, un problema de un cliente con un pedido, etc. Debido a los diferentes usos que un ticket puede tener, existen los tipos de ticket, que cuentan con una serie de campos propios que pueden ser personalizados por el usuario, modificados, o añadir nuevos.

Sobre un ticket ya creado podemos cambiar su tipo, opcionalmente, ya que existe una casilla en el setup para definir este comportamiento. Si lo hacemos, perderemos el valor que contenían los campos personalizados del tipo anterior.

Todas las búsquedas personalizadas se podrán reutilizar en la vista general de tickets además de ser los datos base para los informes estándar de tickets.

El dashboard es una vista simple que permite conocer rápidamente el estado de los tickets agrupados de diferentes maneras y tener acceso directo a las búsquedas personalizadas que hemos creado. Es la pantalla por defecto de la sección de tickets.

Esta sección nos permite construir un informe al que se le aplica una búsqueda personalizada creada previamente.

En el caso de no existir ninguna búsqueda personalizada, se mostrará una ventana que nos dirigirá a la vista de creación de búsquedas.

El contenido del informe está divido en dos secciones:

• Mostrar estadísticas.
• Mostrar lista de tickets.

Si no se selecciona ninguna de las opciones, se mostrará una versión reducida de las estadísticas que contendrá las siguientes gráficas y tablas:

• Tickets por grupo
• Top creadores de tickets
• Top usuarios asignados
• Estadísticas de tickets
• Top 5 grupos por tiempo
• Cumplimiento de SLA

Si se selecciona la opción Mostrar estadísticas se obtendrá, además de las gráficas y tablas descritas en la vista anterior, otras adicionales:

• Tickets por estado
• Tickets por prioridad
• Top usuarios activos
• Top 5 tickets más activos
• Tickets abiertos/cerrados
• Histograma tickets abiertos/cerrados
• Actividad tickets

Al seleccionar la opción Mostrar listado, obtendremos el listado de tickets completo:

Este informe podrá exportarse a PDF pinchando sobre el icono

El SLA es la forma de “comprobar” que la gestión de tickets funciona bajo unos criterios. Integria cuenta con funcionalidades de gestión automática de SLA.

El SLA se procesa conforme unos parámetros:

• Nombre: del conjunto de reglas que definen un tipo de SLA en particular.
• Enforced: hace que el SLA dispare los emails cuando se incumpla (enforced) o que solo avise con un indicador luminoso.
• SLA Base: indica relación con otro SLA a nivel informativo.
• Tipo SLA
  • SLA Normal: se tendrán en cuenta, a la hora de hacer el cálculo, los tickets que no se encuentren en estado Cerrado o Pendiente de terceros.
  • SLA de terceros: se tendrán en cuenta los tickets que estén en estado Pendiente de terceros.
  • Ambos: se tendrán en cuenta los tickets que estén en cualquier estado que no sea Cerrado.
• Max. Tiempo de respuesta: en horas, tiempo máximo que puede transcurrir entre una workunit del creador del ticket y otra respuesta. Por ejemplo, si este tiempo son 4 horas, y un ticket nuevo tiene 4.1 horas de vida, se disparará el SLA. Si un ticket ya tiene varios días de vida y la última unidad de trabajo o workunit es del creador del ticket, tras 4 horas sin respuesta también se disparará el SLA.
• Max. Tiempo de resolución: en horas, el máximo tiempo de vida de un ticket. Si un ticket tiene más de ese tiempo y no está cerrado o resulto, saltará el SLA.
• Nº Máx de tickets abiertos al mismo tiempo: si se supera, saltará el SLA.
• Max. tiempo inactividad
• Hora de comienzo para activar el SLA: hora del día a partir de la cual el SLA se empieza a calcular (p.e: 9 de la mañana).
• Hora de fin para una SLA: hora del día a partir de la cual el SLA ya no se calcula (p.e: 18h).
• Deshabilitar SLA en fines de semana: los fines de semana no se incluirían en los cálculos de SLA.
• Deshabilitar SLA en vacaciones: los días definidos de vacaciones no se incluirán en los cálculos de SLA.
• Descripción: informativo.

Significa que el sistema enviará una notificación por email al propietario del ticket, advirtiendo que el ticket no cumple los baremos establecidos en el conjunto de reglas de SLA asociada al ticket. Esto dependerá del grupo al que está asociado el ticket, ya que es en la configuración de grupo donde especificamos qué SLA se aplicará a los tickets de grupo:

Podemos ver la evolución histórica del cumplimiento de SLA de un ticket, o los valores de cumplimiento en total en los informes generales. Un SLA bajo, generalmente significa que el ticket no se ha gestionado bien. Es un indicador muy usado para ofrecer un resumen de la calidad del servicio y gestión de los tickets.

Cuando el SLA de un ticket se incumple, un indicador luminoso aparece en la vista de tickets.

Ejemplo de definición de SLA:

Los SLA están vinculados al estado de los tickets. De forma que si el tipo de SLA elegido es Normal no se aplicará el SLA para los tickets que están en estados Cerrado y Pendiente de terceras personas. Si el tipo elegido es SLA de terceros sólo se aplicará el SLA para los tickets que estén en estado Pendiente de terceras personas. Si se eligen Ambas se aplicará el SLA para todos los tickets excepto los que estén en estado Cerrado.

Utilizando el sistema de SLA, en el informe de “seguimiento” de un ticket puede verse en una escala de tiempo, cuando el ticket no ha cumplido (en rojo) y cuando ha cumplido (en verde). Además de un indicador del % de cumplimiento del ticket en toda la vida de éste.

Esta característica Enterprise permite definir reglas personalizadas que serán aplicadas en la gestión de tickets de forma automática. Ejemplo práctico: un ticket del grupo Soporte lleva 48 horas sin respuesta, se envía un email al usuario responsable informando de esta situación, ya que cumple una condición asociada a una regla workflow, ejecutando por tanto las acciones definidas, en este caso, envío de un mail.

Estas reglas sólo pueden ser definidas y gestionadas por usuarios tipo “súper administrador”, no siendo accesibles en ningún caso para usuarios agrupados que dependan de configuraciones de perfil-grupo. Por defecto las reglas serán aplicadas una única vez, a excepción de las reglas que tienen como condición la fecha de actualización del ticket. En este caso, la regla se lanzará siempre que corresponda.

En la captura mostramos una regla Añadir WU y enviar email a responsable cuando el ticket lleve 48hrs sin respuesta.

Cada regla tiene condiciones asociadas que se deberán cumplir para ejecutar las acciones. Si una regla tiene más de una condición, habrán de darse todas las condiciones para que se dispare la acción. Para poder modificar la regla o acceder a sus condiciones y acciones, hay que hacer click sobre la descripción. En la edición podremos elegir el modo de ejecución:

• Cron: chequeará cada cierto tiempo (por defecto 5 minutos) si se cumplen las condiciones del workflow.
• Realtime: chequeará inmediatamente si se cumplen las condiciones del workflow.

En Condiciones accedemos al listado donde definiremos en que casos aplicaremos la regla, definiendo una serie de condiciones. En nuestro ejemplo tenemos una condición ya definida. Podemos tener una o varias condiciones por regla workflow. En el caso de que tengamos varias condiciones, con que se cumpla una, la regla se activará y ejecutará la acción o acciones programadas. Las condiciones están compuestas por un conjunto de filtros o subcondiciones, los cuales se describen a continuación:

• Condición: modo de trabajo de las condiciones, pudiendo cumplirse todas, alguna o ninguna.
• Propietario: si un ticket tiene un propietario en particular.
• Prioridad: dependiendo del nivel de prioridad del ticket.
• Fecha de actualización: tiempo desde que el ticket fue actualizado por última vez.
• Texto a buscar en el título o descripción del incidente
• Tarea: si el ticket tiene asociada alguna tarea (definida en la configuración de proyectos).
• Tipo de ticket: seleccionando el tipo de ticket, los campos personalizados aparecerán y podemos hacer uso de ellos para añadirlos al conjunto de filtros de esta Condición.
• Grupo
• Estado
• Fecha de creación: tiempo transcurrido desde la creación.
• SLA: si el SLA fue disparado o no.
• Resolución
• Cumplimiento SLA (%): porcentaje de cumplimiento del SLA del ticket.

En el siguiente ejemplo definiríamos una regla que se cumpliese en caso de: existir un ticket de máxima prioridad asociado al usuario genérico “soporte” y que llevase al menos 1h sin ser actualizado.

En esta otro ejemplo el grupo debe ser Soporte, la prioridad debe ser Media y el estado Asignado. El campo condición elegido es Coincidir todos los campos porque queremos que se cumplan todas las subcondiciones especificadas.

A continuación, vemos las posibles acciones que puede ejecutarse si se cumplen las condiciones anteriores.

Las acciones están formadas por los siguientes campos:

• Descripción
• Tipo de acción: las posibles acciones a ejecutar.
• Variable: diferentes campos adicionales aparecerán dependiendo de la acción escogida. Por ejemplo un campo de tipo texto para la acciín de añadir unidad de trabajo.

Las acciones se definen según el campo Tipo de acción:

• Cambiar prioridad
• Cambiar propietario
• Cambiar grupo
• Cambiar estado
• Enviar correo electrónico: aparecerán los campos “Para”, “Asunto” y “Texto”.
• Añadir WU: el texto establecido se añadirá a la incidencia con el usuario especificado.
• Cambiar fecha de actualización: modificará la fecha de actualización del ticket al momento actual.
• Cambiar resolución: actualiza el valor de la resolución de cierre del ticket.
• Ejecutar comando: permite ejecutar un comando personalizado en es servidor, incluyendo macros para sustitución dinámica de variables, tales como ID del ticket, grupo, usuario, etc. O ejecutar scripts personalizados.
• Bloquear ticket: no se podrán modificar los valores de los campos del ticket.
• Desbloquear ticket: podrán volverse a modificar los valores de los campos del ticket.

Al añadir la primera acción, se añade una acción adicional por defecto que es la modificación de la fecha de última actualización del ticket. Es posible eliminarla manualmente.

Ejemplos de uso:

• “Para cualquier incidencia del grupo Clientes, que lleve más de 10 horas sin actualizar, se envía un email al propietario del ticket con el texto “No se está contestando la incidencia (titulo) del grupo Clientes. Revisad el tema urgentemente”.

• “Para cualquier incidencia, que lleve más de 21 días abierta, con prioridad “Alta” se le cambia la prioridad a “Media” y se le añade la WU que diga “Repriorizada automáticamente por el sistema”.

En general las reglas de workflow se dispararán una sola vez, de forma que si establece una regla para cambiar por ejemplo, el usuario asignado a la incidencia cuando una incidencia tenga más de 30 días de vida, y el usuario asignado es X, pero luego manualmente alguien vuelve a poner ese usuario X, la regla no se volverá a disparar.

La única excepción de este comportamiento es cuando la condición es el tiempo de actualización. Si establece una regla para que salte cuando el ticket lleva más de X tiempo sin actualizar, se creará automáticamente una acción por defecto para “actualizar el ticket”. Esto hará que no salte continuamente la condición. Pasado ese X tiempo, el sistema podrá ejecutar de nuevo la misma regla de Workflow. Esta es la excepción, ya que para ninguna otra condición (Prioridad, Propietario, Estado, Creación ó Grupo), se podrá volver a ejecutar una regla.

Caso típico de uso para este tipo de condición:

• “Necesita enviar un email de aviso a un coordinador, cuando una incidencia de prioridad muy alta y de un grupo determinado lleva más de 5 días sin actualizaciones.“

Simplemente tiene que rellenar en la condición “Coincidir todos los campos”, el grupo específico y la prioridad muy alta, solo para incidencias asignadas. En “Fecha de actualización” escogeremos una semana.

Al añadir la acción de enviar un mail, se creará automáticamente la acción de actualizar el ticket, que dejaremos tal cual, para actualizar el ticket y evitar que siga saltando la regla.

El asunto y el cuerpo del email pueden contener las siguientes macros:

• _incident_id_: ID del ticket.
• _incident_title_: título del ticket.
• _creation_timestamp_: fecha y hora de la creación del ticket.
• _id_group_: ID del Grupo asignado al ticket.
• _name_group_: nombre al Grupo asignado al ticket.
• _update_timestamp_: última vez que se actualizó el ticket.
• _author_: creador del ticket.
• _owner_: propietario del ticket.
• _id_priority_: ID de la prioridad del ticket.
• _name_priority_: nombre de la prioridad del ticket.
• _access_url_: URL directa al ticket.
• _sitename_: nombre del sitio, tal y como se haya definido en el setup.
• _fullname_: nombre completo del usuario que recibe el correo.
• _username_: nombre identificador del usuario que recibe el correo (login name).
• _id_status_: ID del Estado del incidente.
• _name_status_: nombre del Estado del incidente.
• _id_resolution_: ID de la resolución del incidente.
• _name_resolution_: nombre de la resolución del incidente.
• _incident_epilog_: epílogo del ticket.
• _incident_closed_by_: usuario que cierra el ticket.
• _incident_own_email_: email del usuario propietario.
• _incident_group_email_: email del grupo asignado.
• _incident_auth_email_: email del usuario creador del ticket.
• _name_group_: nombre del grupo asignado al incidente.
• Plantillas de campos personalizados: permite usar los campos personalizados de los tipos de tickets. El nombre de los campos personalizados que agregaste también puedes incluirlos como una macro la cual mostrará el valor de dicho campo, el formato sería: _nombre del campo personalizado_.

Ejemplo de la ejecución de un comando personalizado:

A través del API REST de Integria IMS es posible crear nuevos tickets, valiéndonos de esta funcionalidad podemos desarrollar formularios personalizados que nos permitan dar de alta nuevos tickets en el sistema.

El siguiente código PHP crea un formulario y recoge los datos enviados por el formulario. Con ellos compone una llamada al API de Integria IMS que crea un nuevo ticket.

custom_form.zip

Para probarlo basta con copiar este contenido en un fichero de texto, editarlo para los parámetros de nuestra instalación y ubicarlo en la ruta de la consola de integria (por defecto /var/www/html/integria), y realizar la llamada a través del navegador: http://localhost/integria/formulario.php

El formulario resultante tiene el siguiente aspecto:

A continuación comentaremos parte del código. Es importante modificar estas líneas para adaptarlas a nuestra instalación:

$integria_url = "http://inna.lab.artica.lan/integria";
// user and password for which creates the incident
$user  = "admin";
$integria_pass = "integria";
// integria api pass
$integria_api_pass = "1234";

La siguientes variables configuran opciones generales de los tickets, en este caso el título del ticket, el grupo, la prioridad, descripción o cuerpo,etc.

	// Extra - status - new
$ticket_status = 1;	

// Set default parameters
$priority  = 0;
$inventory = "";
$type      = "";
$mail      = "";
$owner     = "";
$parent    = "";

$title = $_POST["title"];
$group = $_POST["group"];
$description = $_POST["description"];

//Get post parameters
if (isset($_POST["priority"])) {
	$priority = $_POST["priority"];
}
if (isset($_POST["inventory"])) {
	$inventory = $_POST["inventory"];
}
if (isset($_POST["type"])) {
	$type = $_POST["type"];
}
if (isset($_POST["mail"])) {
	$mail = $_POST["mail"];
}
if (isset($_POST["owner"])) {
	$owner = $_POST["owner"];
}
if (isset($_POST["parent"])) {
	$parent = $_POST["parent"];
}

Para localizar los IDs de los elementos que necesitamos, por ejemplo el ID del grupo (que es un campo obligatorio), podemos acceder al correspondiente grupo dentro de Integria y veremos el ID en la barra de direcciones del navegador.

A continuación se crea una cadena de texto con la url que usaremos para crear los tickets mediante el API de Integria IMS. Además de la dirección del servidor y el usuario, se configuran los parámetros op con el valor create_incident que indica la función del API que se va a utilizar y params con los parámetros de la función.

$myurl  = $integria_url."/include/api.php?user=".urlencode($user)."&user_pass=".urlencode($integria_pass)."&pass=".urlencode($integria_api_pass);
$myurl .= "&op=create_incident&params=".urlencode($title).",".urlencode($group).",".urlencode($priority).",".urlencode($description).",";
$myurl .= urlencode($inventory).",".urlencode($type).",".urlencode($mail).",".urlencode($owner).",".urlencode($parent).",".urlencode($ticket_status).",,,,";

Es importante tener en cuenta que esta URL está construida para una API con autorización por IP, si estamos utilizando en nuestra API autorización por contraseña, deberemos construir la URL correspondiente, utilizando $myurl = $integria_url.”/include/api.php?user=“.urlencode($user).”&pass=passAPI“.”&op=create_incident.

Por último el código realiza una llamada al API de Integria IMS por medio de la utilidad CURL de PHP.

// Configure curl
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $myurl);
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE);

// Send curl request and close
$ret = curl_exec($ch);
curl_close ($ch);
$_POST = array(); 

En caso de que se deje en blanco los campos obligatorios (Título, Descripción. ID Grupo y Prioridad) no permitirá la creación del ticket.

Integria permite la creación y actualización de tickets mediante el envío de mails. Esta es una característica Enterprise.

Dependiendo del cliente de correo electrónico usado el formato de los emails podría 
ser diferente. La gestión de emails de Integria ha sido validada con los siguientes 
gestores de correo: Evolution, Gmail, Outlook y Mail.

La creación de tickets y workunits por email usa los mismos principios de ACLs que 
el interfaz gráfico. Puedes ver estos principios en la sección Perfiles y usuarios. 

La gestión de tickets por email está basada en la funcionalidad de las colas de correo, configuradas para cada uno de los grupos existentes en Integria IMS. Además deberá configurar los parámetros de correo como se indica en la sección Configuración de email.

Supongamos que tenemos habilitada la siguiente dirección de correo para recibir los email: [email protected] y configurado el parámetro Cola de emails de un grupo con la siguiente información:

[email protected]

Enviaremos un email con los siguientes datos:

• From: <dirección de correo usuario Integria> (Opcional: si el usuario no existe se creará automáticamente)
• To: <mailbox configurado para POP en Integria>, <direcciones de colas de correo>, …
• CC: <otras direcciones en copia>
• Subject: <titulo del ticket>
• Body: <descripción del ticket>
• Adjuntos: <archivos adjuntos al email>

Ejemplo práctico:

• From: [email protected]
• To: [email protected], [email protected]
• CC: [email protected], [email protected]
• Subject: Another problem with the servers
• Body: We are having a big problem with our servers!
• Attachment: screen1.png, screen2.png

1. Una vez el email está en el inbox de la dirección [email protected] se comprobará si corresponde con alguna cola de correo configurada.
   1. Si no encuentra ninguna cola de correo el email se desecha.
   2. Si encuentra una cola de correo entonces se usarán los parámetros por defecto configurados en esa cola de correo para gestionar el ticket.
2. Ahora la aplicación procesa el email, en este punto pueden suceder dos cosas:
   1. El email no se corresponde con ningún ticket actual. En este caso se creará un nuevo ticket.
   2. El email se corresponde con un ticket creado en el sistema. En este caso se creará una nueva workunit y se actualizarán los datos del ticket.
3. Para crear un ticket se configurarán los siguientes parámetros:
   • Creador: será el usuario asociado con la dirección from. Si el usuario no exite se creará siguiendo los parámetros de configuración de la creación de usuarios para la cola de correo detectada.
   • Editor: se usará el mismo usuario asociado con la dirección from del correo.
   • Grupo: grupo correspondiente con la cola de correo.
   • Dueño: el usuario por defecto del grupo asociado a esta cola de correo.
   • Título: asunto del correo electrónico.
   • Descripción: cuerpo del correo electrónico.
   • Notificaciones por email: en este campo del ticket se añaden todas las direcciones de correo de los campos TO y CC que no se correspondan con la dirección encontrada para la cola de correo. En este ejemplo se añadirán las siguientes direcciones: [email protected], [email protected], [email protected]
   • Archivos de ticket: se añadirán los adjuntos del correo electrónico.
4. Si el ticket existe en el sistema se añadirá el contenido del cuerpo del correo electrónico como una workunit y además se realizarán las modificaciones necesarias en el estado del ticket.

La siguiente imagen explica el flujo de gestión de colas de emails de una forma resumida:

Si tiene activado el sistema de envío de emails para seguir las novedades en los tickets de Integria, recibirá emails con las novedades de sus tickets.

En algunos de ellos verá que en el título tiene asignado un ticket ID, respondiendo a estos emails podrá añadir nuevas workunits al ticket correspondiente.

Para añadir una nueva workunit sólo tiene que contestar el email añadiendo en el cuerpo el contenido de la workunit. Como resultado aparecerá una nueva workunit en el ticket. Si por ejemplo responde al email con el siguiente cuerpo “Thanks. Please close the incident all its ok. Javi” aparecerá el siguiente workunit.

Al igual que la creación de tickets por email, la creación de workunits añade los archivos adjuntos en los emails a el ticket correspondiente.

Integria permite modificar los tickets por email. Para ello es necesario añadir la siguiente estructura en el cuerpo del email.

[INCIDENT]
GROUP: IT
ASSIGNED_TO: dario
PRIORITY: 3
STATUS: Assigned
RESOLUTION: Invalid
[INCIDENT]

Los campos y sus posibles valores son los siguientes:

• GROUP: nombre del grupo al que se quiere cambiar el ticket.
• ASSIGNED_TO: nombre corto del usuario al que pertenece el ticket. Es el nombre con el que el usuario entra en Integria.
• PRIORITY: prioridad a la que se cambiará el ticket. La prioridad es un número entre 0 (más baja) y 5 (más alta).
• STATUS: nombre del estado al que se cambiará el ticket. El nombre de los estados se define en el tab de Tickets de la Configuración general.
• RESOLUTION: nombre de la resolución al que se cambiará el ticket. El nombre de los estados se define en el tab de Tickets de la Configuración general.

También es posible modificar algunos parámetros en la creación de la workunit usando la siguiente estructura en el cuerpo del email:

[WORKUNIT]
TIME_USED: 0.05
[WORKUNIT]

Los campos y sus posibles valores son los siguientes:

• TIME_USED: tiempo dedicado a la workunit. Es un número decimal separado por puntos. Por defecto el valor de este parámetro es 0.25 horas.

Las estructuras anteriormente descritas para modificar el ticket o personalizar 
la workunit **no quedarán reflejadas dentro de la información del ticket en la 
aplicación**.

Es muy importante verificar la correcta sintaxis de las estructuras anteriores, 
ya que un error en las cabeceras o en los parámetros resultarán en una detección 
incorrecta de las directivas y por ello no se aplicarán los cambios. En este caso 
se tratarán como otro texto cualquiera y aparecerán en la información de las 
workunits dentro de la aplicación.

Es posible que al crear una workunit mediante el correo electrónico aparezca en el cuerpo del mensaje alguna dirección de email fruto de usar la funcion responder a todos o por cualquier otra razón.

Si en su organización considera que esta información es sensible y no debería aparecer en los workunits. Integria le permite enmascarar las direcciones de correo, de forma que usted sabrá que ahí había una dirección de correo electrónico, pero no podrá adivinar cuál.

Puede configurar esta opción en el tab de Tickets de la Configuración General de la aplicación marcando el flag Masking email addresses.

Cuando este flag está activado Integria cambiará todas las direcciones de correo electrónico por la siguiente dirección comodín [email protected]