Caso de Estudio · 2025
No se puede automatizar un sistema roto
Cómo reconstruí la confianza en un sistema de inventario a la deriva en Compass Coffee, y luego automaticé el flujo de trabajo solo cuando los números eran confiables.
Resumen Ejecutivo
NetSuite se había desviado lo suficiente de la realidad del almacén como para que los pedidos diarios dependieran de verificaciones manuales, correcciones reactivas y juicio personal. Primero corregí el problema de integridad del inventario, luego construí un flujo de pedidos escalonado usando exportaciones de NetSuite, Python, automatización con cron y reportes con n8n. El resultado fue menor carga administrativa, menos errores de picking y menos roturas de stock.
El Problema
Compass Coffee operaba 25 cafés más e-commerce y distribución mayorista desde un almacén central. Se suponía que NetSuite era la fuente de verdad para el inventario, pero los registros ya no coincidían con el stock físico lo suficiente como para que el equipo confiara en ellos.
La desviación provenía de muchos pequeños fallos en lugar de una avería mayor: producción completaba trabajo sin registrarlo, los conteos cíclicos estaban desfasados, las recepciones iban por detrás de las entregas entrantes, y los equipos de eventos retiraban producto sin registrar el movimiento. Cada brecha parecía manejable de forma aislada. Juntas convirtieron el sistema en ficción.
La consecuencia operativa era inmediata. Cada mañana comenzaba con una caminata física por el almacén, una evaluación manual de lo que realmente había disponible, y una conversación basada en mi mejor juicio en lugar de un reporte confiable.
Cómo era realmente la mañana
- • Caminata física por el almacén para verificar stock visualmente
- • Reunión con gerentes de producción basada en faltantes observados
- • Creación manual de rutas en NetSuite para entregas de servicio de alimentos
- • Liberación manual de cada pedido de e-commerce al empacador
- • Conteos manuales para construir órdenes de compra del día
- • Por la tarde, picking y empaque de pedidos de cafés para entrega nocturna
- • Seguimiento constante con proveedores, verificación de recepciones y comunicación con gerentes
Cómo lo reconstruí
Estabilizar los datos antes de construir automatización
- Construí una búsqueda guardada en NetSuite para extraer cada artículo reportado como agotado.
- Encontré que aproximadamente el 20–30% del almacén estaba contado incorrectamente.
- Usé fechas de producción para diagnosticar si el problema era una entrada de producción omitida o un error de conteo persistente.
- Corregí los conteos manualmente y trabajé con los gerentes para mejorar la disciplina de registro.
- Pospuse la automatización hasta que el sistema fuera lo suficientemente confiable para construir sobre él.
Construir la lógica de pedidos manualmente primero
- Creé un script en Python usando ventas de 30 días, inventario actual y tiempos de entrega de proveedores para proponer cantidades de pedido.
- Entregué el resultado primero como hoja de cálculo para que el equipo pudiera inspeccionarlo antes de confiar en él.
- Ejecuté reportes de NetSuite manualmente y los alimenté al script a mano durante las primeras iteraciones.
- Las primeras versiones sobreordenaron porque aún no contemplaban cantidades mínimas de pedido ni variabilidad en tiempos de entrega.
- Usé esos errores visibles para ajustar el modelo en lugar de ocultarlos.
Automatizar la ingesta de datos una vez que el flujo era confiable
- Configuré NetSuite para enviar las exportaciones necesarias por correo cada noche a las 11 PM.
- Inicialmente mantuve un paso de revisión manual cada mañana para validar los datos entrantes.
- Agregué un agente activado por cron que revisaba el correo, descargaba el adjunto y lo enrutaba al proceso de Python.
- Para la mañana, los pedidos propuestos a proveedores estaban listos antes de que el equipo comenzara el día.
Extender a reportes y adopción del equipo
- Usé n8n para automatizar el reporte semanal al COO cubriendo cambios laborales, roturas de stock y seguimiento de errores.
- Reduje el trabajo manual recurrente necesario para ensamblar los reportes de liderazgo.
- Trabajé a través de la resistencia del equipo combinando la aplicación de procesos con mejoras visibles en la calidad del resultado.
- Con el tiempo, el equipo pasó del escepticismo a la adopción porque el sistema seguía demostrando su valor.
Arquitectura del Pipeline de Pedidos
Solo el sistema final. Detalles propietarios sanitizados.
Disparador
NetSuite
Email programado a las 11 PM cada noche
Ingesta
Cron + Agente
Revisa la bandeja y descarga el adjunto
Proceso
Script Python
Usa ventas, stock y tiempos de entrega
Resultado
Reporte Matutino
Pedidos propuestos listos para revisión
Disparador
NetSuite
Email programado a las 11 PM cada noche
Ingesta
Cron + Agente
Revisa la bandeja y descarga el adjunto
Proceso
Script Python
Usa ventas, stock y tiempos de entrega
Resultado
Reporte Matutino
Pedidos propuestos listos para revisión
Resultados
75%
Reducción en carga administrativa
Estimación basada en el tiempo previamente dedicado a caminatas por el almacén, conteos manuales y pedidos reactivos. Al final, la operación podía funcionar sin mi revisión física de stock al inicio del día.
~75%
Menos errores de picking en cafés
Rastreado mediante un formulario de NetSuite usado por gerentes de café para reportar errores de entrega. La mejora se mantuvo visible a lo largo de varios meses de reportes semanales al COO.
~35%
Menos roturas de stock
Calculado a partir de la tendencia de roturas de stock revisada en reuniones semanales con el COO, comparando el punto de partida con la tasa estabilizada después de implementar la calculadora de pedidos.
Qué haría diferente
Incluiría más restricciones operativas en el modelo de pedidos desde el primer día, especialmente cantidades mínimas de pedido, variabilidad de proveedores y vida útil. El modelo mejoró porque los errores eran obvios, pero habría sido mejor diseñar para esas restricciones antes.
También trataría la adopción del equipo y la implementación técnica como flujos de trabajo paralelos. Cambiar el comportamiento de registro no era una tarea posterior a la automatización. Era parte de hacer posible la automatización.
Finalmente, pondría los scripts en control de versiones adecuado inmediatamente. Vivían en una carpeta compartida y nunca causaron una falla seria, pero ese resultado dependió más de la suerte que de la disciplina.