Esto es lo que nadie te cuenta sobre los go-lives de un WMS: el software rara vez es el problema. El problema es la primera semana.
He visto go-lives en los que el sistema pasó todas las pruebas, todas las interfaces devolvieron verde y el plan de corte tenía 40 páginas — y aun así, a las 9 a.m. del primer día el almacén estaba en llamas. Procesos nuevos, códigos de ubicación nuevos, dispositivos nuevos, todo cayendo la misma mañana sobre personas que aprendieron el nuevo flujo en una sesión de capacitación de dos horas tres semanas antes. La sala de guerra es lo único que se interpone entre ese caos y un corte de transportista perdido. Pero la mayoría de las salas de guerra que he visto son solo unas pocas personas sentadas respondiendo teléfonos. El incendio arde igual, porque nadie decidió de antemano cómo sería realmente la primera semana.
Los tres incendios que combatirás, garantizado
El primer incendio son los datos maestros. Códigos de barras que no escanean, códigos de ubicación que no coinciden, conversiones de unidades de medida incorrectas. En 2023 apoyé un go-live en un almacén 3PL de 120,000 pies cuadrados en Ontario, California. Para cumplir con la fecha límite, el equipo aplazó la carga de códigos de barras de más de 200 SKU de baja rotación a "después del go-live". Cada mañana de la semana uno, una docena de oleadas de pedidos se atascaban en la estación de auditoría porque no había código de barras que escanear, y los auditores tenían que rebuscar entre las cajas a mano. Cero dificultad técnica, puro trabajo de preparación incompleto — y el incendio más desgastante de la semana. Nunca te mata, solo arde todos los días.
El segundo incendio son las interfaces. Del WMS al OMS, a los transportistas, al EDI — algo fallará en la semana uno. Los pedidos no bajan, las actualizaciones de estado se pierden, una liberación de oleada muere a mitad de camino. Lo desagradable es que el almacén no puede ver este tipo de problema: los operarios solo saben que "no hay pedidos para surtir". Si la sala de guerra no está vigilando las colas de interfaces, te enteras dos horas después cuando el rezago ya está en miles. Y aquí viene lo peor — a menudo no es culpa del WMS en absoluto. La otra parte cambió un campo y olvidó avisarte. Por eso la sala de guerra necesita a alguien que sepa leer registros y conseguir al ingeniero de la otra parte por teléfono con una sola llamada.
El tercer incendio son las personas. El nuevo flujo se siente incómodo, así que los trabajadores lo rodean discretamente: surten en papel primero y lo registran en el sistema después; se saltan el RF porque escribir a mano es más rápido. Si no matas estos procesos fantasma en la semana uno, nunca lo harás. Una vez que los datos se ensucian, la exactitud del inventario nunca se recupera. De los proyectos que he visto aún conciliando inventario tres meses después del go-live, nueve de cada diez enterraron el problema en la semana uno. Mi regla de sala de guerra: la primera vez que alguien se salta el sistema, es una conversación ese mismo día. La segunda vez, va directo al gerente del almacén. Suena duro. Es la única forma de proteger los datos.
Quién está en la sala de guerra importa más que dónde está
La configuración que mejor funciona es una o dos personas de cada uno de tres lados. Operaciones envía un supervisor de almacén — alguien que conozca el proceso y pueda tomar decisiones como "este pedido puede salir manualmente". TI envía a la persona de interfaces e infraestructura — alguien que pueda leer registros y reiniciar un servicio sin abrir un ticket. El implementador envía un consultor que conozca la configuración — alguien que pueda corregir un parámetro erróneo en el acto. Los tres son innegociables. Sin operaciones, los incidentes no se pueden clasificar. Sin TI, los problemas de interfaces reciben miradas en blanco. Sin el implementador, un elemento de configuración puede paralizarte medio día.
Trabaja en dos turnos, no tres. El turno temprano cubre la liberación de oleadas hasta el pico vespertino; el turno tardío cubre el cierre nocturno, con un traslape de dos horas para la entrega. Fija el horario tres días antes del go-live, imprímelo, pégalo en la pared. Si alguien necesita tiempo libre, busca su propio reemplazo. El "soporte telefónico" no cuenta. En la semana uno, una persona en la sala y una persona al teléfono son dos niveles completamente distintos de capacidad de respuesta.
Lo más importante: nombra a un tomador de decisiones, generalmente el gerente de proyecto del lado del negocio. La enfermedad más mortal de la sala de guerra es tener tres personas y ninguna decisión. Cuando llega un P1, el tomador de decisiones dice una frase — detener la línea y arreglarlo, o rodearlo y proteger el despacho. Esa persona debe tener la autoridad para detener los envíos y la autoridad para decir "trabajamos en manual por dos horas". Una sala de guerra con autoridad difusa debatirá dos horas lo que un tomador de decisiones claro resuelve en una frase.
Seis números en el tablero. Ni uno más.
El tablero de la semana uno debe ser escueto. Yo vigilo seis números: rezago de pedidos sin liberar, tasa de éxito de liberación de oleadas, dispositivos RF en línea, profundidad de colas de interfaces y tiempo de espera más largo, tasa de excepciones de auditoría y tasa de envíos a tiempo del mismo día. Cada uno tiene una línea roja — por ejemplo, una cola de interfaces de más de 200 pedidos sin movimiento durante 15 minutos escala automáticamente a P1, sin informe necesario. Los tres lados acuerdan las líneas rojas antes del go-live, las escriben en papel, las pegan en la pared y no las tocan en toda la semana. Una línea roja que cambia a diario no es una línea roja.
Los niveles de severidad P1/P2/P3 deben existir desde el día uno, y las definiciones deben ser claras y concretas. P1: no podemos enviar, o los datos se van a corromper. P2: el rendimiento cae a menos de la mitad, pero aún podemos enviar. P3: problemas de usabilidad que no afectan el envío. Una sala de guerra sin severidad clara tiene todo "más o menos urgente", lo que significa que nada se prioriza. Una regla de hierro más: desde que se detecta un P1 hasta que alguien asume la responsabilidad, no más de 15 minutos. Si se agota el tiempo, el teléfono del tomador de decisiones suena directamente.
Un plan de rollback no es una vergüenza. Es un seguro.
Dos cosas deben estar listas antes del go-live. Primero, formularios de pedidos en papel de respaldo y un proceso manual. Si el sistema se cae de verdad, el almacén no se detiene: surte en papel, registra a mano, regístralo en el sistema después. Imprime los formularios con anticipación y déjalos en el piso — no vayas a buscar una impresora cuando las cosas ya están rotas. Y ensaya el flujo manual al menos una vez. Los líderes de turno deben recorrer el proceso completo en papel con sus propias manos, o en el día malo no sabrán cómo usar el papel que tienen en las manos.
Segundo, puntos de restauración de datos. Un respaldo completo cada noche, más un respaldo separado antes de cualquier cambio importante de datos maestros. Rollback no significa desinstalar el sistema — significa "el cambio de configuración de hoy rompió algo, y podemos volver al estado de anoche". Honestamente, pocos proyectos usan el plan de rollback en la semana uno. Pero tener uno cambia por completo la psicología del equipo. Un equipo con un plan tocará la configuración. Un equipo sin uno no cambiará ni un solo parámetro, y un problema P2 se arrastra hasta convertirse en P1.
Entonces: antes de la semana del go-live, imprime las definiciones P1/P2/P3 y la lista de teléfonos de escalación, pégalas en la pared de la sala de guerra y pon una pila de formularios de respaldo en papel junto a ellas. El último día de la semana uno, haz una retrospectiva con tres preguntas: qué incendio ardió más fuerte, qué métrica alarmó primero y qué solución manual debería convertirse en un proceso permanente del sistema. Luego disuelve la sala de guerra — mantenerla abierta significa que aún no confías en el sistema.
Una última pregunta para ti. Si tuvieras que apagar tú mismo el sistema viejo la mañana del día uno — ¿te atreverías? Si no, tu plan de rollback no está listo. Arréglalo ahora, mientras aún hay tiempo.
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
