Elegir mal el segundo proyecto para escalar la IA en un pequeño almacén cuesta más que un primer piloto fallido. Un primer piloto fallido cuesta un experimento. Una segunda elección equivocada cuesta la confianza del personal de planta en cada sistema nuevo que venga después. He visto pequeños almacenes acertar con el primer piloto, y luego dejarse llevar por la ambición en el segundo, y el equipo nunca volvió a creer en otra herramienta. Dicho sin rodeos, el segundo proyecto no es un premio. Es una prueba de si se ha aprendido moderación.
Esa es la disyuntiva que nadie pone en la presentación comercial. Por un lado, el segundo proyecto es la expansión más barata que jamás se conseguirá: los datos ya fluyen, la gente ya conoce la primera herramienta y añadir un departamento adyacente cuesta menos que empezar de cero en otro lugar. Por otro lado, es un amplificador de riesgo. El primer piloto tocó a un equipo; un segundo proyecto en un departamento compartido toca a todos. Así que aquí va mi conclusión desde el principio: elige exactamente un departamento, resuelve exactamente un problema concreto y mantenlo estable durante tres meses antes de hablar de un tercero. La ambición es el hábito más caro en la adopción de IA en pequeños almacenes.
Aprendí esto viendo cómo otro pagaba por ello. En marzo de 2024, un pequeño almacén de repuestos de automóvil en las afueras de Ontario, California, con poco más de 40 personas en dos turnos, llevó a cabo un primer piloto magnífico. La IA ayudó al equipo de recepción a cotejar la documentación de entrega con la mercancía física, y los errores de recepción bajaron de 7 por semana a 1 por semana en tres meses. El propietario, impulsado por ese impulso, hizo que el segundo proyecto fuera un pronóstico de recuento cíclico para todo el almacén: el sistema diría a cada ubicación qué contar y cuándo. Sonaba como un paso natural. En la práctica, el recuento cíclico toca todo el edificio. Necesita datos de ubicación precisos, saldos disponibles precisos y datos maestros precisos, y si cualquiera de ellos falla, el pronóstico sale mal. En la segunda semana después de la puesta en marcha, el sistema marcó existencias muertas de lento movimiento como recuentos prioritarios durante tres días seguidos. Dos trabajadores del turno de noche quemaron 6 horas contando artículos cuyos registros ya eran correctos. Para la tercera semana, el equipo de recuento había vuelto discretamente a elegir los recuentos por experiencia e ignorar el sistema. El daño no fue la factura del software. Fue la confianza. El propietario lo admitió después él mismo: la segunda elección no era el problema más doloroso, era la que sonaba más impresionante.
Ese fracaso se convirtió en mi regla de selección. Un segundo proyecto no puede elegirse por intuición, ni a partir de la página más llamativa de una demostración de proveedor. Tiene que superar tres pruebas exigentes. ¿Los datos ya están ahí, generados cada día sin correcciones manuales? ¿Qué cuesta una respuesta equivocada: un recorrido más largo, o un envío erróneo y una línea parada? ¿Y el personal de planta realmente lo quiere: el responsable de ese equipo ha planteado él mismo este problema, o la dirección está imponiendo una herramienta a un equipo que nunca la pidió? Si alguna de las tres falla, aparca la idea. Prefiero ver un segundo proyecto pequeño y un poco aburrido que uno grande e impresionante.
| Departamento candidato | ¿Los datos ya están ahí? | Costo de una respuesta equivocada | ¿Lo planteó el personal de planta? | Adecuación como segundo proyecto |
|---|---|---|---|---|
| Sugerencias de reposición | Los registros de pedidos e inventario ya existen | Una sugerencia errónea se detecta en la revisión antes de enviar | Los preparadores se quejan de roturas de stock | Sí |
| Pronóstico de recuento para todo el almacén | Depende de la precisión del inventario disponible | Una mala semana desperdicia el tiempo de todo el equipo de recuento | Nadie lo planteó | Todavía no |
| Optimización de rutas de picking | Los datos de ubicación y pedidos ya existen | Una ruta equivocada significa caminar más, no un envío erróneo | Los veteranos se quejan de retrocesos | Sí |
| Programación automatizada | Necesita asistencia y reglas laborales | Un mal horario afecta directamente a la asistencia | Los jefes de equipo se resisten | Todavía no |
Segundo proyecto para escalar la IA en un pequeño almacén: tres pruebas exigentes antes de elegir un departamento
Esta tabla no es un juego de puntuación. Te obliga a decir el costo en voz alta. La reposición funciona como segundo proyecto no porque la tecnología sea avanzada, sino porque falla de forma segura: una mala sugerencia es visible en la revisión, se corrige y ningún pedido erróneo se envía por su culpa. La optimización de rutas de picking es la misma historia. Caminar más es un costo, no un accidente. Aquí va el juicio contraintuitivo que la mayoría de los propietarios entienden al revés: el segundo proyecto a menudo no debería ser el departamento más doloroso. El departamento más doloroso suele ser el más enredado y el más sucio en términos de datos, y un equipo que acaba de terminar su primer piloto aún no tiene la fuerza para desenredarlo. Elige un departamento donde un error sea barato y corregible, genera confianza ahí y espera hasta que el personal de planta empiece a preguntar cuándo le toca a su departamento. Solo entonces ve a por el problema más difícil. El orden importa más que la ambición.
El orden de expansión para un segundo proyecto de escalado de IA en un pequeño almacén
En cuanto al orden, solo confío en lo cercano a lo lejano. Cercano significa el departamento de al lado del primer piloto: los mismos datos, la misma gente, el mismo turno. Si el primer piloto vivía en recepción, el segundo proyecto debería mirar a la reposición o al guardado de al lado, no saltar directamente a la verificación de salida o a un pronóstico para todo el edificio. Lejano no significa nunca. Significa más tarde, después de que lo cercano esté estable. En enero de 2025, un pequeño almacén de artículos para el hogar cerca de Dallas hizo exactamente esto. Su primer piloto asistía la verificación de salida. Su segundo proyecto solo dividía los pedidos con excepciones en ese paso: los pedidos con documentación poco clara o cantidades dudosas pasaban a manejo manual enfocado, mientras los pedidos limpios seguían fluyendo. En tres meses, el manejo promedio de excepciones bajó de 9 minutos por pedido a 4 minutos, sin personal adicional y sin aumento de envíos erróneos. Cuando el propietario propuso después un tercer departamento, el responsable de verificación asintió primero. Eso es lo que parece un buen orden: el personal de planta tirando del siguiente proyecto hacia adelante, no la dirección empujándolo hacia abajo.
En cuanto al ritmo, mi regla es estricta. Durante las dos primeras semanas después de la puesta en marcha, revisa el registro de errores cada día; a partir de la tercera semana, semanalmente. A los tres meses, haz una revisión formal y haz solo tres preguntas: ¿este departamento realmente ahorró tiempo o redujo errores?, ¿el equipo lo echaría de menos si desapareciera?, ¿alguien se opondría si lo apagaras mañana? Si dos respuestas son no, no te apresures a un tercer proyecto. Arregla primero el segundo.
También se pasa por alto con demasiada frecuencia un punto de personal. El segundo proyecto necesita un responsable de planta, y ese responsable tiene que ser el jefe del departamento o un veterano de ese departamento, no alguien que solo gestione el software. Un proveedor puede enseñar clics de botones. Solo el jefe sabe qué excepción aparece con más frecuencia, qué horas no pueden permitirse un error y qué palabras escuchará realmente el equipo. He visto un segundo proyecto con excelente soporte técnico y sin responsable de planta: las sugerencias chocaban con el plan real de turnos, el equipo de noche improvisaba por su cuenta y, al cabo de un tiempo, nadie revisaba la herramienta en absoluto. Media hora al día en el registro de errores y una revisión semanal con el jefe es suficiente. Sin esa persona, no empieces.
Escribir la línea de parada en el calendario
Una línea de parada que solo vive en un plan de proyecto no es una línea de parada. He visto muchos planes que dicen «para si los resultados decepcionan», y cuando llegó ese día, nadie quiso admitir que la elección era equivocada. Así que antes de que empiece el segundo proyecto, el propietario, el jefe del departamento y el jefe deberían acordar juntos tres líneas: errores o retrabajo superiores a antes de la puesta en marcha durante dos semanas seguidas, para; un turno sorteando el sistema durante cinco días seguidos, para; mantener la herramienta viva costando más de 4 horas de trabajo por semana sin ahorrar al menos eso mismo, para. Cualquier línea activada significa dos semanas de vuelta al método anterior, y luego una decisión: arreglarlo o abandonarlo. Parar no es fracasar. Negarse a parar sí lo es.
Un último consejo, dirigido al propietario más entusiasmado justo después de que el primer piloto funcione: el mayor costo del segundo proyecto no es la cuota del software. Es la atención que quitas al envío mientras todo el edificio aprende algo nuevo. El envío no puede pausar, y la confianza no puede sobregirarse. Elige un departamento donde un error sea barato, mantenlo estable durante tres meses y deja que el personal de planta pida el siguiente. Eso es lo que realmente parece escalar. ¿Cuál de las tres pruebas exigentes suspende tu segundo proyecto ahora mismo?
Por Lao Mi, Veterano de la cadena de suministro (20 yrs)
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
