Medir el ROI de la automatización sin sistema de registro
El ROI de una automatización es la diferencia entre lo que costaba el proceso antes y después, y los dos números tienen que salir del mismo lugar. Si el proceso vive en hojas de cálculo y mensajes, el "antes" no está registrado en ningún sitio. La automatización funciona y el retorno queda sin prueba. El primer paso es decidir dónde nace el dato.
¿Por qué el ROI de la automatización depende de un sistema de registro?
Porque el retorno es una comparación, y una comparación exige dos puntos medidos de la misma manera. El punto "después" casi siempre existe: la automatización corre, deja un log, cuenta ejecuciones. El punto "antes" solo existe si el proceso manual dejaba un registro estructurado. En la mayoría de las pymes, no lo dejaba.
Piensa en el proceso de cotejar pedidos contra el stock. Quien lo hace sabe que "lleva toda la mañana". Ese número nunca pasó por un sistema. Vive en la percepción de una persona, y la percepción cambia cuando cambia el proceso. Seis meses después de automatizar, nadie recuerda si eran tres horas o cinco, y la dirección pregunta si valió la pena.
Aquí el problema deja de ser de tecnología. La herramienta de automatización entrega lo que se configuró. Lo que falta es una decisión de arquitectura: en qué sistema registra el proceso lo que hace, antes y después de la automatización. Sin esa decisión, cualquier cálculo de ROI de automatización descansa en estimaciones hechas de memoria.
¿Qué dicen los datos sobre retorno y sobre sistemas?
Dicen que el retorno es más raro de lo que sugiere el entusiasmo y que la base de sistemas de la empresa media sigue siendo estrecha. Los dos hechos se conectan.
En la encuesta de Gartner, realizada en noviembre y diciembre de 2025 con 782 líderes de infraestructura y operaciones, solo el 28% de los casos de uso de IA cumplió por completo el retorno esperado, y el 20% fracasó por entero. Entre el 57% que reportó al menos un fallo, muchos dijeron haber esperado demasiado, demasiado rápido. Entre los factores asociados al éxito, el 33% señaló la integración en sistemas y procesos ya existentes. La muestra es de operaciones de TI y de IA, no de procesos de negocio de una pyme. Lo que la encuesta ofrece es un patrón: el retorno depende de que la iniciativa esté encajada donde la operación ya registra lo que hace.
Del lado de los sistemas, los datos de Eurostat sobre e-business de 2025, publicados en mayo de 2026, muestran el ERP como la aplicación más usada en la UE: 41% en las pequeñas empresas y 89% en las grandes, una brecha de 48 puntos porcentuales. Es decir, cerca de seis de cada diez pequeñas empresas europeas operan sin ERP. Eso no significa que operen sin software. Pero una suscripción por área produce datos en cinco lugares, y ninguno mide el proceso de punta a punta.
Las dos fuentes cubren universos distintos (TI corporativa y empresas de la UE por tamaño) y no deben sumarse. Leídas juntas, apuntan a la misma conclusión: la automatización llega a una operación cuyo "antes" casi nunca se midió.
¿Qué datos debe dejar un proceso antes de automatizarse?
Cinco, y ninguno exige un proyecto grande para existir.
El volumen es cuántas veces corre el proceso por semana. Sin volumen no sabes si la automatización atiende 50 casos o 5.000, y el payback cambia en un orden de magnitud.
El tiempo es lo que tarda cada ejecución de punta a punta, incluida la espera entre etapas. La espera suele pesar más que el trabajo en sí, y solo aparece cuando cada etapa registra cuándo empezó y cuándo terminó.
El error es la fracción de ejecuciones que vuelven para corrección. Es el dato más caro de reconstruir después, porque un error corregido en silencio no deja rastro.
El retrabajo es el tiempo gastado en esas correcciones. Separa la automatización que elimina el error de la que solo lo mueve de lugar.
El responsable es la persona que responde por el número. Un dato sin responsable es un dato que nadie actualiza.
Lo central es dónde nacen esos cinco datos. Si el registro depende de que alguien complete una hoja al final del día, falla justo en las semanas de pico, que son las que más importan. Un sistema interno registra como efecto colateral de que el proceso ocurra: entró el pedido, empezó el cotejo, se marcó el error. Es la lógica que sostiene, por ejemplo, el sistema de gestión ambiental de Reatop, donde el dato nace dentro del flujo de trabajo y no después.
Un ejemplo práctico: el retorno que nadie pudo probar
El escenario siguiente es hipotético y los números son supuestos ilustrativos, no mediciones. Una distribuidora con 90 empleados automatiza el cotejo de pedidos. El equipo dice que el proceso consumía "una mañana por día" de dos personas. El proyecto se aprueba con una meta informal de ahorrar 20 horas por semana.
Tres meses después, la automatización corre sin fallos y la dirección quiere el retorno. ¿Qué existe? Una estimación verbal de las 20 horas, dada por quienes vivían el proceso. Ningún registro de cuántos pedidos entraban por semana antes, de cuántos volvían con errores, de cuánto esperaba un pedido entre su llegada y el cotejo. La automatización redujo algo, pero nadie puede decir cuánto, y la pregunta "¿valió la inversión?" se vuelve un debate de percepciones.
Ahora el mismo proyecto con un paso previo. Durante cuatro semanas, antes de automatizar, los pedidos pasan por un registro simple que anota llegada, inicio y fin del cotejo, y errores marcados. Aunque el resultado sea modesto, es demostrable: la dirección ve el antes y el después con el mismo criterio. Y el registro revela algo que la estimación verbal escondía, por ejemplo que el mayor costo era la espera entre la llegada del pedido y el inicio del cotejo, no el cotejo en sí. La automatización se rediseña entonces para atacar la espera.
El cambio de orden es pequeño. Lo que altera es la calidad de la decisión sobre qué automatizar.
¿Cómo empezar sin detener la operación?
Empieza por el proceso que más quieres automatizar y pon el registro antes de la automatización, por un plazo corto y definido. Cuatro semanas suelen mostrar la variación entre semanas normales y de pico, pero ese plazo es una referencia de planificación, no una medición.
Después, decide dónde vivirá el registro. Una hoja compartida sirve para un experimento de un mes. Para ser la base del retorno, el dato tiene que estar en un sistema donde el proceso realmente ocurre, con campos obligatorios e historial. Es la lógica de cuándo reemplazar hojas de cálculo por software a medida: la hoja es el punto de partida del relevamiento, y el sistema es donde el retorno pasa a ser confiable.
El caso de SuperVida muestra este movimiento a otra escala. La red de tarjetas de beneficios de Maranhão, en Brasil, gestionaba contratos en una base improvisada en Airtable, y Yowpi migró la operación a un sistema a medida, con contratos, beneficiarios, vendedores y socios en un solo lugar. El caso de SuperVida no trae cifras de retorno, y este texto no las inventa. Lo que ilustra es la condición previa: con la operación en un único registro, cualquier automatización futura tiene dónde ser medida.
Preguntas frecuentes
Mi equipo está acostumbrado a las hojas de cálculo. ¿Eso dificulta medir el retorno?
No tiene por qué. Empieza con lo que el equipo ya usa y agrega solo los cinco datos mínimos, por un período corto. El objetivo es tener el "antes" registrado, no cambiar de herramienta el primer día. La migración a un sistema llega cuando la hoja empieza a fallar en el pico.
No sé si la automatización tiene retorno financiero. ¿Cómo saberlo antes de invertir?
Lo sabes midiendo antes. Con cuatro semanas de volumen, tiempo y error registrados, el costo del proceso actual se vuelve un número, y el retorno máximo posible de la automatización queda limitado por él. Si el costo del proceso es bajo, el payback no llega, y descubrirlo antes de contratar es un buen resultado.
No tengo un equipo calificado para implementarlo. ¿Se puede igualmente?
Sí, porque el registro mínimo no exige un equipo de tecnología: exige decidir qué cinco datos importan y quién responde por ellos. La parte técnica, cuando llega, puede hacerla un socio. La decisión sobre qué medir tiene que ser tuya, porque depende de conocer el proceso.
El siguiente paso
Si quieres saber en qué sistema debería registrar tu proceso lo que hace antes de automatizarse, el Diagnóstico de Arquitectura Operacional, una conversación de 30 minutos, es el lugar para empezar: habla con Yowpi.
Cases relacionados
¿Reconociste tu operación en este artículo?
Agenda el Diagnóstico de Arquitectura Operacional: 30 minutos para mapear dónde está el cuello de botella de tu operación. Sin propuesta en la primera conversación.
Agendar diagnóstico