ROI de automatización RPA: cómo se calcula realmente.

Un proyecto de software clásico —migrar un ERP, implementar un CRM, lanzar una app— suele justificarse con retorno indirecto: mejores decisiones, mejor experiencia, mejor agilidad. Cuando se pide ROI duro, los números se construyen con asunciones difíciles de auditar.

RPA es otra cosa. La automatización de un proceso operativo tiene retorno medible y específico: tantas horas que dejaron de invertirse, tantos errores que dejaron de producirse, tantas operaciones más por ventana de tiempo. Cuando alguien dice "no sé si esto da ROI", normalmente significa que no se ha hecho el cálculo bien, no que el retorno no exista.

El problema con la mayoría de los Business Cases de RPA no es que sobreestimen — es que simplifican demasiado. Cuentan horas ahorradas y se olvidan del coste de mantenimiento. O calculan ahorro a sueldo bruto y se olvidan de cargas sociales. O ignoran el coste de la infraestructura. El resultado es un número que parece atractivo pero no sobrevive a la primera revisión seria.

Un Business Case honesto suma cuatro categorías de beneficio. No todas aplican a todos los procesos, pero todas hay que considerarlas explícitamente:

1. Horas operativas liberadas

El componente más obvio. Tiempo que un humano dejaba en un proceso repetitivo y ahora invierte en otro. Cálculo: horas/mes × coste totalmente cargado por hora (sueldo + cargas sociales + costes indirectos). Asume que esas horas se reasignan a actividad de mayor valor —si las personas siguen igual de ocupadas haciendo lo mismo, el ahorro es teórico.

2. Reducción de errores y retrabajo

El robot no se distrae a las 4 de la tarde. En procesos con tasa de error humano del 2-5%, automatizar reduce esa tasa típicamente a menos del 0.5% en estado estable. Cada error evitado tiene coste asociado: tiempo de corrección, llamada al cliente, intereses de mora, sanción regulatoria, retrabajo contable. El cálculo se hace tomando volumen × tasa de error baseline × coste promedio por error.

3. Throughput adicional

El robot opera fuera de horario, en paralelo, sin colas. Procesos que antes se ejecutaban en lote nocturno ahora pueden correr en tiempo casi-real. Eso se traduce en métricas operativas concretas: tickets resueltos antes, facturas emitidas en el día, clientes atendidos en SLA. La conversión a dinero depende del proceso pero es real.

4. Mitigación de riesgo regulatorio o reputacional

El componente más difícil de cuantificar pero el más importante en sectores regulados. Un proceso bien automatizado reduce probabilidad de hallazgos en auditoría, sanciones administrativas y eventos reputacionales. La estimación se hace en términos probabilísticos: probabilidad anual del evento × coste esperado del evento × reducción atribuible a la automatización. Conservador, pero defendible.

El denominador del ROI no es solo el coste del proyecto inicial. Hay tres categorías de coste que aparecen y que muchos cálculos ignoran:

• Coste de implementación: licencias de plataforma RPA, desarrollo, integración con sistemas existentes, pruebas, despliegue. Es el más visible y normalmente está bien dimensionado.
• Coste de operación continua: mantenimiento del robot, monitoring, gestión de excepciones, evolución cuando cambian sistemas o regulación. Regla de pulgar realista: el coste anual de mantenimiento ronda el 15-25% del coste de implementación inicial. Si tu Business Case lo ignora, sobreestima el retorno.
• Coste de infraestructura: servidor del orquestador, máquinas para los runners, almacenamiento de logs y evidencias, ancho de banda. En cloud el modelo es OpEx; on-premise se amortiza. En ambos casos, no es cero.

La fórmula honesta queda así:

ROI anual = (horas liberadas + errores evitados + throughput valorado + riesgo mitigado) ÷ (implementación amortizada a 3 años + operación anual + infra anual)

Y antes de defender ese número en un comité, vale la pena bajar el numerador un 20% por incertidumbre y subir el denominador un 15% por sobrecostos. Si el ROI sigue siendo positivo con ese ajuste, el caso es defendible.

Como referencia de viabilidad —no como promesa para ningún proyecto específico—, los rangos típicos reportados en la literatura de mercado RPA (análisis de Gartner, Everest Group, IDC y EY, entre otros) suelen ubicarse en estos órdenes de magnitud:

• Reducción de tiempo en procesos automatizados: 30-70% del tiempo previo, dependiendo de la madurez del proceso de origen y del grado de automatización aplicable.
• Mejora en calidad / reducción de errores: caída de la tasa de error del orden de 80-95% para procesos repetitivos bien delimitados.
• Tiempo a valor (payback period): 6-18 meses para procesos prioritarios, dependiendo del volumen y de la complejidad de integración.
• ROI a 3 años: típicamente 2x-5x sobre la inversión total, descontando ya operación e infraestructura.

Estos rangos son de referencia, no garantía. El número real para tu proceso depende del volumen actual, del coste totalmente cargado del personal involucrado, de la tasa de error baseline, del estado del legacy y del coste regulatorio del proceso. Por eso el Business Case se construye con tus datos, no con benchmarks ajenos.

Cuando un Business Case se cae en el comité, suele ser por una de estas seis razones. Todas son evitables:

1. Contar horas a sueldo bruto, no totalmente cargado. El coste real de una hora de empleado incluye cargas sociales, beneficios y costes indirectos. Saltar este ajuste infla el ahorro un 30-50%.
2. Asumir reasignación inmediata del tiempo liberado. Si el equipo no tiene actividad de mayor valor a la que dedicar las horas liberadas, el ahorro es contable pero no real.
3. Ignorar el coste de mantenimiento evolutivo. El robot se mantiene. Cuando el sistema origen actualiza su UI, hay que ajustar selectores. Cuando cambia regulación, hay que ajustar reglas. Sin presupuesto para esto, el robot se rompe en el primer cambio externo.
4. Estimar throughput sin verificar capacidad downstream. Si automatizas el cuello de botella pero el siguiente paso del proceso sigue manual, el throughput total no mejora — solo cambias el lugar del cuello.
5. Cuantificar mitigación de riesgo sin baseline. "Reduciríamos sanciones" no es estimación: es deseo. Hay que tener histórico de hallazgos, frecuencia y coste antes de cuantificar reducción.
6. Olvidar la curva de adopción. Los primeros 60-90 días post go-live son híbridos: el equipo todavía supervisa, hay excepciones que se ajustan, hay tuning. El ahorro completo llega en estado estable, no el primer día.

Antes de presentar un cálculo de ROI ante un comité de inversión o ante un sponsor exigente, los siguientes elementos definen si el caso va a sobrevivir el cuestionamiento:

1. ¿Tienes baseline real de volumen mensual, horas dedicadas y tasa de error del proceso actual? Sin baseline, todo es proyección.
2. ¿El cálculo de horas liberadas usa coste totalmente cargado, no sueldo bruto?
3. ¿Has incluido 15-25% del coste inicial como operación anual en el denominador?
4. ¿Has aplicado haircut conservador al numerador (-20%) y aumento al denominador (+15%) para defender el caso ante escenarios pesimistas?
5. ¿La cuantificación del riesgo regulatorio está respaldada por histórico real, no por estimación abstracta?
6. ¿Hay plan explícito para reasignar el tiempo liberado, o asumes ahorro contable sin reasignación?
7. ¿Has incluido curva de adopción de 60-90 días donde el ahorro es parcial?

Si los siete puntos están cubiertos con datos, el Business Case es defendible. Si alguno se completa con asunción optimista, sabes dónde el comité va a presionar — y mejor preparar la respuesta antes que improvisar en la reunión.