Errores comunes al implementar RPA (y cómo evitarlos)

Casi todos los proyectos de RPA que terminan mal tienen un robot bien construido adentro. Suena raro, pero es así: la parte de escribir el robot casi nunca es el problema. Lo que falla es lo que lo rodea, y buena parte de eso se decidió antes de que alguien escribiera el primer comando.

Van los errores que más veces vemos en empresas de Chile y Argentina, con lo que conviene hacer en cada caso. No están ordenados por gravedad, sino más o menos en el orden en que aparecen a lo largo de un proyecto.

El primer robot no debería ser el proceso estrella

Cuando una empresa se decide, la tentación es arrancar por el proceso que más duele, el que hace ruido en las reuniones. Y ese suele ser el más caótico: el que tiene cincuenta excepciones y cambia de forma cada tanto. Un mal candidato para estrenar.

Para un primer proyecto conviene algo estable y hasta aburrido, una tarea que se hace igual todas las semanas desde hace un año y que nadie planea cambiar. Ese robot funciona, muestra el retorno rápido y compra la confianza que después vas a necesitar para los procesos difíciles. El camino contrario (empezar por el más complicado, que se rompa a los dos meses, y que la dirección concluya que "el RPA no sirve") lo vimos suficientes veces como para insistir con el orden.

Automatizar algo que todavía cambia todas las semanas

Este lo repetimos hasta el cansancio con los clientes y aun así reaparece. Cuando el proceso cambia de forma cada dos o tres semanas porque el negocio todavía está ajustando cómo lo hace, el robot se convierte en algo que hay que reconfigurar sin parar. El mantenimiento se termina comiendo el ahorro.

Hay una prueba rápida para saber si un proceso está listo: intenta escribir sus pasos exactos en una sola página. Si en cada línea aparece un "depende", el proceso todavía se está cocinando. Primero se documenta, se lo deja correr así un par de meses, y recién cuando deja de moverse se automatiza. Cuándo frenar es parte del trabajo, y lo tratamos aparte en cuándo conviene y cuándo no automatizar en una pyme.

El robot que se construye sin documentar las excepciones

Hay una idea instalada de que el desarrollador va a "entender el proceso mirándolo". A veces alcanza con eso. El problema son las excepciones, y todo proceso las tiene: qué hace la persona cuando el sistema tira un error, cuándo un registro se saltea, qué campo a veces viene vacío y por qué. Esas cosas viven en la cabeza de quien hace la tarea a mano, no en la pantalla que el desarrollador observa.

Un robot construido sin esa información cubre bien los casos normales y se traba justo en los raros, que son los que nadie mencionó en la reunión. Documentar acá no significa escribir un manual de cincuenta páginas. Significa anotar los pasos y, sobre todo, las tres o cuatro rarezas que pasan de vez en cuando. Ahí está escondida buena parte del valor del robot.

Qué pasa el día que el robot falla

Un robot va a fallar en algún momento. El sistema de destino se cae, cambia una pantalla, se corta la conexión a mitad de ejecución. Dar por hecho que eso no va a ocurrir es el error más caro que vemos, y también el más invisible, porque no se nota hasta que ya pasó.

En los robots que armamos con Rocketbot, cada paso crítico va envuelto en control de errores. Cuando algo se rompe, el robot registra en un log qué estaba haciendo, saca una captura de pantalla del momento exacto y avisa a un responsable, en lugar de quedarse colgado en silencio. Un robot sin esto y uno con esto se ven idénticos en la demo, porque el día que todo sale bien hacen exactamente lo mismo. Se diferencian el día que algo se rompe: en un caso alguien recibe el aviso y en dos minutos sabe qué pasó mirando la captura; en el otro, el robot puede estar frenado desde el jueves y nadie enterarse hasta que el área contable pregunta por qué no entraron las facturas. Y a esa altura ya no hay forma de agregarle el control de errores hacia atrás. Esa capa de monitoreo la resolvemos con Robotipy Monitor.

Nadie a cargo después de la entrega

Un robot no es un electrodoméstico que se instala y se olvida. Necesita que alguien revise cada tanto que corrió, lea el reporte de ejecución y avise si algo se ve raro. Cuando ese rol no está asignado, el robot corre solo hasta que un cambio en el sistema lo rompe, y como nadie lo miraba, puede pasar semanas roto sin que se note.

Para esto no hace falta contratar a un desarrollador. Alcanza con una persona de operaciones que sepa leer un reporte y a quién avisar. Lo que sí importa es que ese rol exista antes de la entrega y no se improvise el día del primer error.

Credenciales y rutas escritas dentro del robot

Un error más técnico pero muy frecuente en robots hechos con apuro: dejar contraseñas, usuarios y rutas de carpetas escritas directamente en el código del robot. El día que el sistema obliga a cambiar la contraseña, o que se mueve una carpeta de lugar, hay que abrir el robot para arreglarlo. Y si esa contraseña quedó en un archivo que cualquiera puede abrir, el problema ya no es solo de mantenimiento.

Todo eso va en un archivo de configuración aparte, fuera del robot, donde se cambia sin tocar una línea de código. Es una convención básica del oficio y aun así se saltea seguido cuando se cotiza barato y rápido.

Sin medición previa, el ROI es una opinión

Si arrancas el proyecto sin registrar cuánto tardaba el proceso a mano y con qué frecuencia se hacía, después no vas a poder demostrar que el robot valió la pena. "Ahora es más rápido" no le mueve la aguja a nadie que tenga que firmar el presupuesto del año que viene.

La medición se hace antes de tocar nada: horas por semana, errores por mes, cuánto se reprocesaba. Con esos números el retorno se calcula solo, y el proyecto siguiente se justifica en una reunión de diez minutos. Sin ellos, cada nueva automatización arranca de cero peleando por su presupuesto. Lo desarrollamos en cuánto cuesta automatizar un proceso y cómo calcular el retorno.

Por qué a un mal partner le conviene que caigas en estos errores

Vale decirlo aunque incomode. Varios de estos errores le convienen económicamente a quien te vende el proyecto. Un diagnóstico apurado que no documenta las excepciones sale más barato de hacer y deriva en horas de mantenimiento que se facturan después. Un contrato que no dice qué pasa cuando el proceso cambia deja esa conversación para cuando ya perdiste el margen para negarte a un precio inflado.

Que un partner insista en documentar bien y en dejar el control de errores armado desde el arranque, aunque eso encarezca la primera cotización, dice más de sus intenciones que cualquier caso de éxito de la landing page. Está apostando a que el robot dure. Un proveedor al que le conviene volver a cobrarte en tres meses no te va a pedir ese trabajo extra al principio.

Preguntas frecuentes

Danilo Toro, fundador de Robotipy, desarrolló Rocketbot durante seis años antes de fundar la consultora, y hoy ayuda a empresas en Chile y Argentina a implementar automatizaciones que duren, no que haya que rehacer cada trimestre.