Uno stabilimento, due mercati: come una catena di panetteria sincronizza le ricette con Dynamics 365

Ogni mattina un croissant attraversa un confine

Ogni mattina, furgoni carichi di viennoiserie, pane da sandwich e torte lasciano uno stabilimento di produzione e attraversano un confine terrestre verso un mercato vicino prima che il primo cliente entri in un negozio. Il gruppo dietro questo tragitto non ha nulla di insolito: un marchio regionale di panetteria-caffetteria con una propria rete di vendita, secondo un modello operativo comune alle catene nate in un paese ed espanse in un paese vicino, dove il costo degli immobili e della manodopera rende più difficile far scalare la produzione locale. Un paese produce; l’altro vende principalmente.

Questo modello funziona dal punto di vista commerciale. Sul piano operativo crea un problema che emerge silenziosamente, mesi dopo che il primo camion ha attraversato il confine: lo stabilimento funziona con le ricette, il gruppo funziona con Microsoft Dynamics 365. Per molto tempo, questi due sistemi non si sono parlati.

Cosa sa Dynamics 365, e cosa non sa

Dynamics 365 fa esattamente ciò che un produttore alimentare si aspetta da un ERP: ordini d’acquisto ai fornitori di farina e burro, bolle di ricevimento merci alla banchina dello stabilimento, fatturazione infragruppo tra l’entità di produzione e l’entità di vendita al di là del confine, valorizzazione delle scorte, consolidamento finanziario a livello di gruppo. Nulla di tutto ciò è in discussione — il team finance dello stabilimento gestisce Dynamics 365 correttamente.

Ciò che Dynamics 365 non sa è cosa succede dentro l’impastatrice. Registra che lo stabilimento ha acquistato 800 chilogrammi di burro a un certo prezzo. Non sa quanto burro finisce in un singolo croissant, qual è la resa dopo lievitazione e cottura, cosa deve indicare la dichiarazione allergeni una volta che quel burro incontra farina di frumento e uova, né come una modifica di formulazione per il mercato vicino — un livello di zucchero più basso per ottenere una migliore valutazione nutrizionale in etichetta frontale, per esempio — cambi il costo per unità. Questo divario tra ciò che vede la finanza e ciò che lo stabilimento produce è esattamente il punto in cui appaiono contemporaneamente due problemi: una deriva dei costi che la finanza nota solo a fine mese, ed etichette allergeni o nutrizionali che restano indietro rispetto alla ricetta reale.

Un livello di ricette tra il forno e il libro contabile

La soluzione non è chiedere a Dynamics 365 di diventare un sistema da panificio — non è mai stato costruito per questo, e forzarlo produce esattamente il tipo di scorciatoia che erode l’integrità dei dati di un ERP. La soluzione è dare allo stabilimento un livello di ricette e produzione che parli la lingua dello stabilimento — formulazioni, rese, sotto-ricette, dimensioni dei lotti — e che si riconcili automaticamente con la lingua di Dynamics 365, fatta di ordini d’acquisto e movimenti di magazzino.

In pratica, questo significa che la formulazione di riferimento di ogni prodotto — la ricetta madre con i suoi ingredienti, le percentuali del panettiere e le fasi di processo — vive in un unico posto, condiviso tra entrambi i mercati. Quando un panettiere dello stabilimento modifica una ricetta (una diversa miscela di grassi, un ripieno riformulato), il sistema ricalcola, nello stesso momento: la dichiarazione allergeni, i valori nutrizionali richiesti per l’etichettatura nel mercato vicino, e il costo reale per unità basato sui prezzi degli ingredienti già provenienti dai dati d’acquisto di Dynamics 365. Questo risultato calcolato — il costo standard di un prodotto finito — è ciò che rifluisce in Dynamics 365 come base per la valorizzazione delle scorte e il prezzo di trasferimento infragruppo, invece di una stima mantenuta manualmente che diventa silenziosamente obsoleta non appena un fornitore cambia il proprio prezzo.

La conformità viaggia con la ricetta, non dietro di essa

Per uno stabilimento che spedisce verso un secondo mercato, questo conta doppiamente. Due mercati vicini condividono raramente requisiti identici di etichettatura e sicurezza alimentare, e una modifica di ricetta fatta per uno di essi — ridurre lo zucchero per migliorare la valutazione nutrizionale in etichetta frontale di un dolce, per esempio — deve riflettersi ovunque la ricetta venga utilizzata: l’etichetta stampata in stabilimento, il pannello nutrizionale mostrato al punto vendita, e il registro di tracciabilità che collega un lotto finito ai lotti specifici di ingredienti per i regolatori di entrambi i mercati.

Senza un’unica fonte di verità per la ricetta, è esattamente qui che le cose divergono: lo stabilimento aggiorna la formulazione, ma il modello di etichetta, i dati nutrizionali del punto vendita e il registro dei costi dell’ERP si aggiornano secondo tre tempistiche diverse, quando lo fanno. Quando produzione, etichettatura e costing leggono la stessa ricetta, una singola modifica si propaga ovunque sia necessario, lo stesso giorno in cui viene fatta.

La finanza vede lo stabilimento, non solo la fattura

Il vantaggio commerciale riguarda meno il software e più ciò che esso rende visibile. Quando il team finance del gruppo può vedere il costo reale e attuale per unità — non una ripartizione approssimativa — per ogni prodotto che attraversa il confine, domande che prima richiedevano un mese diventano immediate: un prodotto è ancora redditizio dopo un aumento di prezzo del fornitore? Il prezzo di trasferimento infragruppo tra lo stabilimento e i negozi al di là del confine riflette ancora il costo di produzione reale? Quale linea di prodotto sta silenziosamente erodendo il margine perché la sua formulazione è cambiata mesi fa e nessuno ha ricalcolato il costo standard?

È lo stesso principio che si applica a qualsiasi gruppo che gestisce più sedi da una cucina o uno stabilimento centrale: l’ERP mantiene il proprio ruolo di sistema di riferimento per il denaro — acquisti, pagamenti, consolidamento — e un sistema dedicato di ricette e produzione diventa il sistema di riferimento per ciò che lo stabilimento produce realmente. Dynamics 365 e il livello di ricette concordano tra loro, invece che uno derivi silenziosamente dall’altro.

Pronti a collegare il vostro stabilimento?

Se il vostro gruppo produce in un mercato e vende in un altro — o gestisce più stabilimenti che riforniscono più paesi — lo stesso schema si applica indipendentemente da quale ERP sia al centro. CalcMenu è progettato per affiancarsi a Dynamics 365 o a qualsiasi altro ERP, mai per sostituirlo, così che le vostre ricette, i vostri costi e i vostri dati di conformità restino sincronizzati con il sistema di cui il vostro team finance già si fida.

Prenotate una chiamata di 15 minuti con Marc su https://calendly.com/marceng/15-min-call-calcmenu-marc per vedere come un livello di ricette connesso funzionerebbe per il vostro stabilimento.