El mes antes de la temporada alta es mi época más ocupada del año — no instalando equipos, sino yendo de almacén en almacén preguntando: ¿ya hicieron sus pruebas de carga del WCS? Ocho de cada diez gerentes dicen que sí. Luego pregunto cómo. "Corrimos una ola normal. Salió bien." Cada vez, quiero quitarme el casco. Una ola normal es una fracción de la carga pico — es como juzgar un sprint por un trote matutino.
Probar la carga del WCS no es complicado, pero nueve de cada diez almacenes lo hacen mal. Aquí va la checklist.
Primero, sé claro: qué estresa realmente una prueba de carga del WCS
Una frase para lectores no automatizadores: el WCS (Warehouse Control System) es el comandante de todo el equipo automatizado. El WMS dice "embarca estos pedidos", y el WCS lo traduce a lenguaje de máquina: qué conveyor arranca, qué chute recibe las cajas, qué elevador va a qué nivel. Los PLCs son los jefes de escuadra; el WCS es el cuartel general.
Una prueba de carga nunca estresa realmente el CPU del servidor del WCS — anda en 20% a 30% en un día normal, y llevarlo al máximo no prueba nada. Es un examen físico que solo te pesa. Tres líneas sí importan:
Primero, el canal de mensajes WCS–WMS. En pico, el WMS le arroja cientos de tareas por segundo al WCS; si la cola no las digiere, las tareas se acumulan mientras el equipo espera ocioso — los teléfonos del cuartel general saturados, la línea del frente esperando.
Segundo, el ciclo de scan del PLC — el bucle fijo de leer señales, correr lógica, enviar comandos, normalmente de unos pocos a diez y tantos milisegundos. A plena carga el volumen de señales explota, el ciclo se estira, el equipo se mueve "medio tiempo tarde", el espaciamiento de cajas sale mal: así nacen los atascos.
Tercero, el jitter de red. WCS, PLCs, escáneres, paneles HMI cuelgan todos de una red industrial. Cuando la inundación de datos golpea en pico, los puertos del switch se llenan: pérdida de paquetes, retransmisiones, latencia. Lo irritante es que esta falla nunca aparece en un día tranquilo — una prueba de carga que no llega lo suficientemente lejos nunca la encontrará.
Cualquiera de las tres puede fallar primero con el mismo síntoma: todo atascado. Pero las causas raíz y las soluciones difieren, así que no preguntes solo "¿corrió bien?" — saca los datos de cada línea por separado.
Usa las olas del año pasado como examen: la checklist
¿Qué datos? Mi respuesta nunca cambia: repite las olas históricas reales del pico anterior, sin editar. Los datos sintéticos siempre son subconscientemente "razonables" — y los datos reales de pico nunca lo son. Tres SKUs calientes atascados en un chute, una ola de devoluciones chocando con una ola de salida, una zona sin stock forzando replanificación de tareas. Los gremlins en los datos reales de olas son cosas que nunca inventarías.
El manual de jugadas:
Paso uno, fija la meta: el volumen de la ola más alta de una sola hora del pico anterior por 1.2. El negocio siempre dice "crecemos 20% este año" — mete el margen. Un sistema que no aguanta 1.2x explotará en la noche pico.
Paso dos, arma el ambiente de prueba: aislado de producción, pero WCS, programas PLC y topología de red idénticos. Probar en producción "cuando no hay pedidos" es pecado capital — nunca te atreverías a correr producción a plena carga.
Paso tres, repite las olas: usa la interfaz de historial del WMS en un cronograma comprimido. Conserva las huellas originales — picos y valles, concentración de SKUs, proporciones de excepciones. No "embellezcas" ni una.
Paso cuatro, observa tres juegos de números: profundidad de cola del WCS y latencia de despacho, ciclo de scan máximo del PLC, utilización de puertos de red y pérdida de paquetes. Observar solo "¿se atascó?" es un examen físico que solo te pesa.
Paso cinco, córrelo el tiempo suficiente: cuatro horas continuas a plena carga. Muchas fallas son crónicas — fugas de memoria, protección térmica de motores, deriva de bandas — invisibles hasta la hora dos o tres. Treinta minutos es un ensayo, no una prueba.
Noviembre de 2024, un almacén de e-commerce de ropa en el este de China. Su "prueba de carga": una hora al 70% de la carga normal, y un informe hermoso. A la 1 a.m. del Double 11, el tronco principal del conveyor se atascó: el ciclo de scan del PLC se había estirado, las señales de sorteo llegaron medio tiempo tarde, las cajas se chocaron por detrás. Más de cuarenta personas pasaron a manual hasta las 6 a.m. Su propio post-mortem: las pérdidas de esa noche habrían pagado veinte pruebas de carga bien hechas.
Contraejemplo: agosto de 2025, un 3PL de la costa oeste de EE. UU. preparándose para Black Friday repitió las olas del año anterior a 1.2x por seis horas seguidas. En la hora cuatro, un problema real: el algoritmo de asignación de chutes del sorter se degradaba a plena carga. En días normales los SKUs se reparten y el algoritmo aguanta; cuando los bestsellers de pico se concentran, amontona cajas en el mismo chute y solo alarma cuando está lleno. Esto nunca lo cazas al 70% de carga — el punto de quiebre está justo alrededor del 90%. Dos semanas reescribiendo la ponderación, y la noche de Black Friday corrió limpio. El gerente lo llamó las dos semanas mejor invertidas de su año.
Las líneas de pasa/no pasa: líneas rojas que no cruzas
La tabla de "vida o muerte" que entrego a clientes — cruza una línea roja y no dormirás esa noche:
| Métrica | Pasa | Línea roja (arreglar antes del go-live) |
|---|---|---|
| Throughput de olas por hora | Alcanza 1.2x del pico anterior | Debajo de 1.1x |
| Latencia de despacho de tareas del WCS | 95% despachado dentro de 1 segundo | Cualquier rezago que exceda 5 segundos |
| Ciclo de scan del PLC | Máximo no más de 1.5x de lo normal | Jitter que causa movimiento visiblemente entrecortado del equipo |
| Atascos de conveyor | Cero atascos en 4 horas | Uno o más atascos |
| Pérdida de paquetes de red | Cero pérdida en toda la corrida | Cualquier pérdida de paquetes observable |
| Tiempo continuo a plena carga | 4 horas con cero intervención manual | Necesita reinicio manual o desatasco |
La gente me dice: "un atasco es normal, lo desatascamos a mano". El staffing de la noche pico está planeado para olas normales; mandar gente a desatascar a plena carga es como pedirle a los bomberos que busquen una manguera al llegar al incendio.
Dónde suelen salir mal las pruebas de carga
Trampa uno: el ambiente de prueba es "suficientemente parecido". Una versión de firmware distinta, un switch de menos, cada resultado es un placebo. Lo peor que he visto: el ambiente de prueba corría un backup del WCS de tres meses atrás. Prueba limpia, gran celebración — luego un parche en la nueva versión cambió un timeout de la cola de mensajes, y todo se cayó la noche del go-live. Antes de cualquier prueba de carga: copia todos los números de versión de producción y emparéjalos uno por uno.
Trampa dos: pruebas el equipo pero no a la gente. Alarmas del WCS, pop-ups del HMI, procedimientos de excepción — en la noche pico los humanos hacen clic en todo eso. Inyecta fallas durante la prueba — desconecta un escáner, simula un chute lleno — y mira si la persona de turno puede seguir el manual en cinco minutos. El equipo es de hierro; la gente se congela. El chico de turno a las 3 a.m. podría llevar dos meses en el puesto.
Trampa tres, la más contraintuitiva: el eslabón más estresado rara vez es el primero en romperse. El WCS es software — bajo presión es "honesto", se ralentiza o lanza errores. Los tramposos son los vecinos "confiables": PLCs, escáneres, switches. Una tasa de lectura de escáner bajando de 99.9% a 97% a velocidad parece tres puntos; a volumen pico es un desastre. Un puerto de switch al 90% de utilización está bien en un día tranquilo, pero el tráfico en ráfaga empieza a tirar paquetes de inmediato. Mi consejo de trade-off: apunta el setenta por ciento de tu potencia de fuego a interfaces y fronteras, treinta por ciento al WCS mismo. No lo conviertas en un concurso de benchmarks del WCS — a los vendedores les encanta; no sirve para tu noche pico.
Un trade-off más: ¿empujar hasta el límite físico del equipo? Para en 1.2x del pico de negocio. Los motores a plena carga sostenida reciben un golpe al MTBF (tiempo medio entre fallas) — quemar vida útil del equipo para probar un extremo es ahorrar centavos. El verdadero enemigo del pico nunca fueron los pocos minutos de pico absoluto; son las largas horas de carga alta sostenida. La prueba de carga es una carrera de resistencia, no un sprint.
Si el dinero valió la pena se reduce a un número
Cada conversación termina igual: el ambiente, la gente, el downtime — ¿vale la pena? Los números de abajo son hipotéticos — pon tus propias cifras; la fórmula es lo real:
Digamos que tu pico hace 10,000 pedidos por hora con $60,000 de margen por hora. Un atasco de dos horas fuerza sorteo manual a un tercio de la eficiencia — 14,000 pedidos pierden su hora de embarque. Reembolsos, malas reseñas, penalizaciones de plataforma, más horas extra para cuarenta personas: un incidente quema varios cientos de miles de yuanes sin pestañear.
¿Una prueba de carga bien hecha? El ambiente aislado (muchos integradores lo regalan) más una semana del tiempo de dos o tres personas — decenas de miles de yuanes. Así que se reduce a un número: toma tu volumen más alto de una sola hora del pico anterior, multiplícalo por 1.2, y pregunta si tu sistema puede tragárselo. Si sí, el seguro más barato del edificio. Si no, cada yuan "ahorrado" está financiando colectivamente el accidente de la noche pico.
Un mes antes del pico, deja de preguntar "¿deberíamos probar la carga?". ¿Están listas las olas históricas? ¿Te atreves a escribir la meta de 1.2x en el informe? Si sí, ve a estresarlo; si no, todavía hay tiempo.
Por Da Liu, ingeniero de automatización
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
