Sin línea base, ninguna automatización puede probar que ahorró tiempo

Alguien pregunta en el comité de gerencia cuánto tiempo ahorró la automatización que se implementó hace seis meses. La respuesta suele ser una sensación: "se siente más rápido", "el equipo dice que ya no hace ese trabajo manual". Nadie tiene un número que comparar contra otro número. Esa escena se repite en empresas que automatizaron bien la tecnología y mal la evidencia: puede que el proceso efectivamente haya mejorado, pero no hay forma de probarlo, y sin prueba no hay forma de justificar la inversión ni de decidir si conviene escalarla a otros procesos.

Medir antes no es el paso lento, es el que hace posible comparar

La tentación al automatizar es saltarse la medición previa porque parece burocracia: todos quieren ver la herramienta funcionando, nadie quiere pasar semanas cronometrando un proceso manual que ya se sabe que es lento. Pero esa medición previa —tiempo que toma cada paso, costo asociado, tasa de error del proceso tal como está hoy— es la única variable de control que existe. Sin ella, cualquier cambio posterior queda sin referencia: no hay contra qué compararlo.

La documentación de sistemas comerciales de gestión de procesos formaliza esto de manera explícita. Los métodos que la industria registra para evaluar automatización describen un orden fijo: primero se cuantifica una línea base del proceso —un indicador clave de desempeño y una medida de la complejidad subyacente—, después se mide la mejora lograda por la herramienta, y solo entonces se puede estimar el valor generado. Si el primer paso no existe, los dos siguientes pierden sustento: no hay mejora que medir si no hay punto de partida.

Sin línea base, cualquier resultado se explica por otra cosa

Acá está el problema real, no el metodológico sino el operativo: cuando el proceso automatizado falla o mejora, nadie puede atribuirlo con certeza a la automatización. Pudo ser la automatización, pero también pudo ser un cambio de temporada, la salida de una persona con más experiencia, un ajuste en el volumen de trabajo, o simplemente que el equipo empezó a prestarle más atención al proceso porque ahora está bajo revisión. Sin una línea base documentada, todas esas explicaciones son igual de válidas, y la empresa queda sin argumento para defender la inversión ni para descartarla.

Un estudio de minería de procesos aplicado a la evaluación de automatización robótica de tareas repetitivas ilustra este punto con precisión metodológica: antes de decidir si una actividad era apta para automatizarse, se midió su tasa de fallo actual, identificando qué proporción de casos requería reprocesamiento y qué proporción terminaba en eliminación del ítem original. La conclusión del propio estudio es la que sostiene la tesis de este artículo: sin poder evaluar cómo se comporta el proceso hoy, no se puede evaluar si automatizarlo tiene sentido. No es un matiz técnico, es la condición mínima para tomar la decisión.

Un caso de mejora hospitalaria bajo metodología DMAIC muestra el mismo principio desde el resultado. Se documentó la estancia hospitalaria antes de intervenir —un valor medio con su variabilidad— y después de aplicar los cambios se pudo cuantificar exactamente cuánto se redujo. Esa reducción solo es demostrable porque el número de partida quedó registrado. Si el hospital hubiera intervenido sin medir antes, el resultado final habría sido el mismo, pero la posibilidad de probarlo, no.

Qué debe registrar una línea base para servir de verdad

No cualquier número sirve de línea base. La misma documentación de sistemas de monitoreo de indicadores para automatización advierte que no todos los KPI son igual de útiles para juzgar impacto: solo sirven los que son cuantificables, están efectivamente medidos antes de intervenir, son confiables y están alineados con la decisión que se quiere tomar. Un indicador impreciso, estimado de memoria o registrado de forma inconsistente no funciona como línea base, aunque exista en papel.

Un protocolo académico para automatización auditable propone un orden concreto que cualquier empresa puede adaptar sin depender de herramientas sofisticadas: extraer los datos de línea base del proceso actual, verificar su calidad —que los tiempos estén completos, que no haya eventos faltantes, que la forma de registrar no haya cambiado a mitad de camino— y, si esas verificaciones muestran huecos importantes, tratar esos huecos como el primer problema a resolver antes de automatizar cualquier cosa. El mismo protocolo exige fijar, antes de intervenir, qué tamaño de cambio se considerará una mejora real y cuántas observaciones se necesitan para confiar en el resultado. Ese acuerdo se cierra con las partes interesadas antes de tocar el proceso, no después de ver los primeros resultados.

Un caso de laboratorios clínicos que buscaban aumentar la proporción de resultados verificados automáticamente sigue el mismo orden: la meta y el punto de partida se fijaron en la fase de medición, antes de rediseñar el proceso. Ese orden es el que permite después decir con precisión cuánto se avanzó, no solo que "mejoró".

La revisión de esta semana: ¿qué automatizaste sin saber cuánto costaba antes?

Esta semana vale la pena revisar cada automatización activa en tu empresa y hacer una pregunta simple para cada una: ¿existe un registro de cuánto tiempo tomaba, cuánto costaba y qué tasa de error tenía este proceso antes de automatizarlo? Si la respuesta es no, esa automatización puede estar funcionando perfectamente bien y aun así ser indefendible ante cualquier pregunta seria sobre su valor.

No se trata de deshacer lo ya implementado. Se trata de decidir, desde ahora, que ninguna automatización nueva avanza sin que antes quede registrado el estado del proceso que se va a reemplazar. Ese registro es barato comparado con el costo de no poder responder, dentro de seis meses, la pregunta que alguien en el comité seguramente va a hacer.