Una receta, tres sistemas: cómo mantener sincronizados un ERP, un TPV y CalcMenu

Tres sistemas, un mismo conjunto de datos

Una operación de restauración grande con varios establecimientos — un resort con varios restaurantes y bares, un estadio con puestos de venta, una naviera de cruceros con una decena de espacios de restauración — suele funcionar sobre tres sistemas independientes que, sin embargo, deben coincidir en los mismos datos de base. Un ERP (a menudo algo como JD Edwards) gestiona las compras: códigos de artículo, unidades de medida y precios de todo lo que se adquiere a proveedores. Una plataforma TPV (a menudo algo como Oracle Simphony) gestiona la caja: qué se vende, a qué precio y en qué establecimiento. Y un sistema de gestión de recetas como CalcMenu gestiona el propio producto: recetas, escandallos, valores nutricionales y alérgenos.

Ninguno de los tres sistemas se equivoca al ser la fuente de verdad de lo que le corresponde. El problema aparece cuando nadie se responsabiliza de la relación entre ellos, y alguien acaba volviendo a introducir manualmente el mismo artículo de mercancía en dos o tres sitios distintos, con la consiguiente desviación de datos que eso provoca.

Qué debe hacer realmente la interfaz

Es tentador pensar en “una interfaz con el ERP” como si fuera una única tubería. En la práctica, tiene que resolver dos problemas distintos, en dos direcciones diferentes:

Traer los datos de compras. En el ERP residen los artículos comprados: códigos, unidades y precios. Una interfaz que lee esa exportación y la casa con las fichas de artículo de CalcMenu evita que el equipo de cocina tenga que volver a teclear datos de compra que ya existen en otro sitio; la información entra una sola vez y alimenta el coste, los datos nutricionales y los alérgenos de cada receta que utiliza ese artículo. Un problema habitual: los ERP suelen manejar una unidad base (kilogramos, litros) separada de una unidad de compra (unidad, caja, bandeja) con su propio precio. La interfaz tiene que transportar ambas unidades, y el factor de conversión entre ellas, o una receta escandallada por peso no podrá cuadrarse con un stock comprado por cajas.

Enviar el coste de la receta hacia fuera. En el lado del TPV, lo que la caja necesita en realidad no es la receta tal como la ve CalcMenu, sino el coste por ración realmente vendida, vinculado a un establecimiento concreto. Esa cifra deja de coincidir con el coste por rendimiento de receta en cuanto entran en juego las recetas por lotes, así que la lógica de exportación tiene que construirse a partir de la definición de ración del TPV, no de la de CalcMenu.

Para operaciones con varios establecimientos vinculados que comparten cocina o almacén, suele haber una tercera pieza: mantener sincronizado el listado de productos transferibles del ERP con lo que realmente sigue activo en el sistema de recetas, de modo que un artículo dado de baja no quede como opción válida para mover stock entre ubicaciones.

Por qué hay que construirla pensada para crecer

Este tipo de interfaz nunca está realmente “terminada”. Las convenciones de unidades de medida se estandarizan a posteriori. La lógica de exportación al TPV se corrige en cuanto alguien detecta que estaba reportando la base de coste equivocada. Los productos dados de baja necesitan un tratamiento propio para que dejen de aparecer donde no deben. Y el propio sistema de recetas acaba migrando a una nueva plataforma tarde o temprano, lo que obliga a que la interfaz migre con él en lugar de reconstruirse desde cero. Una interfaz diseñada como una tubería única y rígida se rompe a las primeras de cambio; una diseñada con una capa de mapeo clara entre sistemas absorbe cada cambio como una actualización pequeña y acotada.

La ventaja, en concreto

Bien hecha, este tipo de integración elimina un coste concreto y recurrente, en lugar de añadir una funcionalidad por el mero hecho de tenerla:

1. Sin doble introducción de datos de mercancía. Los códigos de artículo, las unidades y los precios existen una sola vez, en el ERP, y llegan automáticamente al escandallo de recetas.
2. El TPV refleja el food cost real, no una estimación desactualizada. El menu engineering y el análisis de rentabilidad trabajan con cifras de coste por ración actuales, en lugar de una hoja de cálculo que alguien actualizó el trimestre pasado.
3. Las transferencias entre establecimientos no dependen de que alguien se acuerde de actualizar el ERP a mano.
4. La integración sobrevive a los cambios en lugar de romperse con ellos — los rediseños de unidades de medida, las correcciones en la exportación al TPV y las migraciones de plataforma en el lado de la gestión de recetas se convierten en actualizaciones incrementales en vez de proyectos que hay que renegociar.

Este patrón aparece en cualquier operación multiestablecimiento que gestione su restauración sobre un back office corporativo: resorts, navieras de cruceros, catering aéreo y grupos hoteleros multimarca se topan con él en cuanto superan un puñado de establecimientos. Consulte nuestras integraciones con sistemas TPV para ver cómo la capa de integración de CalcMenu aplica el mismo principio en distintas plataformas de ERP y TPV.

---

¿Gestiona restauración en varios establecimientos sobre un ERP y un TPV, y está cansado de volver a introducir los mismos datos de mercancía dos veces? Reserve una llamada de 15 minutos: Concertar cita aquí.