Una receta, miles de etiquetas: ERP, CalcMenu y declaraciones de ingredientes sincronizados

Una producción dirigida por pedidos, no por un menú fijo

Un fabricante por encargo — una panadería que produce bollería para una marca de distribuidor, una fábrica de sándwiches que abastece a cuentas de retail y restauración colectiva, un productor de platos preparados que trabaja para varias marcas propias — no funciona a partir de un menú semanal fijo como lo haría un restaurante. La producción depende de lo que los clientes realmente pidieron ese día, y esos pedidos suelen llegar a través de un ERP — a menudo algo como Oracle — que gestiona los pedidos de compra, las líneas de pedido y las cantidades. Lo que sale de la línea mañana por la mañana es lo que el ERP dice que se pidió, no lo que estaba planificado el mes pasado.

Esto crea un problema de integración específico que la mayoría del software de recetas orientado a restaurantes nunca tiene que resolver. Un sistema de gestión de recetas como CalcMenu gestiona el propio alimento — la receta, su coste, su valor nutricional, sus alérgenos. Un sistema de etiquetado como BlazeIQ Labels gestiona lo que realmente se imprime y termina en el envase. Ninguno de los tres sistemas se equivoca al poseer lo que posee. El problema es que, por defecto, nadie posee el traspaso diario entre ellos — y sin él, alguien termina reescribiendo a mano las cantidades del pedido de hoy en el sistema de etiquetado, justo en el momento del día en que un error es más probable y menos probable que se detecte.

Qué tiene que viajar del ERP a la etiqueta — y por qué el QUID es la parte difícil

El flujo mecánico es sencillo de describir: llega una línea de pedido desde el ERP, CalcMenu la resuelve en una receta, y esa receta se escala a la cantidad de lote realmente producida en esa tanda — no a un rendimiento de referencia fijo de hace meses. A partir de ahí, tres tipos de datos de declaración tienen que llegar a la etiqueta, correctamente, cada vez:

La lista completa de ingredientes. No solo “qué contiene”, sino el QUID — la declaración cuantitativa de ingredientes que la legislación alimentaria europea y suiza exige para cualquier ingrediente nombrado o destacado en el envase (el “Pollo (30%)” en la etiqueta de un sándwich de pollo es una declaración QUID). El QUID no es una cifra fija por receta: hay que recalcularlo según las cantidades que realmente entraron en ese lote concreto, que es precisamente por lo que una etiqueta estática preimpresa no funciona a volúmenes dirigidos por pedido — el porcentaje puede variar de verdad de un lote a otro, de una tanda a otra.

Los alérgenos. Como la base de datos de recetas es la única fuente de verdad sobre lo que realmente contiene una formulación, los datos de alérgenos no necesitan volver a introducirse por separado por referencia, por tanda de producción o por mercado — se derivan del mismo registro de receta que un instante antes ya generó el cálculo del QUID.

El idioma. Un fabricante por encargo que abastece a cuentas en más de un mercado necesita que la misma receta produzca etiquetas en el idioma que exija ese mercado — francés una semana, alemán la siguiente — sin un paso de traducción separado por etiqueta, por referencia, por idioma. Eso solo funciona si los nombres de los ingredientes y los términos de alérgenos existen como datos estructurados en la receta, y no como texto libre que alguien escribe a mano en una plantilla de etiqueta.

Por qué esto solo funciona si está construido para ampliarse

Este tipo de flujo se ejecuta sin supervisión, a primera hora de la mañana, con el volumen que el ERP haya transmitido ese día — lo que significa que tiene que soportar una variabilidad a la que una exportación puntual nunca se enfrenta. Los volúmenes de pedidos varían de un día a otro. Se añaden nuevas variantes de receta para nuevas cuentas. Un producto descatalogado tiene que dejar de generar etiquetas sin que nadie tenga que acordarse de desactivarlo a mano. Los cambios de impresora o de formato de etiqueta siguen su propio calendario, independiente del lado de las recetas. Una interfaz construida como un único script rígido se rompe a la primera de estas situaciones; una interfaz construida con una capa de correspondencia clara entre los datos de pedido del ERP y los datos de receta de CalcMenu absorbe cada cambio como una actualización pequeña y acotada, en lugar de como un proyecto que hay que renegociar.

La ventaja, en concreto

Bien hecho, esto elimina un riesgo concreto y recurrente en lugar de añadir una función por sí misma:

1. Sin reintroducción de datos de ingredientes o alérgenos, por referencia, por tanda de producción o por mercado — existen una sola vez, en la receta, y llegan a la etiqueta automáticamente.
2. Los porcentajes de QUID se recalculan sobre el lote realmente producido, no sobre una receta de referencia estática que se desactualiza en silencio en cuanto cambia la especificación de un proveedor.
3. Las etiquetas multilingües salen de un único registro de receta, sin un proyecto de traducción aparte cada vez que entra un nuevo mercado.
4. El flujo soporta las variaciones diarias de volumen y las nuevas variantes de receta porque está construido para funcionar sin supervisión con lo que envíe el ERP, en lugar de relanzarse a mano cada vez que algo cambia aguas arriba.

Esto no es hipotético — es la forma de un flujo que ejecutamos a diario para un fabricante de sándwiches por encargo que abastece a cuentas de retail y restauración colectiva.

Este patrón no es específico de los sándwiches — cualquier fabricante por encargo que produzca bajo pedido para cuentas de retail o restauración colectiva se topa con el mismo riesgo de fragmentación en cuanto un ERP, un sistema de recetas y una impresora de etiquetas tienen que ponerse de acuerdo cada día sobre los mismos hechos. Es un primo cercano del patrón ERP/POS/CalcMenu que describimos para operaciones hoteleras multiestablecimiento — el mismo problema de fondo, con otros sistemas al otro lado. Consulte nuestra página para fabricantes de alimentos para ver cómo se aplica esto de forma más amplia a la producción dirigida por recetas, y BlazeIQ Labels para el lado del etiquetado del propio flujo.

---

¿Produce contra un flujo diario de pedidos del ERP y está cansado de listas de ingredientes que no terminan de coincidir con lo que realmente sale hoy de la línea? Reserve una llamada de 15 minutos: Programar aquí.

Descubra el software de gestión de recetas de CalcMenu para fabricantes de alimentos y vea cómo se aplica a su cocina.