«Va bien» no es una medición (y el ahorro de la propuesta tampoco)
Hay una conversación que se repite en todas las empresas que automatizaron algo hace más de un semestre. Alguien pregunta si aquello está aportando. Se hace un silencio corto. Y contesta el que lo montó: «funciona, no da problemas». Eso es una respuesta sobre el estado del sistema, no sobre su rendimiento. Un flujo puede llevar seis meses sin caerse y estar procesando la mitad de casos que antes, con dos personas revisando cada salida por si acaso, y seguir contestando «va bien» a la única pregunta que se le hace.
El segundo comodín es peor porque parece un número: el «ahorro estimado» de la propuesta. Veinte horas al mes, decía la diapositiva. Ese número se calculó multiplicando un volumen supuesto por un tiempo unitario supuesto, antes de tener un solo dato real, y sin restar el trabajo nuevo que la automatización iba a crear —revisar excepciones, arreglar la integración del martes, explicarle el caso raro al sistema—. Es una hipótesis de compra, y su sitio está en la decisión de invertir, no en la evaluación de lo invertido. Una previsión no se convierte en medición porque pasen ocho meses.
La línea base: el único número que no puedes tomar después
Aquí está el error que arruina la medición de la mayoría de automatizaciones, y se comete antes de escribir la primera línea del flujo: nadie apuntó cómo iba el proceso antes. Sin ese «antes», todo lo que midas luego son cifras absolutas huérfanas. Procesas ochocientos casos al mes: ¿eso es bueno? No se sabe. Tardas cuatro horas por caso: ¿mejor o peor que en enero? Nadie lo recuerda con precisión, y la memoria de un equipo redondea siempre a favor de lo nuevo, porque lo nuevo lo montó alguien que está en la sala.
La línea base se toma con el proceso todavía a mano, durante dos o tres semanas, y no necesita instrumentación ninguna: una hoja de cálculo y el compromiso de rellenarla. Cinco columnas:
- Volumen. Cuántos casos entran por semana. Con la estacionalidad anotada si la hay: agosto no cuenta igual que octubre.
- Tiempo de punta a punta. Desde que el caso llega hasta que está cerrado, no el tiempo que alguien está tecleando. La diferencia entre las dos cifras —el tiempo que el caso pasa esperando en la bandeja de alguien— suele ser la mitad del total y es donde de verdad se gana.
- Manos que lo tocan. Cuántas personas distintas intervienen. Cada traspaso es un sitio donde el caso se para.
- Errores y rehechos. Cuántos casos hay que volver a hacer. Es la métrica que casi nadie apunta y la que más engaña luego: si automatizas un proceso que se rehacía el 15% de las veces y sigue rehaciéndose el 15%, no has mejorado la calidad, solo la velocidad.
- Casos raros. Cuántos se salen del camino normal y por qué. Esta columna es la que te va a decir, meses después, si las excepciones de tu automatización son las de siempre o unas nuevas que has creado tú.
Si ya desplegaste sin línea base —que es lo más probable, porque casi nadie la toma—, no te inventes el «antes». Reconstruirlo de memoria es peor que no tenerlo, porque produce un número con aspecto de dato que nadie va a volver a cuestionar. Lo honesto es escribir «no hay línea base» en el informe, empezar a medir desde hoy y usar el mes en curso como punto de partida: dentro de un trimestre tendrás comparación. Y si estás a tiempo, el orden correcto es al revés del que todo el mundo sigue: primero se mide el proceso, después se decide qué procesos automatizar, y solo entonces se monta.
Las cuatro métricas que importan
Con cuatro basta. No es minimalismo estético: un cuadro de doce indicadores no se mira, y el que no se mira no existe. Estas cuatro cubren las cuatro preguntas distintas que se le pueden hacer a un sistema en producción —cuánto hace solo, cuánto se atasca, cuánto libera de verdad y cuánto cuesta— y cada una tapa un agujero que las otras tres dejan abierto.
| Métrica | Qué contesta | Cada cuánto se mira |
|---|---|---|
| Porcentaje que pasa solo | De cada cien casos que entran, cuántos salen cerrados sin que toque nadie. Es la única que mide cuánto del proceso está de verdad automatizado. | Semanal |
| Excepciones por semana | Cuántos casos se salen del flujo y, sobre todo, de qué tipo. Distingue el sistema que aprende del que solo aguanta. | Semanal |
| Tiempo real ahorrado vs. prometido | Horas que ya no se hacen menos horas nuevas de revisión y mantenimiento, contra lo que decía la propuesta. Es el único sitio donde la promesa se enfrenta al dato. | Mensual |
| Coste por caso | Todo lo que cuesta el sistema —licencias, tokens, mantenimiento, tiempo humano restante— dividido entre los casos procesados. | Mensual |
El orden importa: las dos primeras son de operación y se leen en la reunión semanal; las dos últimas son de negocio y se llevan al comité. Mezclarlas produce el efecto de siempre —el comité discutiendo excepciones puntuales y el equipo técnico peleándose con una cifra de coste que no puede mover—.
Cómo se cuenta el «pasa solo» sin engañarte
La métrica de casos que pasan de punta a punta sin intervención no la hemos inventado nosotros: viene del mundo financiero, donde se lleva décadas midiendo el straight-through processing —la operación que se liquida sin intervención manual— y donde no es un indicador de vanidad, sino algo que se factura: los bancos cobran comisiones por los pagos que no pasan solos o repercuten el coste de la reparación manual a quien les manda instrucciones de mala calidad. La excepción tiene precio, y por eso allí nadie la esconde.
La trampa de esta métrica es el numerador, y casi todos caen en ella: cuenta como «pasa solo» únicamente el caso que se completa entero sin ninguna intervención humana. Un proceso con la entrada automatizada y la aprobación a mano no pasa solo: pasa la mitad. Si el flujo extrae los datos de la factura pero alguien tiene que darle a validar, eso es un caso asistido, no automático. Y si mides el porcentaje contando la parte automatizada del recorrido en vez de los casos cerrados, obtienes un 90% precioso que no se corresponde con la sensación de nadie que trabaje ahí —y esa disonancia entre la métrica y lo que ve el equipo es lo que mata la credibilidad de toda la medición—.
Las excepciones: la métrica que dice si el sistema mejora o solo aguanta
Si solo pudieras mirar un número cada semana, mira este. El porcentaje que pasa solo te dice dónde estás; las excepciones te dicen hacia dónde vas. Y el truco está en no quedarse en el total: veinte excepciones esta semana y veinte la semana pasada pueden ser dos situaciones opuestas según de qué tipo sean.
Clasifícalas en tres cubos, que son además los tres motivos por los que un caso se sale del camino automático —falta información, la información llega en un formato que la máquina no entiende, o el caso cae fuera de las reglas que se decidió automatizar—:
- Dato incompleto o sucio. El caso llega sin lo que hace falta. Esto casi nunca se arregla en la automatización: se arregla aguas arriba, en el formulario, en la plantilla o en el proveedor que manda mal el fichero. Si crece, tienes un problema de entrada disfrazado de problema de IA.
- Caso legítimo fuera de las reglas. El sistema hace bien en no tocarlo: es una devolución fuera de plazo, un importe por encima del límite, un cliente con condiciones especiales. Estas excepciones no deberían bajar a cero. Son el diseño funcionando.
- Fallo del sistema. La integración se cayó, el modelo devolvió algo que no vale, el flujo se quedó a medias. Estas son las únicas que cuentan como deuda: cada una debería tener nombre, causa y arreglo, y no debería aparecer dos veces la misma. Detectarlas a tiempo es otro asunto y tiene su propia mecánica en detectar fallos en automatizaciones con IA.
La lectura es directa. Si el cubo tres baja y el dos se mantiene, el sistema está madurando: has ido cerrando fallos y lo que queda es la frontera que decidiste no cruzar. Si el cubo tres se mantiene plano mes tras mes, el sistema no está mejorando —está aguantando, y alguien está pagando ese aguante en tiempo—. Y si el cubo uno crece, el problema no está en tu automatización: está en quien te manda los datos.
Aquí es donde aparece el gasto que nunca se presupuesta: el tiempo de gestionar excepciones. Es trabajo nuevo, creado por la automatización, que hace alguien que antes no lo hacía. Si no lo cuentas, tu ahorro es ficción; y si lo cuentas, muchas veces descubres que la mitad del ahorro prometido se lo come la cola de casos raros. Contarlo es lo que convierte una medición en una medición.
Afinar, rehacer o retirar: el criterio para decidir
Medir sin un criterio de decisión previo es coleccionar cifras. El criterio hay que escribirlo antes de mirar los números —si no, el número se interpreta a favor de lo que ya se había decidido— y solo tiene tres salidas.
| Qué ves | Qué significa | Qué haces |
|---|---|---|
| El porcentaje que pasa solo es razonable y las excepciones son casi todas del cubo 2 (fuera de reglas). | El sistema está haciendo su trabajo y la frontera está bien puesta. | Afinar. Ampliar reglas caso a caso solo si el volumen de ese tipo justifica el trabajo. Cambios pequeños y probados. |
| El cubo 3 (fallos) no baja en tres meses y siempre por el mismo sitio. | No es un bug: es un problema de diseño del flujo. Parchear más va a durar otro trimestre. | Rehacer esa parte. Un rediseño acotado sale más barato que doce parches, y se hace con red: ver probar cambios sin romper la automatización. |
| El volumen del proceso cayó, o el mantenimiento cuesta más horas de las que ahorra, o las excepciones superan a los casos automáticos varias semanas seguidas. | Lo que tienes es un proceso manual con un paso automático que estorba y sigue consumiendo licencias, avisos y atención. | Retirar. Apagarlo y documentar por qué. Es la salida que menos se usa y la que más dinero recupera. |
La tercera fila es la incómoda. Apagar una automatización se vive como admitir que no valía, así que el flujo se queda encendido «por si acaso» y pasa a engrosar el censo de automatizaciones zombis: las que corren, cuestan y no le sirven ya a nadie. Retirar a tiempo no es un fracaso del proyecto —es la única prueba de que la medición sirve para algo, porque una medición que solo puede confirmar decisiones anteriores no es una medición, es una ceremonia—.
Cómo montar la medición esta semana
Nada de lo anterior necesita herramienta nueva. En una tarde, y en este orden: define qué cuenta como «caso cerrado sin intervención» y escríbelo, porque esa definición es el 80% de la fiabilidad de todo lo demás; saca del historial de ejecuciones los casos de las últimas cuatro semanas y clasifícalos en pasó solo / excepción, con la excepción etiquetada en los tres cubos; apunta durante un mes el tiempo que el equipo dedica a excepciones y a mantenimiento, aunque sea a ojo, porque es el lado que nadie tiene; y monta el coste por caso con la factura real, no con la estimada. Cuatro números, una hoja, quince minutos cada lunes.
Y una advertencia sobre el ritmo: la medición semanal es para operar, no para juzgar. Una semana mala no significa nada —entró un lote raro, hubo una caída, se fue de vacaciones quien resolvía—. La decisión de afinar, rehacer o retirar se toma con tres meses de datos delante, nunca con una gráfica de siete días. Esa disciplina de mirar seguido y decidir despacio es, de hecho, la mitad del mantenimiento de una automatización: la otra mitad es hacer algo con lo que la medición te dice.
La frontera honesta: esto está escrito para quien tiene unos cuantos flujos y una hoja de cálculo. Cuando lo que hay debajo son agentes decidiendo en vivo, con coste por token que se dispara sin avisar y calidad que se degrada en silencio, la medición deja de ser una hoja semanal y pasa a ser instrumentación con trazas y alertas: eso es monitorizar la IA en producción. Y si lo que quieres es que la línea base, las cuatro métricas y la revisión trimestral queden montadas sobre tus flujos actuales y las lleve alguien que no eres tú, eso es automatización de operaciones: el número, cada mes, sin que tengas que acordarte de pedirlo.