Cuando el ROI existe en papel, pero no en la operación

El business case fue aprobado. Los números eran sólidos. El ROI proyectado superaba el 200%. Seis meses después de la implementación, el proceso sigue tomando el mismo tiempo, el equipo creó alternativas manuales y nadie puede explicar exactamente por qué los ahorros nunca llegaron.

Este escenario es más común de lo que debería ser. Y el problema casi nunca está en el análisis original. El problema está en todo lo que ocurre entre la hoja de cálculo y la realidad.

Por qué fallan los business cases

Un business case se construye bajo supuestos controlados: un cierto volumen de casos, un cierto tiempo de ejecución, un cierto porcentaje de automatización. Esos supuestos son razonables en el momento de hacerlos. También son frágiles.

El volumen cambia. Las personas adaptan el proceso a su propia lógica. Aparecen casos excepcionales que no estaban en el modelo. La herramienta se comporta diferente en uso real que en el piloto. Y los ahorros esperados, que existían en papel, no se materializan porque la realidad no es una hoja de cálculo.

El business case no está equivocado. Está incompleto. Modela lo que debería pasar pero no anticipa cómo responderá la ejecución a la fricción. ⚠️

La brecha entre el diseño y la ejecución

Existe una brecha entre cómo se diseña un proceso y cómo corre en la práctica. Esa brecha tiene nombre en ingeniería industrial: se llama brecha de implementación. En proyectos de automatización, es el espacio donde se evapora el ROI esperado.

La brecha de implementación se produce por varios factores que convergen: falta de un dueño claro del proceso automatizado, casos excepcionales mal definidos, capacitación insuficiente para el equipo que usará la herramienta y ausencia de métricas que hagan visible la brecha en tiempo real.

Lo más dañino es que esta brecha suele ser invisible durante meses. La herramienta corre. Nadie dice que esté fallando. Pero los resultados no están. Y cuando alguien finalmente pregunta por qué, no hay una respuesta clara, solo una mezcla de 'todavía nos estamos adaptando' y 'el proceso era más complejo de lo esperado.'

Falta de adopción y seguimiento

Automatización sin adopción no es automatización. Es software corriendo en paralelo con un proceso manual que el equipo prefiere porque se siente más seguro, porque lo entiende o porque nadie los capacitó bien en el nuevo.

La adopción no es un problema de capacitación. Es un problema de diseño. Un proceso que le exige al equipo cambiar su comportamiento sin entender por qué, sin ver un beneficio inmediato y sin soporte claro, no va a ser adoptado, sin importar qué tan buena sea la herramienta.

El seguimiento es el otro ingrediente que falta. La mayoría de los proyectos de automatización tienen un lanzamiento pero no tienen una revisión sistemática a los 30, 60 o 90 días. Para cuando alguien mira los números, la brecha ya está establecida y normalizándose. 🌀

Indicadores mal definidos

'Funciona mejor' no es un indicador. 'El ciclo de aprobación bajó de 5 a 1.5 días' sí lo es.

Una de las causas más frecuentes de la brecha entre el ROI en papel y el ROI operativo es que las métricas de éxito nunca se definieron con suficiente precisión. Cuando no hay medición, no hay retroalimentación. Cuando no hay retroalimentación, no hay corrección. Y cuando no hay corrección, la desviación inicial se normaliza como el nuevo estándar.

Definir las métricas antes de la implementación, no después, es lo que permite detectar las desviaciones cuando todavía pueden corregirse.

👉 APM no es una metodología más: es el sistema que hace que la automatización funcione.

Cómo cerrar la brecha - gestión de proyectos de automatización

La brecha entre el ROI en papel y el ROI operativo es un problema de gestión, no uno técnico. La respuesta no es mejor software ni un análisis más sofisticado. Es aplicar gestión rigurosa de proyecto a cada iniciativa de automatización, desde el diagnóstico correcto del problema a resolver hasta la medición post-implementación.

En la práctica esto significa: definir un dueño claro del proceso, establecer métricas medibles antes de la primera línea de automatización, programar revisiones sistemáticas y tratar cada automatización como un proyecto vivo, no como una entrega puntual.

Las variables que generan esta brecha y cómo contemplarlas en el análisis se explican en detalle en el artículo sobre las variables que casi nadie incluye al calcular el ROI de automatización.

El ROI que existe en papel es una posibilidad, no una promesa. La diferencia entre los dos es la ejecución. Y la ejecución nunca se gestiona sola. ⏳