RPA y las «viejas prácticas»

rpa automation
rpa automation

Lo obvio no siempre es evidente.

La experiencia de analistas y programadores, la correcta dirección de los proyectos y un buen aseguramiento y control de calidad permiten garantizar que los procesos funcionarán de manera continua, robusta y resiliente.

Varios fabricantes de soluciones de RPA indican que su producto lo pueden emplear personas sin conocimiento o experiencia en tecnología. Simplemente, lo dudo. Puede que en determinadas partes del ciclo de vida de la automatización —como son la fase de análisis y definición del proceso— no se requieran estos conocimientos, pero en el resto sí son necesarios. A modo de símil, esto podría compararse con el hecho de que, por saber montar un mueble de Ikea, uno no se convierte en carpintero.

Para que una empresa adquiera capacidades de automatización de procesos mediante robots de software no solo es necesario contar con técnicos capaces de manejar una herramienta determinada. Si realmente quieren hacer soluciones más allá de pequeñas pruebas, deben conocer otros aspectos de la tecnología tales como todo lo relacionado con arquitecturas, bases de datos, webservices, HTML, JavaScript, etc. Además, se deben también definir los procesos adecuados de gestión y gobierno de toda la solución. Poniendo otro símil, al igual que un técnico no hace un departamento de desarrollo o de sistemas, un analista de procesos tampoco hace un centro de automatización.

Auditorías de automatización

Durante este último año algunas empresas nos han solicitado la realización de auditorías para comprobar la calidad de sus desarrollos en RPA. La sorpresa ha sido mayúscula, en gran parte motivada por esos mensajes de los fabricantes y cierta dosis de ingenuidad.

La revolución actual viene propiciada por un cambio muy importante a nivel tecnológico, pero no debemos olvidar las buenas prácticas, tanto las relacionadas con la gestión como con la propia tecnología, ya que son las que van a permitir asegurar el éxito de los proyectos, su robustez y continuidad en el tiempo. De hecho, los análisis que hacemos están enfocados desde varias perspectivas: organización y personas, metodología de desarrollo y calidad de la construcción.

En ocasiones, cuando analizamos la organización encargada de la automatización de procesos, vemos que las funciones, responsabilidades y capacidades no han sido correctamente construidas o asignadas; y que dicha organización carece de un conjunto de procesos y registros que den soporte a la gestión de la automatización.

RPA es una opción más dentro del conjunto de herramientas con las que cuenta TI

Implicación de negocio

En cualquier tecnología de RPA, es necesaria una adecuada gestión de la demanda o del pipeline, ya sea de manera reactiva o proactiva, así como una concienciación de las posibilidades que esta tecnología puede ofrecer. En este momento es cuando pueden implicarse analistas de negocio, con la debida formación y herramientas, para poder identificar y analizar los procesos y las aplicaciones involucradas, y después valorar, priorizar y realizar un caso de negocio orientado a establecer un roadmap.

¡Señores fabricantes! En este punto, alguien sin conocimiento de TI, pero con un cierto soporte de técnicos de automatización, sí puede responsabilizarse del trabajo. Parece fácil, pero hemos visto situaciones en las que la elección de los procesos no era la adecuada teniendo en cuenta las implicaciones técnicas, por no haber realizado el necesario caso de negocio o, simplemente, porque era un proceso que no tenia sentido automatizar, por su carácter excepcional. En definitiva, decisiones poco afortunadas que siembran la duda sobre la calidad de las soluciones técnicas.

Hay que recordar que la RPA es una alternativa más dentro del conjunto de herramientas con las que cuenta un departamento de TI a la hora de dar solución a las necesidades de Negocio. Es solo una más, que se puede aplicar, o no, en función de ese análisis previo. De hecho, en ocasiones hemos convencido a algunas empresas, por la vía de los hechos, para que no automatizaran determinados procesos mediante RPA, ya que existía una solución mejor que resolvía su problemática y que, además, resultaba en un mejor caso de negocio.

Claves de las mejores «viejas» practicas

Documentación

Pasemos a las metodologías de desarrollo. Todos los fabricantes de RPA disponen de un framework con sus mejores prácticas aplicadas a esta tecnología, no muy diferente a los tradicionales. A lo largo de estas auditorías hemos visto desarrollos sin documentación porque “como es tan fácil y rápido, no merece la pena documentarlo… Ya se hará al final”. ¿Alguien admitiría que un arquitecto construyera un edificio sin un plano previo, y sin verificar paso a paso que la construcción se realiza conforme a ese plano? Cuando esto sucede, el resultado es el esperado: no se cumplen las expectativas en cuanto a los resultados y, además, el proceso no es estable ni robusto, y viene acompañado de unos costes de mantenimiento excesivos. Nada que no sepamos que ya ocurría en las denominadas “viejas tecnologías”.

No seguir las mejores prácticas del fabricante puede derivar en definiciones tanto de procesos sin detallar, diseños imposibles y carentes de cualquier estructura sensata como de estabilidad.

El coste de la no calidad

Siguiendo con los símiles… ¿Pondríais a un perfil muy orientado al negocio, un economista, por ejemplo, a desarrollar una aplicación con tan solo un curso de una semana sobre Java? Pues es lo que está ocurriendo en el ámbito de la RPA. En estas auditorías hemos visto personas recicladas —sin experiencia en desarrollo ni en TI, sin mente estructurada ni orientada a procesos, y solo con conocimientos básicos de una herramienta— tratando de construir soluciones de RPA. No es posible automatizar aplicaciones sin tener conocimientos de JavaScript o de programación estructurada y, sobre todo, si se carece de la experiencia necesaria y de una visión amplia de las posibles implicaciones que tiene un desarrollo. Aquí es donde se hacen presentes esos costes de la no calidad.

Viejas prácticas y nuevas tecnologías

Vayamos pensando en que las “viejas” prácticas se pueden aplicar a las nuevas tecnologías y que, como en todo, son necesarios el conocimiento y la experiencia, además de saber gestionar los proyectos y dotar a los equipos de unas capacidades acordes con cada necesidad.


Las «viejas» prácticas, si son mejores prácticas siguen estando vigentes en un mundo de transformación tecnológica, donde la calidad sigue siendo la piedra angular del mismo.

No subestimemos el poder del aprendizaje, pero tampoco olvidemos tutelar y aplicar unas mejores practicas que aseguren el éxito y la calidad de los desarrollos. Hablamos de:

  • Equipos equilibrados, con todos los roles necesarios.
  • Analistas que, además de conocer los procesos, dispongan del conocimiento para realizar análisis de viabilidad y construir los casos de negocio.
  • Arquitectos de soluciones de automatización que combinen el conocimiento experto de las herramientas, la gestión de su configuración y seguridad con el conocimiento de la arquitectura técnica.
  • Un equipo de desarrollo que conjugue el liderazgo y la experiencia técnica con las buenas prácticas de desarrollo que aseguren la calidad de las entregas, su robustez y resiliencia.

Articulo Publicado en el especial sobre Robotic Process Automation en Digital Biz

Comparte este Post