Modificare un menu in 100 locali non dovrebbe richiedere una settimana

Per la maggior parte degli operatori della ricettività con più sedi, il piano di progetto per "aggiornare il menu primaverile in tutte le strutture" richiede quattro pagine e tre settimane.

La prima settimana è dedicata allo strumento di menu engineering: calcolo dei costi, verifica degli allergeni, servizio fotografico, approvazione dell'executive chef. La seconda settimana riguarda il coordinamento del lancio: e-mail ai general manager, schede di formazione per le brigate di cucina, documenti di FAQ per il personale di sala. La terza settimana è la vera e propria distribuzione tecnica: esportazione del nuovo menu dallo strumento di menu engineering, caricamento sul portale del fornitore EPOS, invio a ciascuna singola cassa, aggiornamento separato del CMS del sito web, nuova sincronizzazione separata con la piattaforma di ordinazione online, verifica che i tablet per il servizio in camera ricevano la stessa versione del menu e, infine, dita incrociate affinché i QR code per le ordinazioni nei dehor puntino al file del menu corretto.

Durante il lancio, casse diverse nella stessa struttura potrebbero mostrare versioni differenti del menu per ore. Il sito web potrebbe riportare prezzi non corrispondenti a quelli della cassa. Il canale di ordinazione online potrebbe promuovere piatti già rimossi dalla cucina. Il tablet in camera potrebbe essere ancora sul menu della stagione precedente perché nessuno sapeva che dovesse essere aggiornato separatamente.

Non è un'esagerazione. È la realtà operativa di qualsiasi gruppo della ricettività con più sedi che utilizza uno stack legacy. Il Food and Beverage Director l'ha accettata come il prezzo da pagare per fare impresa. Il team IT ha smesso di entusiasmarsi per i lanci dei menu. Il team dell'assistenza clienti ha degli script già pronti per gestire le inevitabili lamentele del tipo "ma sul sito c'era scritto £14".

Questo articolo spiega perché non debba per forza essere così e come si presenta l'architettura quando ci si libera da questo schema.

Il motivo architetturale per cui i lanci dei menu sono lenti

Questa lentezza ha una causa di fondo: nella maggior parte degli stack, il menu è duplicato in ogni sistema che necessita di conoscerlo. L'EPOS ha la sua copia. Il CMS ha la sua copia. La piattaforma di ordinazione online ha la sua copia. Il tablet in camera ha la sua copia. Lo schermo per le ordinazioni via QR ha la sua copia. Lo strumento di menu engineering ha la sua copia. Ogni copia risiede in un database diverso con uno schema diverso, di proprietà di un fornitore diverso.

Quando il menu cambia, ogni copia deve essere aggiornata. Ogni aggiornamento è un'operazione separata. Ogni operazione presenta le proprie modalità di errore. Il livello di integrazione che dovrebbe mantenerli sincronizzati esiste solo parzialmente, opera con tempi di latenza propri e fallisce in modo silenzioso, provocando lamentele da parte dei clienti due giorni dopo.

La ragione dell'esistenza di questa architettura è storica. Ogni sistema è stato acquistato separatamente, in momenti diversi, per motivi differenti. Lo strumento di menu engineering è stato l'ultimo acquisto. L'EPOS deriva da una decisione di procurement del 2018. Il CMS è ancora più vecchio. Ogni fornitore ha creato il proprio modello di menu perché era costretto a farlo: il loro prodotto richiede una struttura di menu per funzionare e nessuno poteva fare affidamento sulla disponibilità della struttura di un altro fornitore.

Di conseguenza, ogni operatore che gestisce uno stack frammentato si ritrova con cinque o sei "menu" che descrivono tutti gli stessi piatti. E ogni operatore ha sviluppato un flusso di lavoro (formale o informale) per mantenere sincronizzati quei cinque o sei menu. E tutti gli operatori hanno accettato che, talvolta, questa sincronizzazione fallisca.

Cosa cambia quando esiste un unico menu canonico

L'architettura mDOS adotta un approccio completamente diverso. Esiste un solo menu. È salvato una sola volta per l'intera azienda, insieme alle sue categorie e ai suoi piatti. Ogni struttura viene semplicemente assegnata a questo menu: non viene creata una copia, ma un semplice collegamento, con un insieme opzionale di personalizzazioni (override) per le differenze specifiche della singola sede.

Si tratta di un modello di dati fondamentalmente diverso. Non c'è alcuna duplicazione. Il sito web, l'EPOS, il tablet in camera, lo schermo QR e il canale di ordinazione online leggono tutti i medesimi record dei piatti. Una modifica a un piatto non richiede alcuna sincronizzazione per singola interfaccia, perché esiste una sola copia.

Poiché ogni interfaccia legge da quell'unica fonte, qualsiasi modifica al menu si riflette immediatamente al successivo caricamento (il caricamento di una pagina, la richiesta del menu da parte di un terminale). Non ci sono copie da distribuire o da riconciliare tra fornitori diversi. Per l'unica modifica che deve essere applicata durante il servizio senza attendere un nuovo recupero dati (ovvero l'esaurimento/86'ing di un piatto appena terminato), un canale broadcast live invia la modifica in tempo reale a tutte le interfacce connesse (si veda la sezione dedicata all'86'ing più in basso).

Latenza misurata da quando l'operatore fa clic su "Salva" nel builder del menu a quando la modifica è attiva su ogni interfaccia connessa in tutte le strutture: circa 200 millisecondi al 95° percentile.

Non si tratta di una cifra teorica. Una singola scrittura sul database, distribuita tramite un canale WebSocket, fa sì che ogni cassa in ogni struttura mostri il nuovo stato entro mezzo secondo. Non c'è alcuna finestra di disallineamento della versione. Non c'è alcuna fase di caricamento per ciascun terminale. Non c'è alcuna attesa.

Il sistema di override che ne garantisce il funzionamento su scala aziendale

Un'architettura elementare a "un solo menu" costringerebbe ogni struttura ad essere identica. L'hotel di campagna con il menu degustazione da £180 e l'enoteca in centro città con i piatti stuzzichini da £14 dovrebbero utilizzare menu completamente distinti, annullando i vantaggi della centralizzazione.

mDOS risolve questo problema grazie al sistema di override. Il menu di base viene definito una sola volta a livello aziendale. L'assegnazione di ciascuna struttura include un piccolo set di override in grado di modificare qualsiasi campo di ogni elemento: prezzo, nome, descrizione, disponibilità, allergeni, etichette dietetiche, calorie, immagine, tipo di bevanda, gradazione alcolica (ABV), disponibilità per il servizio in camera, prezzo del servizio in camera, gruppi di modificatori, prezzi delle opzioni dei modificatori, posizionamento delle categorie, disponibilità per fasce orarie o visibilità dell'intera categoria.

Il risolutore viene eseguito interamente lato client dopo il caricamento del menu. La cascata di risoluzione è base → gruppo → struttura, dove l'override della struttura prevale a livello di ciascun campo. Il set di override è in genere inferiore a 1KB per struttura. La latenza di risoluzione è inferiore al millisecondo.

Cosa significa a livello operativo: un gruppo con 50 locali può avere un'unica definizione di "menu primaverile" con 50 set di personalizzazioni locali che gestiscono i prezzi locali, la sostituzione di ingredienti su base regionale, le finestre di disponibilità specifiche per la sede e la fotografia dedicata per ogni locale. Una modifica al menu base (ad esempio, la rimozione di un piatto fuori menu) si propaga istantaneamente a tutti i 50 locali. Una modifica alla personalizzazione di una singola sede (ad esempio, l'aumento del prezzo della bistecca nella sede di Londra) influisce solo su quella sede, senza toccare il menu base.

L'alternativa legacy consiste in 50 file menu separati, ciascuno gestito manualmente e ciascuno necessitante del proprio aggiornamento quando il menu base cambia. Lo scostamento tra di essi è inevitabile. Il carico amministrativo è notevole. La possibilità di errore è costante.

Il blocco di pubblicazione per la Natasha's Law

Nel Regno Unito, il Food Information Regulation (comunemente noto come Natasha's Law) impone agli operatori dell'hospitality di fornire informazioni complete sugli allergeni per qualsiasi alimento preparato nei locali e confezionato per la vendita. Le violazioni comportano sanzioni amministrative significative e, nei casi più gravi, la responsabilità penale.

La maggior parte dei sistemi di gestione menu per l'hospitality gestisce la conformità sugli allergeni a livello di codice applicativo. Lo strumento di creazione del menu mostra un avviso se mancano gli allergeni. Il flusso di lavoro di pubblicazione verifica la completezza. Il materiale di formazione ricorda al personale di verificare gli allergeni prima della pubblicazione. Tutto questo può essere aggirato da un operatore determinato o distratto.

mDOS gestisce questo aspetto a livello di database. Ogni voce del menu contiene uno stato relativo agli allergeni. Gli elementi ancora in attesa di verifica non possono essere pubblicati: una regola del database sull'operazione di pubblicazione del menu blocca la pubblicazione se è incluso un qualsiasi elemento non verificato. La verifica richiede un'azione esplicita: un utente autenticato con il ruolo appropriato contrassegna l'elemento come verificato, e il database registra chi lo ha verificato e quando, ai fini del registro di audit.

Non si tratta di una scelta di UX, ma di una scelta architetturale. Il database si rifiuta di pubblicare elementi non verificati, indipendentemente dall'interfaccia che tenta la pubblicazione, dall'utente che la effettua o da ciò che il codice applicativo considera accettabile. Il blocco di conformità non può essere aggirato poiché viene applicato al livello sottostante l'applicazione.

Per gli operatori multi-sede, questo fa la differenza in sede di audit. Agli ispettori delle autorità di regolamentazione è possibile mostrare il controllo direttamente a livello di database. Non un documento d'indirizzo, non un certificato di formazione, ma la vera e propria regola del database che impedisce pubblicazioni non conformi. L'impostazione della conformità passa così da procedurale ad architetturale.

86'ing in tempo reale: il momento della verità operativo

Il rilascio programmato dei menu è lo scenario pianificato. Lo scenario non pianificato (e quello che conta di più a livello operativo) è la gestione del fuori menu (86'ing) a metà servizio. La cucina esaurisce un ingrediente. Il piatto deve essere rimosso dal menu immediatamente. Ogni canale di vendita deve smettere di proporlo all'istante.

In uno stack di software frammentato, questo è un processo manuale. Lo chef avvisa il responsabile di sala. Il responsabile di sala si reca a ogni cassa per aggiornarla. Il sito web continua a mostrare il piatto per tutto il tempo necessario prima che qualcuno si ricordi di aggiornarlo. Il canale di ordinazione online continua ad accettare ordini che la cucina non può evadere. I menu QR nel dehors continuano a mostrarlo.

mDOS gestisce l'86'ing con un singolo comando. Il responsabile di sala tocca "Non disponibile" sul piatto nell'interfaccia di gestione del menu. L'aggiornamento contrassegna il piatto come non disponibile con un marcatore orario, e un canale di trasmissione in tempo reale aziendale invia la modifica a ogni punto di contatto connesso in modo pressoché istantaneo: ogni cassa smette di mostrare il piatto, ogni schermo QR lo disattiva visivamente, ogni interfaccia di ordinazione online lo contrassegna come esaurito, ogni tablet in camera lo nasconde.

La cucina non riceve mai più un ordine per il piatto messo fuori menu. Lo chef non deve scusarsi con il tavolo successivo. Il cameriere non deve tornare in cucina imbarazzato. L'ospite non prova mai la delusione di ordinare qualcosa che non può essere servito.

Per i locali ad alto flusso (venerdì sera affollati, sale piene durante il servizio, picchi di affluenza in una destinazione turistica), questo è di fondamentale importanza. Ogni minuto di ritardo tra la messa fuori menu e l'effettiva disattivazione ovunque è un minuto in cui si accumulano problemi. mDOS riduce questo ritardo a mezzo secondo.

Cosa significa questo per il F&B Director

Per il Food and Beverage Director di un gruppo multi-sede, la gestione del menu è stata uno dei vincoli operativi più frustranti del proprio ruolo. La realtà tecnica ha limitato quello che poteva realizzare. I rinnovi stagionali dei menu sono eventi trimestrali che richiedono tre settimane per essere implementati. Le modifiche a metà stagione sono complesse da gestire a livello organizzativo: richiedono il coordinamento con l'IT, le operations, il marketing e il team del brand. Quando la modifica viene pubblicata, l'opportunità è ormai passata.

In un'architettura unificata, il F&B Director può rilasciare le modifiche al menu esattamente come desidera. Il menu primaverile viene lanciato il lunedì mattina contemporaneamente in tutti i 200 locali. Le modifiche a metà settimana basate sui primi dati di vendita vengono rilasciate il mercoledì pomeriggio. Una promozione a tempo limitato parte il venerdì con personalizzazioni a livello di singola sede per i prezzi regionali. La tecnologia smette di essere un freno alle attività della funzione F&B.

Per gli acquirenti che valutano mDOS come proprietà intellettuale, la solidità architetturale del sottosistema di gestione dei menu è un indicatore chiaro. La maggior parte dei SaaS per l'hospitality tratta la gestione dei menu come una funzionalità secondaria: una schermata di modifica di base su una tabella menu del fornitore, con logica di propagazione limitata. mDOS la tratta come un sottosistema centrale con lo stesso rigore del motore di pagamento: modello di dati canonico a fonte unica, operazioni atomiche, propagazione broadcast delle disattivazioni per esaurimento scorte (86), blocchi di conformità a livello di database. La profondità ingegneristica di questo componente riflette la profondità ingegneristica dell'intera piattaforma.

---

Il sottosistema di gestione menu gestisce la risoluzione base + personalizzazione, la propagazione broadcast per la disattivazione dei piatti esauriti (86) e il blocco di verifica degli allergeni secondo la Natasha's Law. Documentazione tecnica disponibile previa sottoscrizione di NDA reciproco.