Un'unica ricetta, tre sistemi: come mantenere sincronizzati ERP, POS e CalcMenu

Tre sistemi, un’unica base di fatti condivisi

Una grande realtà di ristorazione con più punti vendita — un resort con diversi ristoranti e bar, uno stadio con i suoi stand gastronomici, una compagnia di crociere con una dozzina di sale ristorante — si appoggia tipicamente su tre sistemi distinti, che devono però condividere la stessa base di fatti. Un ERP (spesso una soluzione come JD Edwards) governa gli acquisti: codici articolo, unità di misura e prezzi di tutto ciò che viene acquistato dai fornitori. Una piattaforma POS (spesso una soluzione come Oracle Simphony) governa la cassa: cosa viene venduto, a quale prezzo, in quale punto vendita. E un sistema di gestione ricette come CalcMenu governa il prodotto alimentare in sé: ricette, costing, valori nutrizionali e allergeni.

Nessuno dei tre sistemi sbaglia a essere la fonte di verità per ciò che gli compete. Il problema emerge quando nessuno si assume la responsabilità della relazione tra i tre, e qualcuno finisce per reinserire manualmente lo stesso articolo di merce in due o tre punti diversi, con il conseguente disallineamento che ne deriva inevitabilmente.

Cosa deve fare davvero l’interfaccia

È facile pensare a “un’interfaccia ERP” come a un unico canale di collegamento. In pratica, deve invece risolvere due problemi distinti, in due direzioni opposte:

Portare in ingresso i dati di acquisto. È nell’ERP che risiedono gli articoli acquistati — codici, unità di misura e prezzi. Un’interfaccia che legge questo export e lo abbina alle schede articolo di CalcMenu fa sì che il team di cucina non debba mai reinserire dati d’acquisto già presenti altrove: il dato entra una sola volta e alimenta automaticamente costo, valori nutrizionali e allergeni di ogni ricetta che lo utilizza. Una complicazione ricorrente: gli ERP tengono spesso traccia di un’unità di base (chilogrammi, litri) distinta da un’unità d’acquisto (pezzo, cassa, vassoio) con un proprio prezzo — l’interfaccia deve trasportare entrambe le unità, e il rapporto di conversione tra loro, altrimenti una ricetta costificata a peso non può essere riconciliata con uno stock acquistato a cassa.

Inviare in uscita il costo della ricetta. Sul versante POS, ciò di cui la cassa ha realmente bisogno non è la ricetta così come la vede CalcMenu, bensì il costo per porzione effettivamente venduta, associato a un punto vendita specifico. È un valore diverso dal costo per resa di ricetta non appena entrano in gioco le ricette in lotto (batch), motivo per cui la logica di esportazione va costruita sulla definizione di porzione del POS, non su quella di CalcMenu.

Per le realtà con più punti vendita collegati che condividono una cucina o un magazzino, c’è spesso un terzo elemento: mantenere sincronizzato l’elenco dei prodotti trasferibili nell’ERP con ciò che è realmente ancora attivo nel sistema ricette, in modo che un articolo dismesso non resti disponibile come opzione valida per lo spostamento di merce tra le sedi.

Perché va progettata per essere estesa

Un’interfaccia di questo tipo non è mai davvero “conclusa”. Le convenzioni sulle unità di misura vengono standardizzate a posteriori. La logica di esportazione verso il POS viene corretta quando qualcuno si accorge che stava riportando la base di costo sbagliata. I prodotti dismessi richiedono una gestione dedicata, perché smettano di comparire dove non dovrebbero. E prima o poi lo stesso sistema di gestione ricette migra verso una nuova piattaforma, il che significa che l’interfaccia deve migrare con esso invece di essere ricostruita da zero. Un’interfaccia progettata come un unico canale rigido si rompe al primo di questi eventi; una progettata con un livello di mappatura chiaro tra i sistemi assorbe ogni cambiamento come un aggiornamento piccolo e circoscritto.

Il vantaggio, in concreto

Se realizzata bene, questo tipo di integrazione elimina un costo specifico e ricorrente, invece di aggiungere una funzionalità fine a se stessa:

1. Nessuna doppia codifica dei dati di merce. Codici articolo, unità di misura e prezzi esistono una sola volta, nell’ERP, e raggiungono automaticamente il costing delle ricette.
2. Il POS riflette il food cost reale, non una stima obsoleta. Il menu engineering e l’analisi della redditività si basano su cifre di costo per porzione aggiornate, invece che su un foglio Excel aggiornato l’ultimo trimestre da qualcuno.
3. I trasferimenti tra punti vendita non dipendono dal fatto che qualcuno si ricordi di aggiornare l’ERP a mano.
4. L’integrazione sopravvive al cambiamento invece di rompersi di fronte ad esso — revisioni delle unità di misura, correzioni della logica di esportazione verso il POS e migrazioni di piattaforma sul lato gestione ricette diventano tutti aggiornamenti incrementali, non progetti da rinegoziare da capo.

Questo schema si presenta ovunque una realtà con più punti vendita gestisca la ristorazione sopra un back office aziendale: resort, compagnie di crociere, catering aereo e gruppi alberghieri multi-marchio lo incontrano tutti non appena superano una manciata di punti vendita. Consultate la nostra pagina sulle integrazioni con i sistemi POS per scoprire come il livello di integrazione di CalcMenu applichi lo stesso principio a diverse piattaforme ERP e POS.

---

Gestite la ristorazione su più punti vendita sopra un parco ERP e POS, e siete stanchi di reinserire due volte gli stessi dati di merce? Prenotate una chiamata di 15 minuti: Prenotate qui.