Revisar una lista de materiales pasó de media tarde a un minuto

El punto de partida

Cada simulador que sale de fábrica lleva detrás una lista de materiales: cientos de líneas con su referencia, cantidad, grupo y descripción. Antes de lanzar compras, alguien tiene que contrastar esa lista, línea a línea, contra el catálogo maestro de la empresa —más de seis mil referencias— para detectar piezas obsoletas, campos vacíos, grupos mal asignados y versiones antiguas.

Se hacía a ojo, abriendo dos documentos en paralelo. Una revisión completa se llevaba buena parte de una tarde, y aun así se colaban errores. Cada error que llegaba a compras significaba una pieza equivocada en el almacén y un montaje parado esperándola.

El agravante: los criterios de revisión no estaban escritos en ningún sitio. Vivían en la cabeza de las dos personas que llevaban años haciéndolo.

Qué se hizo

Mapa de la revisión real. Antes de escribir una línea de código, se documentó qué se comprobaba de verdad. Salieron dieciocho comprobaciones distintas, de las cuales varias no estaban recogidas en ningún procedimiento. Ese documento ya tenía valor por sí solo.

Reglas fuera del código. Los criterios del departamento se sacaron a un archivo de configuración alojado en el servidor compartido: veinticuatro parámetros que el propio departamento puede cambiar cuando cambia un proveedor o una norma interna, sin tocar el programa y sin depender de quien lo escribió.

Una aplicación de escritorio, no un script. Ventana única, tres campos y un botón. El informe sale en Excel con las incidencias resaltadas por color según su gravedad y separadas en hojas por tipo. Quien la usa no necesita saber programar ni acordarse de ningún comando.

Lectura del catálogo optimizada. Con las librerías estándar, cargar el catálogo maestro tardaba unos doce segundos. Se escribió un lector propio que lo hace en medio segundo. Parece un detalle, pero en una herramienta que se abre veinte veces al día es la diferencia entre usarla y evitarla.

Auditoría del propio catálogo. Al automatizar la comprobación quedó claro que parte del problema estaba en la fuente. Una segunda herramienta revisó el catálogo entero y encontró 212 grupos de referencias duplicadas —la misma pieza del mismo proveedor dada de alta varias veces— y 515 piezas marcadas como obsoletas sin ninguna indicación de por cuál se sustituyen.

Documentación de entrega. Manual de uso y archivo de instrucciones para que la herramienta sobreviva a su autor. Es la parte que casi nadie hace y la que decide si algo así sigue vivo dos años después.

El resultado

El ahorro de tiempo era lo esperado. Lo que no se esperaba es que el mayor retorno viniera de la auditoría del catálogo: durante años se había asumido que el maestro era fiable, y resultó que una parte apreciable de los errores de compra no venían de la revisión, sino del dato de origen.

El segundo efecto, menos visible, es que los criterios de revisión dejaron de ser conocimiento tácito. Están escritos, son editables y una persona nueva puede aplicarlos desde el primer día.

Qué haríamos distinto

Comprobar el entorno de despliegue antes de elegir la tecnología. La primera versión de la interfaz se construyó sobre un componente web que resultó inestable en los equipos corporativos, con sus restricciones y sus políticas de seguridad. Hubo que rehacerla con una tecnología de escritorio nativa. Fueron dos semanas perdidas que se habrían evitado con una prueba de veinte minutos en un ordenador real del cliente.