Cambiar de software de distribución sin interrumpir las operaciones

La causa más frecuente de fracaso es la transición de golpe (big-bang): un viernes por la noche se apaga el sistema antiguo, se enciende el nuevo, y el lunes por la mañana toda la empresa descubre lo desconocido al mismo tiempo. El menor problema —un flujo no probado, un permiso ausente, una pantalla mal entendida— se propaga al instante a todos los almacenes, sin red de seguridad. Lo que habría sido un incidente menor se convierte en una crisis visible para todos los clientes.

La segunda causa, silenciosa pero devastadora, son los datos sucios. Clientes duplicados, productos fantasma, unidades de medida incoherentes, direcciones obsoletas: el sistema antiguo los toleraba por costumbre, el nuevo los rechaza o, peor aún, los propaga. Nunca se migra un catálogo ni un fichero de clientes «tal cual» sin haberlos limpiado primero.

La formación descuidada completa el cuadro. Un software excelente usado por un equipo sin preparación produce malos resultados más rápido que un software mediocre bien dominado. Por último, muchas empresas se lanzan sin plan de reversión: cuando algo sale mal, no existe ninguna forma documentada de volver atrás, y el pánico sustituye a la decisión.

El hilo conductor de todos estos fracasos es el mismo: tratar la migración como un evento técnico puntual en lugar de como un proyecto de operaciones progresivo. Las siguientes secciones proponen lo contrario.

El funcionamiento en paralelo consiste en hacer funcionar el sistema antiguo y el nuevo al mismo tiempo durante un período definido. En concreto, durante dos a cuatro semanas, cada operación crítica —entrada de pedidos, recepción, expedición, facturación— se registra en ambas herramientas. Es un sobrecoste temporal, pero es el precio de una red de seguridad real: en ningún momento pierde la capacidad de atender a un cliente.

El núcleo del método es la reconciliación diaria. Al final de cada jornada se comparan ambos sistemas mediante unos pocos indicadores sencillos: número de pedidos, valor total facturado, movimientos de stock, discrepancias de inventario. Una discrepancia no es un fracaso, es información: revela un mapeo incorrecto, una regla de negocio mal traducida o una acción de usuario que corregir. Se documenta cada discrepancia y su resolución.

La transición nunca debe depender del calendario, sino de criterios de confianza medibles definidos de antemano. Por ejemplo: tres días consecutivos sin discrepancia de facturación por encima de un umbral; cero pedidos perdidos; tiempo de registro de vuelta a la normalidad; tasa de error de expedición estable. Mientras no se cumplan estos criterios, se prolonga el paralelo en lugar de forzar.

Este período tiene además una virtud humana: convierte el miedo en costumbre. Los equipos aprenden la nueva herramienta con datos reales, pero sin riesgos irreversibles, ya que el sistema antiguo sigue siendo la fuente de verdad hasta que se establece la confianza. Con SupplyCore, la exportación/importación en CSV y JSON y la API REST pública facilitan esta doble alimentación y la comparación automatizada de ambos conjuntos de datos.

La migración comienza con una exportación completa del sistema antiguo, idealmente en CSV o JSON: clientes, proveedores, catálogo de productos, tarifas, stocks, pedidos abiertos, historial reciente. Esta exportación es su materia prima. La regla de oro: nunca importar directamente de lo antiguo a lo nuevo. Siempre se pasa por una etapa intermedia de limpieza y control.

La limpieza ataca primero el desduplicado. Un mismo cliente registrado tres veces con tres grafías, dos referencias de producto para un artículo idéntico, unidades de medida mezcladas: son los errores que luego contaminan los stocks y la facturación. Se fusiona, se normalizan los formatos (códigos, unidades, divisas), se completan los campos obligatorios del nuevo sistema y se archiva lo que está muerto en lugar de migrarlo.

El mapeo consiste en decidir, campo por campo, en qué se convierte cada dato en el destino: qué campo origen alimenta qué campo de SupplyCore, qué valores se convierten, qué reglas se aplican. Este documento de correspondencia es el contrato de la migración; se revisa y valida con los responsables de negocio, no solo con informática.

La validación se apoya en juegos de prueba y controles de integridad. Primero se importa una muestra representativa, se verifica que los totales coinciden (número de clientes, valor de stock, saldos pendientes), se reproducen algunos pedidos de principio a fin, y luego se amplía. Los agentes de IA de SupplyCore y la API REST ayudan a detectar automáticamente anomalías y duplicados residuales, pero la validación final sigue siendo una decisión humana, tomada sobre cifras que se reconcilian.

En lugar de encender toda la red de golpe, el despliegue progresivo divide la implementación sitio por sitio. Primero se elige un almacén piloto: ni el más grande, ni el más crítico, pero representativo de los flujos, con un equipo motivado y un responsable local capaz de liderar el cambio. Este sitio absorbe los primeros ajustes, allí donde un error queda contenido.

El piloto sirve para descubrir lo que ninguna prueba de laboratorio revela: los hábitos reales, los casos particulares de un cliente histórico, la impresión de etiquetas, las integraciones con un transportista. Cada problema encontrado se corrige y se documenta en una guía de despliegue que servirá a los sitios siguientes. El piloto no tiene éxito cuando «funciona» un día, sino cuando gira varios días sin intervención excepcional.

Luego llega una oleada de dos o tres almacenes adicionales, elegidos para cubrir otros casos. En esta etapa se capitaliza: las correcciones del piloto ya están integradas, la formación está rodada, los criterios go / no-go se conocen. La curva de aprendizaje de la organización se acelera con cada oleada.

La generalización a toda la red solo se produce una vez que el modelo está probado y estabilizado. Este enfoque tiene una ventaja decisiva: en todo momento, la mayor parte de la empresa funciona sobre un sistema conocido —antiguo o nuevo— y nunca toda la operación queda expuesta simultáneamente al mismo riesgo.

La formación fallida es la que trata a todos de la misma manera. Un chofer, un almacenero, un vendedor y un contable no usan el mismo software: usan cuatro softwares distintos dentro de la misma herramienta. Cada uno debe aprender su recorrido —las pantallas que realmente toca— y nada más. Ahogar a un almacenero en funciones de contabilidad garantiza que retendrá mal las suyas.

Se construye entonces un plan por rol. Los vendedores: búsqueda de producto, disponibilidad, entrada de pedidos, precios y descuentos. Los almaceneros: recepción, ubicación, preparación, expedición, inventario. Los choferes: rutas, pruebas de entrega, devoluciones. La contabilidad: facturación, cobros, conciliaciones, impuestos. La dirección: cuadros de mando e indicadores de gestión. Cada recorrido merece su material dedicado.

El formato que funciona está hecho de sesiones cortas y prácticas, sobre casos reales de la empresa, en lugar de largas demostraciones teóricas. Una hora enfocada, seguida de una práctica inmediata durante el funcionamiento en paralelo, arraiga mejor que un día entero mirando. Fichas de una página, colocadas en el puesto, valen más que un manual de cien páginas que nadie abre.

Es útil formar a algunos referentes internos por sitio y por oficio: colegas que suben de nivel más rápido y se convierten en el primer recurso de los demás. Para necesidades específicas, SupplyCore ofrece soporte nativo en francés y bloques de horas de adaptación a 125 $/h, movilizables para personalizar una pantalla, ajustar un flujo o construir un material de formación a medida sin emprender un proyecto pesado.

Un proyecto de migración serio prevé su propio fracaso. El plan de reversión (rollback) es el escenario escrito que responde a una sola pregunta: si el nuevo sistema se vuelve inutilizable una mañana, ¿cómo reanudamos la actividad en menos de una hora? La respuesta honesta, durante todo el período de transición, es mantener el sistema antiguo disponible en solo lectura: los pedidos en curso siguen consultables, el historial sigue accesible y, si hace falta, se puede volver a registrar allí una operación crítica.

El plan de reversión no es un documento guardado en un cajón. Precisa quién decide, quién ejecuta, en qué orden y qué datos deben resincronizarse al volver. Se prueba al menos una vez antes de la transición, como un simulacro de evacuación: un rollback que nunca se ha ensayado es solo una intención.

En cada etapa —fin de la migración de datos, fin del piloto, antes de cada oleada, antes de la generalización— se toma una decisión explícita go / no-go. El «go» nunca es una sensación; se apoya en criterios cifrados fijados de antemano: totales conciliados, cero pedidos perdidos, plazos de tratamiento dentro de la norma, tasa de error por debajo de un umbral, equipos formados y con confianza. Si un solo criterio bloqueante no se cumple, es «no-go», y se corrige antes de avanzar.

Este marco desplaza la decisión del terreno emocional al terreno factual. Nadie tiene que «sentir» que es el momento adecuado: las cifras deciden. Es precisamente lo que permite a una dirección de operaciones emprender el cambio con serenidad, sabiendo que una vuelta atrás limpia sigue siendo posible en todo momento.

Un despliegue de SupplyCore se organiza típicamente en dos a seis semanas, según el tamaño de la red y la complejidad de los flujos. Un distribuidor de un solo sitio con procesos estándar se sitúa hacia el extremo bajo; una red multialmacén con integraciones y casos particulares se sitúa hacia el extremo alto. Lo importante no es la duración absoluta, sino el encadenamiento lógico de las etapas.

Semana 1 — encuadre y datos. Se alinean los objetivos, se identifican los roles y los referentes, se lanza la exportación del sistema antiguo y la limpieza. Se redacta el documento de mapeo y se prepara el entorno. En paralelo, se definen por escrito los criterios go / no-go y el plan de reversión. Semana 2 — importación y validación. Se importa un primer conjunto, se lanzan los controles de integridad, se reproducen pedidos de prueba y se corrige el mapeo hasta que los totales se reconcilien. Comienzan las primeras formaciones por rol.

Semanas 3 a 4 — piloto y paralelo. El almacén piloto pasa a funcionamiento en paralelo: doble registro, reconciliación diaria, ajustes. El sistema antiguo sigue siendo la fuente de verdad en lectura. Solo se hace la transición del piloto cuando los criterios de confianza se mantienen varios días seguidos. La guía de despliegue se llena con los casos reales encontrados.

Semanas 5 a 6 — oleadas y generalización. Apoyándose en el piloto, se despliegan los almacenes siguientes por oleadas, con formación y paralelo comprimidos gracias a la experiencia adquirida, hasta la generalización. Se mantiene el sistema antiguo accesible en solo lectura algún tiempo tras la transición completa, y luego se retira una vez la confianza está definitivamente establecida. A lo largo de todo, el soporte nativo en francés, los agentes de IA y los bloques de horas de adaptación permiten absorber los imprevistos sin descarrilar el calendario, y sin interrumpir jamás la operación.