Te doy el veredicto primero: el mayor riesgo en una implementación de WES no es el software. Es salir a producción con reglas de oleadas que nadie aprobó de verdad.
Tu proveedor puede integrar tus sistemas y someter los servidores a pruebas de esfuerzo. Pero la pregunta de cómo un pedido se convierte en un conjunto de tareas de picking… solo tu equipo puede responderla. Si nadie está dispuesto a firmar la respuesta, una implementación de WES es una apuesta, no un proyecto.
He visto demasiados proyectos morir con esta frase: «Saldremos a producción con la estrategia de oleadas como está y la afinaremos después». Dicho sin rodeos: eso es construir sobre arenas movedizas. Parece rápido hasta que intentas vivir ahí.
Aquí va una que viví yo. 2022, un almacén 3PL en Inland Empire, de unos 120,000 pies cuadrados, enviando unos 12,000 pedidos al día — una mezcla de paquetería de e-commerce y venta al por mayor para algunas marcas pequeñas. Durante el blueprint fijamos las reglas de oleadas: cortar las oleadas por hora de corte de los pedidos, cada oleada cubriendo 90 minutos de pedidos, las cuentas clave en sus propias oleadas. Tres rondas de pruebas, y la orquestación de tareas, las rutas de picking y los destinos de clasificación cuadraban. El equipo de implementación creía que esta ya estaba en el bolsillo.
Tres días antes del cutover, el VP de Operaciones decidió recortar las oleadas por transportista — pedidos de UPS en una oleada, los de FedEx en otra — porque así sería más fácil cumplir las horas de cierre de los tráileres. Una frase, tres meses de estrategia a la basura. El equipo reconfiguró las reglas durante la noche. ¿Retestar? Sin tiempo. Directo a la puesta en marcha.
Día del cutover, 10 a.m. Cayó la primera oleada y el WES mandó a casi todos los pickers al mismo pasillo. Al recortar por transportista, la distribución de ubicaciones de los pedidos había cambiado por completo, y cada supuesto de densidad del motor de tareas estaba mal. Los pickers hacían cola en el pasillo esperando tareas. El clasificador funcionó vacío durante casi dos horas. No se cumplió ni una sola hora de corte de la tarde. Esa noche volvimos a las reglas de oleadas del blueprint, y el sistema no se estabilizó hasta la mañana siguiente. Una ida y vuelta quemó un día entero de throughput — más las penalizaciones de los clientes por entregas tardías.
Dos caras de esto. La parte técnica: cambias las reglas de oleadas y el WES tiene que recalcular la orquestación de tareas, la asignación de mano de obra y el ritmo de los equipos — todo se mueve a la vez, y no existe tal cosa como «solo un pequeño cambio». La parte de gestión: ¿por qué las reglas aún podían cambiar tres días antes del cutover? Porque nadie se atrevió a firmar durante el blueprint; el VP no paraba de decir «déjame pensarlo». Después de todos estos años en implementación, he aprendido que los problemas técnicos siempre tienen soluciones alternativas. Los problemas que nadie quiere decidir son los que te matan.
Así que aquí está la checklist que entrego a cada almacén a punto de implementar un WES. Ocho puertas, una línea de aceptación cada una. Si no puedes pasar la línea, no sigas — seguir significa apostar la temporada alta a la esperanza.
Puerta uno de la implementación de WES: congela el blueprint, firma cada cambio
El momento más peligroso de todo el proyecto es la noche antes de la puesta en marcha, cuando alguien con autoridad decide que las reglas de oleadas necesitan «un pequeño ajuste». Congela el blueprint: estrategia de oleadas, prioridades de tareas y flujos de excepción, todo firmado y sellado. Después del congelamiento, cada cambio pasa por una orden de cambio formal. Las peticiones verbales no cuentan. Quien quiera un cambio firma con su nombre — esa sola regla filtra el noventa por ciento de las ideas de último minuto.
La checklist de aceptación de puesta en marcha de WES en 8 puertas
| # | Puerta | Qué significa «hecho» |
|---|---|---|
| 1 | Congelamiento del blueprint | Estrategia de oleadas, prioridades de tareas y flujos de excepción firmados; cualquier cambio posterior al congelamiento requiere una orden de cambio formal |
| 2 | Datos maestros listos | Maestros de SKU, códigos de ubicación y especificaciones de empaque cargados; verificación puntual de ubicaciones físicas contra el sistema, cero registros maestros faltantes |
| 3 | Pruebas de integración | WMS, clasificador, pick-to-light e impresoras hablando entre sí; haz un simulacro de caída de red y uno de equipo caído — ni mensajes perdidos ni duplicados |
| 4 | Configuración de oleadas y tareas | Reglas configuradas según el blueprint; reproduce al menos tres rondas de pedidos históricos reales y revisa a mano las asignaciones de tareas |
| 5 | Pruebas de esfuerzo | Prueba con el volumen de temporada alta, no con el volumen promedio; el despacho de tareas se mantiene receptivo y nada se cae en pico |
| 6 | Corrida en paralelo | Los sistemas nuevo y viejo corren lado a lado; conciliación pedido por pedido, tres días seguidos con cero varianza antes de hablar de cutover |
| 7 | Ventana de cutover | Elige el turno de menor volumen; duplica la dotación en el turno de cutover y mantén el sistema viejo caliente y listo para retroceder |
| 8 | Hypercare | De dos a cuatro semanas tras la puesta en marcha; equipo central en sitio, incidencias clasificadas por severidad, las críticas con un decisor en menos de dos horas |
Dos puertas merecen atención extra. La corrida en paralelo es donde la mayoría de los equipos hacen trampa — la corren un día, miran por encima unos pocos pedidos y la dan por buena. Tres días seguidos de cero varianza es la línea. Suena lento; es más barato que un retroceso. Y el hypercare no es «la línea de soporte del proveedor». Es tu propio equipo central, físicamente en el edificio, con autoridad para tomar decisiones. Una línea de soporte no puede decidir si recortar una oleada a las 2 a.m. Tu líder de turno sí — si le diste esa autoridad por escrito antes de la puesta en marcha.
¿Big bang o almacén por almacén? Dos caras
Aquí va el dilema del que nadie quiere hablar. Un cutover big bang concentra el riesgo: si falla, todo el edificio se detiene. La recompensa es que el dolor es corto — el equipo se concentra una vez, y no mantienes dos lógicas de proceso en paralelo. Encaja en un solo edificio con volumen diario manejable y operaciones sencillas.
Un cutover por fases, almacén por almacén, reparte el riesgo: la falla de un edificio no toca a los demás, y las lecciones del edificio uno se transfieren directamente al edificio dos. El costo es un cronograma más largo, doble sobrecarga de gestión durante el solapamiento y lógica especial para transferencias entre almacenes. Encaja en redes multisitio, o en un solo sitio cuyo volumen es tan grande que un día detenido duele de verdad.
Mi recomendación: un edificio, corta una vez, no lo alargues. Varios edificios, córtalos uno por uno, no te vuelvas avaricioso. El peor patrón es «por fases de nombre, pero todos los edificios persiguiendo la misma fecha límite» — pagas ambos costos y no recoges ningún beneficio.
Una opinión contraria antes de cerrar: la mayoría piensa que el mayor riesgo en la puesta en marcha de un WES son los bugs de software. Dicho sin rodeos: los bugs siempre tienen soluciones alternativas. Lo que mata proyectos es salir a producción con reglas de oleadas que nadie decidió de verdad. Con las reglas resueltas, hasta un sistema mediocre funciona bien. Sin ellas, la configuración más bonita es solo adivinanza.
Así que deja de preguntarme qué proveedor de WES elegir. Pregúntense primero esto: ¿hay alguien dispuesto a firmar el documento de reglas de oleadas? Si no, el proveedor no importa.
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.
