Gestión de incidencias RPA: ¿Por qué los fallos de usuario no son incidencias de robots?
Dentro de la operación RPA muchas de las incidencias que se producen con impacto en negocio, no deberían considerarse incidencias de robots, al tratarse de fallos de usuarios. En la mayoría de las ocasiones estas incidencias son las que más tiempo conllevan hasta su resolución y las que más penalizan a los departamentos de Mantenimiento de robots.
De sobra es sabido que los robots desarrollados con tecnología RPA son muy sensibles a incidencias o cambios que se puedan producir en la infraestructura que los soporta, en los aplicativos que navegan o en las lógicas de negocio que ejecutan. Pero no debemos olvidar que algunos de los fallos más frecuentes son los fallos humanos en el proceso automatizado como los que se detallan a continuación y que no podemos nunca sacar de la ecuación.
A pesar de que uno de los principales objetivos de RPA es reducir los errores humanos en las operativas, debemos considerar que el fallo humano es intrínseco a la propia definición del robot en muchas ocasiones. Por ello, se recomienda evitar este eslabón humano en la cadena de acciones que ejecute el robot siempre que se pueda.
Con los siguientes ejemplos podemos hacernos una idea del tipo de incidencias a las que nos referimos:
- El robot falla porque el usuario no ha colocado correctamente o enviado el fichero de entrada del robot.
- El usuario ha cambiado los formatos o literales del fichero de entrada del robot o son incorrectos conforme a la definición validada del robot.
- Validaciones de información necesarias e incorrectas por parte del usuario, previo al lanzamiento del robot.
- El usuario ha cambiado la contraseña de alguna credencial compartida con el robot, cambios en la contraseña de algún FTP o unidad al que acceden ambos.
Y en general cualquier otro descuido que pueda venir dado por el hecho de participar en el proceso como humanos.
Normalmente los equipos de Reporting consideran todos estos casos como incidencias de robots en los informes de Operación, debido a que todos ellos se registran en los sistemas de gestión de tickets para poder tener trazabilidad y darles solución, en muchas ocasiones penalizando al proveedor de servicios de la operación por estos fallos cuando son ajenos al robot.
¿Pero qué hacemos mal? Dichas incidencias son resueltas, ¿verdad?
Cada ticket de un usuario de robot se tipifica como consulta, petición o incidencia. La naturaleza del ticket determina el tipo de interacción que requiere para su resolución.
Los equipos de Mantenimiento y Operación por defecto, asumen que el usuario tiene derecho a recibir asistencia porque su robot está fallando. Entienden que la funcionalidad del robot de la que ellos son garantes está viéndose afectada y buscan la rápida actuación para restablecer el servicio con sus protocolos de actuación, restaurando el funcionamiento en el menor tiempo posible ya sea con la solución definitiva o utilizando algún “workaround” (solución de contingencia/parche).
Se invierte mucho tiempo en diagnosticar la causa raíz de las incidencias derivadas de fallos humanos, encontrando múltiples dificultades por no disponer de entrada de casos de prueba que les permitan trazar los errores, y poder descartar que no se trata de un fallo del propio robot.
Una vez descartado que el fallo es del robot, la degradación o indisponibilidad del mismo perdurará hasta que el usuario sea informado del fallo que se produjo, corrija el problema, comunique su corrección y el equipo de Mantenimiento pueda de nuevo verificar que el robot funciona correctamente dando por resuelta la incidencia.
¿Qué otros impactos producen estos fallos humanos de robots?
Adicional al tiempo invertido por los equipos de Mantenimiento en el diagnóstico de fallos no achacables al robot, se dejan de atender otras incidencias del resto de procesos automatizados. Las incidencias de usuario conllevan múltiples cruces de emails y llamadas con los peticionarios intentando depurar responsabilidades y agilizar la resolución de la incidencia. Por norma general, los fallos humanos no suelen tener una resolución ágil, ya sea porque el usuario esté ilocalizable, indisponible o desconozca dónde se encuentra el error.
Otro grupo que generalmente está afectado son los equipos de Reporting. En muchas ocasiones no tienen manera de discriminar las incidencias de un tipo u otro a ciencia cierta, impactando en las métricas e indicadores mensuales de los departamentos de Operación y Mantenimiento, teniendo que estar aplicando factores correctores para no desvirtuar dichas métricas.
Finalmente, los propios equipos de Negocio y el impacto en cliente final, son los grandes afectados, ya que no tendrán los robots operativos hasta que el usuario resuelva correctamente el problema con los consecuentes retrasos de las ejecuciones, muchas veces con acuerdos de nivel de servicios (SLAs) y posibles sanciones o penalizaciones asociadas.
¿Qué podemos hacer para evitar o mitigar estos fallos humanos?
No es posible evitar totalmente los fallos humanos, pero existen una serie de recomendaciones en base a nuestra experiencia que ayudan a mitigar el problema y no afectar tanto a la calidad del servicio de mantenimiento:
- Se recomienda, en fases tempranas de la definición del proceso a automatizar, trasladar dichos riesgos a los usuarios/propietarios del robot de manera que puedan valorar estas casuísticas de fallo, para decidir si lo asumen o no en base a la criticidad del proceso, así como reforzar los protocolos de actuación por su parte.
- Otra pieza clave es la utilización de unos logs de robots detallados y robustos que permitan trazar todas las acciones que ejecutan. Dichos logs deben contemplar los diferentes escenarios que se puede encontrar un robot, incluidos algunos fallos humanos. Una definición de logs con una correcta descripción de los mismos, acompañado de las notificaciones necesarias a los usuarios, puede ayudar a identificar esos fallos de manera preventiva por el propio robot y comunicarlo automáticamente a los usuarios, evitando la apertura de tickets indebidos.
- En la herramienta de gestión de tickets se recomienda disponer de algún campo que permita identificar a los equipos de Mantenimiento que se trató de un fallo humano y no de un fallo del propio robot. De esta manera facilitará a los equipos de Reporting la exclusión de dichas incidencias a la hora de generar informes, sin penalizar a los resultados de la calidad del servicio de Mantenimiento.
Como conclusión, podemos confirmar que un alto porcentaje de robots requiere de alguna acción previa por parte de un humano o en mitad del proceso. Estas acciones son candidatas a generar fallos que se imputan indebidamente a los departamentos de Operación y Mantenimiento de robots. Es importante remarcar estos aspectos al inicio de la definición y modelado de un proceso automatizado con los propios usuarios de robots, buscando un compromiso por su parte y asegurando la correcta colaboración entre ambos, diferenciando claramente la naturaleza de las incidencias.
Team Member Grupo de Expertos itsm4RPA-IA
Comité de Estándares de itSMF España