Cómo implementar un WMS sin detener el depósito

Por Pablo Porcelo, cofundador de Conectodo · Revisión editorial: 26/08/2026

La respuesta corta: un WMS puede implementarse reduciendo el impacto sobre el trabajo diario si el cambio empieza con un alcance acotado, se prueba con condiciones reales, avanza por un gate definido y conserva una salida operativa. No existe una receta que garantice interrupción cero para todos los depósitos.

El error más costoso no suele ser elegir entre una puesta en marcha total o una gradual. Es comenzar sin haber definido qué cambia, qué queda afuera, quién decide, cómo se prueba y qué se hace si el nuevo flujo no está listo.

Esta guía propone un método para una PyME ecommerce en Argentina. No fija días ni volúmenes universales. Cada implementación depende del proceso elegido, los canales, las integraciones, la calidad de los datos, el hardware y la capacidad del equipo.

“Sin detener” no significa que nada cambie

Una implementación modifica tareas, permisos, datos y decisiones. Puede exigir capacitación, conteos puntuales, configuración de dispositivos o una ventana controlada para cambiar un flujo. Prometer que la operación no sentirá ninguna variación oculta ese trabajo.

La estrategia puede ser por fases, con un piloto o, en ciertos casos, con una convivencia temporal. Un cambio total también puede ser razonable en una operación simple. La decisión debe basarse en riesgo, complejidad, recursos, dependencias y capacidad de recuperación, no en una consigna.

El mapa de implementación en seis decisiones

Una transición ordenada puede representarse como una secuencia. No son seis semanas ni seis entregables rígidos. Son seis decisiones que deben estar resueltas antes de ampliar el uso.

Si todavía estás comparando productos, primero usá la checklist de funciones WMS por proceso. La implementación empieza después de haber comprobado que el sistema cubre el problema correcto.

1. Delimitá qué cambia y qué queda afuera

“Implementar el WMS” es demasiado amplio para operar. Convertí esa frase en una frontera concreta. Podés empezar por un canal, una mesa, una familia de productos, una modalidad logística o un turno. La elección tiene que permitir observar el flujo completo sin abarcar todo el depósito.

Un alcance limitado no sirve si depende de criterios ambiguos. “Pedidos simples” puede significar cosas distintas para cada persona. “Órdenes de Tiendanube del turno mañana procesadas en la mesa 2” permite clasificar y auditar.

Prepará solo los datos necesarios para ese alcance

No toda implementación requiere migrar todo el historial. Sí necesita que los datos del primer flujo sean confiables. Para un WMS orientado a la salida, la preparación suele incluir productos, identificadores, variantes, cantidades, ubicaciones de picking cuando se usan, usuarios, permisos, canales y configuraciones de impresión.

Asigná un dueño a cada dato y separá tres estados: dato aceptado, dato pendiente y dato que bloquea la salida. Cargar información sin una regla de aceptación traslada el problema al piloto.

2. Probá el flujo real, no solo la demo

Una demostración sirve para conocer el producto. Una prueba de implementación debe reproducir el entorno operativo: personas reales, dispositivos reales, etiquetas, conectividad, permisos e integraciones. El camino correcto es apenas una parte.

Las pruebas deben tener resultado esperado y responsable de aprobarlo. “Funcionó” no alcanza. Para una etiqueta, por ejemplo, definí cuándo puede imprimirse, qué ocurre si se reimprime y cómo se comprueba que sigue vinculada al pedido correcto.

3. Usá un piloto acotado y con final explícito

El piloto introduce trabajo real dentro de una frontera controlada. Su valor no está en mover pocas órdenes. Está en revelar qué ocurre cuando datos, personas, hardware e integraciones se encuentran al mismo tiempo.

Antes de iniciarlo, documentá:

• criterio exacto para incluir una orden;
• responsable operativo del turno;
• canal de soporte y prioridad de incidentes;
• duración o condición de salida del piloto;
• criterios de avance, corrección y reversa;
• tratamiento de pedidos que quedan en proceso al cerrar.

Paralelo controlado no es doble carga permanente

Operar temporalmente dos mecanismos puede aportar una comparación útil, pero también duplica tareas, datos y posibilidades de inconsistencia. Si se elige, tiene que responder una pregunta concreta y terminar cuando esa pregunta queda resuelta.

4. Definí el go/no-go antes del piloto

El gate evita decidir bajo presión. Antes de procesar la primera orden real, acordá qué evidencia permite ampliar, qué problema exige corregir y qué condición obliga a detener el avance.

Los criterios tienen que pertenecer a tu operación. No copies un porcentaje de otra empresa. Podés definir, por ejemplo, que no se amplía mientras exista una excepción crítica sin responsable, mientras una impresora no tenga reemplazo o mientras no pueda reconstruirse el estado de un pedido.

5. Diseñá la salida antes de necesitarla

Rollback no siempre significa deshacer todo con un botón. En un depósito existen acciones físicas que ya ocurrieron. La salida debe distinguir qué pasó con cada orden y evitar que una reversa informática duplique una preparación o pierda una etiqueta.

El plan debe nombrar quién activa la salida, cómo se comunica, dónde queda la fuente de verdad y qué evidencia se revisa antes de retomar. Practicar esa secuencia con pedidos de prueba permite detectar dependencias que un documento no muestra.

6. Medí contra tu propia línea base

La implementación no se valida porque el sistema quedó encendido. Compará el flujo nuevo contra una línea base tomada antes del cambio y elegí pocas métricas que reflejen el problema que querías resolver.

1. Tiempo del flujo: desde que una orden queda disponible hasta que el paquete está listo, usando el mismo criterio antes y después.
2. Backlog y antigüedad: cuántas órdenes esperan y cuánto tiempo lleva la más antigua.
3. Excepciones: tipo, momento, responsable y resultado, no solo un total agregado.
4. Reimpresiones y reaperturas: cuándo aparecen y si conservan la relación con el pedido correcto.
5. Adopción operativa: tareas que siguen resolviéndose por mensajes, planillas o memoria fuera del flujo definido.

Una mejora aparente puede esconder trabajo paralelo. Si baja el tiempo en pantalla pero aumentan consultas por WhatsApp, correcciones manuales o dobles registros, la implementación todavía no consolidó el proceso.

Preguntas frecuentes sobre implementar un WMS