¿Grabar o programar Robots Software? Esa es la cuestión en RPA

Desarrollada íntegramente en Java y con un SDK modular, Jidoka es la mejor herramienta RPA para desarrolladores.

La nota publicada por HfS, titulada Bots are Starting to Comprehend Spanish sitúa a Jidoka como “a leading position in the Spanish-speaking world” y destaca el hecho de ser una plataforma Java (a diferencia de la competencia que ofrece soluciones .NET) y también nuestra visión en abordar programáticamente procesos de negocio (enfoque “top down”) en lugar de utilizar un “grabador” y tener un enfoque de tareas (“bottom up”).

Para los que no lo conozcan, los enfoques top-down y bottom-up son dos estrategias de diseño de sistemas software, que en el caso de Robotic Process Automation (RPA) se traducen en:

  • Bottom up
    • Se centra en la automatización de tareas individuales que se van componiendo hasta definir un proceso de negocio.
    • La construcción se haría en base a “scripts” sobre tareas y utilizando “grabación de sesiones”. Un proceso end-to-end es complicado de grabar, sí es más viable grabar tareas individuales.
  • Top down
    • Se parte de un flujo de negocio (workflow) a alto nivel que describe el proceso, donde incluso, según la granularidad del flujo, no tiene por qué haber relación entre una acción del workflow y una tarea individual que realiza una persona
    • Es un enfoque habitual cuando se realiza la construcción de forma programática, es decir, con un SDK/API.

 

¿Una solución RPA sin programar?

Y es que el “universo RPA” es mucho más amplio que el que la gran mayoría de los fabricantes están contando a los clientes afirmando que “no se necesitan programadores para construir robots software”.

Estos fabricantes RPA manifiestan abiertamente que para programar un robot (nótese que ellos mismos hablan de “programar” un robot), basta con que un analista de negocio utilice un grabador que capture todas las acciones que se realizan en la pantalla asociadas a un proceso de negocio, y voilà, ya tienes un robot funcionado.

No digo que para una demostración el efecto “te hago un robot en 5 minutos” no quede espectacular, pero el problema surge no en una demostración controlada sino en entornos reales donde debes conectarte a varias aplicaciones, donde los procesos pueden ser repetitivos pero de alta complejidad y además estos procesos suelen cambiar: no es posible tener claro desde el inicio qué pasos hay que dar o qué reglas de negocio implementar.

¿Qué se hace en este caso? ¿Volvemos a grabar el proceso? La respuesta en la gran mayoría de ocasiones es que no, que se necesita un programador que codifique estos cambios, y claro, lo tiene que hacer sobre un código que no es suyo, que es ajeno a su forma de programar, ya que lo ha generado de forma automática el grabador.

Cualquier proceso real incluye una serie de casuísticas, bifurcaciones, excepciones, etc. que no aparecen en una única sesión de demostración del proceso por parte de las personas que lo realizan antes de acometer su automatización. Estas variaciones aparecen siempre a posteriori, a medida que se va desarrollando el robot y se va utilizando un volumen de datos de entrada más extenso. Es entonces cuando el conocimiento, la destreza, las dotes de programación del desarrollador entran en acción. Que para “hacer 4 clics y montar una hoja Excel no necesitamos a un programador” puede ser cierto, el tema es que en un proceso real nunca son solo 4 clics y gestionar una hoja Excel. Jugar con scripts es divertido un rato, para algo serio: haz un programa.

 

Las ventajas de poder programar robots software

Hay muchas otras preguntas alrededor de  un grabador:  ¿El grabador genera también casos de prueba sobre esos robots? ¿Cómo es el código generado por un grabador? ¿Es modular y fácil de mantener? ¿Cumple con los patrones de diseño o reglas de calidad aceptadas por la industria? Ya nos hemos encontrado alguna RFI donde el cliente, entre sus requerimientos, incluye la revisión del código del robot para validar la calidad de mismo.

Nuestra visión es claramente diferente: los programadores son los que deben construir los robots, desde el inicio.

Para ello, los fabricantes deben proporcionar el arma más potente en el mundo de la programación que no es precisamente un grabador (a pocos programadores les apasiona el código generado de forma automática) ni siquiera un IDE, sino un SDK (Software Development Kit) potente, modular, extensible y fiable, construido en un lenguaje robusto, abierto y universal, como es Java.

En Jidoka un robot es un programa no un script. Y es un programa almacenado en un repositorio de código (Subversion, Git), que cumple con reglas de calidad definidas en herramientas como PMD o Checkstyle, que implementa casos de prueba (por ejemplo con JUnit) y que se incluye en herramientas de integración continua como Jenkins.

Los clientes deben invertir además de en licencias en formar a sus programadores. En ese sentido Jidoka cuenta con un extenso plan de autoformación que incluye guías de desarrollo y  tutoriales. Y la pregunta que hacen los clientes siempre es la misma: ¿Cuánto tiempo puede tardar mi programador en poder desarrollar robots? En base a nuestra experiencia, con una media de 30-60 horas de autoformación, un desarrollador es capaz de construir y desplegar un robot Jidoka. Si no fuera suficiente con la autoformación puedes contratar un curso presencial o remoto para tus programadores, impartido por el propio equipo que construye y da soporte a la plataforma. Y por último, si necesitas más asistencia puedes contratar el soporte técnico mediante un asiento de desarrollo (developer seat) por el cual proporcionamos asistencia al uso del SDK de Jidoka para la construcción de Robots Software.

Así que la respuesta a la pregunta de grabar o programar un robot es realmente sencilla: programar. Y si queremos programar un robot, será mejor que lo haga un programador, como dice el refranero popular: “zapatero a tus zapatos”.

Víctor Ayllón
Víctor Ayllón
CEO de Jidoka. Socio fundador de Novayre, empresa tecnológica apasionada por la innovación software y la automatización. Desde los años 80 con un ZX Spectrum como compañero de juegos y en los 90 compañero de trabajo.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *