Pregunta rápida: ¿qué hace su WCS cuando un paquete se atasca en la confluencia a las 2 a.m., el escáner empieza a fallar lecturas y alguien pulsa la parada de emergencia, todo en la misma hora? Si su respuesta honesta es "lo descubriremos el día de la puesta en marcha", siga leyendo. Yo estuve en ese edificio ese día, viendo a docenas de personas mirar fijamente un transportador que simplemente... se había detenido. El WCS decía una cosa, el WMS decía otra, y la cara del gerente del proyecto lo decía todo.
Casi todos esos desastres eran evitables. El método tiene un nombre poco glamoroso: comisionamiento virtual, y significa exactamente lo que parece: antes de que se levante el acero, usted hace que el WCS real crea que el equipo ya existe, y lo somete a una prueba dura. Ejecuta pedidos, rompe cosas, corrige la lógica. Romper cosas en un entorno virtual es gratis. Romperlas en sitio cuesta dinero cada minuto.
Lo que realmente está probando
En una frase: un software modela todo su sistema de transportadores y clasificación, y el WCS real se conecta y lo ejecuta. La simulación construye su línea según el diseño — la longitud, cuántas tolvas de desvío, dónde están los escáneres, dónde está el carril de rechazo — y el WCS emite comandos exactamente como lo haría en sitio. El modelo responde según la física: el peso del paquete, la velocidad de la banda, lo que ocurre cuando el flujo se congestiona.
Una distinción que la gente confunde constantemente: la simulación es virtual contra virtual, útil para validar la lógica del proceso. La emulación es el WCS real moviendo equipos virtuales, y eso es lo que valida la lógica de control. Antes de la puesta en marcha, usted quiere emulación, y el WCS bajo prueba debe ser exactamente la versión que va a producción, ni una línea de código diferente. Una prueba en verde con una versión de demostración seguida de un cambio a la versión de producción es una prueba desperdiciada.
Insisto en que el entorno de emulación se construya durante las pruebas de aceptación en fábrica, no después de que el equipo se envíe. Una vez que el acero empieza a levantarse en sitio, la presión del cronograma comprime el comisionamiento a un tercio de lo planeado, y cada problema sin resolver viaja con usted hasta el día de la puesta en marcha. En la fábrica, cuando la lógica está mal, un ingeniero corrige el código del PLC o la lógica del WCS en casa. En sitio, lo hace rodeado de grúas, andamios y un responsable de seguridad: el costo psicológico de cambiar una línea de código es completamente distinto.
Inyección de fallos: pruébelo en su peor momento, a propósito
Diez mil pedidos limpios le enseñan menos que cien pedidos feos. El mayor valor del comisionamiento virtual es el sabotaje sin consecuencias. ¿Atascaría deliberadamente un clasificador en vivo? En el mundo virtual, atáquelo todo el día y restablezca con un clic.
Mi lista obligatoria de fallos es la siguiente. Atascos: bloquee la tolva de desvío, la rampa inclinada y la confluencia — uno a la vez — y observe qué tan rápido lo detecta el WCS, si la alarma es precisa y si la secuencia de recuperación funciona de verdad. Fallos de lectura: lecturas fallidas consecutivas, códigos de barras dañados, dos paquetes parecidos uno tras otro — ¿la lógica de rechazo expulsa limpiamente el paquete problemático, o lo recircula para siempre? Un paquete malo recirculando sin fin es el modo de fallo más tonto que existe; un solo artículo malo puede arrastrar el rendimiento de toda la línea. Parada de emergencia: púlsela en momentos aleatorios — ¿la secuencia de apagado es correcta, se conserva el estado del pedido al recuperarse, se "olvida" algún paquete en un tramo de banda? Pérdida de red: corte el enlace WCS–WMS por unos minutos — ¿los mensajes se pierden o se ponen en cola, y los dos sistemas se reconcilian después?
Después de cada categoría de fallo, exija tres cosas al proveedor: los registros del sistema de ese momento, los registros de alarmas del WCS y cuánto tomó la recuperación. Esa es su historia clínica para solucionar problemas en la puesta en marcha. Un proyecto sin estas historias vuelve a diagnosticar desde cero cada vez que algo se rompe: media hora de inactividad por cada suposición.
La interfaz WCS–WMS es donde mueren los proyectos
La mitad de los fallos de automatización son equipos. La otra mitad es la interfaz. El WCS mueve las máquinas, el WMS es dueño de los pedidos y el inventario, y se reconcilian mediante mensajes. Cuando la interfaz miente, el piso miente con ella: el WMS cree que envió el pedido, el WCS dice que nunca llegó; la clasificación termina, el inventario nunca se descuenta; un parpadeo de red y cada lado lleva sus propios libros.
Pruebe la interfaz en el peor caso, en tres partes. Primero, reconciliación de mensajes: después de una corrida por lotes, compare el estado de los pedidos, los conteos de piezas y los resultados de clasificación línea por línea entre los dos sistemas. Ni una sola línea puede diferir — y observe: línea por línea, no totales. Totales que coinciden con líneas revueltas es un problema peor y más traicionero. Segundo, latido y reconexión: simule fluctuaciones de red y observe si hay mensajes perdidos al reconectar, y si los reintentos causan dobles clasificaciones. Una doble clasificación es el error de interfaz más caro que existe: un pedido clasificado dos veces, el cliente recibe dos paquetes, y las devoluciones más el costo de servicio al cliente llegan de inmediato. Tercero, pedidos de casos límite: sobredimensionados, con sobrepeso, de múltiples piezas, cancelados en pleno vuelo — los "pedidos raros" que el WMS sin duda enviará. Los pedidos normales corren en cualquier lugar. Los pedidos raros son la verdadera prueba.
Los criterios de aceptación pertenecen al contrato
El comisionamiento virtual no es "funciona, envíelo". Los criterios de aceptación van en el contrato al firmarlo. El mío tiene tres líneas, y no firmo sin las tres.
Primero, operación continua sin supervisión. Ejecute la emulación al rendimiento de diseño con cero intervención humana: pido ocho horas como mínimo. Esta es la línea más fácil de trampear: a los proveedores les encanta la "operación continua" con un operador rondando, listo para rescatar. Eso no es sin supervisión. Mi regla: durante la prueba, los operadores pueden mirar pero nunca tocar. Un toque reinicia el reloj. ¿Duro? Claro. El día de la puesta en marcha no ofrece reinicios, y los pedidos de temporada alta no lo esperarán.
Segundo, precisión de clasificación. Tolva equivocada, desvío perdido, excepción no rechazada: todo cuenta como error, y la tasa permitida va en el contrato como un número, dimensionada a su tolerancia de negocio. "Lo más preciso posible" no es un estándar. Un estándar sin número no es un estándar.
Tercero, tiempo de recuperación de fallos. Tiempo máximo permitido desde la alarma de atasco hasta la operación normal: si lo excede, no pasa. Esta línea es para el equipo de operaciones: cuando suene la alarma de las 2 a.m. después de la puesta en marcha, la persona de guardia necesita saber cuánto debería tomar y cuándo escalar. Los tiempos de recuperación medidos en el comisionamiento virtual son la base de esa línea.
El comisionamiento virtual suele consumir entre el cinco y el diez por ciento del tiempo total del proyecto. Parece un costo; en realidad es la cobertura de riesgo más barata que jamás comprará. Un día de comisionamiento en sitio — mano de obra, aparejos, líneas detenidas — le compra cientos de miles de pedidos virtuales. Recuerde esto: cada error que no cometa en el entorno virtual se paga con intereses el día de la puesta en marcha.
Una última pregunta: ¿fue el comisionamiento virtual idea de su proveedor, o tuvo que exigirlo usted? Si fue de ellos, felicidades: eligió al proveedor correcto. Si fue suya, pídalo ahora. Aún hay tiempo, siempre que el acero no esté levantado todavía.
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
