Im April 2014 hat die Stürmer Gruppe den Betrieb in ihrem neuen Logistikzentrum in Pettstadt aufgenommen. 22.000 Quadratmeter Hallengrundfläche, 20.000 Palettenstellplätze, über 345.000 lieferbereite Artikel, mehr als 100.000 Sendungen im Jahr. Der Anlass war physisch. Der Maschinengroßhändler war am Stammsitz in Hallstadt an seine Kapazitätsgrenze gekommen.
Ich habe dort über zehn Jahre die IT verantwortet, zuletzt als Leiter IT der Unternehmensgruppe und Prokurist. Die Systemlandschaft rund um Lager, Versand und Vertriebskanäle habe ich in dieser Zeit konzipiert und mit meinem Team umgesetzt.
Zwei Jahre später haben wir die Lagerprozesse auf ein Warehouse Management System umgestellt. Bis dahin wurde über das ERP-System scannergestützt kommissioniert. Dessen Logistikfunktionen waren rudimentär ausgelegt, ausreichend für eine überschaubare Lagerstruktur, aber ohne systemseitige Lagerplatzführung, Wegeoptimierung, Cross-Docking und detaillierte Materialflusssteuerung. Für ein Zentrallager dieser Größenordnung war das keine Basis.
Die Diskussion in solchen Projekten dreht sich um Funktionsumfang. Welches System kann Lagerplatzführung, welches kann Wegeoptimierung, welches kann Nachschubsteuerung. Diese Fragen sind beantwortbar und deshalb attraktiv. Die Entscheidung, die tatsächlich über die nächsten zehn Jahre bestimmt, liegt darunter und wird selten explizit getroffen.
Führung wird pro Datenobjekt vergeben, nicht pro System
Die tragende Frage lautet, welches System welche Wahrheit führt. Sie klingt banal und wird trotzdem regelmäßig falsch beantwortet, weil sie meistens global gestellt wird. Man entscheidet sich für ein führendes System und ordnet alles andere unter.
Wir haben die Führung stattdessen pro Datenobjekt vergeben.
Das ERP führte die kaufmännische Sicht, also Disposition, Preisfindung, Versandvorschlag und den buchhalterischen Bestand. Das WMS führte die operative und physische Lagersicht, also Lagerplatzmanagement, Nachschub, Kommissionierung, Wareneingang und Warenausgang. Das Außenhandels- und Versandsystem hat Multi-Carrier-Steuerung, Packplatzabwicklung, Labeldruck sowie Ausfuhr-, Einfuhr- und Meldeprozesse geführt. Das PIM-System, das ich mit meinem Team eingeführt und inhaltlich verantwortet habe, hat die beschreibende Seite des Produkts geführt, also Mediadaten, Marketinginformationen, Katalogstruktur und Sortimentszuordnungen.
Ein Artikel hatte damit vier Wahrheiten an vier Orten. Was er kostet, wo er liegt, wie er das Haus verlässt und was er ist. Keine dieser Wahrheiten war an einer anderen Stelle nochmals vollständig vorhanden.
Zwischen ERP und WMS lief ein eng getakteter Bestandsabgleich auf Aggregationsebene. Wir wussten jederzeit, in welchem Lager wie viele Einheiten liegen. An welchem chaotischen Lagerort in welcher Zone, das wusste ausschließlich das WMS. Der Bestandsabgleich zwischen beiden Systemen lief im Viertelstundentakt, was zusammen mit der permanenten Inventur in den Kommissionierzonen auch die Anforderungen der Wirtschaftsprüfer erfüllt hat.
Diese Aufteilung ist die eigentliche Architekturentscheidung. Wir haben exakt so viel Information repliziert, wie außerhalb des Lagers gebraucht wurde, und keine Ebene tiefer. Redundanz auf der Aggregationsebene, Detailtiefe ausschließlich dort, wo sie physisch entsteht.
Was diese Entscheidung gekostet hat
Eine Grenze, die pro Datenobjekt gezogen wird, macht die Systeme einfacher und die Verbindungen dazwischen anspruchsvoller. Der aufwendigste Teil der Einführung war entsprechend nicht das WMS selbst, sondern die Schnittstelle zum ERP. Sie ist von einer Nebenaufgabe zum kritischen Bauteil geworden, mit allem, was daran hängt, von Fehlerbehandlung über Wiederanlauffähigkeit bis zur Frage, welcher Zustand bei einer Unterbrechung gilt.
Der zweite Aufwand lag in der initialen Datenübernahme, für die ich verantwortlich war. Ein Bestand, der bis dahin ohne systemseitige Lagerplatzführung geführt wurde, musste in eine Struktur überführt werden, die jede Einheit einem Platz zuordnet. Die dafür nötigen Artikelattribute existierten teilweise nicht und mussten erst erhoben werden.
Die Aggregationsebene als Kompromiss hat außerdem eine Unschärfe, die man aushalten muss. Wer außerhalb des Lagers steht, sieht eine Menge und keinen Ort. Das reicht für jedes Kundenversprechen und für jede kaufmännische Betrachtung, es reicht nicht für Rückfragen zum Einzelfall. Diese Rückfragen laufen zwangsläufig über das Lager, und diese Zuständigkeit muss organisatorisch geklärt sein, sonst entsteht Druck, die Detailtiefe doch nach außen zu spiegeln.
Der eigentliche Belastungstest kam zwei Jahre später
Als wir die Systemgrenze gezogen haben, gab es keine Online-Bestellmöglichkeit. Der Bestellprozess lief über Telefon, Telefax und E-Mail. Es existierte kein Kundenversprechen im Frontend, für das die Architektur hätte ausgelegt werden können.
Ab 2018 kam das Partnerportal für gelistete Händler dazu. Ich habe das Portal konzipiert und die Prozesse festgelegt, mein Team hat es technisch umgesetzt. Der Anspruch war hoch. Warenverfügbarkeit in Echtzeit, Auftragsstatus, Zugriff auf Ersatzteillisten und technische Daten, Reklamationseinreichung mit Statusverfolgung. Vor allem aber vollständige Preistransparenz für den einzelnen Händler, also Katalogpreise, personalisierte Einkaufspreise, Aktionskonditionen und explizit ausgewiesene Zusatzkosten. In der Auflösung waren das bis zu sieben Preisvarianten je Artikel und Kunde.
Ein solches Versprechen verträgt keine Preis- und Bestandsinformationen, deren Aktualität nicht sicher bestimmt werden kann. Wenn zugesagt wird, dass Preis und Verfügbarkeit für diesen Händler in diesem Moment gültig sind, muss die Wahrheit im führenden System bleiben. Wir haben deshalb beim Login den kundenindividuellen Datensatz live aufgelöst und beim Aufruf eines einzelnen Artikels denselben Abruf erneut ausgeführt, für den Fall, dass sich in der Zwischenzeit etwas verändert hat.
Möglich wurde das durch eine Integrationsschicht, die dem Portal ein einheitliches API bereitstellte. Sie führte keine eigene Wahrheit, sondern adressierte für jede Anfrage das jeweils zuständige Kernsystem und setzte dessen Antworten zusammen: Preisinformationen aus dem ERP, Bestand und Reservierungen aus dem WMS sowie technische Beschreibungen und Bilddaten aus dem PIM.
Der entscheidende Punkt an dieser Stelle ist, dass wir dafür keines der Kernsysteme umbauen mussten. Die Grenze von 2016 hat eine Anforderung getragen, die es 2016 noch nicht gab.
Wie tragfähig sie war, hat sich an der Internationalisierung gezeigt. Das Portal lief nicht nur gegen das deutsche Zentrallager, sondern in identischer Form auch für die Standorte in Polen und Österreich. Deren Lagerstrukturen waren erheblich kleiner und wurden ohne WMS allein im ERP geführt. Für das Portal war dieser Unterschied unsichtbar, weil die Zwischenschicht Verfügbarkeit auf Aggregationsebene abgefragt hat und diese Ebene an beiden Stellen existierte, unabhängig davon, wie tief die Bestandsführung darunter reichte.
Möglich war das, weil kaufmännische Prozesse und Versandabwicklung über die Gesellschaften hinweg weitgehend identisch waren und die Datenbasis vollständig identisch war. Über die Intercompany-Anbindungen liefen Bestände, Belege und Warenbewegungen lückenlos zwischen den Gesellschaften. Eine weitere Gesellschaft anzubinden war deshalb keine Architekturaufgabe, sondern eine Konfigurationsaufgabe.
Später hat dieselbe Architektur auch den Ersatzteilshop für gewerbliche Endkunden getragen, mit eigener Zahlungsanbindung und einem völlig anderen Preis- und Kundenmodell. Zwei Kanäle mit gegensätzlichen Versprechen und mehrere Gesellschaften mit unterschiedlicher Logistiktiefe, getragen von einer einzigen Systemgrenze.
Der Wert einer sauber gezogenen Systemgrenze zeigt sich nicht im Projekt. Er zeigt sich in dem Moment, in dem eine Anforderung auftaucht, an die beim Entwurf niemand gedacht hat.
Die Rückrichtung wird meistens vergessen
Bis hierhin stellt das Frontend Anforderungen an das Lager. Die interessantere Bewegung läuft in die andere Richtung.
Wir haben den physischen Prozessfortschritt aus dem Lager nach außen sichtbar gemacht. Welche Positionen gerade kommissioniert werden, welche bereits verpackt und verladen sind. Diese Information hat bestimmt, ab wann eine Änderung oder eine Stornierung nicht mehr möglich war.
Damit hat der Zustand im Lager die Handlungsfreiheit im Vertriebskanal begrenzt. Das ist die ehrlichere Variante gegenüber einer willkürlich gesetzten Frist im Bestellprozess, die entweder zu früh greift und Kunden unnötig einschränkt oder zu spät greift und Sendungen zurückholen muss. Eine Grenze, die aus dem tatsächlichen physischen Fortschritt abgeleitet wird, ist gegenüber dem Kunden begründbar und gegenüber dem Lager belastbar.
Dasselbe Prinzip hat auf der Packplatzseite gegriffen. Die Rückmeldung der Verpackungsdaten an das ERP hat dort den Lieferscheindruck ausgelöst. Der physische Vorgang war der auslösende Zustand, nicht eine Statusänderung im kaufmännischen System.
Was davon übertragbar ist
Die Frage lautet in jeder Systemlandschaft gleich. Welches Versprechen geben wir nach außen, welche Wahrheit muss dafür wo liegen, und in welcher Tiefe brauchen wir sie außerhalb des Systems, in dem sie entsteht.
Sie stellt sich zwischen CRM und ERP genauso wie zwischen HR-System und Payroll, zwischen PIM und Vertriebskanal, zwischen Produktionsplanung und Terminzusage. In allen diesen Fällen wird über Funktionsumfang verhandelt, während die Führungsfrage implizit mitentschieden wird.
Aus Transaktionsperspektive ist das keine Nebensache. In einer IT-Due-Diligence wird bewertet, wie schnell eine Landschaft neue Anforderungen aufnehmen kann und welche Risiken in Prozessen liegen, die keine eigene Kontrolle mitbringen. Beides hängt an der Frage, wo die Systemgrenzen verlaufen und ob sie begründet gezogen wurden. Eine Landschaft, in der Führung pro Datenobjekt geklärt ist, nimmt neue Kanäle und neue Gesellschaften mit überschaubarem Aufwand auf. Eine Landschaft, in der die Grenzen historisch gewachsen sind, zahlt bei jeder Integration nach.
Quellen und weiterführende Referenzen
Weitere Informationen zum Logistikzentrum sowie zu den beschriebenen System- und Prozesslösungen finden sich in den öffentlichen Darstellungen und Referenzberichten von Stürmer Maschinen, COGLAS, TimeLine ERP und LOGISTIK HEUTE.
