Ein Werk, zwei Märkte: Wie eine Bäckereikette Rezepte und Dynamics 365 synchron hält

Jeden Morgen überquert ein Croissant eine Grenze

Jeden Morgen verlassen Lieferwagen voller Viennoiserie, Sandwichbrot und Kuchen ein Produktionswerk und überqueren eine Landgrenze in einen Nachbarmarkt, bevor der erste Kunde ein Geschäft betritt. Die Gruppe hinter dieser Route ist nichts Ungewöhnliches: eine regionale Bäckerei-Café-Marke mit eigenem Filialnetz, nach dem Betriebsmodell, das für Ketten üblich ist, die in einem Land entstanden und in ein Nachbarland expandiert sind, in dem Grundstücks- und Personalkosten die lokale Produktion schwerer skalierbar machen. Ein Land produziert; das andere verkauft überwiegend.

Kommerziell funktioniert dieses Modell. Operativ entsteht dabei ein Problem, das sich leise zeigt, Monate nachdem der erste Lastwagen die Grenze überquert hat: Das Werk läuft auf Rezepten, die Gruppe läuft auf Microsoft Dynamics 365. Lange Zeit haben diese beiden Systeme nicht miteinander gesprochen.

Was Dynamics 365 weiss — und was nicht

Dynamics 365 leistet genau das, was ein Lebensmittelhersteller von einem ERP erwartet: Bestellungen bei Mehl- und Butterlieferanten, Wareneingangsbelege am Werkstor, konzerninterne Rechnungsstellung zwischen der Produktionseinheit und der Verkaufseinheit jenseits der Grenze, Bestandsbewertung und Konsolidierung auf Gruppenebene. Daran gibt es nichts auszusetzen — das Finanzteam des Werks führt Dynamics 365 gut.

Was Dynamics 365 nicht weiss, ist, was im Kneter passiert. Es erfasst, dass das Werk 800 Kilogramm Butter zu einem bestimmten Preis eingekauft hat. Es weiss nicht, wie viel Butter in ein einzelnes Croissant fliesst, wie hoch die Ausbeute nach Gare und Backen ist, was die Allergendeklaration aussagen muss, sobald diese Butter auf Weizenmehl und Eier trifft, oder wie eine Rezepturänderung für den Nachbarmarkt — ein niedrigerer Zuckergehalt, um eine bessere Nährwertbewertung auf der Verpackungsvorderseite zu erreichen, zum Beispiel — die Kosten pro Einheit verändert. Genau diese Lücke zwischen dem, was die Finanzabteilung sieht, und dem, was das Werk produziert, ist der Ort, an dem zwei Probleme gleichzeitig auftreten: eine Kostenverzerrung, die die Finanzabteilung erst am Monatsende bemerkt, und Allergen- oder Nährwertetiketten, die dem tatsächlichen Rezept hinterherhinken.

Eine Rezeptschicht zwischen Ofen und Hauptbuch

Die Lösung besteht nicht darin, von Dynamics 365 zu verlangen, ein Bäckereisystem zu werden — dafür wurde es nie gebaut, und es zu erzwingen erzeugt genau die Art von Workaround, die die Datenintegrität eines ERP untergräbt. Die Lösung ist, dem Werk eine Rezept- und Produktionsschicht zu geben, die die Sprache des Werks spricht — Rezepturen, Ausbeuten, Teilrezepte, Chargengrössen — und sich automatisch mit der Sprache von Dynamics 365 abstimmt: Bestellungen und Lagerbewegungen.

In der Praxis bedeutet das: Die Referenzrezeptur jedes Produkts — das Masterrezept mit seinen Zutaten, Bäckerprozenten und Prozessschritten — liegt an einem einzigen Ort, geteilt über beide Märkte hinweg. Wenn ein Bäcker im Werk ein Rezept anpasst (eine andere Fettmischung, eine neu formulierte Füllung), berechnet das System im selben Schritt neu: die Allergendeklaration, die für die Kennzeichnung im Nachbarmarkt erforderlichen Nährwerte und die tatsächlichen Kosten pro Einheit auf Basis der Zutatenpreise, die bereits aus den Einkaufsdaten von Dynamics 365 einfliessen. Dieses kalkulierte Ergebnis — die Standardkosten eines Fertigprodukts — fliesst dann als Grundlage für Bestandsbewertung und konzerninterne Verrechnungspreise in Dynamics 365 zurück, statt einer manuell gepflegten Schätzung, die still veraltet, sobald ein Lieferant seinen Preis ändert.

Compliance reist mit dem Rezept, nicht hinterher

Für ein Werk, das in einen zweiten Markt liefert, zählt das doppelt. Zwei Nachbarmärkte teilen selten identische Kennzeichnungs- und Lebensmittelsicherheitsanforderungen, und eine Rezepturänderung für einen von ihnen — weniger Zucker, um die Nährwertbewertung auf der Verpackungsvorderseite eines Gebäcks zu verbessern, zum Beispiel — muss sich überall niederschlagen, wo das Rezept verwendet wird: auf dem im Werk gedruckten Etikett, in der am Verkaufsort gezeigten Nährwerttabelle und im Rückverfolgbarkeitsdatensatz, der eine fertige Charge mit den konkreten Zutatenlosen für die Regulierungsbehörden beider Märkte verknüpft.

Ohne eine einzige Rezeptquelle als Wahrheit ist genau das der Punkt, an dem die Dinge auseinanderdriften: Das Werk aktualisiert die Rezeptur, aber die Etikettenvorlage, die Nährwertdaten am Verkaufspunkt und der Kostendatensatz des ERP aktualisieren sich nach drei verschiedenen Zeitplänen — wenn überhaupt. Wenn Produktion, Etikettierung und Kalkulation dasselbe Rezept lesen, verbreitet sich eine einzelne Änderung überall dorthin, wo sie gebraucht wird, noch am selben Tag.

Die Finanzabteilung sieht das Werk, nicht nur die Rechnung

Der kommerzielle Nutzen liegt weniger in der Software selbst als in dem, was sie sichtbar macht. Wenn das Finanzteam der Gruppe die realen, aktuellen Kosten pro Einheit sieht — keine grobe Verteilung — für jedes Produkt, das die Grenze überquert, werden Fragen, die früher einen Monat brauchten, sofort beantwortbar: Ist ein Produkt nach einer Lieferantenpreiserhöhung noch profitabel? Spiegelt der konzerninterne Verrechnungspreis zwischen dem Werk und den Filialen jenseits der Grenze noch die tatsächlichen Produktionskosten wider? Welche Produktlinie frisst still die Marge auf, weil ihre Rezeptur vor Monaten geändert wurde und niemand die Standardkosten neu berechnet hat?

Das ist dasselbe Prinzip, das für jede Gruppe gilt, die mehrere Standorte von einer Zentralküche oder einem Zentralwerk aus führt: Das ERP behält seine Rolle als führendes System für Geld — Einkauf, Zahlungen, Konsolidierung —, und ein dediziertes Rezept- und Produktionssystem wird zum führenden System für das, was das Werk tatsächlich herstellt. Dynamics 365 und die Rezeptschicht stimmen miteinander überein, statt dass eines vom anderen still abdriftet.

Bereit, Ihr Werk anzuschliessen?

Wenn Ihre Gruppe in einem Markt produziert und in einem anderen verkauft — oder mehrere Werke betreibt, die mehrere Länder beliefern — gilt dasselbe Muster, unabhängig davon, welches ERP im Zentrum steht. CalcMenu ist so konzipiert, dass es neben Dynamics 365 oder jedem anderen ERP steht, niemals an dessen Stelle, damit Ihre Rezepte, Ihre Kosten und Ihre Compliance-Daten mit dem System synchron bleiben, dem Ihr Finanzteam bereits vertraut.

Vereinbaren Sie einen 15-minütigen Anruf mit Marc unter https://calendly.com/marceng/15-min-call-calcmenu-marc, um zu sehen, wie eine vernetzte Rezeptschicht für Ihr Werk funktionieren würde.