Por Danilo Toro, Fundador de Robotipy
Cuándo NO conviene automatizar un proceso
Cuándo no conviene automatizar un proceso: las señales que nos llevan a recomendar no construir un robot y qué alternativas revisar antes de invertir.
De cada diez procesos que nos piden cotizar, dos o tres terminan con la recomendación de no automatizarlos. Casi todos se podían construir y el robot habría funcionado bien, pero iba a resolver algo que no convenía resolver de esa manera. En los artículos sobre RPA se habla poco de esto, porque un proyecto descartado no se factura.
Lo escribo igual porque, cuando la decisión es mala, el cliente paga dos veces: primero al construir el robot y después al mantenerlo durante tres años.
El proceso cambia con frecuencia
Alguien explica la tarea y, a mitad de la explicación, dice "bueno, ahora lo hacemos así, antes era distinto". Esa frase indica que el proceso no está listo. Si cambió de forma dos veces en el último trimestre, todavía es un borrador.
Un robot RPA depende de la mecánica exacta del proceso, es decir, en qué pantalla y en qué orden se completa cada campo. Si eso cambia, el robot deja de servir y hay que pagar para reconfigurarlo. Con cambios cada seis semanas, el mantenimiento se come el ahorro antes de que termine el primer año.
El contenido, en cambio, puede variar sin problema. Pasar de 300 facturas un mes a 900 al siguiente no afecta al robot. Si el próximo mes esas facturas se cargan en otro sistema, hay que rehacerlo.
El volumen es demasiado bajo
Hay tareas que la persona a cargo odia, porque son tediosas y es fácil equivocarse, y que aun así no justifican un desarrollo. Un proceso mensual de veinte registros ocupa quizás dos horas al año de alguien. El desarrollo cuesta lo mismo si el robot se ejecuta veinte veces o veinte mil, así que con ese volumen la inversión no se recupera.
Esa cuenta conviene hacerla antes de empezar, y la detallamos en cuánto cuesta automatizar un proceso. En la primera reunión uso un criterio más rápido. Si el proceso no ocupa al menos varias horas semanales de alguien, o no evita un error que sale caro cuando ocurre, los números no van a cuadrar por buena que sea la solución.
Antes de descartar un proceso por pequeño, pregunta si se hace en más de un lugar. A veces un volumen bajo esconde uno alto. Cuatro personas en cuatro sucursales que dedican "un ratito" a la misma carga pueden sumar una jornada completa por semana, y nadie lo nota porque el trabajo está repartido.
Hay una alternativa más barata que un robot
Si el sistema que hay que operar tiene una API documentada, un robot que simula clics resulta más lento y más frágil que una integración directa o un flujo en n8n, y por eso cuesta más mantenerlo. Revisa también si el proveedor del software ofrece una función de importación masiva. Es común que esa función exista y que nadie en la empresa la conozca.
Otro caso es el trabajo que consiste en leer documentos desordenados y decidir con criterio qué hacer con cada uno. Ahí un agente de IA rinde mucho mejor que un robot RPA tradicional, que no está pensado para eso. Lo comparamos en detalle en RPA vs IA Agéntica.
RPA conviene cuando el sistema no tiene API, su interfaz cambia poco y el proceso se repite muchas veces de la misma forma. Si tu caso no cumple esas condiciones, revisa las otras vías antes de firmar.
La tarea depende del criterio de una persona
"Revisa la solicitud y aprueba si está todo bien." Dicho así en una reunión, suena automatizable.
Pide a quien hace la tarea que escriba las reglas exactas detrás de ese "está todo bien". Si logra armar una lista cerrada, el proceso se puede automatizar. Cuando contesta "depende, uno ya sabe", tienes a una persona con veinte años de oficio y ninguna regla escrita.
En ese caso, automatizar es prematuro. Primero hay que documentar el criterio y convertirlo en reglas, y solo con ese trabajo terminado se empieza a construir. Al documentarlo, lo habitual es descubrir que cerca del 80% de los casos se resuelve con reglas y que el 20% restante requiere juicio. El robot toma ese 80% y deriva el resto a la persona.
El proceso no debería existir
Pasa con un reporte semanal que nadie abre hace un año, con una doble carga que existe porque dos áreas nunca acordaron qué sistema manda o con una conciliación manual que empezó el día que alguien desactivó una integración y nadie la volvió a activar.
Automatizar cualquiera de ellos funciona en lo técnico. El robot libera horas y el ROI cuadra en la hoja de cálculo. Aun así, la empresa gastó presupuesto en conservar un problema que podía eliminar, y ahora además tiene un robot que mantener.
Para detectarlo, pregunta por qué existe el proceso. Cuando la respuesta empieza con "porque en su momento...", conviene confirmar que todavía hace falta antes de cotizar nada.
No hay un responsable del robot en operaciones
Un robot en producción necesita un dueño en operaciones, alguien que revise el reporte de ejecución, avise cuando algo se ve raro y sepa a quién llamar. Esa persona no necesita saber programar ni ser de TI. Por eso pregunto quién va a cumplir ese rol antes de escribir la primera línea de código. Si la respuesta es un silencio o un "ya veremos", lo más probable es que el robot termine abandonado.
El abandono es gradual. El robot falla una vez sin que nadie lo note y alguien hace la tarea a mano ese día. Tres meses después, el proceso volvió a ser manual, aunque el robot sigue apareciendo en el presupuesto.
Qué hacemos cuando recomendamos no automatizar
Cuando descartamos un proceso, seguimos con el resto de los candidatos. En casi todos los diagnósticos donde dijimos que no a uno, había otro en la misma lista que sí se justificaba y que el cliente no había considerado porque no era el que más ruido hacía. Encontrar ese otro candidato es la parte útil del diagnóstico, y por eso no lo cobramos.
Decir que no a veces nos cuesta la cotización original. Lo preferimos a entregar un robot que en dos años sea el ejemplo interno de por qué la automatización "no funcionó aquí".
Si estás armando tu lista de candidatos, en cómo priorizar qué procesos automatizar primero explicamos en qué orden revisarlos. Los tropiezos más repetidos están en errores comunes al implementar RPA.
