Lo que sigue nace de una consultoría operacional con un cliente real, donde lideré un proyecto de transformación desarrollado junto a un partner tecnológico. Mientras ese equipo estuvo a cargo de la implementación del WMS y sus integraciones, nosotros lideramos el diagnóstico, el rediseño de procesos, la lógica de planificación y la coordinación del proyecto. Caso real adaptado y anonimizado; ciertos antecedentes operacionales fueron modificados o agregados para resguardar la confidencialidad comercial. También por resguardo de datos personales conforme a la Ley N.º 21.719, que entra en vigencia en diciembre de 2026.
Estuvimos desarrollando una asesoría con una operación de e-commerce y delivery de pizzas, específicamente enfocados en su logística de perecederos y preparación de masa. Esta sección estaba en una fase de crecimiento acelerado y tenía un problema que al principio nos costó muchísimo identificar.
Para dimensionar el cuello de botella, ellos administraban un catálogo de 60 SKUs críticos de alta rotación para soportar un flujo base de 100 pedidos diarios de domingo a jueves, que saltaba violentamente a 250 órdenes los viernes y sábados.
Tenían métricas de merma en insumos que eran extraordinariamente bajas, de las más bajas que nos ha tocado ver. Pero la realidad, es que recibían muchas quejas por pedidos cancelados y tiempos de entrega tardíos… eso si, concentrados exclusivamente los fines de semana. La operación celebraba que eran muy eficientes en la gestión de la mermas, pero se lamentaban por las ventas que no capturaban el viernes por la noche.
Lo que descubrimos bastante rápido es que el equipo de cocina y su ritmo de trabajo lo hacían con bastante precisión. El error residía principalmente en que los estábamos obligando a optimizar el indicador equivocado [1].
El costo de una venta perdida a las 21:00 hrs (margen no capturado más el costo de recuperar a ese cliente frustrado) resulta casi siempre significativamente mayor que el costo de botar un bollo de masa sobre-fermentada o un kilo de vegetales. Nadie en la operación estaba mirando ese número.
Lo que ahora sigue es el relato de cómo trabajamos para transformar esa operación en tres fases. Sustituimos la intuición por reglas físicas; hoy cada lote de masa o queso tiene caducidad estricta en sistema y el volumen de preparación obedece exclusivamente al margen calculado.
Lo que encontré al auditar la operación
Al entrar a revisar cómo funcionaba el día a día, encontré algo que en este tipo de negocios es más común de lo que parece: toda la gestión de compras y de la cámara de frío recaía en dos personas con décadas de experiencia, armadas con libretas y hojas de cálculo propias. Esa forma de trabajar, basada solo en lo que recordaban los veteranos, era insostenible a largo plazo. Ningún software gestionaba ese proceso previo a la venta.
A primera vista podía parecer que funcionaba, y en cierto modo funcionaba, pero sobre una base muy frágil. Identifiqué cuatro problemas estructurales que estaban frenando a la empresa.
Para empezar, el sistema entero dependía de esas dos personas. Si una se enfermaba o renunciaba, el cálculo de cuánta masa preparar el jueves para cubrir el sábado tambaleaba. Su conocimiento permanecía tácito y era intransferible.
Luego, el equipo se medía, formal o informalmente, por la merma. Su objetivo implícito era «que no se bote comida». Eso los llevaba a preparar masa y pedir insumos de forma conservadora, asegurando usar el 100%, pero sacrificando en el camino decenas de ventas de fin de semana que nunca llegaron a concretarse por falta de materia prima.
Otro problemón era la falta absoluta de visibilidad del inventario en proceso. Sin un WMS acoplado a la producción, nadie podía decir con precisión cuánta masa en fermentación (ej. masa en fermentación de 48 hrs) había ni cuándo llegaba a su punto óptimo. Eso hacía imposible tomar decisiones oportunas de marketing, como lanzar una promoción flash para rotar inventario a punto de caducar.
Y rematando, era la pérdida de confianza del cliente. Quedarse sin mozzarella un viernes significa perder esas lucas inmediatamente. Peor aún, espantas para siempre a ese comprador recurrente. Cliente que pide pizza y se la cancelan a los 20 minutos, es cliente cedido a la competencia.
Fase 1: construir una única fuente de verdad
El paso inicial era el más básico: exigir visibilidad absoluta del inventario en cámara frío. Antes de cualquier optimización, necesitábamos datos confiables de los insumos.
Implementamos un WMS ligero con módulo de forecasting integrado, provisto por un partner especializado. Toda la gestión migró desde las libretas hacia este sistema centralizado. Fue una migración con reticencia inicial en la cocina, como casi siempre ocurre, pero ineludible.
El segundo paso fue rediseñar el proceso de recepción y preparación. En una pizzería, la masa y los lácteos son críticos. Implementamos gestión por lotes: al recibir mercancía o al bolear la masa, se registra obligatoriamente la fecha y hora de vencimiento/óptimo. La gestión evolucionó desde el concepto genérico de «mozzarella» hacia el control de «mozzarella, lote X, vence en 7 días» y «bollos de masa madurada, lote Y, límite 72 horas».
Pero el software no frena la termodinámica: la masa es un producto vivo[2].
Tuvimos que subordinar el escaneo del sistema a la física del cuarto frío, implementando un cross-stacking (apilado cruzado) estricto de las bandejas para forzar el enfriamiento del bollo antes de que el WMS iniciara su cuenta regresiva de maduración.
El tercer cambio fue reemplazar FIFO (primero en entrar, primero en salir) por FEFO (primero en caducar, primero en salir), la regla de oro. Esto se implementó con pantallas en la zona de preparación: cuando entra un pedido, el sistema indica al operario exactamente de qué bandeja tomar la masa con la fecha de maduración más próxima. Para asegurar la disciplina, implementamos un Poka-Yoke mediante escaneo rápido que bloquea la comanda si se intenta usar un lote incorrecto. La rotación correcta quedó sistematizada.
Fase 2: cuánto preparar y cuándo comprar
Una vez que tuve datos confiables, pude construir el motor de decisión. Esta fue la conversación más importante que tuve con la gerencia durante todo el proyecto.
Les presenté el modelo newsvendor, el estándar para operaciones con vida útil muy corta. Resuelve el dilema central de la pizzería: si preparo masa de más, asumo merma; si preparo de menos, apago las apps de delivery el sábado a las 21:00. El modelo define matemáticamente el punto donde la rentabilidad total esperada es máxima.
El modelo trabaja con dos costos: Co (costo de overstocking): el costo de los insumos de una pizza que no se vende (harina, levadura, etc., que es bajísimo). Cu (costo de understocking): el margen que se pierde por no tener la masa lista para vender esa pizza el fin de semana.
Y el ratio crítico (CR) que determina el nivel de servicio óptimo:
CR = Cu / (Cu + Co)
Para fines de decisión gerencial, utilizamos el modelo newsvendor clásico asumiendo el costo de sobreproducción (Co) como pérdida total. Esto constituye una simplificación matemática deliberada. En la realidad, parte de esa masa se rescata al día siguiente disminuyendo su precio o transformándola. Calcular el valor exacto de salvamento añadía una complejidad que paralizaba la toma de decisiones. Optamos por castigar el Co al máximo para forzar un sesgo conservador hacia la sobre-preparación, validando posteriormente que el error de estimación no distorsionaba el óptimo operativo.
Cuando la gerencia vio la desproporción entre el costo marginal de botar un bollo de masa (Co) frente al alto margen que dejaba vender una pizza familiar (Cu), entendieron que debían preparar mucha más cantidad para cubrir los picos del fin de semana. Cero espacio para interpretaciones cautelosas de la cocina.
Además, cuando se incorpora el costo de lealtad del cliente (la pérdida de recurrencia que genera cancelar un pedido de viernes por la noche) el ratio sube de forma importante. El modelo recomienda sistemáticamente sobre-preparar insumos baratos para asegurar los ingresos de alto margen.
Para alimentar el modelo, aproveché el módulo de ML del WMS y lo personalicé con las variables críticas: clima (la lluvia es oro puro para el delivery) o partidos de fútbol importantes. El módulo genera una distribución de probabilidad de demanda y determina exactamente cuántos kilos de masa deben entrar a fermentación cada miércoles.
La implementación requirió ajustes empíricos. En la segunda semana de piloto, el modelo ignoró un frente de lluvias torrenciales de fin de semana y proyectó demanda plana de fin de mes; nos quedamos sin masa a las 19:30 hrs y tuvimos que apagar el sistema, perdiendo más de 40 pedidos garantizados[3].
Tuvimos que entrar al backend, inyectar mayor peso a la variable climática para delivery y forzar un buffer de seguridad en la predicción algorítmica antes de soltarlo en automático. La teoría aguanta mucho, pero en la cocina el modelo requiere calibración ruda.
Por otro lado, el modelo recomienda sobre-preparar, pero un sistema sin techo genera riesgos de cola gruesa. Establecimos un límite de falla segura (fail-safe): Si la merma proyectada superaba el 6% del costo de ventas de la jornada, el sistema bloqueaba la preparación adicional y forzaba un ajuste a la baja del menú en el front-end, prefiriendo perder ventas marginales antes que incurrir en un desperdicio incontrolable.
Fase 3: conectar el sistema al ecosistema digital
Con los insumos controlados y la planificación de masa funcionando, el último paso fue conectar el piso de producción con las apps y el e-commerce.
Integrar el WMS como fuente única de verdad para el front-end fusionó la disponibilidad física con la digital. Si la cámara registraba cero bollos, el botón de ‘Pedir’ se bloqueaba. Sin embargo, esta arquitectura de acoplamiento estrecho introdujo un nuevo punto único de fallo: si el WMS perdía conectividad, las ventas se paralizaban en seco. Para mitigar esta vulnerabilidad sistémica, programamos un modo degradado: si la latencia de respuesta al WMS superaba los tres segundos, el sistema desacoplaba la validación e inhabilitaba temporalmente el bloqueo automático, habilitando un buffer de ventas manuales pre-aprobado por el gerente de turno.
Lo segundo fue implementar dinámicas promocionales atadas al inventario. Con la trazabilidad por lote operativa, creamos una regla para rotar inventario próximo a su límite. Un topping perecedero a 24 horas de caducar activaba una oferta automática. Aquí chocamos con dos límites sistémicos inesperados.
El primero, de percepción de marca: ofrecer «doble porción por liquidación» entrena al cliente a esperar descuentos y le hace sospechar de la frescura. Reconfiguramos la salida: el sistema usaba ese inventario para activar ofertas exclusivas para clientes de alta recurrencia bajo el concepto de «Beneficio VIP», transformando un pasivo logístico en una herramienta de fidelización sin dañar el posicionamiento.
El segundo límite era puramente operativo. Inyectar demanda adicional (y más compleja, por la doble porción) justo cuando el sistema está bajo mayor estrés satura la línea de armado. Programamos un interruptor de seguridad: la promoción solo se activa si el WMS detecta que el horno y la make-line mantienen una holgura operativa superior al 15% en tiempo real. Si la capacidad está comprometida, la prioridad es proteger el throughput base; la merma inminente se asume como un costo tolerable. El marketing no puede devorar a la operación.
Lo tercero fue erradicar los ‘bomberazos’ de los jueves con los proveedores de queso y cajas por ejemplo, mediante integración comercial. Antes, los proveedores recibían pedidos reactivos. Una llamada de urgencia el jueves al mediodía porque venía un clásico de fútbol y faltaban cajas. Esa variabilidad generaba entregas inconsistentes.
Empezamos a compartir con los proveedores críticos una ventana de visibilidad de tres semanas basada en el modelo de ML. Tuvimos que demostrarles con los primeros despachos que nuestra proyección era sólida. Con esta visibilidad, nuestras órdenes funcionaron como un simple acuse de recibo de sus propias proyecciones. El proveedor estabilizó su ruta al tratar, por fin, con una cuenta predecible, y a nosotros jamás nos volvió a faltar un insumo clave un sábado a la noche.
Qué obtuvimos
Corrimos un piloto de seis semanas. Los resultados los comparamos contra el período equivalente del año anterior.
Pasamos de promediar 28 tickets explosivos por stockout cada fin de semana a registrar menos de 4 incidentes críticos. La merma de cocina subió, efectivamente, pasando de un 2% a cerca de un 4.5% sobre el costo de ventas, pero ese fue el precio de tener stock suficiente para no fallar en los picos de demanda.
La rentabilidad neta del fin de semana mostró una variación positiva del 18,2% frente al período equivalente del año anterior. No puedo afirmar que todo el aumento venga del proyecto, porque seguramente hubo otros factores. Pero la caída de los stockouts fue tan grande que es difícil no atribuirle buena parte del resultado. No obstante, la caída abrupta de los tickets explosivos (de 28 a menos de 4) funciona como una variable directamente atribuible al WMS, otorgando robustez indirecta para mantener que la captura de demanda rescatada actuó como el principal motor de ese diferencial. El payback (retorno de inversión) de la implementación del sistema fue de apenas ocho semanas, financiado enteramente por el margen rescatado de estas ventas nocturnas.
Este aumento de volumen fue posible gracias a una auditoría previa aplicando TOC (teoría de restricciones) sobre la línea caliente. Para absorber el peack de 250 órdenes en la ventana crítica de cuatro horas nocturnas, el Takt Time exigía la salida de una pizza cada 57 segundos. El throughput cronometrado del horno de cinta y la make-line arrojó un ciclo sostenido de 24 segundos por unidad (150 pizzas/hora).
La capacidad instalada física tenía holgura operativa para duplicar el flujo; la restricción estructural del sistema radicaba exclusivamente en el quiebre de inventario intermedio. Desde la óptica estricta de la Teoría de Restricciones, aumentar el inventario intermedio de masa aparenta una contradicción, dado que el inventario suele ocultar las variabilidades del sistema.
Pero la auditoría demostró que la restricción real era una «restricción de política», es decir, el miedo a la merma. Al subordinar la operación al nuevo ratio crítico, el inventario de masa se convirtió en un buffer calculado y explícito, diseñado exclusivamente para proteger el throughput frente a esa política limitante.
Al eliminar el quiebre de masa, la restricción del sistema migró inmediatamente. Con 250 órdenes y masa de sobra, el nuevo cuello de botella pasó a ser la estación de toppings y el empaquetado. Tuvimos que aplicar un nuevo ciclo de análisis para reconfigurar la make-line y asegurar que el horno no se quedara parado esperando los ingredientes extra. La optimización se reveló como un proceso continuo de identificación y subordinación de nuevas restricciones.
El equipo abandonó la libreta para asumir la supervisión de las excepciones del algoritmo y el control estricto de los tiempos de fermentación. Las horas-hombre se reorientaron hacia la protección real de la caja: negociar descuentos por volumen de insumos y estandarizar la calidad del producto.
En el fondo dejamos de depender de la memoria de dos personas para empezar a depender de la calidad de nuestros datos. El sistema resulta superior para gestionar el estado estable del viernes por la noche, aunque la operación pierde la capacidad de los veteranos para improvisar sobre la marcha cuando algo inesperado sucede.
Hoy, gestionar esto significa tener gente preparada para reaccionar cuando el modelo se desvíe. Al final, los humanos están ahí para vigilar los casos raros que un algoritmo no puede manejar.
Notas al margen
[1] Una ilusión común en la gestión es asumir que las métricas reflejan la realidad de forma pasiva. En la práctica las métricas te dictan las reglas del juego. Si le dices a un equipo que su éxito depende de no tirar basura, estás diseñando su comportamiento. La cocina ejecutaba de manera impecable la estrategia que el entorno le exigía. El problema de la gerencia residió en confundir el marcador del juego con la salud del negocio.
[2] El software cuenta el tiempo como si todo fuera instantáneo pero la masa tarda en enfriarse. Escanear un bollo no hace que se enfríe más rápido; por eso tuvimos que apilar las bandejas de forma que el aire circulara bien y la temperatura bajara de verdad. Solo entonces el sistema podía empezar a contar la maduración.
[3] Los algoritmos de predicción suelen fiarse demasiado de lo que ya pasó. Si aparece un temporal que era inesperado, el modelo no tiene forma de saber que la gente va a pedir más delivery; simplemente extrapola los datos de días normales. Por eso tuvimos que darle más peso a la variable climática, para que el sistema aprenda a reaccionar ante estos cambios bruscos del clima en lugar de quedarse pegado repitiendo el promedio histórico.