[20/02/2021] Toda buena historia de ciencia ficción tiene al menos un robot mayordomo y un genio que todo lo sabe y todo lo ve, y que puede hacer que todos nuestros problemas desaparezcan en una fracción de segundo. La gente que acuñó la palabra de moda "automatización robótica de procesos" estaba claramente tratando de aprovechar este sentimiento. Los clientes que compran la plataforma esperan poder entregar sus tareas a un mayordomo informático para que los humanos que quedan en planilla puedan concentrarse en los retos más importantes.
La buena noticia es que hay muchos ejemplos de que la palabra de moda es precisa. Las empresas están simplificando los flujos de trabajo y creando sofisticados cuadros de mando que absorben datos y escupen infografías útiles. Las herramientas de RPA han demostrado ser exitosas al permitir que la computadora realice algunas de las tareas más onerosas que molestan a todos en la cadena alimentaria.
Las herramientas de RPA también dan nueva vida a los sistemas heredados, al añadir una nueva capa que puede manipular inteligentemente el código antiguo y ayudar a prolongar su vida útil. Muchas herramientas de RPA también pueden ser desplegadas por personas que no son programadores, permitiendo a quienes conocen el dolor de trabajar con herramientas heredadas arrastrar y soltar nuevos íconos para mejorar sus flujos de trabajo. Elija la herramienta y la implementación correctas, y cualquiera que pueda escribir macros de hojas de cálculo podrá agilizar los procesos de trabajo utilizando RPA.
Toda esta magia es clara, proporcionando una maravillosa fachada que barre con gran parte del trabajo y la monotonía. Pero bajo el barniz que RPA añade a sus sistemas se esconden varias cuestiones que podrían resultar problemáticas con el tiempo.
Lo inevitable se retrasa
Una de las grandes ventajas de RPA es su capacidad de construir una capa para pegar los paquetes de software heredados. Por supuesto, podría reescribir los paquetes desde cero para armonizarlo todo, pero una buena solución de RPA puede lograr casi lo mismo en un tiempo mucho menor. Es la versión digital de la goma de mascar y el hilo de embalar.
Este enfoque puede hacer maravillas. El aumento de la productividad puede ser emocionante cuando se presenta por primera vez. Pero no se deshace del código heredado, solo lo esconde.
El apoyo político a las soluciones reales disminuye
Cuando la bonita capa de RPA soluciona los puntos de dolor de los quejosos, es una gran victoria. Pero como los problemas más profundos no han desaparecido, el barniz de una solución puede tener otro problema oculto: ya nadie presta atención.
Los arreglos temporales que satisfacen el aquí y el ahora pueden incluso perjudicar cualquier esfuerzo por asignar presupuesto para arreglar el código heredado de una vez por todas, porque los de traje dejarán de escuchar las quejas inmediatas. Asumirán que RPA ha hecho el trabajo y podrán gastar su presupuesto en otra parte.
La complejidad aumenta
El usuario medio puede pensar que la solución RPA lo simplifica todo, pero bajo la superficie todo se vuelve más complejo. Donde antes había N capas de código deficiente, ahora hay N+1 capas. Esto hace que la depuración y el mantenimiento sean mucho más difíciles. Cuando surge un problema, hay que buscarlo en N+1 capas con la esperanza de encontrar el lugar donde se ha introducido el error.
Los errores heredados persisten
Las soluciones de RPA pueden ocultar la fealdad del código heredado, pero no pueden arreglar las limitaciones o los errores que hay en su interior. La buena noticia es que una capa de RPA inteligente puede interceptar algunos de los problemas potenciales. A veces la solución será maravillosa y estable, y otras veces será como una capa de pintura fresca en un porche podrido.
Las traducciones de datos pueden costar
Una buena parte de la codificación puede consistir en reordenar los bits para adaptarlos a un formato de datos exigido por alguna biblioteca y luego, cuando la respuesta llega, reordenarlos para almacenarlos en un formato diferente en otro lugar. Una parte del código quiere el primer año en la fecha y otra quiere el último. Alguien con un sentido del humor malicioso diseñó las utilidades de Java para comenzar la matriz del mes con cero, por lo que febrero es el mes uno. Sin embargo, la primera fecha del mes es un uno. Este es el tipo de codificación que ayudó a poner un techo sobre mi cabeza.
Muchas pilas de RPA automatizan algunas de estas traducciones para que usted no tenga que preocuparse por ellas. Esto facilitará la creación de un software que funcione, pero no eliminará el trabajo subyacente necesario para realizar estas interminables traducciones. Los servidores tendrán que ser más potentes y, literalmente, pagará todo este malabarismo de datos con cuentas de luz más altas. En muchos casos, esto podría ser solo unos pocos centavos, por lo que no valdrá la pena preocuparse por ello. Pero si tiene una operación grande, el costo de escalar podría ser material. En algún momento puede merecer la pena contratar a un equipo de programadores para que escriban un código limpio y elaborado a mano.
Sus "superusuarios" no tienen poderes de programación
Todo el mundo, desde la C-suite hasta el grupo de becarios a tiempo parcial, podrá poner en marcha una herramienta de RPA y realizar algo con solo un breve esfuerzo. La automatización realmente funciona, pero, aunque los superpoderes sean reales, no vienen acompañados de la sabiduría necesaria para entender cómo utilizarlos eficazmente.
Los programadores conocen las estructuras de datos y ya han dedicado mucho tiempo a conocer la forma idiosincrásica en que las computadoras pueden ser desconcertados por una fecha en un formato incorrecto, por ejemplo. Los programadores entienden de redes y comprenden las reglas básicas de la arquitectura de computadoras y sistemas. Todos estos instintos tienen un valor incalculable cuando se trata de encadenar los diversos conjuros que impulsa la RPA.
Los programadores siguen siendo su mejor opción
A pesar del argumento de venta de que los usuarios empresariales serán los implementadores de RPA a los que deberá acudir, los programadores siguen representando el uso más eficaz y eficiente de las herramientas de RPA. Tienen años de experiencia trabajando en cada capa de la pila. Saben qué consultas pueden ser respondidas rápidamente por la base de datos y cuáles estarán llenas de JOINs que convertirán la máquina en una melaza. Todos los pelos que se han arrancado a lo largo de los años les han permitido conocer las mejores formas de formular preguntas para que los sistemas generen respuestas que valgan la pena.
Si las herramientas de RPA son un multiplicador de fuerza de, digamos, 10 veces, y se las da a un programador estrella que ya ofrece 10 veces más que el codificador promedio, podría ver 100 veces más rendimiento. El efecto multiplicador puede ser realmente grande.
La amplitud del soporte tiene sus inconvenientes
La mayoría de las herramientas de RPA vienen con la promesa de que pueden interactuar con mil millones de productos diferentes que hablan de mil millones de formatos de API diferentes. La afirmación suele ser correcta, pero los resultados suelen estar lejos de ser perfectos. Los proveedores de RPA están respondiendo a las demandas de un amplio soporte, pero esta amplitud es difícil de soportar y mantener.
Es habitual, por ejemplo, encontrar errores o lagunas en los datos que fluyen a través de las conexiones. A veces la fecha puede tener un formato extraño. A veces se cuelan resultados "nulos". Hay cientos de fallas que aparecen. Puede que no sean fatales, pero habrá que añadir otra capa para limpiar los errores o tal vez conformarse con alguna laguna ocasional.
Las computadoras solo pueden eliminar una parte de la burocracia
Las herramientas de RPA prometen agilizar los flujos de trabajo, pero la mayoría de los cuellos de botella de los procesos no tienen nada que ver con las computadoras o la RPA. A menudo se añaden pasos a los flujos de trabajo porque algún humano encontró la manera de hacer las cosas mal. Quizás alguien en la oficina de Kansas perdió un millón de dólares porque no se asesoró en Portland. Tal vez algún becario resultó ser un ladrón.
El mejor software de RPA puede suavizar algunas de estas molestias, pero no puede deshacerse de ellas. Si alguien decide que el equipo de Hong Kong tiene que aprobar todas las facturas, la suite de RPA solo podrá facilitar un poco el empaquetado de la documentación para la gente de Hong Kong. El software no podrá sacarlos del bucle. La verdadera complejidad proviene de las personas. Apoyarse demasiado en la RPA como solución mágica puede cegar a su organización respecto del verdadero trabajo que supone la racionalización de sus procesos.
Demasiada automatización puede ser peligrosa
Por supuesto, gran parte de los trámites burocráticos de sus flujos de trabajo han sido puestos ahí por una razón. Uno de los peligros secretos es que una implementación de RPA acelere las cosas hasta el punto en que los problemas pasen por encima de los guardianes humanos, que asumirán que la RPA está haciendo el trabajo pesado. Se conectarán a su panel de control y pasarán rápidamente por las páginas mientras ven la televisión o escuchan un podcast. ¿Por qué dedicar demasiado tiempo a los detalles si el RPA marcará los casos extraños?
Es posible que no haya una forma fácil de automatizar muchas de las tareas difíciles relacionadas con el cumplimiento de la normativa o la protección contra el fraude. Los malos sondearán el sistema y explotarán cada pequeña debilidad de RPA. A veces es necesario que haya cierta fricción en el sistema. A veces, hacer las cosas demasiado fáciles es un error.
Basado en el artículo de Peter Wayner (CIO) y editado por CIO Perú
Peter Wayner es editor colaborador de InfoWorld y autor de más de 16 libros sobre diversos temas, como el software de código abierto, los coches autónomos, la computación con privacidad, las transacciones digitales y la esteganografía.