¿Por qué se murió mi robot? Razones por las que un robot comete un error

Adiferencia de otras soluciones de TI tradicionales, Robotic Process Automation (RPA) permite a las compañías automatizar sus procesos, generando ahorros en costo y tiempo, al imitar tareas repetitivas como hacer clic, escribir, copiar y pegar, abrir aplicaciones, visitar sitios web, etc.

Los robots RPA son excelentes para hacer exactamente lo que les decimos que hagan, pero en ocasiones se encontrarán con una situación que no fue programada para manejar y, en estos casos, “morirá” (parará la ejecución). Entonces, ¿cómo puedo confiar mi proceso a un programa de computadora que no está preparado para situaciones inesperadas?

En este artículo vamos a explorar cuáles son las razones por que las que un robot cometerá un error o dejará de funcionar, conoceremos a los participantes que ocasionan la falla y comprenderemos las consecuencias que pueden generar.

Limitaciones de RPA

Cuando hablamos de RPA hay que destacar que, en principio, los robots de software no tienen implementadas funciones cognitivas ni de inteligencia artificial, es decir, no tienen capacidad de aprendizaje (razonar, crear y/o decidir). Las tareas que fundamentalmente resuelve hoy en día RPA son, precisamente, las menos inteligentes, las que son masivas, repetitivas y basadas en reglas.

Cuando el robot se encuentra con una excepción, recurre al agente humano para que decida qué hacer en ese caso. En ese momento, el proceso se actualizará y, a partir de ahí, sabrá qué hacer ante esa casuística. Cada vez que algo cambia en el proceso, el robot dejará de funcionar o fallará.

Diferencias entre error, defecto y falla en RPA

Cuando el usuario se da cuenta de que el robot no actúa según las expectativas o de manera anormal, lo llaman “error”: “…el robot tuvo un error…”, pero hay una confusión al usar este término, a continuación, explicaremos las diferencias que existen entre error, defecto y falla.

Error

Es una acción humana que produce un resultado incorrecto. Aparece un error no solo debido al error lógico en el código realizado por el desarrollador. Cualquier persona en el equipo puede cometer errores durante las diferentes fases de la automatización de un proceso:

• El analista del negocio puede malinterpretar los requisitos.
• El usuario puede proporcionar información insuficiente o incorrecta del proceso.
• El desarrollador puede equivocarse en el diseño del software.
• Las personas en el equipo también pueden cometer errores debido a requisitos poco claros o insuficientes, presión de tiempo, letargo u otras razones.

Algunos tipos de errores son más difíciles de detectar y reparar que otros pero, en general, en RPA responden a diferentes tipos y pueden clasificarse de la siguiente manera:

• Sintaxis: el programador escribió mal un comando o instrucción (expresiones erróneas o incompletas, variables que no han sido declaradas, etc.). Los errores de sintaxis se detectan en la fase de compilación (proceso de traducir las líneas de código del robot), por lo que en la fase de desarrollo es fácil detectar y corregir este tipo de errores.

• Lógicos: estos errores se presentan cuando el robot no hace lo que queríamos que hiciera, es decir, el robot funciona, pero no hace lo que debería hacer. No existe ningún robot que pueda determinar qué es lo que tratamos de conseguir. Contra estos errores solo cabe hacer un correcto levantamiento del proceso, realizar juntas con los involucrados, conseguir toda la información y tener la comprensión del proceso, dar seguimiento y depurar al robot hasta que cumpla con los requisitos especificados.

• Uso incorrecto: estos errores son los más difíciles de detectar. El uso incorrecto de un robot son situaciones que no fueron consideradas por el programador o que están fuera de su control, por el simple hecho que no deben ser controladas. Antes de empezar la construcción de un robot para la automatización se hace una revisión con los usuarios para validar la solución propuesta por el equipo RPA, donde se incluyen todas las precondiciones que el robot necesita para su correcta ejecución, si una de estas no se cumple, la falla del robot es casi inevitable.

Defecto

Es la manifestación del error en la ejecución de un robot. Es cualquier variación entre el resultado real y el esperado, lo cual puede ser causado por varias razones, aquí algunas de ellas:

• Discrepancia o problema en el código.
• Introducción de un paso, proceso o definición de datos incorrectos.
• Una anomalía o irregularidad en el robot, que hace que este se comporte de manera incorrecta y no según los requisitos establecidos.

Falla

Cuando un robot es incapaz de realizar las funciones requeridas, ofrece resultados que no son adecuados, lejos de lo esperado, entonces se denomina falla. Las fallas usualmente ocurren cuando un defecto se presenta en el entorno de ejecución del robot, lo que lo obliga a producir resultados imprevistos y funciona de manera inapropiada.

Pero la falla puede generarse no solo por errores humanos durante la construcción sino también por el mal uso del robot e incluso por errores externos. A continuación mencionamos las razones principales de fallas en un robot:

• Error humano: errores cometidos por el humano al interactuar con el robot y al proporcionar entradas incorrectas o incompletas.
• Uso del sistema: pueden surgir fallas debido a errores en la forma en que se usa el robot (fecha y hora de ejecución incorrectas, traslape de ejecuciones, etc.).
• Condiciones de entorno: una falla en el hardware/software donde se ejecuta el robot provocará una falla en el mismo.

Los errores en el proceso de desarrollo son muy comunes por todos los puntos que vimos anteriormente. Aunque su existencia representa un riesgo, bajo un esquema de prevención y corrección adecuado, lograremos que jamás se presente el defecto y, si se presenta, con los suficientes controles lograremos minimizar el impacto de la falla. Ahora podemos entender de mejor manera que:

El error genera el defecto que causa la falla

Es muy normal pensar que la gente llame error a un defecto, o cuando falla un robot te indiquen que han encontrado varios errores en el robot al revisar el resultado. Pero esto va más orientado al rol y su intervención en un determinado ciclo de vida del robot. Por ejemplo, un programador es responsable de la codificación y es el que tiene la orientación para identificar y solucionar un error. La responsabilidad de un tester es validar que el comportamiento de un robot sea el adecuado (antes de llegar a un entorno real), muchas veces guiado por un Manual de Usuario, y cuando identifica (en tiempo de ejecución) una anomalía, le reporta al desarrollador la existencia del defecto. Si no tenemos cuidado y el defecto se materializa afectando el resultado, el usuario final que conoce el proceso detectará la incorrecta realización de una terminada acción y reportará la falla.

La existencia del error, con el adecuado control de excepciones, no es tan grave, pero su existencia representa un riesgo potencial que se convierte en crítico cuando se manifiesta en un entorno real, detectarlos a tiempo con una adecuada etapa de pruebas es totalmente necesario. 

Lo anterior mencionado se resume en la siguiente imagen:

La mejor estrategia para la implementación de un robot es medir el comportamiento del mismo bajo entornos que nos permitan validar no solo la configuración realizada sino también las reglas de negocio que han sido definidas.

No es lo mismo que se presente una falla en un entorno real a un entorno controlado

Como consultores RPA hemos visto diferentes ambientes para los diversos sistemas a automatizar, y para no dar una amplia explicación sobre las variaciones podemos hablar del enfoque DTAP (Development, Testing, Acceptance and Production): es un enfoque comúnmente aceptado para probar y desplegar software.

Un flujo típico en RPA sería pasar secuencialmente por cada uno de los siguientes ambientes:

• Desarrollo: es el primer entorno que se utiliza y es en donde se desarrolla el robot. Los cambios son muy frecuentes aquí, ya que este es el primer entorno donde se materializan las reglas de negocio.
• Prueba: aquí se realizan los primeros intentos de estandarización y alineación con el entorno de producción futuro, donde se verifica que el producto funcione como se espera.
• Aceptación: una vez que el equipo de desarrollo considera que el robot está listo se implementará para su aceptación. El usuario final probará el robot para verificar si cumple con sus expectativas.
• Producción: cuando implementas un robot en producción significa que todos lo han aprobado para que se ejecute. El robot estará disponible para generar los resultados según la programación requerida.

La orientación jamás deberá ser construir el robot sobre un ambiente productivo, lo ideal es ir avanzando bajo el enfoque DTAP para poder tener un mayor control de las fallas ocasionadas por el robot. Es muy habitual que durante el desarrollo y las pruebas se identifiquen varios errores, pero para eso fueron diseñados estos entornos: para construir y probar, equivocarse y corregir cuantas veces sea necesario hasta conseguir el resultado esperado. El entorno de Aceptación nos permitirá guiar al usuario sobre el manejo e interacción que tendrán con el robot. Si el proceso requiere una entrada proporcionada por el área usuaria, este debe tener una estructura estandarizada y debe ser proporcionado de una manera específica. Durante este proceso de capacitación se producirán fallas en más de una ocasión, pero es parte del proceso de aprendizaje previo a la producción.

Las fallas se presentan principalmente por una inadecuada recopilación de requerimientos, así como un mal diseño y configuración del robot. Sin embargo, hay que recordar que una implementación RPA es soportada bajo 3 pilares: Personas, Proceso y Tecnología, esta última es el que le ha dado un gran un auge a la automatización y ha generado la relevancia que tiene hoy en día. Como cualquier otra solución tecnológica, demanda características tecnológicas especiales, que al no cumplirlas pueden generar inestabilidad, ineficiencia, ineficacia y para nosotros todo eso se traduce como fallas.

Es responsabilidad del área de TI proporcionar el adecuado ambiente según las necesidades de la herramienta RPA a implementar y asegurarse que el entorno en el que habite sea propicio para desempeñar su correcta funcionalidad. Cuestiones como acceso a los sistemas a automatizar, permiso para el envío de correos, acceso a carpetas compartidas, etc., darán al robot el óptimo necesario para cumplir su propósito.

A continuación, presentamos un diagrama que nos permite resumir lo anterior: