Mi veredicto de entrada: en la apertura de un nuevo almacén, el tiempo de pruebas de integración nunca es suficiente. La única pregunta es si quemas esas horas antes de la puesta en marcha o después, mientras los teléfonos de atención al cliente no dejan de sonar. He visto demasiados proyectos gastar el 80 por ciento de su presupuesto en diseños de ubicación y puesta en marcha de equipos, dejando una sola semana para las integraciones. Luego, el día del lanzamiento, el proveedor del WMS, los transportistas y los marketplaces se echan la culpa unos a otros mientras unos cientos de paquetes permanecen en las estaciones de empaque sin etiquetas de envío.
El entorno de pruebas no es un decorado: alinea los entornos antes de probar nada
En 2024, entré en un sitio nuevo de 120,000 pies cuadrados en Ontario, California, una semana antes de la puesta en marcha para revisar las pruebas de integración. El entorno de pruebas se veía genial: pedido dentro, etiqueta fuera, envío confirmado — una demostración impecable para los ejecutivos. El día del lanzamiento contó otra historia. La plantilla de etiquetas del entorno de pruebas no era la misma que la configurada en producción. La plantilla de producción tenía una regla adicional de dígito de control en el campo del número de seguimiento. Las etiquetas se imprimían, los escáneres las rechazaban y los paquetes se acumulaban en la inducción del clasificador durante media hora mientras toda la línea estaba parada.
La lección es aburrida y concreta: las configuraciones del entorno de pruebas y de producción deben coincidir elemento por elemento — plantillas de etiquetas, modelos de impresoras y controladores, cuentas de transportistas, zonas horarias de los servidores. Fíjate especialmente en las cuentas de transportistas: las credenciales de prueba y las de producción suelen tener permisos diferentes. He visto una cuenta de prueba que podía comparar tarifas e imprimir etiquetas, pero no podía obtener eventos de seguimiento, lo que significó que la ruta del webhook de seguimiento quedó completamente sin probar hasta el día del lanzamiento. Cada desajuste es un incidente del día del lanzamiento esperando a ocurrir. Antes de empezar las pruebas, elabora una lista de verificación de dos columnas — entorno de pruebas frente a producción — y no empieces hasta que cada fila esté marcada.
Una cosa más sobre el entorno de pruebas: cárgalo con datos de forma real, no con datos de juguete. Cinco SKU con una unidad cada uno no revelarán nada. Carga unos pocos miles de SKU, pesos dimensionales reales, los códigos de servicio de transportista que realmente usarás y direcciones con apartamentos, apartados de correos y algún error tipográfico ocasional. La mayoría de los errores de integración que he visto no eran errores de lógica — eran errores de forma de los datos, y los datos de juguete los ocultan todos.
Y el primer día de pruebas, haz que las tres partes escriban la versión de la API que están usando. La documentación de las API de los transportistas se revisa tres o cuatro veces al año, los campos cambian sin aviso, y la versión que probaste en el entorno de pruebas puede no ser la que corre en producción. Hago que todos confirmen el número de versión de producción, por escrito, en la reunión inicial — ahorra una semana de echarse la culpa después.
Prueba los casos feos, no el camino feliz
Todo el mundo prueba el pedido normal. Los pedidos que te matan son las excepciones, así que construye el plan de pruebas alrededor de ellas: direcciones faltantes o malformadas, paquetes con sobrepeso o sobredimensionados, SKU que no existen, inventario negativo, cancelaciones después de iniciado el picking, un pedido dividido en varias cajas, varios pedidos fusionados en uno. Ejecuta al menos tres de cada tipo y verifica que el estado del pedido coincida en los tres sistemas — WMS, marketplace y transportista. El fallo clásico es un desacuerdo a tres bandas: el marketplace muestra "enviado", el WMS sigue diciendo "pendiente de picking" y tu equipo de atención al cliente se entera por los correos furiosos.
Tampoco olvides el ERP. El flujo de recepción de órdenes de compra — ASN entrante, recepción de mercancía registrada, instantánea de inventario sincronizada de vuelta — merece su propia ronda de pruebas. El clásico eterno es el desajuste entre el inventario inicial y el final: el ERP cree que recibiste 500 unidades, el WMS contó 480 y nadie concilia hasta que el cierre de mes se convierte en un ejercicio forense. Ejecuta un ciclo completo de recepción a conteo en el entorno de pruebas y concilia los números antes del lanzamiento, no después.
Hay dos categorías que casi siempre se omiten. Primera, el pedido de pico de volumen: una semana antes del Black Friday, inyecta con scripts veinte mil pedidos al día en el entorno de pruebas y observa si los límites de velocidad y las colas de mensajes aguantan. Diez pedidos por segundo se ven bien en pruebas; doscientos por segundo durante el pico aplastarán una API sin preparar. Lo he visto más de una vez. Segunda, la devolución. Nueve de cada diez sitios nuevos nunca ejecutan una devolución completa en el entorno de pruebas antes del lanzamiento, y la ruta de devolución es una cadena completamente separada — autorización de devolución del marketplace, recepción en el WMS, inspección, almacenamiento, reversión del inventario al marketplace. Si algún eslabón se rompe, las devoluciones quedan en el limbo. La primera semana de devoluciones tras el lanzamiento expondrá cada hueco que no probaste.
Termina cada día de pruebas con conciliación: exporta los estados de pedido de los tres sistemas — marketplace, WMS y transportista — y confirma que el mismo lote de números de pedido muestre estados consistentes en todos. Escribe el script de conciliación el primer día y ejecútalo automáticamente; no lo revises a ojo. Cada desajuste es el error prioritario de mañana.
Día de corte: planea el camino de vuelta antes de planear el de ida
Antes del lanzamiento, define la línea de reversión — por escrito. Si la precisión de salida cae por debajo de un umbral fijado dentro de las dos horas posteriores al corte, o la tasa de errores de la API cruza un límite, reviértete al sistema heredado o a pedidos manuales de inmediato. Cuélgala en la pared de la sala de crisis. No la dejes como "ya veremos cómo va". En el momento, nadie tiene la cabeza para tomar esa decisión; solo puedes ejecutar una regla que escribiste de antemano.
Mantén el sistema antiguo caliente el día de corte. Opera lo antiguo y lo nuevo en paralelo durante medio día a un día completo: los pedidos fluyen a ambos, el despacho sale del sistema antiguo y el nuevo ejecuta validación en sombra. En concreto, eso significa comparar las primeras cincuenta etiquetas que imprime el sistema nuevo con la salida del sistema antiguo, línea por línea — direcciones, niveles de servicio, números de seguimiento — antes de confiarle volumen real. La operación paralela cuesta el doble de mano de obra durante un día. Saltársela significa apostar los pocos miles de pedidos del día de lanzamiento a la esperanza. Mal negocio.
Y cubre el turno de noche: los fallos de integración se concentran en las primeras horas nocturnas después del corte. Desarrollo, el supervisor del almacén y atención al cliente necesitan cada uno a alguien en el sitio o de guardia, en un solo chat grupal, con los datos de contacto fijados. No empieces a llamar buscando gente después de que las cosas se rompan.
¿Cuándo fue la última vez que tu entorno de pruebas ejecutó una devolución completa — devolución iniciada en el marketplace, recepción en el WMS, inspección, almacenamiento, inventario revertido — de principio a fin? Si no puedes nombrar la fecha, retrasa el corte una semana. En las pruebas de integración no existe el "bastante cerca". La producción encontrará cada atajo que tomaste, uno por uno, el día del lanzamiento.
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
