Tu piloto funcionó. Tu despliegue murió. Nueve de cada diez veces, se reduce a tres cosas.
He visto esta película demasiadas veces. En 2023 ayudé a un 3PL a las afueras de Plainfield, Indiana, a pilotar un optimizador de rutas de picking impulsado por IA en una instalación de 180,000 pies cuadrados. Seis semanas después, las ganancias de eficiencia hicieron que el cliente preguntara cuándo podríamos operar en todas partes. Diez almacenes, dijeron. Llegamos al almacén número dos en Ohio antes de que todo se estancara. Los operarios de picking allí ignoraron por completo las sugerencias de rutas del sistema. El tercer sitio nunca arrancó, y la cláusula de despliegue del contrato quedó allí acumulando polvo. Ese proyecto me enseñó algo que ahora les digo a todos los clientes: un piloto demuestra que la tecnología puede funcionar. Un despliegue pone a prueba si puede sobrevivir al edificio de otro.
Causa de muerte uno: tus datos del piloto fueron criados a mano
Los datos del piloto nunca son naturales. Piensa en tu piloto. ¿Los ingenieros del proveedor acamparon en el sitio durante semanas? ¿Alguien etiquetó a mano cada pedido de excepción? ¿Se les dijo a los operarios, explícitamente, que siguieran el sistema y no improvisaran? La gente se comporta distinto cuando sabe que la están observando. Los datos salieron limpios porque toda la operación estaba en su mejor comportamiento, como una casa modelo.
Esos datos mimados son lo que tu modelo aprendió. Luego el almacén número dos no recibe ninguno de esos cuidados. Se omiten escaneos, los motivos de devolución se eligen al azar, los cambios de slotting quedan sin registrar durante dos días. Mismo modelo, distinta cena. Y el deterioro es lento: el primer mes se ve bien, para el tercer mes las recomendaciones se desvían, los operadores dejan de confiar en ellas, y la desconfianza empeora los datos. Una espiral de muerte que nadie nota hasta que es demasiado tarde.
Así que el primer paso de cualquier despliegue es una auditoría de línea base de datos en cada nuevo sitio. Envía a alguien a vivir allí durante dos a cuatro semanas y no cambies nada. Solo observa: cumplimiento de escaneo, integridad de datos maestros, qué tan rápido se procesan las excepciones. Si un sitio no puede igualar la calidad de datos que tenía tu almacén piloto, corrige los datos primero y programa el go-live para después. Este tiempo y dinero no se pueden omitir. Omitelos y pagarás diez veces más.
Causa de muerte dos: el modelo extraña su hogar en el almacén número dos
Dos edificios llamados «almacén» pueden ser especies distintas por dentro. Nuestro piloto en Plainfield hacía picking de caja completa con un perfil de SKU concentrado y rutas de viaje fijas. El sitio de Ohio manejaba comercio electrónico de paquetería pequeña con un orden de magnitud más de SKU y una lógica de oleadas completamente distinta. Todo lo que el modelo había «aprendido» era casi inútil allí.
Las diferencias se acumulan en tres capas. Una es la mezcla de productos y pedidos: caja completa versus unidades sueltas, B2B versus venta directa al consumidor — los supuestos del modelo cambian debajo de él. Segunda, el proceso: dos sitios pueden llamar «picking» a lo mismo mientras uno recoge hacia un put wall y reverifica, y el otro recoge directo a totes. Cambia los pasos y las acciones sugeridas por el modelo dejan de corresponder a la realidad. Tercera, y la más traicionera: las versiones de sistema. Dos sitios con versiones de WMS separadas por dos releases pueden definir el mismo evento de «picking completo» con distinta semántica de campos y lógica de marcas de tiempo. Conectas la interfaz y los datos llegan desalineados.
Mi regla ahora: antes de que cualquier sitio nuevo entre en vivo, llena un registro de variaciones contra el sitio piloto — perfil de producto, tipos de pedido, pasos clave del proceso, versiones de sistema y campos de interfaz, punto por punto. Donde las brechas sean amplias, corrige el proceso y alinea las definiciones de datos antes de que el modelo aparezca. Nunca esperes que el modelo se adapte a tu desorden. No puede. Y una regla dura: congela las actualizaciones de versión del WMS y de la interfaz durante el despliegue. El fracaso más injusto que he visto fue un equipo de TI que actualizó el WMS a mitad del despliegue; cambió una definición de campo y los modelos de tres sitios en vivo se rompieron al mismo tiempo. Un congelamiento no significa no actualizar — significa que cada actualización pasa primero una regresión del modelo en pruebas.
Cada sitio nuevo también recibe un período de sombra. El sistema hace recomendaciones pero no toma las decisiones; los operadores trabajan como siempre lo han hecho. Dos a cuatro semanas de comparación: dónde divergen las sugerencias del sistema de las elecciones de los veteranos, y si la brecha es un problema de datos o prueba de que el modelo genuinamente no entiende este edificio. Los datos de sombra son la única base legítima para la decisión de corte total. Nunca decidas por intuición.
Causa de muerte tres: nadie quiere usarlo, y las matemáticas no cuadran
Durante el piloto, los ejecutivos lo impulsaron, el proveedor estaba en el sitio, y los operadores tenían curiosidad. ¿Durante el despliegue? El gerente del nuevo sitio piensa «este es el proyecto de la casa matriz, no mi bono». Los operadores piensan «esta cosa me hace escanear dos veces, ¿por qué debería hacerlo?». Cuando la sugerencia de la IA choca con el instinto de un veterano de veinte años, el veterano gana, porque nadie está del lado de la IA.
El andamiaje organizacional tiene que llegar con la tecnología. Cada sitio de despliegue necesita un responsable de negocio nombrado — y digo negocio, no TI. Los objetivos trimestrales de esa persona deben incluir «despliegue de IA en vivo y rindiendo a los niveles medidos en el piloto». La gente lucha por lo que está en su plan de bonos. Esa es la naturaleza humana; no luches contra la naturaleza humana.
Y no desbandes al equipo del piloto. El error más común que veo: el piloto tiene éxito, el personal del proveedor se va, el equipo interno del proyecto se disuelve, y cada sitio queda solo para descifrar la réplica. En cambio, convierte al equipo piloto en un escuadrón de réplica que lleve el registro de variaciones, el estándar de línea base de datos y el manual de operación en sombra, trabajando sitio por sitio. Soporte total para los primeros tres sitios, solo revisión desde el cuarto, manos fuera después del séptimo. Este ritmo no se puede apresurar.
La matemática del ROI también tiene que estar cerrada con finanzas antes del despliegue, no después. El ROI del piloto suele ser «matemática ideal»: ahorros de mano de obra contados, costos de implementación ignorados, retrabajo por recomendaciones falsas ignorado, mano de obra duplicada durante el modo sombra ignorada. Cuando finanzas suma todo de vuelta durante el despliegue, los números se ven delgados y el proyecto es cuestionado. Mejor haz tú mismo la matemática honesta por adelantado: implementación, remediación de datos, el costo de errores de picking por malas recomendaciones — todo incluido, amortizado por sitio. Un ROI delgado pero real y replicable supera a uno gordo e irreplicable cada vez. Usa las cifras medidas de tu piloto, no la presentación del proveedor, cuando te sientes con finanzas.
Antes de copiar ese piloto al siguiente edificio, recorre esta lista de verificación: ¿se cumple la línea base de datos del sitio?, ¿está lleno el registro de variaciones?, ¿están congeladas las versiones de sistema?, ¿está programado el período de sombra?, ¿está nombrado el responsable de negocio con el despliegue en sus objetivos?, ¿sigue intacto el escuadrón de réplica?, ¿está acordada la metodología de ROI con finanzas? Si no puedes responder sí a las siete, no instales nada todavía. Ganar un piloto una vez es suerte. Repetir esa victoria diez veces es la verdadera habilidad.
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
