Beneficios de RPA vs codificación tradicional

Cuando un tecnología emerge en el mercado existe una tendencia a compararla con las existentes. Lo mismo ha ocurrido con el uso de RPA (Robotics Process Automation). Lo importante de disponer de una determinada tecnología es saber cuándo es mejor emplearla para obtener mejor sus beneficios. Vamos a profundizar en cuales son los beneficios de emplear tecnologías de RPA respecto a las herramientas tradicional basadas en codificación.

La tecnología de RPA, es ante todo, No/Low-code, es decir, no requiere de la escritura de líneas de código para automatizar un proceso. Simplemente emplea elementos ya diseñados que recopilan datos, realizan operaciones, conectan con aplicaciones estándares e incluso permiten hacer dichos conectores con otras de manera sencilla. En esto difiere radicalmente con las herramientas tradicionales de desarrollo basadas en codificación, como pueden ser javascript, HTML, C#, C++, python, java, etc.

Toda tecnología requiere una curva de aprendizaje y adquirir una cierta madurez para implementarla y sobre todo mantenerla. Así que, puede ocurrir que una vez una persona o área de tecnología se especializa en una tecnología, la abraza, la cuida, la desarrolla y la defiende ante una posible agresión de otras. Sin embargo, esta actitud “taliban” dista mucho de la que realmente se necesita. Un área de TI, así como un buen profesional, debe disponer del mayor numero de herramientas en su arsenal para hacer frente a los problemas que plantea el negocio, y seleccionar la más apropiada y eficiente para acometer dichas tareas.

Los que llevamos unos años en tecnología, sabemos que se puede hacer casi todo con tiempo y dinero. Las soluciones de RPA se han centrado en la automatización de procesos, no tanto en el desarrollo de aplicaciones. Y es cierto, que con las herramientas tradicionales de codificación también se puede automatizar procesos integrando diversas aplicaciones.

Así que veamos cuando interesa aplicar unas respecto a otras.

Las herramientas de desarrollo basadas en codificación han sido diseñadas para la construcción de aplicaciones, ya sean de escritorio, web o para smartphones. Sin embargo, las herramientas de RPA ha sido diseñadas para automatizar procesos e integrar aplicaciones, y en concreto para interactuar con la capa de presentación de éstas, aunque también, pueden interactuar con APIs (Application Programming Interface). En las soluciones de RPA, sólo hay que construir las nuevas integraciones con las aplicaciones, y solo las que no existan ya desarrolladas, ya que en general hay un conjunto de componentes ya diseñados por el propio fabricante o por la comunidad de usuarios. Esto hace que sea un desarrollo rápido, en torno a diez veces mas rápido que el desarrollo con una herramienta de codificación.

Así si necesitamos integrar aplicaciones únicamente mediante API es mejor recurrir a la codificación tradicional o a conectores prediseñados. Sin embargo, en el momento que necesitamos interactuar con un sistema legacy o sistemas que carecen de APIs, es mejor emplear soluciones de RPA.

Una de las ventajas que tienen las soluciones de RPA frente a la codificación tradicional es que no hay que modificar las aplicaciones existentes, al interactuar con las capas de presentación, la funcionalidad y la seguridad sigue residiendo en la aplicación a la que se conecta, y a la que añade una nueva capa lógica. En el desarrollo tradicional, si queremos integrar dos o más aplicaciones que carezcan de APIS, tenemos varias opciones. Si las aplicaciones disponen de un lenguaje de scripting, es posible desarrollar sobre ellas dicha integración, pero si no,  tendremos que desarrollar complejas interacciones con las bases de datos, re-crear la lógica de negocio, crear módulos de seguridad específicos, entre otros,  haciendo que tiempo empleado en la construcción de la integración crezca de manera importante.

Últimamente, una de las características que han incorporado las soluciones de RPA, es que con ellas se pueden construir interfases de aplicaciones empleando No/low code, es decir, podemos construir una aplicación “tradicional” simplemente arrastrando y soltando componentes prediseñados, y ya probados. Esto ha permitido la interacción de personas y robots, así como su uso más allá de la automatización de procesos.

Estas herramientas basadas en No/Low code no requieren grandes conocimientos de informática y ningún conocimiento de lenguajes de programación, aunque si disponer de una mente estructurada.  Esto hace que la curva de aprendizaje sea rápida y que en pocas semanas se esté en condiciones de construir automatizaciones.

En el otro extremo, es difícil encontrar desarrolladores especializados en lenguajes de codificación, la curva de aprendizaje es mucho más lenta y lleva mayor tiempo adquirir la experiencia necesaria para desarrollos complejos. Por tanto, estamos hablando de recursos escasos en el mercado, y, por tanto, en los departamentos de TI. En definitiva, desarrollar con leguajes tradicionales, también es más caro.

Una de las problemáticas a las que se enfrentan las empresas es la gestión de demanda de automatizaciones. Los departamentos de TI, ya de por si, saturados, no pueden gestionar de manera diligente las necesidades de automatización que solicitan las áreas de negocio. Por eso en algunas empresas, se ha decidido formar en herramientas No/Low code para que sea el propio negocio el que pueda automatizar sus propias tareas. Esto es posible, por la sencillez en el uso de estas herramientas, algo que sería impensable con lenguajes de codificación tradicional. Que las áreas de negocio sean capaces de automatizar sus propias tareas beneficia de varias maneras, por un lado haciendo factibles las automatizaciones, y por otro liberando a los recursos de TI de estas actividades.

Otro de los aspectos a tener en cuenta es la mantenibilidad de los desarrollos hechos con estas tecnologías. Un desarrollo visual en el que se emplean módulos prediseñados y probados es mucho mas fácil de mantener que un desarrollo tradicional basado en código. Si es cierto que para ambos existen mejores prácticas que tratar de estructurar los desarrollos y hacerlos más sencillos de entender, probar y mantener, pero en las herramientas Low/no code es muchísimo mas sencillo.

Claramente las herramientas de low/no code van destinadas a los usuarios que no son desarrolladores profesionales, permitiéndoles disponer de aplicaciones que satisfagan sus necesidades de manera sencilla y rápida. Estos son lo citizen developers.

Eso no quiere decir que no puedan ser empleadas por desarrolladoras profesionales. Es una alternativa más de la que disponen para dar soluciones sin tener que invertir más tiempo del necesario para hacerlo. ¿Tiene sentido reinventar funciones que ya vienen realizadas? ¿Tiene sentido poner ladrillos si ya viene la pared construida? Probablemente no.

Lo que sí es claro es que hay nuevas herramientas en nuestra caja de herramientas, ya sea para profesionales o no. Analizarlas, probarlas y ver que pueden aportar, y sobre todo que valor pueden aportar a toda la compañía en su conjunto, es algo que ya depende de nosotros.

No son tecnologías excluyentes sino complementarias, y solamente hay que identificar donde es mas eficiente emplear una, otra o ambas.