El año nuevo se nos ha atragantado un poco y se ha quedado descolgado la tercera parte de la trilogía. Esta entrada va a ser densa. Sin ánimo de asustar, tenemos cambios significativos en la gestión de tickets en la nueva GLPi 9.2. No tanto porque sea necesario que cambiar la forma de trabajar, sino por las nuevas posibilidades que se abren ante nosotros.

Aviso: Peticiones = Tickets. Usaré ambos indistintamente, que no te confundan.

Lo nuevo en Peticiones

Nueva terminología: SLM

El nuevo menú donde se encuentran las antiguas SLA o (ANS en su traducción) es Service Levels.  Para terminar de clarificarlo (o más bien confundirlo) GLPi ha cambiado las denominaciones en las 3 últimas versiones de los procesos ITIL contemplados. Sirva esta tabla para intentar arrojar luz sobre la evolución de la misma:

Evolución de Service Level Management en GLPI
Versión GLPiProceso ITILSubproceso ITILTérminos
0.90SLA--
9.1SLASLTTTO / TTR
9.2SLM (SL)OLA(i)TTO / (i)TTR
SLATTO / TTR

OLA

Ahora que ya has visto la tabla, te habrás fijado en el nuevo concepto: OLA (Operational Level Agreement) o acuerdos de nivel operativo. Se trata de un subproceso de control interno, que simplificando, funcionaría como una SLA entre departamentos de la misma empresa. Este concepto se contrapondría con el SLA (Service Level Agreement) acuerdo de nivel de servicio (ANS) compuesto por los tiempos de de atención y resolucion ofrecidos al cliente final.

GLPI SLA y OLA en las nuevas peticiones del helpdesk

Las dos OLAs se encuentran bien visibles en la parte superior de los tickets, de momento con los nombres en inglés:

  • Internal Time To Own - Tiempo interno de resolución
  • Internal Time To Resolve - Tiempo interno de respuesta

Resumiendo:

En GLPi, SLM (Service Level Management) o gestión de niveles de servicio englobaría las SLA + OLA.

Nuevos enlaces entre tickets: Hijo de o Padre de

Hasta ahora teníamos dos formas de vincular dos tickets:

  • Enlazada con, para peticiones que estaban relacionadas
  • Duplicados, para cuando se abren más de dos tickets de una sola incidencia o petición.

La novedad es que ahora a los duplicados podemos asignarles una jerarquía:

  • Hijo de (Son of)
  • Padre de (Parent of)

La idea subyacente es identificar en cual de las peticiones duplicadas se va a trabajar, para evitar la creación de tareas en varias, por medio de la elección de un ticket principal o padre (parent).

Gestión de peticiones vinculadas o duplicadas en GLPi

Cambios menores en diseño

Nos han cambiado algunos iconos, como las prácticas (i) que abren la útil información de contacto de los actores implicados en cada petición. No te perdarás con esto 🙂

Peticiones recurrentes

Tareas en las plantillas de las peticiones

Hasta ahora podíamos crear plantillas de peticiones y automatizar, por ejemplo, la creación de un ticket para la revisión de los backups cada viernes a las 9:00. Sin duda algo muy cómodo, pero el técnico o gestor de técnicos asignado, aún tenía que añadir manualmente la tarea, el tiempo que le llevaría, y si está realizada o no.

Imagina que ahora a la vez que creas la plantilla, puedes agregar las tareas involucradas en las misma.

Pues no lo imagines. Ya es posible en GLPi 9.2.

 

Seguramente habrá quedado algo atrás, pero si sigo dilatando estas publicaciones, acabaré uniéndolas con la prometedora GLPi 9.3.

¿Has descubierto una nueva funcionalidad que  no aparece aquí? Déja un comentario y la documentaremos.

Puesta en marcha, actualización o soporte de tu instalación GLPi.

Si no has leído las entradas anteriores:

  1. ¿Que hay de nuevo en GLPi 9.2? (I) UX
  2. ¿Que hay de nuevo en GLPi 9.2? (II) Nuevos activos de inventario y más

 

 

 

Pin It on Pinterest

Share This