En breve hará dos años ya de mi aterrizaje en el Service Desk de UNICC. Me ha parcido un buen momento para una introspección y ver los cambios que ha habido y que impacto han tenido.

Las métricas

De esto ya hablé en otro post, no había casi métricas y las que había no eran conocidas por todos, y los que las conocían no las compartían.

Eso cambio, para bien y para mal. Hay mucha teoría sobre como los humanos nos centramos en alcanzar (haciendo trampa en ocasiones) los objetivos que se nos definen. Y eso ha pasado.

Las métricas no pueden ser estáticas, ni desatendidas, porque podrían llevar a que las trampas se extiendan. Hay que cambiarlas y adaptarlas a las necesidades y madurez del equipo.

El autoservicio

Esto fue mi obsesión desde casi el principio y casi dos años ha costado ponerlo en marcha, el portal de autoservicio. El motivo es fácil, si los clientes del service desk rellenan sus peticiones, los técnicos de service desk pueden emplear ese tiempo (key-in) en otras cosas…

Era algo que vi en mi proyecto anterior y que me gustó muchísimo. En EUIPO el portal de autoservicio del service desk era muy extenso y tenía muy buena acogida.

El problema es educar a los usuarios en el uso del portal de autoservicio. Aquí admito el fracaso (en tres meses no se usa todo lo que me gustaría). Hay que insistir. En EUIPO se tomaron medidas más extremas, se anularon canales de contacto para forzar a la gente a usar el portal de autoservicio.

Mejorar el conocimiento

Una de las sombras quizás de estos dos años ha sido la merma en el número de personas que componen el equipo, esto obliga a formar a más técnicos en hacer más cosas.

Conseguir que algunas labores más complejas se hagan en formato 24×7 ha sido un logro.

Fallos: Katas, hacer al equipo consciente de la mejora

Un experimento fallido todavía, hacer katas con gente en rotación es más complejo. El seguimiento de las acciones se hace difícil y para los equipos proponer acciones también lo es.

Aún así ha habido alguna mejora positiva, obtener feedback de primera del resto de equipos, por ejemplo, entender que esperan los clientes internos de nosotros.

Y lo que llegará

Después de dos meses leyendo, formándome y haciendo pinitos con RPA (Robotic Process Automation) veo gran potencial para la introducción de RPA en los ámbitos de Service Desk y Monitoring.

En las últimas semanas he desarrollado ya una prueba de concepto sencilla para revisar casos que deberían cerrarse y que actualiza la resolución de los mismos.

RPA tiene potencial para hacer el Key-In, e incluso la autoremediación de ciertos casos ahorrando tiempo de equipos de nivel 2.