Seamos francos: un piloto de IA exitoso y un despliegue escalable son dos animales distintos. He visto esta película demasiadas veces. El almacén n.º 1 ejecuta un piloto precioso: precisión de picking arriba, tasa de errores abajo, aplausos en la revisión trimestral. Luego el almacén n.º 2 se atasca. ¿El almacén n.º 3? Ni siquiera lo mencionan.
La cosa es así, y tiene doble filo. Los pilotos triunfan gracias a las personas y la inversión: tu mejor edificio, tu equipo más fuerte, los ingenieros del proveedor en sitio, todo concentrado en un solo lugar. Claro que funciona. Escalar triunfa con algo completamente distinto: estándares, disciplina y un sano respeto por el hecho de que no hay dos almacenes iguales. Copiar el manual del piloto tal cual es buscarse problemas.
En 2023, un 3PL en Ontario, California — fulfillment de comercio electrónico, seis edificios en la red — vino a verme. El edificio n.º 1 había pilotado visión artificial para la verificación de picking. Tres meses después, la tasa de envíos erróneos había caído casi a cero, y el cliente estaba encantado. El CEO agitó la mano: desplíeguelo en todas partes. El edificio n.º 2, en Dallas, salió en vivo y se desmoronó de inmediato. Mismo SKU, pero los datos maestros — nombres de artículos, reglas de códigos de barras — no coincidían para nada con los de California. El modelo reconocía imágenes sin problema, pero en cuanto intentaba cotejar contra el SKU del sistema, nada cuadraba. La precisión cayó del 99% del piloto a poco más del 90%. La gente de planta protestó. El proyecto quedó congelado dos meses de retrabajo, y solo la limpieza de datos costó más que todo el piloto.
Esa es la barrera número uno.
Barrera n.º 1: los datos del piloto no viajan al edificio n.º 2
La IA come datos, no presentaciones. Los datos del piloto suelen "renovarse" antes de que empiece el proyecto: el proveedor y el equipo de TI depuran los datos maestros, conectan las interfaces, resuelven los flujos de excepción. ¿Pero el edificio n.º 2? Su WMS puede ir dos versiones por detrás. Sus reglas de códigos de barras se definieron hace una década. Las convenciones de nomenclatura de SKU varían de un edificio a otro, y los códigos de motivo de devolución nunca se estandarizaron.
He visto demasiadas empresas concluir "ya resolvimos el problema de datos" durante el piloto. No — resolvieron el problema de datos del edificio n.º 1. Cada edificio arrastra un bagaje histórico distinto, y cada uno pone un techo a lo que los datos pueden dar. Replicar significa rehacer en cada sitio el trabajo de gobernanza de datos del piloto — y esa partida nunca estuvo en el presupuesto del piloto.
La solución: conviértalo en una regla de hierro en el arranque del piloto. Cada "limpieza de datos puntual" hecha para el piloto debe quedar capturada como un script repetible y un SOP — y probarse en el edificio n.º 2 antes de que el piloto cuente como un éxito.
Barrera n.º 2: el equipo de ensueño del piloto no se transfiere
Detrás de cada piloto exitoso hay un equipo de ensueño: el mejor consultor de implementación del proveedor, el líder de TI más afilado de la central, el gerente de sitio más cooperativo de la red. Esos tres grupos no lo van a seguir a cada edificio.
El problema más difícil es la gente de planta. Los pilotos se dotan con voluntarios — alta energía, alta implicación. En el edificio n.º 2, la primera reacción a "llega la IA" es "¿esto me va a reemplazar?". En 2022 vi un DC de ropa donde los pickers del piloto ayudaban activamente a la IA a corregir sus errores, mientras que los pickers del segundo sitio pegaban deliberadamente las etiquetas torcidas. No fue un fallo tecnológico. Fue un fallo de confianza. El equipo del proyecto dedicó un trimestre entero a capacitación e incentivos antes de que la adopción se recuperara.
Esto tiene dos caras, y ambas importan: la tecnología es la parte fácil de copiar. Las personas son la parte difícil. El éxito del piloto crea la ilusión de que la parte difícil era técnica. Nunca lo fue.
La solución: dele a las "personas" su propia partida en el presupuesto del despliegue. Cada edificio nuevo recibe al menos un veterano del piloto en sitio durante tres meses — capacitación, incentivos, manejo de excepciones, todo. Escatime aquí y estará sembrando minas.
Barrera n.º 3: escalar a múltiples sitios reescribe el ROI
Esta es la que duele. El ROI del piloto suele estar distorsionado: los proveedores descuentan o regalan el POC para ganar el contrato empresarial e incluyen ingenieros en sitio. El piloto corre en su mejor edificio, así que las ganancias se ven enormes. Luego llegan las cotizaciones reales: licencias de software por edificio, tarifas de integración por sitio, soporte facturado por día.
Una vez le expliqué a un cliente las cuentas reales de un proyecto de verificación de picking con visión artificial. El piloto y el despliegue tenían estructuras de costos completamente distintas:
| Partida de costo | Piloto (1 edificio) | Réplica (edificios n.º 2–3, por edificio) |
|---|---|---|
| Licencias de software | Con descuento o gratis | Precio completo, por edificio |
| Integración de sistemas | Una vez, la absorbe TI central | Por edificio; los sistemas heredados cuestan extra |
| Gobernanza de datos | Hecha informalmente por el equipo del proyecto | Rehacer en cada edificio |
| Capacitación y gestión del cambio | El equipo piloto la cubre de lado | Flujo de trabajo separado, presupuesto separado |
| Retornos | Mejor edificio, mayor base | Edificios promedio, ganancias marginales decrecientes |
¿Ve el patrón? Los costos suben, los retornos se atenúan. Un piloto con un ROI precioso no dice nada sobre el ROI del despliegue. Muchos proyectos mueren en el edificio n.º 2 — no porque la tecnología fallara, sino porque el CFO miró las cuentas de la réplica y no firmó.
Y aquí va la opinión contraria: cuanto más exitoso el piloto, más peligroso el escalamiento. El éxito hace que todos subestimen la dificultad de replicar. Los presupuestos se aprueban a la ligera; los obstáculos se imaginan que desaparecen. La jugada de veterano es la opuesta — el día que arranca el piloto, exija la cotización para el edificio n.º 2, y presupueste contra su edificio más difícil, no contra el mejor. Un piloto que sobrevive al edificio más difícil es un verdadero éxito.
Cinco preguntas antes de replicar
En la práctica, antes de dar luz verde al despliegue, responda estas cinco preguntas. ¿No puede responder una? Arregle eso primero.
- ¿Pueden las interfaces de datos y los estándares de datos maestros del edificio n.º 2 reutilizar directamente la configuración del piloto? Si no, ¿qué tan grande es la limpieza?
- ¿Puede el equipo del piloto destinar al menos una persona para integrarse en el edificio n.º 2 durante tres meses?
- ¿Tiene en mano la cotización multisitio del proveedor — por edificio, o en paquete?
- ¿El gerente del sitio del edificio n.º 2 realmente quiere este proyecto, o se lo asignaron desde la central?
- ¿Se recalculó el ROI del despliegue con los números reales del edificio n.º 2, o solo se copió del piloto?
Responda las cinco y sus probabilidades saltan dramáticamente. Falle una, y ya sabe exactamente por dónde empezar.
Un último consejo: la próxima vez que ejecute un piloto de IA, hágale al proveedor una pregunta antes de firmar — "¿Puedo ver ahora mismo la cotización para el almacén n.º 2?". Pregúntelo, y descubrirá que el final de muchas historias de "éxito de piloto" se escribió mucho antes de que el piloto comenzara.
Por Lao Mi, veterano de la cadena de suministro (20 años)
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
