RPA y la máquina del tiempo

¿Por qué cuándo estamos frente a un RPA nos olvidamos de todas esas buenas prácticas que hemos aprendido en todos estos años?

Soy un fanático de las tecnologías de robotización automatizada de procesos (RPA), pero estoy tremendamente sorprendido de cómo, con un avance de esta envergadura, al final me quedo con la sensación de haber entrado en una máquina del tiempo que me lleva al pasado en unos 30 años.

He visto muchas implementaciones RPA y el resultado me parece fantástico, pero cuando he mirado lo que está detrás de muchas robotizaciones, ahí volví al pasado. Volvimos al punto cuando no teníamos buenas prácticas de fabricación de software, simplemente nos concentrábamos en hacer que un programa funcionara de la mejor manera sin importar como lo lográbamos y con escasas reglas que cumplir.

En la actualidad, cuando hacemos un software, nos preocupamos desde el nombre, que es una norma básica, verificamos que las variables se utilicen correctamente, usamos parametría, no usamos valores en “duro”, nos preocupamos de aspectos de seguridad, revisamos las instrucciones que estamos utilizando, tenemos arquitectos que nos definen estándares, tenemos software que inspecciona lo que estamos haciendo para asegurar buenas prácticas y mucho más.

¿Por qué cuándo estamos frente a un RPA nos olvidamos de todas esas buenas prácticas que hemos aprendido en todos estos años?, he visto robots que para acceder a internet guardan nuestros nombre de usuario y claves en un “.ini” como texto, exponiendo nuestra seguridad. Cada robot genera, en una misma compañía, un log en formatos diferentes ubicados en lugares distintos que además cuando logramos encontrar (porque nadie sabe dónde están) no contienen ninguna información valiosa, “Se ha encontrado un problema”…¿qué es eso? Codificaciones inciertas y desordenadas que poco cumplen con los estándares mínimos de un buen diseño, con costos de mantención muy altos y muy poco valor para nuestra organización y si genera valor, seguro será mientras no tenga que hacer cambios.

Cuántas veces me ha tocado escuchar que llegaron los robots y ahora tenemos más problemas, el robot no hace lo que debiera hacer y ahí está en una máquina llenándose de polvo en un rincón sin funcionar y cuando llamaron al soporte te dice que el problema no lo tiene el robot, lo que pasa es que no hay conexión con internet o que la clave ha vencido u otra cosa que de haber utilizado una buena práctica en el diseño no hubiese quedado a la suerte de las circunstancias.

Los desarrolladores están codificando siempre en positivo, es decir, el camino feliz. La mayoría de las acciones están pensadas en hacer y hacer y hacer, pero poco y nada de ¿qué pasa si es que no ocurre la condición del camino feliz?, ¿qué pasa si no hay conexión al sistema que el robot quiere usar?, ¿pensamos en las acciones a seguir? o simplemente generamos un mensaje (en el mejor de los casos) en un log y que poco dice del problema, o lo que es peor, que nos enteramos cuando el problema revienta muchísimo después, cuando ya no podemos hacer nada. Los desarrolladores están haciendo lo que les pedimos y no estamos concentrados en el diseño de buenos flujos de proceso para luego ser robotizados.

Si un robot reemplaza lo que hace una persona, pues hagamos lo que haría una persona. Si detectamos un problema mandemos un correo al jefe del área, si no funciona algo generemos un “ticket” en el sistema de atención de problemas, prendamos una luz, pero hagamos algo.

Esto es lo que ocurre y creo que no debiéramos subir a una máquina del tiempo para viajar al pasado, sino que todo lo contrario, crear buenos robots para viajar más al futuro, realizar una verdadera revolución en las organizaciones, lograr el anhelo de la transformación digital, mejorar en eficiencia, bajar costos, tener cada día clientes más felices por el buen servicio de nuestra compañía.

Estamos concentrados en incorporar robots y no en automatizar procesos.

Un robot es un programa, sí, es un programa como cualquier otro, ya veremos en otra oportunidad cual es la diferencia de un programa robot con un programa “tradicional”, pero que ambos son un programa no hay duda de eso. Entonces, comencemos aplicando lo que la humanidad ha aprendido en todos estos años para hacer buen software, que seguro siempre se puede mejorar, pero si comparamos con 30 años atrás vaya que si tenemos avances geniales.

Definamos reglas universales para nuestras robotizaciones, estándares, sin importar si usamos una u otra herramienta o simplemente usamos un lenguaje. Definamos acerca de la seguridad, acerca de la infraestructura, de la nemotecnia, de la forma de generar un mensaje de error y su contenido, identifiquemos a los roles a quienes les vamos a informar los problemas para que puedan tomar acciones inmediatas y les hacemos llegar mensajes de una forma clara y evidente de que nuestro robot tiene un problema y cuál es ese problema. ¿No estoy diciendo nada nuevo cierto?, pues a eso me refiero con esta máquina del tiempo que nos lleva a un momento en el cual no queremos estar.

No busco generar polémica, pero si busco generar una reflexión genuina para que este maravilloso enfoque de la robotización nos genere valor.

Mi mayor consejo es antes de pensar en herramientas o lenguajes, para construir un robot, simplemente definamos un ecosistema que sea sustentable para nuestra compañía, que permita diversidad de herramientas y lenguajes, pero con reglas claras para tener robots muy “sanos” y en lugar de construir robots como nuestro objetivo, que el objetivo sea definir los procesos en su completitud, use la técnica que quiera, con esto verá que “casi” sin importar la herramienta, sus robots serán una maravillosa ayuda a su organización y no un dolor de cabeza.

Si tienes ya un conjunto de robots operativos en tu organización, toma esa experiencia para generar estándares y sino organiza pequeños experimentos de robotización (1 a 2 semanas) y toma esa experiencia para iniciar un estándar de implementación de robotizaciones. Recuerda que un “estándar” no es un elemento estático, sin duda que va a evolucionar y debe evolucionar, no perdamos de vista la mejora continua. Con ello, cuándo se va a robotizar ya sea con equipos internos o externos podrá compartir la línea base de su estándar considerando todos los aspectos que deben ser respetados para su organización y tendrás un mejor resultado.

¿Qué prefieres, 1 error que se repite 1.000 veces o 1.000 errores diferentes?, el error es parte del ciclo de vida de cualquier solución, podemos gestionarlos a partir de nuestros estándares, aprendemos de ellos y el beneficio es inmenso. Si no los gestionamos, los repetiremos eternamente y no evolucionaremos a mejorar nuestras robotizaciones.

Con esto podrás aprovechar los beneficios de diferentes herramientas y lenguajes, no es necesario estar en una sola trinchera. Observa lo que necesitas después del diseño del proceso y luego decide cual es la mejor alternativa. Existen condiciones técnicas que permiten que algunas soluciones operan mejor que otras y por último La robotización no es el único camino para automatizar procesos.

¿Y cuándo tengamos un gran número de robots, cómo vamos a gobernarlos?...ups!!!, vamos a verlo en otra oportunidad ?