Tres meses después del go-live, de vuelta a las hojas de cálculo
Un almacén de artículos para el hogar invirtió $60K en un WMS. Tres meses después del go-live, el supervisor del almacén devolvió a todo el mundo a Excel. El dueño me preguntó si todavía tenía arreglo. Tras un día en el almacén, mi conclusión: el sistema estaba bien — las personas y los procesos estaban rotos. Ese es el guion compartido de casi todas las implantaciones fallidas de WMS.
El secreto a voces del sector: las tasas de fracaso de los proyectos WMS son mucho más altas de lo que admiten los proveedores. Y las causas se concentran en cinco motivos.
Motivo 1: Arrancar sin requisitos claros (el mayor asesino)
La forma más común de morir. Requisitos vagos durante la selección; los consultores configuraron "procesos estándar"; al go-live nada coincidía con la realidad: tus reglas de oleaje no están soportadas, tu lógica de facturación necesita desarrollo a medida, nadie mencionó nunca tu flujo de devoluciones.
Solución: antes de empezar la implantación, haz un "recorrido de procesos" — toma 20 pedidos históricos reales y ejecuta cada uno de principio a fin, del pedido al envío, dentro del sistema. Todo lo que no funcione se convierte en una solicitud de cambio en el acto. No esperes al go-live.
Motivo 2: Datos sucios en producción
Un WMS es un sistema de datos: ubicaciones, maestros de SKU, cantidades de inventario — si algo está mal, el go-live es un desastre. Lo peor que he visto: un almacén salió a producción con un 60% de exactitud de inventario. El sistema asignaba tareas de picking sobre stock fantasma, el almacén cayó en el caos y la operación se detuvo en tres días.
Solución: haz un inventario físico completo antes del go-live; no pases a producción por debajo del 95% de exactitud. Recuerda la fórmula: garbage in, garbage out — el sistema amplifica la calidad de los datos, para bien o para mal.
Motivo 3: Sin patrocinio de la dirección
Implantar un WMS es un cambio organizativo, no un proyecto de TI. Los proyectos donde "el jefe solo firma cheques" fracasan a un ritmo alarmante: los departamentos se bloquean sin nadie que decida, el personal veterano se resiste al nuevo sistema sin nadie que lo imponga, y las decisiones de los consultores quedan sin aprobar una semana entera.
Solución: el dueño debe recibir una sesión informativa del proyecto cada mes y asistir a los hitos clave (firma de procesos, cutover). El tiempo invertido por la dirección es el mejor predictor del éxito del proyecto.
Motivo 4: Formación exprés
Muchos proyectos "forman" con un PowerPoint de dos horas el día antes del go-live. Los operarios cogen el PDA a la mañana siguiente perdidos — escanean mal y no saben cómo deshacerlo, topan con una excepción y no saben a quién llamar. Así que todo el mundo vuelve discretamente a lo de siempre: Excel y papel.
Solución: forma en tres niveles — operarios (SOP por rol + prueba práctica; sin aprobado, sin acceso en el go-live), jefes (informes y gestión de excepciones), TI (administración básica). "Examen para habilitar" es la línea que separa la formación del teatro.
Motivo 5: Cutover demasiado agresivo — el Big Bang
"¡Cutover total el lunes que viene!" — la frase más peligrosa del almacenamiento. Los grandes almacenes en especial no pueden hacer big-bang: un bug oculto golpea todos los envíos del edificio.
Solución: primero un piloto. Corta a producción una zona, un turno, o el 20% del volumen de pedidos; corre 2–4 semanas estable y luego expande. Llevar dos sistemas a la vez durante el piloto es agotador — y es el seguro más barato que jamás comprarás.
| Causa de fracaso | Síntoma típico | Costo de prevención vs. costo de fracaso |
|---|---|---|
| Requisitos poco claros | Los procesos no coinciden en el go-live | 2 semanas de descubrimiento vs. 3 meses de retrabajo |
| Datos sucios | El sistema asigna tareas imposibles | 1 inventario completo vs. 3 días de parada |
| Dirección ausente | Decisiones retrasadas, guerras de territorio | 2 horas/mes vs. proyecto abandonado |
| Formación exprés | El personal vuelve a Excel | 1 semana de formación práctica vs. sistema parado |
| Cutover big-bang | Un bug paraliza el almacén | 1 mes de piloto vs. parada total |
Señales de alerta temprana: cinco banderas rojas en los 30 días previos al go-live
Muchos fracasos quedan sellados antes del go-live. Si estás a mitad de la implantación y detectas alguna de estas, para y corrige de inmediato — nunca apuestes al "lo arreglaremos después del lanzamiento":
- Los consultores entienden tus procesos peor que tú: si preguntan "qué significa este documento" más de tres veces en una reunión, el descubrimiento no se hizo bien.
- Los datos maestros no dejan de retrasarse: a dos semanas del go-live y los maestros de SKU siguen incompletos — el caos en el lanzamiento está casi garantizado.
- Los usuarios clave se saltan la formación: el supervisor del almacén dice "estoy muy liado, manda a Xiao Li en mi lugar". La primera persona en resistirse al nuevo sistema tras el lanzamiento suele ser ese supervisor.
- Las pruebas solo cubren el camino feliz: los casos de prueba solo ejercitan flujos estándar — sin excepciones, sin devoluciones, sin diferencias de inventario. El primer día del go-live, las excepciones te pondrán en tu sitio.
- El director falta dos revisiones del proyecto seguidas: la señal más peligrosa — el proyecto ya ha caído de su lista de prioridades.
Los 30 días previos al go-live son tu última oportunidad de frenar. Retrasar el lanzamiento dos semanas siempre cuesta menos que tres meses de operaciones fallidas.
La formación se paga sola: una semana de formación práctica a operarios cuesta una fracción de un solo día de caos post-go-live. Y haz que la formación perdure — imprime los 10 flujos de PDA más usados en tarjetas plastificadas y pon una en cada dispositivo. El mejor SOP es el que está al alcance de la mano.
Caso de estudio: un proyecto rescatado al borde del abismo
Un almacén de repuestos de automóviles en Texas vio caer los envíos a tiempo del 98% al 82% dos semanas después del go-live del WMS; el dueño estaba listo para matar el proyecto. Encontré tres problemas: el 15% de los SKU carecían de datos de peso/dimensión (el sistema no podía cartonizar), el turno de noche nunca había sido formado en excepciones, y el cutover big-bang no dejó aislamiento. El rescate: dos semanas para completar los datos maestros, reentrenamiento dedicado al turno de noche, y devolver las devoluciones al proceso antiguo. La tasa de envíos a tiempo se recuperó al 97% en un mes, al 99% en tres. La mayoría de los proyectos "fracasados" no necesitan un sistema nuevo — necesitan un plan nuevo.
Conclusión
Los cinco asesinos — requisitos poco claros, datos sucios, directivos ausentes, formación exprés, cutover agresivo — no son ni un ápice técnicos. Son todos problemas de gestión. Y eso es en realidad una buena noticia: los problemas técnicos necesitan al proveedor; los problemas de gestión los puedes resolver tú mismo. Antes de tu próximo proyecto WMS, imprime estas cinco trampas y pégalas en la pared de la sala de reuniones.
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
