Medir el ROI real de una automatización (no el prometido)

El ROI de una automatización se calcula dos veces. La primera, antes de implementar, con supuestos sobre cuánto tiempo se va a ahorrar, cuántos errores se van a eliminar y cuánto va a costar el proyecto. La segunda, después de operar, con datos reales.

La mayoría de los equipos solo hacen el primero. Y el problema no es que calculen el ROI esperado, es que lo tratan como si fuera el ROI real. Esa confusión tiene consecuencias: proyectos que se presentan como exitosos porque el sistema funciona, sin verificar si el retorno proyectado se cumplió.

Medir el ROI real no es un ejercicio académico. Es el mecanismo que permite saber si los supuestos con los que se priorizó el proyecto eran correctos, y si no lo eran, qué cambiar en la próxima decisión de inversión.

ROI esperado vs. ROI real

El ROI esperado es un modelo. Tiene supuestos explícitos o implícitos sobre el comportamiento del proceso, el volumen de transacciones y el costo de implementación. Esos supuestos pueden ser incorrectos, y casi siempre lo son en alguna medida.

Los supuestos más frecuentemente incorrectos son estos tres: el tiempo de ahorro por transacción (los procesos rara vez se eliminan completamente, se reducen), el costo de implementación (especialmente el tiempo interno del equipo que no se contabiliza como costo), y la frecuencia de excepciones (los casos que el sistema no puede resolver solo y requieren intervención humana).

El ROI real emerge cuando se miden esas tres variables con datos de operación real. La diferencia entre el modelo y los datos es lo que permite mejorar los siguientes proyectos.

🔍 El ROI real también depende de haber priorizado bien desde el inicio. Ve cómo se priorizan proyectos de automatización con criterio de ROI.

Tiempo, costos y errores: las tres variables que importan

La medición del ROI real se estructura alrededor de las mismas variables que se usaron para proyectarlo, pero ahora con datos en lugar de supuestos.

Tiempo: cuántas horas reales se dejaron de dedicar al proceso manual por período. Esa cifra tiene que compararse contra la proyección inicial. Si el ahorro fue menor, la causa puede ser que el proceso tenía más excepciones de las proyectadas, que el volumen fue diferente, o que el sistema requirió más intervención de la esperada.

Costos: el costo total del proyecto incluyendo implementación, integración, mantenimiento del sistema en producción y tiempo del equipo dedicado a operar y supervisar. Sin ese último componente, el costo está subestimado.

Errores: cuántos errores del proceso manual desaparecieron y cuántos no. Algunos errores son consecuencia directa del proceso manual y desaparecen con la automatización. Otros son consecuencia de los datos o de las reglas de negocio, y siguen existiendo aunque el proceso esté automatizado.

💡 Esas tres variables son la base del ROI real. El tiempo, el riesgo y la capacidad son las palancas que las mueven. Ve cómo el tiempo, el riesgo y la capacidad determinan el ROI de una automatización.

Ciclos de revisión: cuándo y cómo medir

El ROI real no se mide una sola vez. Se mide en ciclos porque el comportamiento del sistema cambia con el tiempo: el volumen fluctúa, el proceso evoluciona, el costo de mantenimiento se acumula.

El primer ciclo de medición debe ocurrir entre 30 y 60 días después del lanzamiento. En ese período, el sistema ya procesó suficiente volumen real para comparar contra los supuestos iniciales, pero todavía es temprano para hacer ajustes si la brecha entre el ROI esperado y el real es significativa.

Los ciclos siguientes se programan trimestralmente, o cuando hay cambios en el proceso o el volumen que afectan los supuestos del modelo original. Cada ciclo produce dos salidas: un reporte del ROI acumulado hasta ese momento, y una actualización del modelo que mejora la proyección del siguiente proyecto.

🎯 Un ciclo de revisión bien ejecutado no solo mide el pasado. Define mejor los supuestos del futuro.

Decidir el siguiente ciclo con datos reales

La medición del ROI real no termina en el reporte. Termina en una decisión.

Si el ROI real supera el proyectado, la pregunta es qué supuesto subestimó el retorno y si ese supuesto puede aplicarse a los siguientes proyectos del backlog. Si el ROI real es menor, la pregunta es si la brecha se cierra ajustando el sistema, si hay un problema en el diseño del proceso que la automatización no puede resolver, o si la priorización del proyecto fue incorrecta desde el inicio.

Esa última pregunta es la más incómoda y la más valiosa. Un proyecto que se ejecutó bien técnicamente pero no generó el retorno proyectado no es solo un problema de implementación. Es una señal de que el criterio de priorización necesita ajustarse.

APM cierra ese ciclo con la fase de revisión de ROI, que alimenta directamente la priorización del siguiente sprint. Ve cómo APM estructura la ejecución sin dependencia de personas clave.

📌 Escríbeme y conversamos sobre un proceso.