Cuando tu sistema legacy frena la operación de distribución

Hay una conversación que se repite. El Gerente TI explica que el sistema de distribución "funciona", pero que para cada excepción hay que llamar a Rodrigo, que es el único que sabe cómo meterle mano. O que el sistema sí procesa las guías, pero los datos hay que exportarlos a Excel y cruzarlos a mano con el WMS porque la integración se rompió hace dos años y nunca nadie la arregló. O que el sistema "siempre ha sido así" y la operación se adaptó.

El sistema legacy no está fallando. Está frenando.

Y la diferencia importa, porque cuando el sistema falla de golpe hay urgencia. Cuando frena despacio, hay resignación.

El deterioro silencioso

Los sistemas heredados en distribución no colapsan en un día. Se degradan durante años, a veces décadas, de una forma que es difícil de ver desde adentro porque cada parche fue una solución razonable en su momento.

El módulo de despacho lo programó alguien que ya no está. La integración con el carrier la hizo el proveedor anterior, en un lenguaje que nadie en el equipo domina. El proceso de conciliación de guías requiere que alguien abra tres pantallas y haga cálculos intermedios porque el sistema no los hace solo.

Ninguna de esas cosas es un desastre. Todas juntas son un freno.

El costo no aparece en ningún reporte. Aparece en el tiempo que el equipo operacional dedica a trabajar alrededor del sistema en vez de con él. En los errores que se cometen al cruzar datos manualmente. En las decisiones que se toman tarde porque la información no está disponible cuando se necesita.

Señales concretas de que el sistema está frenando la operación

No son señales dramáticas. Son las que se normalizan con el tiempo:

El sistema genera datos pero no información. Las transacciones se registran, pero para saber el estado real del inventario, los plazos de entrega o los costos por ruta hay que hacer trabajo manual adicional. El sistema guarda lo que pasó; la persona reconstruye lo que significa.

El conocimiento crítico está concentrado en una persona. Hay alguien — a veces dos — que sabe cómo funciona de verdad el sistema. No cómo debería funcionar según el manual. Cómo funciona con los parches, los atajos y los casos excepcionales que se acumularon durante años. Si esa persona se va de vacaciones, hay nerviosismo. Si renuncia, hay crisis.

Las excepciones se manejan fuera del sistema. El 80% de las operaciones fluye bien. El 20% restante se maneja en Excel, en WhatsApp, en notas en papel, o simplemente con la memoria de alguien. Ese 20% suele incluir los clientes más grandes, los pedidos más complejos o las rutas más críticas.

Las integraciones se mantienen con fe. Hay sistemas que "hablan entre sí" pero nadie sabe exactamente cómo. Cuando algo falla en la cadena — una guía que no llega, un stock que no actualiza — la solución es reiniciar procesos, volver a cargar archivos o llamar al soporte de un proveedor que tampoco tiene claro cómo funciona la integración original.

El sistema frena las iniciativas del negocio. Cada vez que operaciones o gerencia propone algo nuevo — un nuevo canal de despacho, un cambio en la estructura de precios, la incorporación de un carrier adicional — la respuesta de TI empieza con "el sistema no lo soporta". No porque no sea posible técnicamente. Porque la deuda acumulada hace que cada cambio sea un riesgo.

Por qué no se resuelve antes

La respuesta honesta es que resolver un sistema heredado requiere tiempo, personas y tolerancia a la incertidumbre — tres cosas que siempre están escasas en distribución.

El equipo TI sabe que el sistema necesita trabajo. Pero también sabe que meterle mano puede romper algo que hoy funciona, aunque sea con parches. El riesgo de tocar supera el beneficio percibido de arreglarlo, especialmente cuando la operación no puede detenerse.

El negocio empuja por resultados de corto plazo — más despachos, menos errores, menos costo por guía — y la modernización del sistema no aparece en el radar porque no tiene una métrica directa en el próximo trimestre.

Y hay una tercera razón que rara vez se dice en voz alta: nadie quiere ser el responsable de haber roto algo. La cultura de no tocar lo que funciona es racional cuando el sistema es opaco y el conocimiento es frágil.

Lo que hay que hacer, en ese orden

El primer error que veo frecuentemente es intentar resolver el problema técnico antes de entender el problema operacional.

Antes de escribir una línea de código, hay que mapear tres cosas:

Qué depende de qué. No el diagrama idealizado que existe en la documentación (si existe). El mapa real de qué sistema alimenta a qué proceso, dónde hay datos que se duplican, dónde hay pasos manuales que compensan una integración rota.

Dónde está el conocimiento tácito. Quién sabe cómo funciona de verdad el sistema, qué decisiones tomaron en su momento y por qué, qué hay que hacer cuando algo falla. Eso hay que documentarlo antes de tocar nada.

Qué puede detenerse y qué no. En distribución, algunos procesos pueden pausarse por horas o días sin consecuencias graves. Otros no pueden interrumpirse ni cinco minutos. La estrategia de modernización depende de entender ese mapa con precisión.

Después de ese mapa, recién se puede plantear una estrategia: qué se moderniza primero, qué se reemplaza, qué puede esperar, qué hay que hacer en paralelo para no detener la operación mientras se trabaja.

Una modernización no es un reemplazo total

El error inverso también existe: creer que la solución es tirar todo y empezar de cero. Eso rara vez es la respuesta correcta.

En la mayoría de los sistemas de distribución que hemos visto, hay partes que funcionan bien y partes que están fallando. La clave es distinguir qué puede refactorizarse, qué conviene aislar y reemplazar por módulos, y qué realmente necesita una migración completa.

Un sistema de gestión de rutas que lleva diez años puede tener una lógica de negocio valiosa enterrada en código viejo. Tirar esa lógica significa volver a aprenderla desde cero — o, peor, perderla. Modernizarlo significa extraerla, documentarla y construir una aplicación web a medida encima de ese conocimiento, no reemplazarla.

El costo de no hacer nada

Hay un cálculo que vale la pena hacer en serio: cuánto cuesta el estado actual, en horas de trabajo manual, en errores operacionales, en decisiones que se toman con información incompleta, en proyectos del negocio que TI no puede soportar.

Ese costo es invisible porque está distribuido en el día a día. Nadie tiene un ítem en el presupuesto que diga "costo de sistema heredado". Pero está ahí, y suele ser más grande de lo que parece cuando se suma.

La comparación relevante no es "modernización vs. cero costo". Es "costo de modernizar vs. costo de seguir igual durante los próximos tres años".

Cuando se hace ese cálculo honestamente, la decisión suele ser más clara.

---

Si reconoces alguna de estas señales en tu operación de distribución, el primer paso es entender con precisión dónde está el problema real — no el declarado. Eso es lo que hacemos en el diagnóstico inicial. Sin compromisos de tecnología ni presupuestos prefijados: primero entendemos qué hay, y después proponemos qué hacer.