Gestión de incidencias, el valor de la experiencia compartida

 

El principal objetivo de la gestión de incidencias es restaurar cuanto antes la operativa normal del servicio minimizando el impacto negativo en las operaciones de negocio.

 

Por este motivo, se deben utilizar herramientas de gestión que permitan la asignación de recursos y la estimación de tiempos, utilizar alertas y escalados para facilitar la respuesta/resolución de las incidencias dentro de un tiempo máximo definido.

 

Adicionalmente, la correcta gestión de las incidencias exige que estas sean registradas de forma independiente, así como contar con información descriptiva de la incidencia con el objetivo de facilitar la resolución en primera instancia. Esta información descriptiva no solo ha de aportar valor en la resolución de la incidencia, sino que también debería permitir la retroalimentación del conocimiento para facilitar la resolución de posteriores incidencias similares.

 

Hace unas semanas, tuve la oportunidad de asistir a uno de los congresos celebrados por ITSMF (Vision 2017) y ahí, en una de las charlas, nos ofrecían un ejemplo muy gráfico de la gestión una incidencia que no me resisto a contar.

 

Juan (nombre supuesto), entra a trabajar en la resolución de incidencias de una entidad financiera tal día como hoy. Por supuesto, faltaría más, Juan en su primer día de trabajo recibe un manual con los protocolos de actuación para los diferentes tipos de incidencias. Dos semanas después de entrar a trabajar, entra en la rotación de las guardias y le toca el turno de noche, pero recién entra en su turno, recibe una alerta: se ha producido un fallo en los cajeros de la red y tres cajeros han quedado fuera de servicio.

 

Preocupado, Juan acude a su manual y encuentra  la información correspondiente al protocolo de actuación: primero hay que evaluar el porcentaje de cajeros que han quedado fuera de servicio, siguiente paso, si este porcentaje supera el 3 %…

 

Juan evalúa que se han caído tres cajeros, así que no supera el umbral, por tanto el protocolo indica que se han de reiniciar. Así que Juan procede a lanzar el proceso de reinicio. Pero 30 minutos después llega una alerta de que se han caído, 25 cajeros y el número va in crescendo. Puesto que Juan, ya conoce el protocolo, la caída de este número de cajeros supone que la incidencia ha de ser escalada, entonces sabe que debe escalarlo e informar a la persona correspondiente.

 

Levanta el teléfono y procede a detallar qué ha sucedido, los protocolos que se han seguido, el resultado de los mismos y la situación actual, pero mientras tanto, el número de cajeros que se encuentran fuera de servicio continúa  creciendo.

 

Al teléfono, entre los dos intentan solucionar la incidencia que se desarrolla en esta secuencia, siendo A: Juan, B: la siguiente persona encargada y C: otro sujeto más en el protocolo.

 

  • A: Reinicia los cajeros.
  • B: Comprueba que en el sistema X, todo está funcionando
  • A: No tengo acceso
  • B: Entra en el servidor Z y desde allí realiza la comprobación
  • A: No tengo acceso
  • B: Utiliza mis credenciales
  • A: Tampoco puedo comprobar el estado del sistema X
  • B: Espera, que llamo a C …(un escalón más)
  • B: Si, buenas noches (le explica la situación)
  • C: Dile que entre desde la máquina que se encuentra en … al sistema … que utilice mis credenciales y reinicie …
  • B: Juan, que dice que uses sus credenciales y procedas a reiniciar entrando en….
  • A: No funciona
  • B: Un momento, montamos una call

 

Afortunadamente, el gabinete de crisis es capaz de restablecer todos los sistemas, la red está operativa a las 7 de la mañana tras 6 horas de intenso trabajo y lo único que resta es que Juan escriba el informe de lo sucedido y lo guarde junto con el cierre de la incidencia. De esta recreación aparecen por encima, dos conclusiones importantes:

 

  1. En el sistema de gestión nunca se registró lo que había sucedido.
  2. Más allá de lo que Juan recordase que había sucedido durante las 6 horas, el conocimiento de lo sucedido y el protocolo de cómo actuar, se queda en las personas que han estado involucradas en la resolución.

 

En esta experiencia, por supuesto inventada y exagerada, tuvimos la oportunidad de ver cómo se producía en realidad en un proyecto que abordamos hace unos meses.

Nuestro principal objetivo consistía en emplear los logs de la herramienta de gestión, y a través de técnicas de minería de procesos, descubrir el mapa real de cómo en la realidad se reporta a la herramienta de gestión lo que está sucediendo.

Más allá de conclusiones sobre cómo se utiliza el sistema, llegamos a observar que existían patrones en los que un mismo tipo de incidencia se asignaba a un mismo equipo para su resolución, y este equipo lo rechazaba en cada una de las ocasiones. Por tanto, decidimos buscar si esto es era un comportamiento más extendido, llegando a la conclusión de que efectivamente es un patrón que se produce a menudo.

Aventuramos todo tipo de hipótesis que pudieran estar generando este comportamiento y al final nos quedamos con aquellas que parecían más sólidas y que resumo a continuación:

 

  • En los equipos que realizan la atención de primer nivel, existe una alta rotación, por lo que la experiencia se pierde.
  • No existe retroalimentación, es decir, no existe un rechazo de la incidencia, sino una redirección y por tanto la persona que la asignó en primera instancia no puede adquirir dicho conocimiento.
  • Tampoco existe conocimiento adquirido por el sistema, es decir, en el sistema queda registrado el equipo que ha cerrado la incidencia. En contadas ocasiones se encuentra la descripción del motivo de la incidencia y el proceso de resolución.

 

Como muy bien nos mostraron en la conferencia de ITSMF, es importante tener la capacidad de almacenar y evidentemente poder consultar el histórico de lo que ha sucedido para poder aprender y establecer protocolos de previsión y resolución de incidencias.

 

Sin embargo, el planteamiento es: ¿Podemos ir más allá y permitir que la máquina utilice la información que existe en el sistema?  Para ello realizamos una prueba de concepto básica, en la que nos marcamos como objetivo ayudar a la atención de primer nivel en dos ámbitos:

 

  1. Poner a disposición de la atención de primer nivel información sobre cómo se habían resuelto anteriormente incidencias con parámetros de entrada similares. Esto lo haríamos proponiendo la ruta óptima para la resolución.
  2. Contribuir de este modo en la formación de los equipos de primer nivel.

 

Así pues, tomamos una muestra de información de 100.000 registros donde utilizamos 70.000 para entrenamiento y 30.000 para testear los resultados.A partir de este punto, se analizaron aquellos parámetros de entrada cuya influencia es mayor en la resolución de la incidencia y lanzamos el proceso de aprendizaje utilizando como algoritmos Decision Tree y Random Forest.

 

Como resultado de la prueba de concepto, obtenemos que cumplida la premisa de que la información se está almacenando, las máquinas contribuyen en un 15% adicional en la mejora de este proceso. Las lecciones que aprendimos con esta aproximación son que en este ámbito cambiante, las máquinas y el aprendizaje automático dan un soporte fundamental en la gestión de tareas y en la toma de decisiones.

 

Tampoco podemos, ni debemos prescindir del componente humano, ya que la tarea de la desambiguación sigue siendo una tarea humana, finalmente vemos que el propio sistema puede ser utilizado como una base de conocimiento y llegado el momento, como motor de formación de personas.

Investigar, comprender y crear nuevas perspectivas es el motor inagotable que me mueve personal y profesionalmente. Product Manager en el área de Analytics, en la que nos encargamos de dar nuevas formas y analíticas a los procesos, a los datos y la información no estructurada.