Una bodega retail mal gestionada se nota antes en el bolsillo del gerente que en el inventario: pedidos que llegan tarde, clientes que cancelan, mermas que aparecen recién en la auditoría anual. Este artículo abre un caso real de automatización de procesos en una bodega retail chilena. Cifras, decisiones y aprendizajes que cualquier empresa con bodega de mediano volumen puede replicar.
Por confidencialidad cambiamos el nombre del cliente. Las cifras, decisiones técnicas y plazos son reales.
El cliente y el problema
Cliente: cadena de retail especializado con 12 tiendas en Chile (Región Metropolitana, Valparaíso, Biobío) y una bodega central de 4.200 m² en Santiago. Stock activo: ~14.000 SKUs. Despachos diarios: 280 a 450 entre tiendas, e-commerce y B2B.
Los síntomas
- Quiebres de stock invisibles. El sistema decía 12 unidades, en bodega había 4. Cliente esperaba, comercial perdía venta.
- Picking ineficiente. Cada operario caminaba ~9 km al día en zigzag. Pedidos tardaban 35-50 minutos en armarse.
- Recepción manual. Llegaba un camión y se digitaba todo en planilla, después se pasaba al ERP. Errores: ~7%.
- Cierre de inventario imposible. El último cierre real había sido hace 14 meses. Las cifras del ERP y la realidad física se separaban un 11%.
- Merma sin explicación. ~CLP 38M anuales en pérdidas no atribuibles.
El diagnóstico
Hicimos diagnóstico en terreno durante 5 días: acompañamos turnos, conversamos con jefes y operarios, mapeamos cada paso del flujo. Conclusión: el ERP era razonable, pero todo lo que pasaba en la bodega vivía fuera del ERP. Faltaba un WMS (Warehouse Management System) a medida que reflejara la operación real.
Por qué a medida y no enlatado
Evaluamos tres WMS comerciales del mercado. Costos de licencia entre USD 22.000 y 60.000 anuales más implementación. Dos problemas reventaron la opción enlatada:
- Reglas de negocio específicas del cliente (descuentos por lote vencido, promociones por tienda, devoluciones cruzadas) no calzaban en los flujos predefinidos.
- Integración compleja con el ERP existente y con el sistema de e-commerce. Los WMS de mercado pedían meses de consultoría adicional para conectarse.
El desarrollo de software a medida salía menos en 24 meses y dejaba al cliente dueño de su sistema, sin licencias mensuales atadas. Decisión: WMS a medida.
La solución que construimos
Una plataforma con tres componentes:
- Backend en Node.js con base de datos PostgreSQL. APIs para todos los procesos.
- Aplicación móvil para operarios (desarrollo de aplicaciones en Flutter) con lectura de código de barras vía cámara y soporte de pistolas Bluetooth.
- Panel web para jefes de bodega y administración: dashboards, ajustes, auditoría.
Funcionalidades clave
- Recepción de mercadería con validación contra orden de compra al momento.
- Ubicación inteligente. El sistema sugiere dónde guardar cada producto en función de rotación, peso y zona.
- Picking optimizado. El sistema ordena los ítems del pedido por ruta más corta dentro de la bodega.
- Inventario cíclico. Cada operario tiene 15 minutos al día para contar 1 zona pequeña. En 60 días se cuenta toda la bodega.
- Integración con ERP vía API REST con reintentos y cola, para que la caída del ERP no congele la bodega.
- Trazabilidad por lote y vencimiento con alertas configurables.
Plazos y equipo
- Diagnóstico: 1 semana.
- Diseño y arquitectura: 2 semanas.
- Desarrollo: 14 semanas en sprints quincenales con demos al cliente.
- Piloto en bodega: 4 semanas con un equipo de operarios voluntarios.
- Rollout total: 3 semanas.
- Total: 24 semanas (~5,5 meses).
Equipo: 1 product manager, 1 arquitecto, 2 desarrolladores backend, 1 desarrollador mobile, 1 QA, 1 UX. Por parte del cliente: 1 jefe de bodega como product owner interno y 4 operarios senior como early adopters.
Resultados a 9 meses post-rollout
| Indicador | Antes | Después | Mejora |
|---|---|---|---|
| Tiempo de armado de pedido | 42 min | 17 min | -60% |
| Errores en recepción | 7% | 0,8% | -89% |
| Diferencia inventario físico vs sistema | 11% | 1,3% | -88% |
| Quiebres de stock por SKU activo / mes | 280 | 62 | -78% |
| Merma anual no explicada | CLP 38M | CLP 9M | -76% |
| Pedidos despachados / día con mismo equipo | 350 | 540 | +54% |
| Tiempo de cierre mensual de inventario | 3 días | 4 horas | -94% |
El número que más sorprendió
El cliente esperaba reducir errores. Lo que no esperaba era despachar 54% más pedidos sin sumar personal. La automatización no liberó horas para descansar: liberó capacidad para crecer.
Aprendizajes que aplicamos en cualquier proyecto de bodega
1. Los operarios saben más que los manuales
En las primeras 2 semanas de diagnóstico, los operarios senior nos dijeron exactamente dónde estaban las pérdidas. Lo que faltaba era el sistema que los escuchara.
2. La adopción se gana en el piloto, no en la capacitación
El truco fue elegir bien a los 4 early adopters: operarios respetados, no necesariamente los más jóvenes. Cuando ellos validaron el sistema, los demás siguieron sin resistencia.
3. Diseñar para el escenario sin internet
La cobertura WiFi en una bodega de 4.200 m² no es perfecta. La app guarda cola local de transacciones y sincroniza apenas hay señal. Ese detalle salvó el rollout.
4. La integración con ERP es donde mueren los proyectos
Dedicamos 25% del esfuerzo solo a la integración con el ERP. Manejo de errores, reintentos, conciliación nocturna. Vale el costo: sin esto el proyecto se rompe en producción.
5. Medir desde el día uno
Antes de tocar código, definimos los 7 indicadores que iban a probar el éxito. Los medimos durante 30 días pre-proyecto. Esa baseline es lo que después permitió defender el ROI.
Riesgos que controlamos durante el rollout
Un proyecto de bodega no falla por código: falla por las interrupciones operacionales que generan pánico. Estos fueron los riesgos que más cuidamos:
- Caída de operación en horario crítico. El rollout se hizo de a una zona de bodega por vez, en horario fuera del peak (martes a jueves, 14:00-17:00). Nunca tocamos viernes ni cierres de mes.
- Resistencia de operarios mayores. Los 4 operarios senior que participaron del piloto se convirtieron en capacitadores informales del resto. Eso aceleró la adopción y bajó el ruido sindical.
- Pérdida de datos durante migración. Antes del corte, corrimos 3 inventarios físicos con conciliación contra el ERP. Cada SKU pasó al WMS con su realidad, no con su teoría.
- Falla de hardware en terreno. Compramos 2 dispositivos extra como respaldo, con configuración idéntica y sincronización automática. En el primer mes los usamos dos veces por daño físico real.
- Dependencia del proveedor. Dejamos toda la documentación técnica, runbooks de operación y acceso al repositorio en el servidor del cliente. Si mañana cambian de proveedor, el sistema sigue su curso.
Stack técnico utilizado
Por si tu equipo de TI quiere referencia técnica, el stack final fue:
- Backend: Node.js 20 + Fastify + Prisma sobre PostgreSQL 16.
- Mobile: Flutter 3.x con soporte iOS y Android, cámara nativa para códigos de barras y conexión Bluetooth a pistolas Honeywell y Zebra.
- Frontend admin: React 18 + TypeScript + Tailwind + shadcn/ui.
- Infraestructura: servidor on-premise del cliente (requisito por política de datos) con réplica en Cloudflare R2 para respaldos.
- Integración con ERP: API REST con cola Redis y reintentos exponenciales.
- Monitoreo: logs estructurados + dashboard interno con métricas operacionales.
Stack moderno, mantenible, sin sorpresas.
ROI del proyecto
- Inversión total: USD 78.000 (desarrollo + capacitación + infraestructura inicial).
- Ahorro anualizado año 1: USD 96.000 (merma evitada + horas reasignadas + reducción de errores).
- Capacidad incremental: +54% sin contratar personal nuevo.
- Tiempo de retorno: ~10 meses.
Lo que pasó después: de bodega automatizada a operación digitalizada
A los 6 meses del rollout, el cliente nos pidió extender el sistema en tres frentes que solo eran posibles porque la bodega ya tenía datos confiables:
- Reposición automática hacia tiendas. El sistema sugiere despacho a cada local en función de venta histórica, stock actual y temporada. Tiendas pasaron de quiebres frecuentes a quiebres residuales.
- Pronóstico de compra. Con 8 meses de datos limpios, integramos un modelo simple que sugiere a compras qué pedir, cuánto y cuándo. Disminuyó stock muerto en ~22%.
- Trazabilidad para clientes B2B. Algunos clientes corporativos exigen trazabilidad de origen. Lo que antes era una tortura manual hoy es un PDF generado en segundos.
Conclusión operacional: el WMS a medida no fue un proyecto, fue la base que permitió tres proyectos posteriores. Sin esa base, ninguno habría sido viable. Esto pasa con cualquier sistema serio: el ROI real se mide a 3 años, no a 1.
Cuándo conviene un WMS a medida (y cuándo no)
Conviene cuando: bodega de >1.500 m² o >5.000 SKUs, integración compleja con ERP existente, reglas de negocio específicas, planes de crecer sin doblar personal.
No conviene cuando: bodega pequeña con <800 SKUs, operación estable sin planes de crecer, ERP del cliente trae módulo de bodega que ya cubre el 80% del flujo.
En el segundo caso, recomendamos extender el ERP o usar un SaaS especializado. Decir “no” cuando corresponde es parte del trabajo serio.
Cómo enfocamos este tipo de proyectos en Codelan
En Codelan partimos siempre por el terreno: 3 a 5 días dentro de la bodega del cliente antes de tocar una línea de código. De ahí sale el verdadero alcance, no de una reunión en sala. Después estructuramos un proyecto con sprints quincenales, demos al cliente cada dos semanas y un piloto controlado antes del rollout total.
Si tu empresa está evaluando automatizar bodega o procesos logísticos y quiere una conversación sin presión comercial, escríbenos. El diagnóstico inicial es gratuito y, si el proyecto no es para nosotros, te lo decimos.
