Previsión e inventario, en trozos lo bastante pequeños como para entregarlos

Un cockpit que planifica la red y reacciona cuando se rompe

La demanda de cliente vivía en un sistema, el suministro retornado en otro y los costes de transporte en un tercero. Los planificadores podían decir qué había pasado, normalmente con una semana de retraso, y nunca cuánto había costado. Rebalancear la red era un ejercicio anual en hojas de cálculo, y cada imprevisto — un temporal, una línea parada, falta de camiones — se resolvía con una cadena de llamadas.

Construimos una plataforma de optimización de red que modela la demanda de cliente junto con la probabilidad de que el suministro vuelva a cada planta, valora ambas contra costes de transporte reales y convierte el resultado en recomendaciones de rebalanceo: qué planta debe servir qué demanda, y cuánto cuesta equivocarse. Encima va un cockpit completo de cadena de suministro: los mismos números para planificación, para operaciones y para quien firma la factura.

• Probabilidad de retorno estimada por planta en vez de supuesta, porque el flujo que vuelve a la red es lo que decide en silencio la capacidad real.
• Cada recomendación de rebalanceo lleva su coste de transporte, así que el intercambio se ve en el momento de decidir y no en el informe del mes que viene.
• Una capa operativa que aprende cada día de qué recomendaciones aceptan y cuáles rechazan los planificadores, y deja de proponer lo que ese equipo nunca hace.
• Los imprevistos — meteorología, faltas de producción, capacidad de transporte — llegan como acciones propuestas con su coste, no como una alerta que alguien tiene que interpretar.
• Sobre Databricks: el mismo lakehouse alimenta la optimización, el cockpit y los modelos, sin una segunda copia de la verdad.

Cuánto debería costar el transporte, y quién va a coger de verdad la carga

Las tarifas se negociaban contra las tarifas del año anterior. No había forma de saber si una ruta era cara porque el mercado estaba caro o porque nadie la había mirado en tres años. Y cuando un transportista rechazaba una carga a última hora, cubrirla era una carrera contra el reloj sin saber cuál era el precio correcto.

Comparamos la operación de transporte contra la industria ruta a ruta, y encima construimos un motor de recomendación que reacciona a los rechazos de última hora: cuando un transportista suelta una carga, propone a quién acudir y a qué precio, ordenado por quién ha hecho realmente esa ruta, con qué fiabilidad y a qué coste.

• Cada ruta comparada contra el mercado y no contra su propio histórico, para que la conversación con el transportista empiece con evidencia y no con el número del año pasado.
• Los rechazos tratados como información de precio, no como incidencias: un transportista que rechaza siempre la misma ruta te está diciendo que tu precio está mal antes de que te lo diga el gasto.
• Un precio propuesto en cada recomendación, para que quien cubre la carga a las seis de la tarde no negocie a ciegas.
• El mismo lakehouse detrás del benchmark y de las recomendaciones, para que lo que dice el análisis y lo que propone la herramienta no puedan separarse.