¿Robot o agente? Cómo priorizar qué automatizar

Cuando llego a una organización que quiere automatizar, casi siempre existe una lista. A veces en un Excel, a veces en la cabeza de alguien. Y casi siempre está ordenada por la variable equivocada: por quién la pidió más fuerte.

Esta nota es el método que uso para reordenarla. No tiene nada de sofisticado y justamente por eso funciona.

Tres preguntas antes de cualquier estimación

Para cada proceso candidato, sólo tres:

1. ¿Cuánto se repite? Veces por día, por semana o por mes, y cuántos minutos toma cada vez.
2. ¿Qué tan estable es? ¿Los sistemas cambian seguido? ¿Las reglas de negocio están escritas o viven en la experiencia de alguien?
3. ¿Qué tan variable es la entrada? ¿Llega siempre igual, o cada caso viene distinto?

Las dos primeras deciden si vale la pena automatizar. La tercera decide con qué.

El descubrimiento honesto

Antes de las preguntas hay un paso que suele pasarse por alto y es el que más tiempo ahorra: observar el proceso real.

Significa sentarse junto a quien ejecuta la tarea a diario y anotar cada excepción práctica: planillas paralelas o comentarios como “cuando pasa esto yo hago otra cosa”, detalles que casi nunca quedan reflejados en manuales ni diagramas oficiales.

Ese “ah, pero” es donde vive el 40% del esfuerzo del proyecto. Si no aparece en el descubrimiento, aparece en la UAT, y ahí ya cuesta cinco veces más.

Un proceso documentado y un proceso real casi nunca son el mismo proceso. Automatiza el real.

La matriz de decisión

Con la variabilidad de la entrada y la estabilidad de las reglas, se arma esto:

	Reglas estables	Reglas que cambian
Entrada uniforme	🤖 Robot RPA clásico. El caso ideal: rápido de construir, barato de mantener, predecible	⚙️ Robot + configuración externa. Saca las reglas del código a una tabla que negocio pueda editar
Entrada variable	🧠 Híbrido RPA + LLM. El modelo interpreta la entrada, el robot ejecuta con reglas fijas	🕸️ Agente autónomo. Cuando ni la entrada ni el camino son predecibles

Y una cuarta casilla que no está en la tabla pero debería: no automatizar. Si el proceso ocurre tres veces al mes, tarda diez minutos y cambia todos los trimestres, automatizarlo es un pasatiempo caro. Documéntalo bien y sigue adelante.

El cálculo que sí importa

El cálculo de horas ahorradas es el que se muestra en las presentaciones, pero rara vez es el que decide bien:

horas_al_año = (veces_al_mes × minutos_por_vez × 12) / 60

El problema es que trata todas las horas como iguales, y no lo son. Yo agrego tres factores que cambian el orden de la lista:

• Criticidad del error. Un proceso de bajo volumen donde un error cuesta una multa vale más que uno de alto volumen donde el error se corrige al día siguiente.
• Costo de mantención esperado. Un proceso sobre un sistema que cambia cada dos meses te va a costar el 30% del desarrollo cada año, para siempre.
• Desgaste humano. El proceso que todos odian tiene un retorno que no aparece en la planilla: la gente empieza a creer que la automatización sirve. Ese capital político es real y se gasta rápido si el primer proyecto falla.

Por dónde partir de verdad

Mi recomendación después de varios primeros proyectos, algunos buenos y otros que preferiría olvidar:

El primer proceso debe ser predecible. Alto volumen, reglas claras, sistema estable y bajo impacto si falla. Conviene priorizar una solución con alta probabilidad de éxito sobre una compleja pero riesgosa.

Un primer proyecto exitoso compra permiso para el segundo. Un primer proyecto ambicioso que se atrasa tres meses convence a toda la organización de que “eso de la automatización no funciona acá”, y esa idea toma años en desarmarse.

Señales de que un proceso no está listo

Aprendí a decir “todavía no” cuando aparece alguna de estas:

• Nadie puede explicar la regla completa. Si tres personas dan tres versiones distintas, primero hay que definir el proceso, no automatizarlo.
• El sistema está por cambiar. Automatizar sobre algo que muere en seis meses es tirar el trabajo.
• El volumen real no coincide con el declarado. Pide los datos: casi siempre son menos casos de los que la gente recuerda.
• Nadie del área quiere participar en las pruebas. Sin un dueño que valide, el robot llega a producción y nadie lo mira.

El entregable del descubrimiento

Cierro esta etapa con un documento corto que responde:

1. Qué hace el proceso hoy, paso a paso, incluidos los “ah, pero”.
2. Volumen real medido, no estimado.
3. Qué se automatiza, qué queda manual y por qué.
4. Qué pasa cuando falla cada paso.
5. Qué tipo de solución corresponde según la matriz.
6. Cómo se va a medir que funcionó.

Ese último punto es el que más se olvida y el único que permite decir, tres meses después, si el proyecto valió la pena o no.

---

El éxito de una iniciativa de automatización radica en priorizar procesos con reglas claras y beneficio tangible. Cuando la organización ve resultados estables desde la primera entrega, gana la confianza necesaria para abordar flujos de mayor complejidad sin acumular deuda técnica.