Wie du Prozesse über mehrere Standorte im ERP standardisierst: Blueprint inkl. Rollen, Workflows & Berechtigungen

Warum Wachstum auf mehrere Standorte ohne ERP-Struktur zu Problemen führt 

Die Anfangszeit vieler Handels- und Logistikunternehmen verläuft gut überschaubar: Ein Lager, ein Team, ein Prozess, ein Ort. Wenn jemand nicht weiß, wie eine Retoure zu bearbeiten ist, hilft kurzes Nachfragen auf dem Flurfunk.

Dann kommt das Wachstum. Ein zweites Lager, ein externer Dienstleister, vielleicht ein Großhandelsstandort zusätzlich zum eigenen Shop. Und plötzlich funktioniert das, was vorher selbstverständlich war, nicht mehr. Nicht weil das Team schlechter geworden ist, sondern weil der zugrunde gelegte Prozess der Warenwirtschaft nie für mehrere Standorte gebaut war.

Bestände laufen auseinander, weil jeder Standort seine eigene Logik entwickelt und niemand weiß, welcher Standort welchen Auftrag bearbeitet. Mitarbeitende bauen Insellösungen wie Excel-Listen, WhatsApp-Gruppen oder handgeschriebene Notizen. Und in der Peak-Saison, wenn Fehler am teuersten sind, häufen sich genau diese Fehler.

Das ist kein Organisationsproblem, es ist ein Strukturproblem. Die Lösung dafür ist keine neue Kommunikationsregel, sondern ein ERP für Multi-Lager. Es trägt die Standardisierung standortübergreifend und automatisch; es sichert sie ab, ohne dass jemand permanent nachhaken muss.

Was Standardisierung für das ERP mehrerer Standorte wirklich bedeutet 

Wenn größere Unternehmen von Prozessstandardisierung sprechen, meinen sie üblicherweise monatelange Dokumentationsprojekte, Zertifizierungen und externe Beratungen. Bei der Standardisierung im Sinne des ERP geht es aber ganz pragmatisch darum, dass wachsende Handelsunternehmen mit zwei oder drei Standorten alle Prozesse für alle Standorte mithilfe des ERP-Systems vereinheitlichen.

Zum Beispiel: Eine neue Lagermitarbeiterin an Standort B kann am ersten Tag genauso arbeiten wie das Team an Standort A, weil das ERP ihr genau zeigt, was sie sehen darf, was sie tun soll und wie der Prozess läuft. Nicht, weil jemand es ihr erklärt hat.

Das ist der Unterschied zwischen einem ERP, das Daten verwaltet, und einem ERP, das Prozesse trägt.

Die 3 Ebenen: Rollen & Berechtigungen – Workflows – Bestandsführung 

Ebene 1: Rollen & Berechtigungen festlegen – wer sieht was, wer darf was 

Bevor du Workflows für Lagerprozesse im ERP standardisieren kannst, musst du klären, wer an welchem Standort welche Informationen braucht, und welche nicht. Das ist die Grundlage.

Ein häufiger Fehler: Alle Mitarbeitenden erhalten Zugriff auf alles, weil es einfacher einzurichten ist. Das klingt praktisch, erzeugt aber Probleme. Lagermitarbeitende sehen Einkaufskonditionen, die sie nicht sehen sollten. Jemand ändert versehentlich Stammdaten, die standortübergreifend gelten. Und wenn etwas schiefläuft, ist unklar, wer was gemacht hat.

Wie ein sauberes Rollenmodell aussieht:

In Xentral werden Rollen und Berechtigungen auf Benutzerebene konfiguriert und sind standortspezifisch einschränkbar, je nachdem, was operativ sinnvoll ist. Das bedeutet: Dieselbe Person kann an Standort A volle Lagerrechte haben, an Standort B aber nur Lesezugriff.

Warum das für KI relevant ist: Wenn ein KI-Agent Eingangsrechnungen verarbeitet und automatisch den richtigen Standort zuordnen soll, funktioniert das nur, wenn die Berechtigungsstruktur sauber definiert ist. Ein Agent, der nicht weiß, welche Belege zu welchem Standort gehören, kann menschliche Entscheidungen nicht sinnvoll vorbereiten. Die Rollenstruktur ist also nicht nur für Menschen wichtig, sie ist vielmehr die Grundlage dafür, dass Automatisierung standortübergreifend wirkt.

Ebene 2: ERP-Workflows für die Lager standardisieren – was muss überall gleich laufen, was darf variieren 

Nicht jeder Prozess muss an jedem Standort identisch sein. Aber manche müssen es, und wenn das nicht klar geregelt ist, entstehen genau hier die meisten Fehler.

Die Faustregel: Alles, was Daten erzeugt, die standortübergreifend genutzt werden, muss standardisiert sein. Alles, was rein lokal bleibt, darf variieren.

Muss standardisiert sein:

• Kommissionierung: Wenn Pick-Listen an Standort A nach Lagerplatz sortiert werden und an Standort B nach Auftragsreihenfolge, entstehen unterschiedliche Fehlerquoten und kein vergleichbares Reporting. Einheitliche Pick-Logik im ERP verhindert das.
• Eingangsrechnungsverarbeitung: Jede Eingangsrechnung muss nach demselben Schema erfasst, geprüft und dem richtigen Standort zugeordnet werden. Andernfalls stimmt die Kostenstelle nicht, und die Buchhaltung hat ein Problem.
• Retourenbearbeitung: Retouren, die an unterschiedlichen Standorten unterschiedlich bewertet und eingebucht werden, erzeugen Bestandsdifferenzen. Einheitliche Retourengründe, Bewertungsregeln und Buchungslogik sind Pflicht.

Darf variieren:

• Verpackungsmaterial (lokale Lieferanten, unterschiedliche Formate)
• Lokale Lieferanten für Verbrauchsmaterial
• Schichtzeiten und interne Lagerorganisation
• Regionale Versanddienstleister

In Xentral kannst du Workflows über den Workflow-Editor standortübergreifend definieren und gleichzeitig lokale Ausnahmen abbilden. Das bedeutet: Der Grundprozess ist überall gleich, aber Standort B kann trotzdem seinen regionalen Paketdienstleister nutzen.

Ebene 3: Bestandsverwaltung über mehrere Standorte im ERP – der technisch konkreteste Teil 

Sobald zwei Lager dieselbe Stock Keeping Unit (SKU) halten, entstehen Fragen, die ohne saubere ERP-Konfiguration nicht lösbar sind: Das wird für viele Operations Manager zum eigentlichen Knackpunkt.

• Welcher Bestand ist wo verfügbar?
• Wie wird ein Transfer zwischen Standorten abgebildet?
• Wie verhindert man Überverkäufe, wenn beide Lager denselben Artikel anbieten?

Bestandsführung im Mehrstandort-Betrieb – die Grundprinzipien:

1. Lagerplätze und Standorte sauber trennen 
   ⁠Jeder Standort ist im ERP als eigenes Lager angelegt, mit eigenen Lagerplätzen. Der Gesamtbestand einer SKU ergibt sich aus der Summe aller Standorte, aber jeder Standort führt seinen eigenen Teilbestand. So sieht die Lagerleitung den Gesamtüberblick, während die Lagermitarbeitenden nur ihren eigenen Bereich sehen.
2. Transfers zwischen Standorten als eigene Bewegung abbilden
   ⁠Wenn Ware von Standort A nach Standort B geht, ist das keine einfache Umbuchung, sondern ein Transferauftrag mit eigenem Status. Warum das wichtig ist: Während die Ware unterwegs ist, gehört sie weder vollständig zu Standort A noch zu Standort B. Ein sauber abgebildeter Transfer verhindert, dass dieser „schwebende“ Bestand doppelt verkauft wird.
3. Verfügbaren Bestand pro Kanal steuern
   ⁠Ein ERP stimmt die Lagerverwaltung für mehrere Lager zuverlässig aufeinander ab: Wenn dein Shop und dein Großhandelsstandort aus denselben Lagern bedient werden, musst du dafür definieren, welcher Bestand für welchen Kanal reserviert ist. In Xentral kannst du über die Lagerverwaltung Bestandspuffer und Kanalzuordnungen konfigurieren. So verhinderst du, dass ein Artikel im Shop als verfügbar angezeigt wird, obwohl er bereits für einen Großhandelsauftrag reserviert ist.
4. Überverkäufe aktiv verhindern
   ⁠Der häufigste Fehler im Mehrstandort-Betrieb: Zwei Kanäle greifen gleichzeitig auf denselben Bestand zu, ohne dass das ERP eine Sperrmechanik hat. Die Lösung ist eine zentrale Bestandssteuerung, bei der der verfügbare Bestand in Echtzeit aktualisiert wird, und nicht einmal täglich per Batch-Import.

Übersicht: Bestandsführung im Mehrstandort-Betrieb

Und hier kommt die unterstützende Automatisierung eines KI-nativen ERPs ins Spiel: Wenn diese Bestandsstruktur sauber im ERP abgebildet ist, kann ein KI-Agent in Xentral Bestandsanomalien erkennen, bevor sie zum Problem werden.

Zum Beispiel: Der Agent erkennt, dass Standort B in den nächsten drei Tagen unter den Mindestbestand einer SKU fällt, und schlägt automatisch einen Transferauftrag aus Standort A vor. Das funktioniert aber nur, weil die Datenstruktur dahinter sauber angelegt ist. Ohne standardisierte Bestandsführung hat der Agent keine verlässliche Grundlage.

Blueprint: Dein Schritt-für-Schritt-Plan für den Mehrstandort-Aufbau 

Nun geht’s an die praktische Umsetzung der theoretischen Grundlagen. Mit dem folgenden Blueprint kannst du ein ERP für mehrere Lager einrichten, mitsamt Rollen, Workflows und Bestandsführung. Nutze ihn direkt als Grundlage für deinen eigenen Aufbau.

Schritt 1: Standorte und Lager im ERP anlegen 

• Jeden physischen Standort als eigenes Lager im ERP abbilden
• Lagerplätze standortspezifisch strukturieren (Gänge, Regale, Zonen)
• Externe Fulfiller als eigenes Lager anlegen (auch wenn du keinen direkten Zugriff auf die physische Struktur hast)

Schritt 2: Rollenmodell definieren 

• Welche Rollen gibt es in deinem Unternehmen?
• Welche Rolle braucht Zugriff auf welchen Standort?
• Welche Daten darf welche Rolle sehen, und welche nicht?
• Rollen im ERP anlegen und Berechtigungen standortspezifisch konfigurieren

Schritt 3: Kernprozesse standardisieren 

• Kommissionierlogik für alle Standorte einheitlich definieren
• Eingangsrechnungsverarbeitung mit Standortzuordnung aufsetzen
• Retourenprozess mit einheitlichen Gründen und Buchungsregeln konfigurieren
• Lokale Ausnahmen (Verpackung, Lieferanten) als standortspezifische Parameter hinterlegen

Schritt 4: Bestandsführung konfigurieren 

• Zentralen Gesamtbestand mit Standort-Teilbeständen aufsetzen
• Transferprozess zwischen Standorten definieren und im ERP abbilden
• Bestandspuffer und Kanalzuordnungen für Shop und Großhandel konfigurieren
• Mindestbestände pro Standort und SKU hinterlegen

Schritt 5: Workflows im ERP abbilden 

• Standardprozesse als Workflows im ERP konfigurieren
• Automatische Trigger definieren (z. B. Transfervorschlag bei Unterschreitung des Mindestbestands)
• Benachrichtigungen und Eskalationsregeln standortspezifisch einrichten

Schritt 6: Testen und ausrollen 

• Pilotbetrieb an einem Standort, bevor alle Standorte umgestellt werden
• Mitarbeitende an den neuen Prozessen schulen; zur Verdeutlichung: nicht an der Software, sondern am Prozess
• Erste vier Wochen eng begleiten, Abweichungen dokumentieren und Konfiguration anpassen

Schritt 7: KI-Agenten aktivieren (wenn Grundlage steht) 

• Erst wenn Schritte 1–6 stabil laufen, KI-Agenten einschalten
• Startpunkt: Bestandsüberwachung und automatische Transfervorschläge
• Nächster Schritt: Eingangsrechnungsverarbeitung mit automatischer Standortzuordnung

Wichtig: Schritt 7 ist kein optionaler Bonus. Er ist vielmehr der zentrale Grund, warum die Schritte 1 bis 6 so wichtig sind. Ein KI-natives ERP kann nur dann mehrere Lager verwalten und standortübergreifend automatisieren, wenn die Daten- und Prozessstruktur dahinter sauber ist.

Fazit: Bereits wenige Grundlagen sorgen für geordnetes Wachstum 

Wachstum über mehrere Standorte ist kein Selbstläufer. Wenn ein zweites Lager oder ein externer Fulfiller dazukommt, dann funktionieren Prozesse, die bisher auf persönlicher Kommunikation basierten, nicht mehr.

Die gute Nachricht: Das ist lösbar. Nicht durch mehr Meetings oder neue Kommunikationsregeln, sondern durch eine saubere Struktur im ERP, mit Rollen, Workflows und Bestandsführung, die standortübergreifend einheitlich laufen.

Und wenn diese Struktur steht, passiert etwas Interessantes: Du hast nicht nur einen besseren Überblick. Du hast die Grundlage dafür, dass KI-Agenten echte Arbeit übernehmen und Entscheidungen vorbereiten können. Agenten unterstützen fortan etwa bei Transfervorschlägen, Rechnungsverarbeitung oder Bestandsüberwachung, ohne dass jemand manuell eingreifen muss.

Du siehst also: Das ist der Unterschied zwischen einem ERP, das Daten speichert, und einem ERP, das dein Unternehmen aktiv trägt.