LE-Stammdaten sind in vielen Mittelstandssystemen über Jahre gewachsen. Versandstellen wurden je nach Bedarf angelegt, Routen je nach Kundenkonstellation dazugefügt, Spediteure ohne klare Rolle ins System gebracht. Nach zehn Jahren steht eine Konstruktion, die niemand mehr vollständig versteht und in der jede Anpassung Nebenwirkungen produziert.
Dieser Beitrag zeigt, wie eine saubere LE-Stammdatenarchitektur in der Praxis aussehen sollte und welche fünf Entscheidungen am Anfang die spätere Komplexität bestimmen.
Die vier Bausteine
Eine LE-Architektur im klassischen Mittelstand besteht im Kern aus vier Objekten:
- Versandstelle (VSTEL): die organisatorische Einheit, in der ausgehende Lieferungen bearbeitet werden.
- Route: der Transportweg von der Versandstelle zum Empfänger, mit Transitzeit und Vorlaufzeit.
- Transportzone: die geografische Gruppierung, über die Routen ermittelt werden.
- Spediteur: der Lieferant in der Partnerrolle SP.
Wer diese vier Objekte sauber aufeinander abstimmt, hat ein wartbares System. Wer auch nur eines davon ohne Konzept anlegt, baut technische Schulden auf, die sich später in falschen Lieferterminen, manueller Versandstellenfindung und Eskalationen bemerkbar machen.
Anmerkung zur Ladestelle: SAP kennt im klassischen LE-SHP auch die Ladestelle (LSTEL) als feinere Unterteilung innerhalb einer Versandstelle. In der Praxis ist sie ohne EWM oder TM funktional kaum nutzbar. Wer wirklich rampen- oder torgenaue Steuerung braucht, sollte das als EWM- oder TM-Thema einordnen, nicht als Erweiterung der klassischen Versandstellenlogik.
Versandstellen: Weder Inflation noch Mangel
Die häufigste Architektur-Frage zu Beginn lautet: wie viele Versandstellen brauchen wir? In der Praxis sehe ich zwei Extreme.
Auf der einen Seite die Inflation. Eine Versandstelle pro Lagerbereich, eine pro Produktgruppe, eine pro Versandart. Schnell stehen zwanzig Versandstellen im System. Die Folgen: Picking-Pools werden unübersichtlich, Kalenderpflege wird zur Daueraufgabe, Auswertungen werden komplex, Anwender wählen die falsche Versandstelle.
Auf der anderen Seite der Mangel. Eine Versandstelle für alles, weil es bei der Einführung am einfachsten war. Die Folgen: keine Differenzierung in Arbeitszeiten, keine getrennte Kapazitätsplanung, keine sinnvolle Auswertbarkeit nach Versandprozess.
Die pragmatische Regel: eine Versandstelle pro physischem Standort. Zusätzliche Versandstellen nur dann, wenn sich der Versandprozess fundamental unterscheidet (z. B. Paketversand und LKW-Versand mit jeweils eigenen Arbeitszeiten, Picking-Strategien und Anwendern). Drei bis fünf Versandstellen reichen für die meisten mittelständischen Unternehmen.
Wenn rampen- oder torgenaue Steuerung wirklich gebraucht wird, ist das in der Regel ein EWM- oder TM-Thema, nicht ein Versandstellen-Thema. Wer das nicht hat, sollte die Versandstellen-Architektur bewusst ohne diesen Anspruch planen.
Transportzonen: Drei oder vier Ebenen, mehr nicht
Transportzonen sind die Grundlage der Routenfindung. Sie geografisch zu zerlegen ist eine Architektur-Entscheidung mit langer Lebensdauer.
Zwei typische Fehler:
- Zu grob. Eine Transportzone pro Land. Folge: alle Lieferungen nach Deutschland bekommen dieselbe Route, obwohl München und Hamburg unterschiedliche Transitzeiten haben.
- Zu fein. Eine Transportzone pro Postleitzahlengruppe. Folge: tausende Zonen, niemand kann die Routenfindung mehr nachvollziehen, Pflegeaufwand wird zum Vollzeit-Job.
Pragmatische Empfehlung für den DACH-Mittelstand:
- Ebene 1: Kontinent (Europa, Amerika, Asien).
- Ebene 2: Land oder Ländergruppe.
- Ebene 3: Region innerhalb des Landes (Bundesland, NUTS-2 oder vergleichbar).
- Optional Ebene 4: feinere Aufteilung nur dort, wo Transitzeiten sich tatsächlich relevant unterscheiden.
Drei Ebenen reichen für die meisten Mittelständler. Wer eine vierte Ebene anlegt, sollte sie schriftlich begründen können.
Routen: Vom Determination-Geheimnis zur dokumentierten Logik
Die Routenfindung läuft über mehrere Kriterien gleichzeitig: Versandbedingung des Kunden, Abgangs- und Empfangszone, Transportgruppe des Materials und optional Gewichtsgruppe. Wer im System fragt „warum hat dieser Auftrag diese Route bekommen?“, bekommt selten eine klare Antwort.
Pragmatisches Vorgehen:
- Routenfindung in einem einseitigen Diagramm dokumentieren. Welches Feld in welcher Reihenfolge greift, was als Default fungiert.
- Transitzeiten jährlich überprüfen. In den meisten Systemen stehen Werte aus dem Jahr der Einführung. Spediteure liefern heute teils schneller, teils langsamer.
- Z-Code in der Routenfindung vermeiden. Wenn der Standard nicht reicht, ist es meist ein Stammdatenproblem, kein Code-Problem.
Eine saubere Routenarchitektur erkennen Sie daran, dass ein neuer Anwender nach einer Stunde Erklärung selbst nachvollziehen kann, warum ein Auftrag eine bestimmte Route bekommt.
Spediteure: Lieferant, klare Rolle, klare Stammdaten
Spediteure sind Lieferanten in der Partnerrolle SP. Drei häufige Fehler in der Praxis:
- Spediteure als Kunde angelegt, weil das bei der Einführung einfacher schien. Spätere Integration mit Frachtkosten-Modulen wird so unmöglich.
- Spediteure ohne Rolle und ohne Bankverbindung angelegt, weil die Rechnungsstellung „extern läuft“. Spätestens beim Versuch, Frachtkosten im System abzubilden, fliegt das auf.
- Spediteure ohne Verknüpfung zu Routen oder Transportzonen. Die Routenfindung kennt die Spediteure nicht, die Spediteurfindung läuft als manueller Schritt.
Die saubere Variante: Spediteur als Lieferant mit Partnerrolle SP, zugeordnet zu Routen und Transportzonen, mit hinterlegten Frachtraten (klassisch in LE-TRA oder bei aktivem TM dort), mit dokumentiertem Service-Level pro Route.
Die fünf häufigsten Architektur-Fehler
Aus der Praxis kommen immer dieselben Probleme:
- Zu viele Versandstellen. Lösung: Konsolidierung auf physische Standorte. Wer feinere Granularität braucht, sollte ehrlich prüfen, ob das wirklich der Versandstellen-Ebene zugehört oder ob es ein Lagerort-, Picking- oder EWM-Thema ist.
- Veraltete Transitzeiten in Routen. Lösung: jährliches Review mit Spediteur-Beteiligung.
- Z-Code in der Versandstellen- oder Routenfindung. Lösung: Standard-Determination prüfen, fast immer reicht sie.
- Spediteure ohne Rollen und ohne Frachtraten. Lösung: Lieferanten-Stammdaten ergänzen, einmaliger Aufwand, dauerhafter Nutzen.
- Fehlende Dokumentation der Determination-Logik. Lösung: einseitige Übersicht in SharePoint, Confluence oder dem Tool Ihrer Wahl. Hauptsache, sie existiert.
Die jährliche Wartung, die niemand macht
LE-Stammdaten sind keine Einmal-Anlage. Sie sind ein wartungsbedürftiger Datenbestand, der mindestens einmal im Jahr durchgesehen werden sollte. Konkret:
- Transitzeiten gegen aktuelle Spediteur-Daten abgleichen.
- Versandstellen-Kalender für das kommende Jahr aktualisieren.
- Frachtraten an aktuelle Verträge anpassen.
- Inaktive Routen, Spediteure und Transportzonen ausräumen.
- Determination-Logik prüfen: greift sie noch wie dokumentiert?
Diese Wartung kostet einen halben Tag pro Versandstelle pro Jahr. Sie spart sich selbst zehnfach in vermiedenen Lieferterminproblemen.
Fazit
LE-Stammdaten sind kein Glanzthema. Aber sie sind die Grundlage dafür, dass Versandtermine stimmen, Frachtkosten kalkulierbar sind und Anwender im Tagesgeschäft entlastet bleiben. Eine saubere Architektur erkennen Sie an drei Dingen: wenige, klar benannte Versandstellen, eine dokumentierte Routenfindung und ein Spediteur-Stammdatenmodell, das nicht mit Kundendaten verwechselt werden kann.
Der Unterschied zwischen einer gewachsenen und einer geplanten LE-Architektur ist meist nicht groß im Aufwand. Er ist groß im Effekt. Wer einmal aufräumt und dann jährlich pflegt, hat ein System, in dem auch nach zehn Jahren noch jemand erklären kann, warum dieser Auftrag diese Route bekommt.