ERP für Filialnetze: zentrale Steuerung mit lokaler Flexibilität

Filialnetze haben eine spezielle ERP-Anforderung: zentral gesteuerte Stammdaten und Konditions-Strukturen müssen mit lokal autonomer Operativ-Steuerung verbunden werden. Wo eine einzelne Filiale schnell auf Kunden reagieren muss, braucht die Zentrale gleichzeitig sofortigen Überblick über alle Standorte.

Dieser Use-Case beschreibt die typischen Anforderungen von Multi-Standort-Strukturen — Einzelhandel, Gastronomie, Banken-Filialen, Service-Unternehmen mit Filialnetz — und zeigt, welche ERP-Architekturen diese Balance am besten abbilden.

Multi-Mandanten vs. Multi-Standort: was ist der Unterschied?

Wichtige Unterscheidung in der ERP-Welt: Multi-Mandant bedeutet rechtlich getrennte Unternehmen unter einem ERP — z. B. Tochtergesellschaften mit eigener Bilanzierung. Jeder Mandant hat eigene Stammdaten, eigene Buchhaltung, oft eigene USt-IdNr. Multi-Standort bedeutet ein Unternehmen mit mehreren physischen Standorten (Filialen, Niederlassungen) — gemeinsame Bilanzierung, gemeinsame Stammdaten, getrennte operative Bestände und Vorgänge. Filialnetze sind meist Multi-Standort, manchmal aber auch Multi-Mandant (z. B. Franchise-Modelle, in denen jeder Franchisenehmer rechtlich eigenständig ist). Die Architektur-Entscheidung beeinflusst die ERP-Auswahl erheblich — nicht alle ERPs beherrschen beide Modelle gleich gut.

Zentrale Stammdaten, lokale Vorgänge — Architektur-Pattern

Standard-Architektur für gut funktionierende Filialnetz-ERPs: Zentral verwaltet (von Headquarter): Artikelstamm, Konditions-Strukturen, Lieferanten, globale Promotions, Berichts-Templates, Compliance-Vorgaben. Änderungen werden zentral gepflegt und automatisch an alle Filialen verteilt. Lokal verwaltet (pro Filiale): Bestände, Kunden-Vorgänge, Tages-Abrechnung, Personal-Einsatz, lokale Sonder-Konditionen (innerhalb zentral definierter Bandbreiten). Synchronisations-Logik: tagsüber arbeiten Filialen weitgehend autonom, abends/nachts wird mit der Zentrale synchronisiert. Bestände, Umsätze, Personal-Stunden fließen zur Zentrale, neue Stammdaten und Konditionen kommen zurück. Echtzeit-Aspekte: für Aufgaben wie Filial-übergreifende Verfügbarkeits-Prüfung (Kunde fragt im Laden A nach Artikel, der in Laden B verfügbar ist) braucht es Echtzeit-Datenzugriff. Nicht alle Filial-ERPs unterstützen das gleichermaßen.

Kassen-Integration: POS und ERP

Im Einzelhandel ist die Verbindung zwischen Point-of-Sale (Kassensystem) und ERP zentral. Drei Architektur-Optionen: Integriertes ERP+POS: ein System (z. B. Microsoft Dynamics 365 Business Central mit Commerce-Modul, SAP Business One mit Retail-Add-on). Vorteil: einheitliche Datenbasis. Nachteil: schwer-gewichtig für kleine Filialen. Best-of-Breed mit Schnittstelle: Spezialisiertes POS-System (Vectron, Lightspeed, Korona) plus ERP, verbunden über REST-API. Vorteil: jedes System optimiert für seine Domäne. Nachteil: Schnittstelle muss gewartet werden. Cloud-POS mit ERP-Integration: Square, Lightspeed Cloud, Shopify POS — direkter Austausch über Cloud-APIs. Modernste Variante, gut skalierbar.

Konzern-Reporting für Filialnetze

Das Reporting in Filialnetzen ist mehrdimensional: Pro Filiale (operativ relevant für den Filial-Leiter), Pro Region (für Regional-Manager), Konzern-übergreifend (für Geschäftsführung), Pro Produkt-Kategorie, Pro Saison, Vergleich vs. Vorjahr, Vergleich vs. Plan. Klassische ERP-Standard-Reports decken das selten alle ab. Empfehlung: dediziertes BI-Werkzeug (Power BI, Qlik Sense, Tableau) anbinden, das auf die ERP-Datenbasis aufsetzt. Vorteil: flexible Filter-Dimensionen, schnelle Drill-Down-Möglichkeiten, von Filial-Leiter bis CFO einheitliches Tool.