Modernizar un sistema de almacén de 12 años sin detener los camiones

El software más peligroso de una pequeña empresa es el software que funciona. No la herramienta defectuosa de la que todos se quejan: esa acaba sustituyéndose tarde o temprano. El peligroso es el sistema de doce años que nadie quiere pero del que todos dependen, el que arranca desde una torre beige en un rincón y lleva gestionando el almacén desde antes de que se contratara a la mitad del equipo. Funciona. Hasta el día en que casi deja de hacerlo, y todos se dan cuenta a la vez de que el negocio entero se sostiene sobre él.

Esta es la historia de uno de esos sistemas y de cómo lo sustituimos. El cliente es un distribuidor regional: unos pocos miles de referencias, un único almacén, alrededor de treinta personas entre la nave y la oficina. Lo hemos anonimizado y redondeado las cifras, pero la forma del proyecto es exactamente como ocurrió. Si usted está sentado sobre un sistema envejecido que teme tocar, así es más o menos como se ve por dentro una modernización sensata.

En esta historia no hay una reescritura heroica, ningún fin de semana en el que pulsamos un interruptor y todo era nuevo. La clave —lo que hizo que funcionara— es que no pasó nada dramático. Los camiones siguieron cargándose. El almacén apenas notó que el suelo se movía bajo sus pies. Ese es el objetivo en el trabajo con sistemas heredados, y conviene entender por qué.

La situación: un sistema sostenido por la memoria de una sola persona

El almacén funcionaba con un sistema a medida construido hacia 2013 por un desarrollador que hacía mucho que se había marchado. Cumplía la función esencial —controlar el stock, imprimir listas de picking, sacar pedidos por la puerta— y en un día normal lo hacía bien. El problema no era realmente el software. El problema era todo lo que había crecido alrededor del software para mantenerlo utilizable.

A lo largo de una década, el equipo había montado en silencio un sistema en la sombra hecho de cinta adhesiva: una hoja de cálculo para los recuentos de stock que el software erraba, una segunda hoja que conciliaba la primera con la realidad, un grupo de WhatsApp para que el jefe de almacén marcara artículos que el sistema no sabía representar, y una carpeta impresa de apaños que los nuevos tenían que memorizar. Nada de esto estaba documentado en un solo lugar. Vivía en la cabeza de la responsable de operaciones, una mujer serena de cincuenta y tantos años que llevaba allí catorce años y que era, en la práctica, la documentación.

Cuando el dueño nos llamó por primera vez, no fue por una caída del sistema. Fue porque ella había anunciado que quería jubilarse en dos años, y él había echado cuentas y comprendido que el día en que ella se fuera, una parte significativa de cómo funcionaba realmente el almacén saldría por la puerta con ella. Ese es un detonante de modernización más común que cualquier fallo técnico: no que el sistema se rompa, sino la constatación de que las personas que lo remiendan no estarán para siempre.

Los síntomas que todos habían dejado de notar

Cuando dedicamos nuestros dos primeros días simplemente a observar el almacén trabajar, los costes del viejo sistema estaban por todas partes, pero se habían vuelto tan normales que ya nadie los señalaba como problemas. Se confiaba en que las cifras de stock estuvieran equivocadas por un margen predecible, así que todo pedido grande recibía una comprobación física manual «por si acaso». El personal nuevo tardaba semanas en ser útil porque buena parte del trabajo era saber no escrito. Y el sistema corría sobre un sistema operativo tan antiguo que ya no podía parchearse, en una red que el dueño sabía en privado que era un incidente de seguridad esperando a ocurrir.

• La precisión del inventario rondaba el 80 %, así que el personal volvía a contar a mano cualquier cosa importante: horas al día, en silencio.
• La lógica de la lista de picking no encajaba con la distribución actual del almacén, así que los preparadores seguían la ruta que indicaba la carpeta, no la pantalla.
• La conciliación de stock de fin de mes ocupaba a dos personas buena parte de tres días.
• Solo una máquina podía ejecutar la parte de administración del software, y si fallaba, nadie tenía un plan claro.
• Nada se conectaba con el canal de pedidos online que la empresa había añadido en 2019: esos pedidos se reescribían a mano.

Lo que deliberadamente no hicimos

El movimiento obvio —el que muchos proveedores habrían propuesto— es comprar una gran plataforma de gestión de almacén estándar, migrarlo todo en un fin de semana y apagar el viejo sistema el lunes por la mañana. Hemos visto ese enfoque salir mal las veces suficientes como para no proponerlo a un negocio como este. Una migración de golpe presupone que se entiende el viejo sistema por completo. Con una década de apaños sin documentar, nadie lo entendía, ni siquiera quienes lo manejaban.

El segundo movimiento tentador es una reescritura completa a medida desde cero: tomar todo lo que hace el viejo sistema, reconstruirlo de forma limpia y entregar el nuevo. Suena responsable y es una manera clásica de quemar un año y un presupuesto grande mientras el negocio espera, congelado, un reemplazo que sigue retrasándose. El problema es que una reescritura tiene que reproducir cada peculiaridad antes de poder lanzarse, incluidas las peculiaridades que nadie recuerda que eran de carga hasta que faltan.

Así que no hicimos ninguna de las dos cosas. Tratamos el viejo sistema no como algo que demoler, sino como algo que rodear y sustituir despacio, una capacidad cada vez, con el viejo sistema funcionando por debajo como red de seguridad durante todo el camino. Poco glamuroso. También la única versión de esto que funciona de forma fiable.

El enfoque: estrangular el viejo sistema, no volarlo

Entre los desarrolladores hay un nombre muy conocido para este patrón: el enfoque «estrangulador», por una enredadera que crece alrededor de un árbol hasta que puede sostenerse sola y el original desaparece en silencio. No se sustituye el viejo sistema de un solo movimiento. Se construyen piezas nuevas a su alrededor, se desvía trabajo real hacia ellas una a una, y se deja que el viejo sistema se encoja hasta que lo que queda es lo bastante pequeño como para apagarlo sin que nadie contenga la respiración.

Para este almacén, eso significó acordar de antemano una secuencia: qué capacidad desprenderíamos primero, cuál guardaríamos para el final y —fundamental— una regla según la cual en cada etapa, si la pieza nueva se portaba mal, podíamos volver de inmediato al viejo método ese mismo día. A ningún paso se le permitió ser un punto sin retorno hasta el final mismo. Esa única regla es lo que dejó dormir al dueño y lo que hizo que el personal del almacén confiara en el proyecto en lugar de resistirse a él.

1. 1
   Mapear lo que el sistema hace de verdad

   Tres semanas siguiendo de cerca la nave y la oficina para documentar el flujo de trabajo real, incluido cada apaño en hojas de cálculo y carpetas. Anotamos el sistema que existía, no el que describía la especificación original.
2. 2
   Limpiar los datos antes de moverlos

   Hicimos un recuento físico de stock completo y limpiamos la base de datos de productos contra él. Migrar datos sucios a un sistema nuevo solo da una respuesta equivocada más rápido, así que esto fue antes de que cualquier software nuevo tocara los datos.
3. 3
   Sustituir primero la pieza más dolorosa

   Construimos el nuevo módulo de control y recuento de stock, lo ejecutamos en paralelo con el viejo y solo confiamos en él cuando las cifras coincidieron con la realidad durante un mes entero.
4. 4
   Conectar los canales que el viejo sistema ignoraba

   Después conectamos el canal de pedidos online directamente con los nuevos datos de stock, acabando con la reescritura manual que existía en silencio desde 2019.
5. 5
   Desprender el resto y luego retirar el núcleo viejo

   Picking, informes y conciliación se trasladaron uno a uno. Cuando casi nada real corría sobre el viejo sistema, por fin lo apagamos: para entonces, un no-evento.

Las partes que fueron de verdad difíciles

Sería deshonesto presentar esto como algo fluido. El trabajo técnico fue la parte fácil. Las partes difíciles fueron humanas y de procedimiento, y son las mismas partes difíciles de casi todo proyecto heredado.

La regla no documentada que rompió una función

A las dos semanas de ejecutar el nuevo módulo de stock en paralelo, las cifras se desviaron para una categoría de producto y no veíamos por qué. Tras un día escarbando, la responsable de operaciones mencionó, casi de pasada, que ciertos artículos a granel se contaban por palé, no por unidad, y que el viejo sistema tenía una conversión oculta incorporada que nadie había documentado en una década. No estaba en ninguna especificación. Vivía solo en su cabeza y en la carpeta. Nunca lo habríamos encontrado solo a partir del código: únicamente al ejecutar ambos sistemas en paralelo y preguntar por qué discrepaban. Ese es todo el argumento a favor de la ejecución en paralelo, en una anécdota.

Ganarse a la nave

El personal del almacén había sobrevivido a más de una «mejora» bienintencionada que les empeoró el día, así que recibieron el proyecto con una desconfianza razonable. No lo combatimos con una presentación. Elegimos al preparador que más se quejaba, nos sentamos con él una mañana y reconstruimos la pantalla de picking en torno a cómo recorría realmente la nave. En cuanto empezó a defender el nuevo sistema en la sala de descanso, el resto siguió. En los proyectos heredados, el crítico más duro, una vez ganado, se convierte en su mejor defensor, y eso no se compra con un comunicado.

Los resultados, un año después

Desconfiamos de las cifras relucientes de antes y después, porque cada empresa mide de forma distinta y en su caso variarán. Trátelas, pues, como cifras honestas y redondeadas de un proyecto, pensadas para mostrar la forma del retorno más que una promesa. El titular tiene menos que ver con una métrica concreta y más con lo que dejó de dar miedo.

La cifra que más le importaba al dueño no estaba en ninguna gráfica. Fue que, cuando la responsable de operaciones se jubiló de verdad —unos meses antes de lo previsto, según resultó—, el almacén ni se tambaleó. El conocimiento que antes vivía en su cabeza vivía ahora en un sistema en el que cualquiera podía formarse en días. La razón original de todo el proyecto quedó resuelta en silencio, por completo.

Si usted está sentado sobre un sistema así

La mayoría de los dueños con un sistema central envejecido sienten dos cosas a la vez: es arriesgado conservarlo y da pánico sustituirlo. Ambas son ciertas. El error es dejar que gane el segundo miedo, porque el riesgo del viejo sistema no se mantiene estable: crece en silencio cada año, a medida que las personas que lo entienden se acercan a marcharse y la plataforma sobre la que corre se aleja más del soporte.

No tiene que elegir entre «déjalo en paz y reza» y «apuesta la empresa a una gran reescritura». El camino intermedio —rodearlo, sustituirlo pieza a pieza, conservar el viejo como red hasta que el nuevo se haya ganado la confianza— es más lento y mucho menos heroico. También es la versión que no detiene los camiones. Si hay algo que llevarse de toda esta historia, es eso.

Preguntas frecuentes