La potencia transformadora de RPA

Estos ejemplos muestran lo que es posible cuando se implementa RPA como parte de una estrategia dirigida por el negocio que toma tiempo para analizar procesos e identificar dónde la automatización puede ser más efectiva.

Pero para casi la mitad de las organizaciones que han implementado RPA, los resultados no han sido tan increíbles.⁴ O bien la RPA no ha entregado el ROI esperado en absoluto, o las ganancias iniciales no se han escalado en una optimización continua y en toda la empresa.

Esto a veces puede parecer un problema del software. Pero en casi todos los casos, el problema no es tanto la solución de RPA como la forma en que se ha implementado.

En particular, los pocos obstáculos de acceso a la RPA significan que a menudo se implementa en un solo departamento, para automatizar tareas específicas que ocupan el tiempo de los empleados o que parecen estar provocando cuellos de botella e ineficiencias.

Por ejemplo, imagine una organización que ha estado recibiendo quejas de proveedores acerca de pagos atrasados. El tiempo dedicado a introducir manualmente los datos de facturas en papel parece ser un problema, por lo que el departamento de finanzas utiliza la RPA para crear un bot que escanee las facturas e introduzca los detalles en el sistema financiero SaaS.

El bot funciona bien, pero los plazos del proceso de la adquisición a pago (P2P) no parecen mejorar. Con el tiempo, la persona que desarrolló el bot se va de la empresa. Nadie más sabe cómo mantenerlo actualizado, por lo que cuando el proveedor de SaaS actualiza el sistema de finanzas, el bot deja de funcionar.

Este sencillo ejemplo resalta varias formas en que las implementaciones de RPA pueden fallar:

Sólo se abordó una parte del proceso: los procesos de adquisición a pago y de pedido a cobro son algunos de los procesos más complejos de una organización, ya que abarcan múltiples departamentos y stakeholders externos, e incluyen largas cadenas de tareas interdependientes. Abordar sólo una parte del proceso puede aportar algo de alivio, pero si hay cuellos de botella en otras partes del proceso, la mejora general puede ser mínima o inexistente. Un arreglo aislado en una parte del proceso puede incluso crear nuevos problemas o cuellos de botella en sentido ascendente o descendente.

La automatización se aplicó en un proceso incorrecto: este proceso implicaba facturas en papel, que pueden haber sido enviadas a la organización, ordenadas en la secretaría, pasadas al contacto del cliente, y tal vez perdidas por un tiempo en un desordenado escritorio antes de pasar físicamente a Cuentas. La automatización de la extracción de datos de esas facturas ha hecho muy poco para acelerar todo el ciclo P2P. El proceso completo debía replantearse antes de aplicar cualquier automatización.

Los KPI no estaban claros: los líderes de la organización sabían que había un problema, pero no pensaron bien en qué mejora querían ver. En lugar de especificar un resultado deseado y KPI medibles, sólo aplicaron la RPA como un apósito a una de las fuentes más visibles de la ineficiencia. Al dar un paso atrás y examinar todo el proceso, podrían haber señalado todas las ineficiencias, decidir cómo solucionarlas y calcular el ROI de cada arreglo antes de actuar.

El uso de herramientas ad-hoc hizo insostenible la automatización: el bot fue creado por una persona de finanzas que tenía curiosidad por la tecnología, usando una herramienta de RPA de baja codificación. El software pareció fácil de usar, pero ese conocimiento partió con ella cuando se fue. Esto no solo implica el mal funcionamiento del bot, sino también una oportunidad perdida de escalar el uso de la RPA para hacer frente a otras ineficiencias.

Faltaba una gestión permanente: debido a que el bot fue creado e implementado ad-hoc en lugar de como parte de una estrategia de automatización, nadie (y ningún sistema de supervisión) estaba atento a él, por lo que nadie podía prever que dejaría de funcionar debido a una actualización del sistema financiero.