Sin línea base no hay decisión fundada

¿El sistema nuevo mejoró las cosas? ¿La automatización ahorró tiempo?

Son preguntas que cualquier empresa debería poder contestar después de invertir en tecnología. Casi siempre la respuesta es una impresión: “anda mejor”, “el equipo está más contento”, “hay menos problemas”. Puede ser cierto. Pero no hay forma de compararlo con lo que había, porque nadie midió cómo estaban las cosas antes de empezar.

Y eso no afecta solo a la inversión que ya se hizo. Afecta a la siguiente: si no sé si lo anterior funcionó, tampoco sé si conviene seguir por ese camino, corregirlo o frenar.

Qué es una línea base

Una línea base son pocos números, con fuente y con fecha, tomados antes de cambiar algo. No requiere un tablero ni un proyecto aparte, y conviene que estén en el idioma del negocio, no en el del sistema. En una empresa sin área de sistemas pueden ser las horas que se van en tareas manuales o los días que lleva cerrar el mes. En una empresa de software, cuánto tarda un cambio en llegar a producción y cuántos errores aparecen después.

“Antes andaba mejor”

Hay una queja que aparece en casi todos los cambios de sistema, y la escuché más de una vez. Cuento dos.

Una fue en la migración de servidores de un sistema muy grande, con muchas bases de datos y sistemas hechos a medida. Se hizo sin que se perdiera un día de trabajo. Y aun así, apenas terminamos, algunos usuarios empezaron a decir que andaba más lento que antes. Algo de razón tenían: surgieron algunos problemas puntuales de conectividad, que se fueron ajustando. Pero no todo era eso, y no teníamos forma de saber qué parte era real y qué parte era sensación, porque nunca habíamos medido cuánto tardaba lo anterior.

La otra fue en una migración tecnológica. Apenas pasamos a los usuarios a la versión nueva, la mayoría quería volver a la anterior: algunas cosas llevaban más tiempo, otras no se podían hacer, y en general “el otro andaba mejor”, sin mucho más detalle. Ahí el tiempo ni siquiera era la pregunta correcta. Lo que importaba era si la operación funcionaba mejor, y tampoco teníamos con qué compararlo.

En los dos casos, no podíamos defender lo que había salido bien, ni encontrar rápido lo que había salido mal. Sin línea base, el pasado lo reescribe la memoria: lo de antes deja de ser lo que había, con sus problemas, y pasa a ser lo que se recuerda.

Lo que haría distinto hoy

Antes de tocar nada, le propondría al cliente medir juntos lo que el cambio tiene que mejorar, o al menos no empeorar. Y eso cambia en cada caso.

En la migración de servidores, el sistema era el mismo y la queja era que andaba más lento, así que hubiera medido el tiempo de los procesos críticos: los que, si se demoran o dejan de funcionar, frenan el trabajo. Cronometrados como los hace un usuario, de punta a punta, no solo lo que tarda el sistema en responder.

En la migración tecnológica, hubiera medido lo que la operación consume y produce: cuántas horas de trabajo lleva, cuántos reprocesos hay, cuánto se desperdicia, y qué otras tareas puede tomar el equipo con el tiempo que se libera. Un sistema nuevo tiene que mejorar algo que le importe al negocio: estos números, o el riesgo, el costo o la dependencia de un proveedor. Ser más nuevo no alcanza.

Con eso, cada queja tiene contra qué compararse. Lo que empeoró se arregla primero, y lo que es costumbre se acompaña con tiempo, sin discutir quién tiene razón.

Mejor, ¿comparado con qué?

Además, una vez que alguien dijo “antes andaba mejor”, sin un número lo va a seguir pensando, aunque se haya arreglado. La impresión dura más que el problema.

Para resolverlo, a la línea base le falta su otra mitad: un objetivo acordado, que diga cómo tiene que estar. Y ese objetivo depende del contexto y de la frecuencia: una venta en el punto de venta tiene que resolverse en segundos, con un cliente esperando; un reporte histórico o una exportación para una auditoría pueden tardar cinco minutos, porque se hacen pocas veces al año.

Una sin la otra no alcanza. Saber que el cierre del mes pasó de ocho días a cinco no dice si cinco está bien. Y saber que debería llevar tres no dice cuánto se mejoró.

Para que la medición sirva

• Pocos números. Tres a cinco. Con más, nadie los mira.
• Tomados antes del cambio, y medidos de la misma forma después, o la comparación no vale.
• En el idioma del negocio: cuánto tarda una tarea, cuántos reprocesos hay, cuántas horas lleva.
• Uno que no puede empeorar. Toda mejora necesita un número que diga qué mejoró y otro que vigile qué no se rompió. Bajar el tiempo y subir los errores, automatizar una tarea y multiplicar las excepciones manuales, o escribir código más rápido con IA y sumar correcciones, no es mejorar.

Medir para decidir

La línea base sirve para que la próxima decisión se tome sobre datos: qué se arregla, qué se reemplaza, qué se deja como está. Es el orden del método con el que trabajo, medir para decidir: primero se cuantifica, después se decide, y se vuelve a medir para saber si funcionó.

Y conviene tomarla antes de tocar nada. Después del cambio, lo de antes ya no se puede medir: solo se puede recordar.