Ein Warenwirtschafts- oder ERP-System weiß, wie viele Stück eines Materials in einem Lagerort vorhanden, reserviert, bestellt oder gesperrt sind. Es beantwortet kaufmännische Fragen: Können wir liefern? Was ist der Bestand wert? Wann müssen wir nachbestellen? Ein Lagerverwaltungssystem beantwortet operative Fragen: In welchem Fach liegt die Ware? Welcher Mitarbeiter geht in welcher Reihenfolge welchen Weg? Wie kommt Nachschub in die Kommissionierzone, bevor sie leerläuft? Wie werden zwanzig Aufträge so gebündelt, dass ein Rundgang statt zwanzig entsteht? EWM ist konsequent für diese zweite Fragenklasse gebaut.
Der fachliche Kern von EWM ist die Lageraufgabe. Jede physische Bewegung im Lager – Einlagern, Umlagern, Kommissionieren, Nachschub, Auslagern – wird als Aufgabe erzeugt, einem Bearbeiter oder einer Maschine zugewiesen, ausgeführt und quittiert. Aufgaben werden zu Lageraufträgen gebündelt, Aufträge zu Wellen zusammengefasst, Wellen an Aktivitätsbereiche und Arbeitsplätze verteilt. Wer dieses Modell verstanden hat, versteht EWM. Alles Weitere – Slotting, Yard Management, Value-Added Services, Labor Management – ist Ausbau auf dieser Grundlage.
EWM ist nicht neu. Die Lösung entstand ursprünglich als Bestandteil der SAP-Welt für Supply-Chain-Anwendungen und lief zunächst auf einem eigenen technischen Stack, getrennt vom ERP-System und über Warteschlangen mit diesem verbunden. Diese Herkunft erklärt zwei Eigenschaften, die bis heute prägen: Erstens ist EWM funktional eigenständig aufgebaut, mit eigenem Stammdatenmodell, eigenen Organisationsobjekten und eigener Prozesslogik. Zweitens war die Trennung vom ERP von Anfang an vorgesehen – was heute als Vorteil erscheint, weil sich Lager und kaufmännischer Kern unabhängig voneinander betreiben und warten lassen.
Mit S/4HANA hat SAP die Architektur erweitert. EWM kann seitdem direkt im S/4HANA-System betrieben werden, im selben Mandanten und auf derselben Datenbasis. Diese eingebettete Variante beseitigt einen erheblichen Teil des Integrationsaufwands, weil Materialstamm, Charge, Bestandsführung und Buchungslogik nicht mehr repliziert werden müssen. Parallel bleibt der dezentrale Betrieb möglich und ist für bestimmte Konstellationen weiterhin die bessere Wahl. Welche Variante passt, ist eine der frühesten und folgenreichsten Entscheidungen im Projekt – Kapitel 02 und Kapitel 07 gehen darauf im Detail ein.
Wichtig für die Einordnung: EWM ist innerhalb der SAP-Welt die strategische Lösung für Lagerverwaltung. Das klassische SAP WM, im Sprachgebrauch häufig LE-WM genannt, ist ein Auslaufmodell und wird nicht mehr weiterentwickelt. Unternehmen, die heute auf LE-WM arbeiten, stehen daher früher oder später vor einer Entscheidung. Konkrete Termine für Wartungsenden nennen wir hier bewusst nicht – sie haben sich in der Vergangenheit mehrfach verschoben und sind ausschließlich in den offiziellen Wartungsangaben der SAP nachzulesen.
Der augenfälligste Unterschied ist die Granularität. EWM kennt Lagerplätze als eigenständige Stammdatenobjekte mit Koordinaten, Kapazitäten, Gewichtsgrenzen, Zugriffsregeln und Sortierfolgen. Es kennt Handling Units, also physische Packeinheiten wie Paletten, Gitterboxen oder Kartons, die mit einer eindeutigen Nummer geführt werden und ihren Inhalt mit sich tragen. Es kennt Aktivitätsbereiche, die festlegen, welcher Teil des Lagers von welcher Tätigkeit bearbeitet wird. Und es kennt Arbeitsplätze mit definierten Abläufen für Packen, Prüfen, Etikettieren oder Konsolidieren.
Der zweite Unterschied ist die Strategiefähigkeit. Wo eine ERP-Lagerverwaltung typischerweise mit wenigen festen Regeln arbeitet, hinterlegt EWM Ein- und Auslagerungsstrategien, die abhängig von Material, Menge, Verpackung, Haltbarkeit, Charge, Gefahrstoffklasse oder Lagerbereich unterschiedlich greifen. Feste Platzzuordnung, freie Platzsuche, Zusammenlagerungsverbote, Ablaufdatumssteuerung, Chargenauswahl nach Verfallsdatum, Quarantäne- und Sperrbestände – all das ist Konfiguration, nicht Programmierung.
Der dritte Unterschied ist die Maschinennähe. EWM enthält ein Materialflusssystem, das Fördertechnik und automatische Kleinteilelager direkt ansteuern kann, ohne dass zwingend eine separate Steuerungsebene dazwischenliegt. Für Betriebe mit hoher Automatisierung ist das ein architektonisches Argument, weil eine Systemebene entfällt. Für Betriebe ohne Fördertechnik ist es schlicht nicht relevant – und genau hier beginnt die Frage nach der richtigen Dimensionierung.
EWM richtet sich an Lager, in denen die Komplexität nicht mehr im Kopf einer erfahrenen Lagerleitung verwaltbar ist. Typische Merkmale: viele tausend Lagerplätze, mehrere Kommissionierzonen mit unterschiedlichen Techniken, chargen- oder seriennummerngeführte Ware, Haltbarkeitsdaten, Gefahrstoffe, mehrstufige Prozesse mit Konsolidierung und Verpackung, Automatisierungstechnik, hoher Auftragsdurchsatz mit Wellensteuerung oder anspruchsvolle Nachweispflichten. Wo mehrere dieser Merkmale zusammenkommen, spielt EWM seine Stärke aus.
Nicht gebaut ist EWM für kleine, überschaubare Lager mit wenigen hundert Plätzen, einer Handvoll Mitarbeitern und einem klaren Sortiment. Dort steht der Konfigurations- und Betreuungsaufwand in keinem Verhältnis zum Nutzen, und die Bestandsführung des ERP-Systems oder ein schlankes Lagermodul leistet, was gebraucht wird. Ebenso wenig ist EWM ein Transportmanagementsystem, ein Versandkostenrechner oder eine Multi-Carrier-Plattform – für diese Aufgaben gibt es eigene Systeme, die über Schnittstellen zusammenarbeiten.
Und schließlich: EWM ist kein Produkt, das man einfach einschaltet. Es ist ein Baukasten, der modelliert werden muss. Die Qualität des Ergebnisses hängt weniger von der Software ab als von der Frage, ob die eigenen Prozesse vorher verstanden und bewusst gestaltet wurden. Wer ein unaufgeräumtes Lager digitalisiert, bekommt ein unaufgeräumtes Lager mit Bildschirmen. Diese Erkenntnis ist unbequem, aber sie ist der wichtigste Erfolgsfaktor in jedem Lagerprojekt, das wir begleitet haben.
Beim eingebetteten Betrieb läuft EWM als Bestandteil des S/4HANA-Systems. Materialstamm, Chargen, Bestandsbuchungen und Belege liegen in derselben Datenbank, eine Replikation über Warteschlangen entfällt weitgehend. Der Nutzen ist unmittelbar spürbar: weniger Schnittstellenüberwachung, weniger Abstimmfehler zwischen zwei Beständen, weniger Betriebsaufwand, eine einheitliche Benutzerverwaltung. Für die meisten Unternehmen, die ohnehin auf S/4HANA konsolidieren, ist das der naheliegende Weg.
Der dezentrale Betrieb hat dennoch klare Anwendungsfälle. Erstens, wenn mehrere ERP-Systeme das Lager beliefern – etwa in Konzernstrukturen mit verschiedenen Landesgesellschaften oder nach einer Zukäufe-Historie. Zweitens, wenn das Lager auch dann weiterarbeiten muss, wenn der kaufmännische Kern gewartet wird oder ausfällt; ein eigenständiges Lagersystem entkoppelt die Verfügbarkeiten. Drittens, wenn Release- und Änderungszyklen unterschiedlich getaktet sein sollen, weil im Lager Stabilität wichtiger ist als Aktualität. Und viertens bei Logistikdienstleistern, die für mehrere Auftraggeber arbeiten.
Der Preis der Entkopplung ist Aufwand. Ein zweites System bedeutet eine zweite Basis-Betreuung, eine zweite Berechtigungswelt, einen Stammdatenabgleich, der überwacht werden muss, und eine Schnittstelle, die im Störungsfall analysiert werden will. Unsere Empfehlung im Mittelstand lautet deshalb regelmäßig: eingebettet betreiben, sofern nicht ein konkreter, benennbarer Grund dagegenspricht. Die Entkopplung als Vorsichtsmaßnahme ohne konkreten Anlass rechnet sich in aller Regel nicht.
SAP unterscheidet innerhalb von EWM zwischen einer Basisausprägung und einer erweiterten Ausprägung. Die Basisausprägung deckt den klassischen Lagerprozess ab: Lagerstruktur mit Plätzen, Wareneingang mit Einlagerung, Kommissionierung und Warenausgang, Handling Units, Inventur, mobile Erfassung. Für viele Lager ist das bereits deutlich mehr, als eine ERP-Bestandsführung leistet. Die erweiterte Ausprägung ergänzt die anspruchsvollen Bausteine – die Steuerung von Automatisierungstechnik, Arbeitszeit- und Leistungsauswertung, Hofsteuerung, Umlagerungsoptimierung, mehrstufige Prozesse in voller Tiefe.
Für die Systemauswahl ist die praktische Konsequenz wichtiger als die Begriffe: Der Funktionsumfang, den ein Anbieter oder Berater in einer Präsentation zeigt, ist nicht automatisch der Funktionsumfang, der mit der eigenen Lizenz nutzbar ist. Wir empfehlen deshalb, die eigene Anforderungsliste vor der Vertragsverhandlung in eine Tabelle zu überführen und je Anforderung schriftlich bestätigen zu lassen, in welcher Ausbaustufe sie enthalten ist. Diese eine Stunde Arbeit verhindert die teuerste Überraschung, die es in Lagerprojekten gibt: eine Funktion, die im Konzept steht, aber lizenzrechtlich nicht verfügbar ist.
Zur Kostenwirkung äußern wir uns bewusst nicht mit Zahlen. Lizenzmetriken der SAP haben sich im Zeitverlauf mehrfach verändert, sie unterscheiden sich zwischen klassischem Lizenzkauf, Subskription und Cloud-Verträgen, und sie sind verhandlungsabhängig. Was sich sagen lässt: Die höhere Ausbaustufe ist ein eigener Kostenblock, und die Frage, ob sie gebraucht wird, sollte an konkreten Prozessanforderungen entschieden werden – nicht am Wunsch, für alle Fälle gerüstet zu sein.
Sehr viele Unternehmen im DACH-Raum arbeiten seit Jahren mit dem klassischen SAP WM. Es ist stabil, es ist verstanden, und es tut, was es soll. Es wird aber nicht mehr weiterentwickelt, und seine Zukunft im S/4HANA-Kontext ist begrenzt. Damit entsteht Handlungsbedarf – nicht als Notfall, aber als Planungsaufgabe mit mehrjährigem Vorlauf.
SAP hat für diesen Übergang zwei Wege geschaffen. Der eine ist EWM, mit vollem Funktionsumfang und entsprechendem Projektaufwand. Der andere ist Stock Room Management, eine bewusst reduzierte Lösung, die den einfachen Lagerprozess abbildet und für Anwender gedacht ist, deren WM-Nutzung ohnehin schlank war. Stock Room Management ist ausdrücklich kein Ersatz für ein anspruchsvolles Lager: Wer heute schon Automatisierung, komplexe Strategien oder mehrstufige Prozesse braucht, findet dort nicht, was gebraucht wird.
Für die Entscheidung hat sich eine einfache Reihenfolge bewährt. Zuerst prüfen, was im heutigen System tatsächlich genutzt wird – nicht was konfiguriert ist, sondern was im Alltag Buchungen erzeugt. Anschließend die absehbare Entwicklung der nächsten fünf bis sieben Jahre einschätzen: Wächst der Durchsatz, kommt Automatisierung, steigen Nachweispflichten, kommen neue Standorte? Erst dann entscheiden. Ein Unternehmen mit stabilem, einfachem Lager fährt mit dem schlanken Weg gut. Ein Unternehmen, das absehbar wächst oder automatisiert, spart sich mit dem direkten Weg zu EWM ein zweites Projekt. Die Wartungs- und Verfügbarkeitsangaben zu allen genannten Optionen sind beim Anbieter zu prüfen.
Am Anfang jedes EWM-Projekts steht die Modellierung des Lagers. Eine Lagernummer bildet den physischen Standort ab. Innerhalb dieser Nummer beschreiben Lagertypen die verschiedenen Bereiche mit ihren Eigenschaften: Hochregal, Palettenblocklager, Kleinteilebereich, Kommissionierzone, Wareneingangs- und Warenausgangszonen, Sperrbereich, Retourenprüfung. Lagerbereiche fassen Plätze mit gleichen Merkmalen zusammen, etwa nach Gewichtsklasse oder Zugriffshäufigkeit. Der Lagerplatz selbst trägt Koordinate, Kapazität, Sortierfolge für Wegeoptimierung und Regeln, welche Ware dort liegen darf.
Die zweite Ebene ist die Handling Unit. Sie ist der digitale Zwilling eines physischen Packstücks – Palette, Gitterbox, Karton, Behälter – mit eindeutiger Identifikation und bekanntem Inhalt. Handling Units können geschachtelt werden, sie tragen Gewichte und Maße, sie lassen sich als Ganzes bewegen, teilen und zusammenführen. Für die Rückverfolgbarkeit ist dieses Konstrukt zentral: Wer wissen muss, welche Charge auf welcher Palette an welchen Kunden ging, braucht genau diese Struktur. Für Lebensmittel, Pharma, Chemie und Automotive ist das keine Kür, sondern Voraussetzung.
Die dritte Ebene ist das Aufgabenmodell. Bewegungen entstehen als Lageraufgaben, werden zu Lageraufträgen gebündelt und über Aktivitätsbereiche den Ressourcen zugeordnet. Dieses Modell ist der Grund, warum EWM Arbeit steuern kann statt sie nur zu buchen: Aufgaben lassen sich priorisieren, umverteilen, sperren, in Reihenfolge bringen und auswerten. Der Lagermonitor macht den gesamten Bestand an offenen und erledigten Aufgaben sichtbar und ist im Betrieb das wichtigste Werkzeug der Lagerleitung – vorausgesetzt, jemand hat sich die Mühe gemacht, ihn auf die eigenen Fragen zuzuschneiden.
Im Wareneingang beginnt der Prozess mit einer angekündigten Anlieferung. EWM erzeugt daraus eine Anlieferung mit Positionen, Erwartungswerten und gegebenenfalls einem Tor- und Zeitfenster. Bei der Vereinnahmung werden Handling Units erfasst oder erzeugt, Mengen und Chargen geprüft, Qualitätsprüfungen angestoßen und Einlagerungsaufgaben nach den hinterlegten Strategien erzeugt. Die Strategie entscheidet, ob eine Palette ins Hochregal, in die Kommissionierzone oder zunächst in einen Prüfbereich geht – abhängig von Material, Menge, Verpackung, Haltbarkeit und aktueller Auslastung.
Auf der Ausgangsseite entsteht aus dem Kundenauftrag eine Auslieferung. Hier setzt das Wellenmanagement an: Statt jeden Auftrag einzeln durch das Lager zu schicken, werden Aufträge nach Kriterien gebündelt – Versandtermin, Tour, Carrier, Zielzone, Auftragsgröße, Artikelüberschneidung. Aus einer Welle entstehen Kommissionieraufgaben, die nach Zonen und Wegen sortiert werden. Anschließend werden die Teilmengen konsolidiert, verpackt, gewogen, etikettiert und bereitgestellt. Der Warenausgang wird gebucht, die Verladung dokumentiert. Diese Kette ist der Ort, an dem Leistungsgewinne entstehen – und der Ort, an dem Konfigurationsfehler unmittelbar spürbar werden.
Zwei Nebenprozesse verdienen besondere Beachtung, weil sie in Konzepten regelmäßig zu kurz kommen. Der erste ist der Nachschub: Wenn die Kommissionierzone leerläuft, steht das Lager. EWM kennt verschiedene Nachschubverfahren, von der festen Meldemenge bis zur auftragsbezogenen Anforderung, und die richtige Wahl je Artikelgruppe hat unmittelbaren Einfluss auf den Durchsatz. Der zweite ist die Inventur: Neben der Stichtagsinventur unterstützt EWM permanente und platzbezogene Zählverfahren, die den Betrieb erheblich weniger stören. Wer das früh einplant, spart sich jährlich wiederkehrende Ausnahmezustände.
Slotting beantwortet die Frage, wo ein Artikel liegen sollte. Auf Basis von Zugriffshäufigkeit, Gewicht, Volumen, Verpackungseinheit und Saisonalität schlägt das System eine Platzzuordnung vor; die Umlagerung setzt sie um, idealerweise in Zeiten geringer Auslastung. Der Nutzen ist unmittelbar: kürzere Wege, weniger Ergonomieprobleme, bessere Auslastung der Vorzugsplätze. Yard Management erweitert die Steuerung auf den Hof – Anmeldung, Torzuweisung, Rangierbewegungen, Stellplätze für Auflieger. Für Standorte mit vielen Lkw-Bewegungen und knappen Toren ist das ein echter Engpassbaustein.
Cross-Docking verkürzt den Weg für Ware, die nicht eingelagert werden muss, sondern direkt vom Wareneingang in den Warenausgang läuft. Value-Added Services bilden Tätigkeiten ab, die im Lager an der Ware ausgeführt werden: Kitting und Set-Bildung, Umpacken, Etikettieren, kundenspezifische Beilagen, einfache Montage. Für Handelsbetriebe mit Konfektionierung und für Logistikdienstleister ist dieser Baustein häufig der Grund, überhaupt ein leistungsfähiges WMS einzuführen – weil sich diese Leistungen nur dann sauber dokumentieren und abrechnen lassen.
Labor Management erfasst Arbeitszeiten und Leistungsdaten und stellt sie geplanten Vorgabewerten gegenüber. Der betriebswirtschaftliche Nutzen liegt in der Personalplanung und in der Kostenzuordnung. Gleichzeitig ist es der mitbestimmungs- und datenschutzrechtlich sensibelste Baustein des gesamten Systems – Kapitel 09 geht ausführlich darauf ein. Das Materialflusssystem schließlich steuert Fördertechnik, automatische Kleinteilelager und Regalbediengeräte direkt an. Wo dieser Baustein zum Einsatz kommt, entfällt eine separate Steuerungsebene, aber die Anforderungen an Verfügbarkeit, Test und Notfallkonzept steigen deutlich. Ein Lager, das ohne Fördertechnik nicht mehr arbeiten kann, braucht einen dokumentierten Handbetrieb – und regelmäßige Übung darin.
Der weitaus größte Teil dessen, was im Lager automatisch abläuft, hat mit KI nichts zu tun. Es ist Regeltechnik – und genau deshalb belastbar. Das Materialflusssystem in EWM kommuniziert mit Steuerungen von Fördertechnik und automatischen Lagern über definierte Telegramme, führt Behälter durch Verteilpunkte, weist Einlagerplätze zu und meldet Störungen zurück. Für Betreiber ist der architektonische Vorteil, dass ein eigenständiges Materialflussrechnersystem entfallen kann. Der Nachteil ist die Bindung: Die Lagersteuerung liegt dann in einem System, das auch kaufmännische Prozesse trägt, mit entsprechenden Anforderungen an Wartungsfenster und Ausfallsicherheit.
Mobile Roboter sind der Bereich mit der höchsten Marktdynamik. Autonome Transportfahrzeuge, die Behälter oder ganze Regale bewegen, Kommissionierroboter für definierte Artikelspektren, automatisierte Palettierung – das alles ist inzwischen im Mittelstand angekommen, meist als Ergänzung einzelner Prozessschritte, nicht als Vollautomatisierung. SAP adressiert diesen Bereich mit einem eigenen Angebot zur Orchestrierung von Robotern, das Aufträge aus dem Lagersystem an Flottenmanagementsysteme verschiedener Hersteller weitergibt. Die Idee dahinter ist richtig: eine herstellerübergreifende Schicht, statt für jeden Roboterhersteller eine Sonderintegration zu bauen.
Für die Praxis gilt eine einfache Regel: Automatisierung amortisiert sich über Wiederholung. Ein Prozessschritt, der tausendfach am Tag identisch abläuft, ist ein guter Kandidat. Ein Schritt mit hoher Variantenvielfalt und vielen Ausnahmen ist es nicht. Und jede automatisierte Kette braucht einen dokumentierten manuellen Rückfallweg, der nicht nur beschrieben, sondern regelmäßig geübt wird. Wir haben Lager gesehen, in denen der Handbetrieb theoretisch vorgesehen war und praktisch niemand mehr wusste, wie er funktioniert.
Zwischen klassischer Regeltechnik und generativer KI liegt ein Feld, das seit Jahrzehnten existiert und heute unter neuen Namen firmiert: statistische und lernende Verfahren auf Betriebsdaten. Im Lager sind das vor allem Prognosen des Arbeitsvorrats für die Personaleinsatzplanung, Vorschläge für die Platzoptimierung auf Basis von Zugriffsverläufen, Erkennung von Bestandsauffälligkeiten für gezielte Nachzählungen und Bündelungsvorschläge für Wellen. Diese Verfahren sind nützlich und in der Sache unspektakulär. Sie brauchen eines: eine ausreichend lange und saubere Datenhistorie.
Genau daran scheitert es in Projekten häufiger als an der Methode. Wer erst seit einem Jahr strukturiert erfasst, wer Sondereffekte nicht kennzeichnet, wer Stammdaten mit falschen Maßen und Gewichten führt, bekommt Vorschläge, die im besten Fall belanglos und im schlechteren Fall irreführend sind. Unsere Empfehlung lautet deshalb, datengetriebene Optimierung nicht am Anfang eines Lagerprojekts zu planen, sondern etwa ein bis zwei Jahre nach dem produktiven Start – wenn die Datenbasis trägt und die Prozesse stabil sind.
Ebenso wichtig ist die Frage nach der Entscheidungshoheit. Ein Vorschlag zur Umlagerung, den eine Lagerleitung prüft und freigibt, ist unkritisch. Eine Automatik, die selbstständig Personal umdisponiert oder Prioritäten verschiebt, braucht Grenzen, Protokollierung und die Möglichkeit, sie zu übersteuern. Bei allem, was Arbeitsverteilung und Leistungsbewertung berührt, kommt zusätzlich die Mitbestimmung ins Spiel – auch dann, wenn die Software es nur als Vorschlag bezeichnet.
SAP bündelt seine KI-Aktivitäten unter dem Begriff Business AI und bietet mit Joule einen Assistenten an, der in verschiedenen Anwendungen zugänglich ist. Solche Assistenten verändern vor allem den Zugang zum System: Fragen in natürlicher Sprache statt Transaktionscodes, Zusammenfassungen statt Rohlisten, geführte Hilfestellung statt Handbuchsuche. Für ein System mit der Komplexität von EWM ist das potenziell relevant, weil die Einarbeitung neuer Mitarbeiter traditionell aufwendig ist.
Wir formulieren an dieser Stelle bewusst zurückhaltend und nennen keine konkreten Funktionen, Verfügbarkeiten oder Termine – der Funktionsumfang unterscheidet sich zwischen Betriebsvarianten und Releaseständen und verändert sich laufend. Was in eine Bewertung gehört, sind vier Prüffragen. Erstens: Welche konkrete Entscheidung unterstützt die Funktion, und kann ein Mensch sie überschreiben? Zweitens: Welche Daten werden dabei verarbeitet, wo geschieht das, und werden sie zur Modellverbesserung genutzt? Drittens: Wie wird die Funktion abgerechnet, und was passiert bei intensiver Nutzung? Viertens: Was ist der messbare Nutzen im eigenen Betrieb, in Stunden oder in Fehlern?
Unsere Haltung dazu ist unaufgeregt. Der weitaus größte Teil der Effizienzgewinne im Lager entsteht durch saubere Stammdaten, eine durchdachte Zonen- und Wegeplanung, gut geschnittene Wellen und funktionierende Nachschubregeln. Das ist unglamourös, aber es wirkt. KI-Funktionen sind Feinschliff auf einem Fundament, das erst gebaut werden muss. Wer die Reihenfolge umdreht, investiert in Assistenz für Prozesse, die das eigentliche Problem sind.
Im eingebetteten Betrieb ist die Integration weitgehend gelöst, weil Lager und kaufmännischer Kern dieselben Stammdaten und dieselbe Datenbank nutzen. Was bleibt, ist die Abstimmung der Organisationsobjekte: Welcher Lagerort im ERP entspricht welcher Lagernummer in EWM, wie werden Bestandsarten abgebildet, wie laufen Buchungen zwischen den Welten. Das ist Konfigurationsarbeit mit hoher Bedeutung, weil Fehler hier später als unerklärliche Bestandsdifferenzen sichtbar werden.
Im dezentralen Betrieb kommt eine echte Schnittstelle hinzu. Stammdaten werden repliziert, Anlieferungen und Auslieferungen werden übertragen, Bestandsbewegungen zurückgemeldet. Technisch laufen solche Verbindungen in der SAP-Welt seit jeher über asynchrone Warteschlangen; historisch spielte auch der Core Interface aus der Planungswelt eine Rolle. Für den Betrieb bedeutet das vor allem eines: Warteschlangen müssen überwacht werden. Ein hängender Eintrag, den niemand bemerkt, führt binnen Stunden zu einem Lager, das mit falschen Beständen arbeitet.
Aus Projektsicht gehören deshalb drei Dinge von Anfang an geregelt. Erstens eine automatische Überwachung mit Alarmierung, nicht nur eine Transaktion, in die jemand gelegentlich schaut. Zweitens ein benannter Verantwortlicher für Schnittstellenstörungen mit klarer Eskalation. Drittens eine schriftliche Regel, was das Lager tun darf, während die Verbindung steht – weiterarbeiten und nachbuchen oder anhalten. Diese Frage im Störungsfall zu klären, ist der schlechteste denkbare Zeitpunkt.
Die Verzahnung von Lager und Transport ist einer der größten ungehobenen Hebel in vielen Betrieben. Wenn die Verladereihenfolge bekannt ist, bevor kommissioniert wird, lässt sich in der richtigen Reihenfolge picken und die Ware an der richtigen Rampe bereitstellen. Wenn Torbelegung und Zeitfenster mit dem Arbeitsvorrat abgestimmt sind, entstehen weniger Wartezeiten für Fahrer und weniger Spitzen im Lager. SAP bietet dafür die Verzahnung mit der eigenen Transportmanagementlösung an, in der Transporteinheiten, Touren und Tore gemeinsam betrachtet werden.
Nicht jeder Betrieb braucht diesen Ausbaugrad. Wer überwiegend Paketversand abwickelt, ist mit der Anbindung einer Versand- oder Multi-Carrier-Plattform häufig besser bedient als mit einem vollwertigen Transportmanagement. Wer dagegen Stückgut und Komplettladungen disponiert, mehrere Speditionen steuert und feste Rampenzeiten hat, findet in der engeren Verzahnung realen Nutzen. Die Entscheidung sollte am Transportprofil hängen, nicht an der Frage, was innerhalb einer Produktfamilie am elegantesten zusammenpasst.
Auf der Planungsseite ist die Verbindung zur Bedarfs- und Bestandsplanung relevant, weil Lagerbestände und Verfügbarkeiten dort einfließen. Für Auswertungen gilt: EWM erzeugt eine große Menge operativer Daten – Aufgaben, Zeiten, Wege, Fehler, Auslastungen. Diese Daten sind wertvoll, aber sie werden erst nützlich, wenn jemand definiert, welche Kennzahlen tatsächlich gesteuert werden sollen. Ein Dutzend gut gewählter Kennzahlen schlägt ein Berichtssystem mit hundert Auswertungen, die niemand ansieht.
Nach außen gibt es drei wiederkehrende Integrationsfelder. Das erste ist die Automatisierungstechnik: Fördertechnik, automatische Kleinteilelager, Sorter, Palettierer, Roboter. Hier ist die Kernfrage, wo die Grenze zwischen Lagerverwaltung und Anlagensteuerung gezogen wird. Übernimmt EWM den Materialfluss direkt, oder gibt es einen Materialflussrechner des Anlagenherstellers? Beide Wege funktionieren, aber die Verantwortungsteilung muss vertraglich und technisch eindeutig sein – sonst wird jede Störung zur Schuldfrage zwischen zwei Anbietern.
Das zweite Feld sind Geräte am Arbeitsplatz: Handhelds, Staplerterminals, Ringscanner, Waagen, Etiketten- und Belegdrucker, Sprachsysteme, gegebenenfalls Kamera- oder Volumenmesssysteme. EWM bringt für die mobile Erfassung ein eigenes Rahmenwerk mit, das bildschirmorientierte Abläufe für Scanner bereitstellt, sowie browserbasierte Oberflächen. In der Praxis entscheidet über die Akzeptanz weniger die Technik als die Gestaltung: Wie viele Tastendrücke braucht ein Vorgang, wie eindeutig ist die Fehlermeldung, wie schnell reagiert das Gerät. Diese Details sollten mit echten Mitarbeitern getestet werden, bevor Hardware in Stückzahl beschafft wird.
Das dritte Feld sind externe Partner: Logistikdienstleister, Kunden mit Belieferungsvorschriften, Zollsysteme, Lieferanten mit Avisierung. Hier laufen Verbindungen typischerweise über etablierte Nachrichtenformate und den elektronischen Datenaustausch. Wer viele Kunden mit unterschiedlichen Anforderungen an Etiketten, Avise und Packvorschriften bedient, sollte diesen Bereich früh bewerten – Kundenspezifika im Versand sind einer der häufigsten Gründe für Zusatzaufwand nach dem Start.
Das stärkste Argument für EWM ist selten der Funktionsvergleich, sondern die Systemlandschaft. Wenn der kaufmännische Kern ohnehin S/4HANA ist, wenn Material- und Chargenstamm dort gepflegt werden, wenn Beschaffung, Vertrieb und Buchhaltung dort laufen und wenn interne Kompetenz für diese Welt vorhanden ist, dann spricht vieles dafür, das Lager in derselben Welt zu führen. Der Wegfall einer Schnittstelle ist kein romantisches Argument, sondern eine dauerhaft eingesparte Betriebsaufgabe.
Ein zweites Argument ist die Personalfrage. Fachkräfte für die SAP-Welt sind knapp, aber sie sind auffindbar, und der Markt für Beratung und Betreuung ist groß. Bei kleineren Spezialanbietern hängt die Betreuung häufiger an wenigen Personen. Für ein System, das eine kritische Rolle im Tagesgeschäft spielt und über zehn Jahre und mehr betrieben wird, ist die Frage nach Verfügbarkeit von Know-how am Markt ein legitimes Auswahlkriterium.
Ein drittes Argument ist die Zukunftsplanung. Wer absehbar automatisiert, wer weitere Standorte anbinden will, wer strengere Nachweispflichten erwartet, ist mit einem System besser bedient, das diese Ausbaustufen bereits enthält. Das gilt allerdings nur, wenn der Ausbau realistisch geplant ist. Ein Ausbaupfad, der seit fünf Jahren in einer Präsentation steht und nie begonnen wurde, ist kein Argument für ein größeres System.
Es gibt gute Gründe, sich gegen die naheliegende Lösung zu entscheiden. Der erste ist die Passung zum Lagertyp. Spezialisierte Anbieter haben teils sehr ausgeprägte Vorlagen für bestimmte Branchen und Lagerformen – Kühl- und Tiefkühllogistik, Pharma mit Serialisierung, Ersatzteillager, Kontraktlogistik mit mandantenfähiger Abrechnung. Wo eine solche Vorlage passt, kann der Einführungsaufwand deutlich geringer ausfallen als bei einer generischen Konfiguration.
Der zweite Grund ist die Größenordnung. Für ein mittelständisches Lager mit überschaubarer Komplexität ist ein schlankes, fokussiertes System oft schneller eingeführt, einfacher zu bedienen und günstiger zu betreiben. Nicht jede Lagerorganisation braucht Aktivitätsbereiche, Wellenstrategien und Ressourcenmanagement – und was nicht gebraucht wird, muss trotzdem konfiguriert, getestet und dokumentiert werden.
Der dritte Grund ist die Unabhängigkeit. Manche Unternehmen wollen bewusst vermeiden, dass kaufmännischer Kern und Lagersteuerung in einer Anbieterhand liegen – aus Verhandlungsgründen oder weil ein möglicher ERP-Wechsel offengehalten werden soll. Das ist eine strategische Entscheidung, keine technische, und sie ist legitim. Sie sollte nur bewusst getroffen und nicht mit vorgeschobenen Funktionsargumenten begründet werden.
Aus unserer Projekterfahrung führt ein Vergleich nur dann zu einer tragfähigen Entscheidung, wenn er an eigenen Prozessen entlang geführt wird. Konkret heißt das: eigene Anforderungen in einem Lastenheft beschreiben, gegliedert nach Prozessschritten und mit klarer Trennung zwischen Muss und Wunsch. Anschließend Anbieter nicht ihre Standardpräsentation zeigen lassen, sondern drei bis fünf eigene Szenarien im System vorführen – darunter mindestens ein Sonderfall und eine Störung.
Ergänzend gehören vier Punkte abgefragt, die in Präsentationen selten vorkommen: Wie läuft ein Release-Wechsel ab und wie viel Test bedeutet er? Wie werden Erweiterungen umgesetzt und was passiert mit ihnen bei Updates? Welche Reaktionszeiten gelten bei einem Ausfall im Zwei- oder Dreischichtbetrieb? Und wie kommt man im Trennungsfall an die eigenen Daten in verwertbarer Form? Die Antworten auf diese vier Fragen sagen über die nächsten zehn Jahre mehr aus als jede Funktionsmatrix.
Und schließlich: Sprechen Sie mit Referenzkunden, die dem eigenen Profil ähneln, und zwar ohne Begleitung des Anbieters. Fragen Sie nicht, ob sie zufrieden sind, sondern was sie beim zweiten Mal anders machen würden. Diese Frage liefert die ehrlichsten Antworten, die im Auswahlprozess zu bekommen sind.
Neben der Architekturfrage aus Kapitel 02 steht die Betriebsfrage. SAP bietet seine Unternehmenssoftware im eigenen Rechenzentrumsbetrieb des Kunden, in einer privaten Cloud-Variante und in einer öffentlichen Cloud-Variante an; das Programm RISE with SAP bündelt Software, Infrastruktur und Betriebsleistungen in einem Vertrag. Für ein Lagersystem hat diese Wahl handfeste Konsequenzen, die über die üblichen Cloud-Argumente hinausgehen.
Die wichtigste ist die Anbindung an Technik vor Ort. Fördertechnik, Regalbediengeräte und Handhelds stehen im Lager, das System läuft möglicherweise in einem entfernten Rechenzentrum. Damit werden Netzanbindung, Latenz und Ausfallsicherheit der Leitung zu kritischen Größen. Ein Lager, dessen Scanner ohne Internetzugang stumm bleiben, steht still. Eine zweite, unabhängige Leitung, klare Zusagen zu Antwortzeiten und ein belastbares Notfallkonzept gehören deshalb in jede Cloud-Entscheidung für Lagersysteme.
Die zweite Konsequenz betrifft Wartungsfenster und Änderungszyklen. In Cloud-Betriebsmodellen bestimmt der Anbieter Zeitpunkte und Umfang von Aktualisierungen in weit größerem Maß als beim Eigenbetrieb. Für einen Dreischichtbetrieb mit Wochenendarbeit ist die Frage, wann gewartet wird und wie lange ein Fenster dauert, keine Randnotiz. Welche Zusagen im konkreten Vertrag möglich sind, ist ausdrücklich beim Anbieter zu klären; pauschale Aussagen dazu wären unseriös.
Der häufigste Irrtum in Gesprächen mit LE-WM-Anwendern lautet, der Wechsel zu EWM sei eine Art Umstellung mit Konvertierung. Das ist er nicht. EWM hat ein eigenes Stammdatenmodell, eigene Organisationsobjekte, eine eigene Prozesslogik und eigene Oberflächen. Lagertypen, Plätze, Strategien und Prozesse werden neu entworfen und neu aufgebaut. Bestände und Stammdaten werden übernommen, die Konfiguration nicht.
Das klingt nach schlechter Nachricht, ist aber eine Chance. In den meisten Lagern, die seit vielen Jahren mit dem klassischen WM arbeiten, haben sich Sonderregeln, Eigenentwicklungen und Umgehungslösungen angesammelt, die niemand mehr vollständig überblickt. Ein Neuaufbau zwingt dazu, jede dieser Regeln zu begründen. Unsere Erfahrung: Ein erheblicher Teil überlebt diese Prüfung nicht, weil der ursprüngliche Anlass längst entfallen ist.
Praktisch bewährt hat sich ein Vorgehen in drei Schritten. Erstens eine Bestandsaufnahme der tatsächlichen Nutzung – welche Bewegungsarten, welche Transaktionen, welche Eigenentwicklungen erzeugen wirklich Buchungen. Zweitens ein Zielprozessentwurf, der bewusst am Standard entlang gebaut wird und Abweichungen einzeln begründet. Drittens eine Umstellung je Standort oder je Lagerbereich statt eines Stichtags für alles, sofern die Struktur das zulässt. Wer mehrere Lager hat, sollte mit dem zweitkomplexesten beginnen: Das einfachste liefert zu wenig Erkenntnisse, das komplexeste zu viel Risiko.
Zur Projektdauer nennen wir bewusst keine Zahlen, weil sie ohne Kenntnis des Lagers nichts aussagen. Was sich sagen lässt: EWM-Einführungen sind mehrmonatige Vorhaben, und der Aufwand skaliert nicht mit der Lagergröße, sondern mit der Prozessvielfalt. Ein großes Lager mit einem einzigen, klar geschnittenen Prozess ist einfacher als ein kleines Lager mit fünfzehn Sonderwegen für verschiedene Kundengruppen. Die zweite Größe, die die Dauer bestimmt, ist die Verfügbarkeit interner Fachleute – und die wird fast immer unterschätzt.
Denn ein Lagerprojekt kann nicht ausgelagert werden. Beratung bringt Methodik, Systemkenntnis und Erfahrung aus anderen Projekten. Was sie nicht bringen kann, ist die Kenntnis der eigenen Ware, der eigenen Kunden und der ungeschriebenen Regeln, nach denen das Lager heute funktioniert. Dafür braucht es Mitarbeiter aus dem Lager selbst, mit echter Freistellung und nicht nur mit gutem Willen neben dem Tagesgeschäft. Ein Projekt, in dem die Lagerleitung keine Zeit hat, produziert ein System, das an der Realität vorbeigeht.
Für die Rollenverteilung hat sich bewährt: eine interne Projektleitung mit Entscheidungsbefugnis, ein bis zwei Fachverantwortliche aus dem Lager mit substanzieller Freistellung, ein interner technischer Ansprechpartner für Geräte und Netzwerk, dazu externe Beratung für Konfiguration, Integration und Test. Und eine Rolle, die oft fehlt: jemand, der nach dem Start dauerhaft für das System zuständig ist. Ein Lagerverwaltungssystem ohne benannten fachlichen Betreuer verliert innerhalb von zwei Jahren einen erheblichen Teil seines Nutzens, weil Parameter veralten und niemand sie pflegt.
Die belastbarste Faustregel aus unseren Projekten lautet: EWM trägt dort, wo mindestens zwei der folgenden Bedingungen erfüllt sind. Erstens, der kaufmännische Kern ist bereits S/4HANA und soll es bleiben. Zweitens, im Lager gibt es echte Komplexität – mehrere Zonen, mehrstufige Prozesse, Chargen- oder Serialnummernführung, Haltbarkeitssteuerung, Gefahrstoffe. Drittens, es besteht ein konkreter Automatisierungsplan. Viertens, es gibt Nachweispflichten gegenüber Kunden oder Behörden, die eine lückenlose Dokumentation verlangen.
Wo diese Bedingungen zusammenkommen, ist EWM auch für Unternehmen mit zwei- bis dreistelliger Mitarbeiterzahl eine tragfähige Wahl. Der Projektaufwand ist real, aber er verteilt sich auf eine Nutzungsdauer von zehn Jahren und mehr. Und der Gegenwert ist konkret: weniger Fehllieferungen, weniger Suchzeiten, belastbare Bestände, dokumentierte Rückverfolgbarkeit, eine Basis für Automatisierung, die nicht in zwei Jahren wieder ersetzt werden muss.
Ein Argument, das im Mittelstand besonders zählt, ist die Unabhängigkeit von Personen. Viele mittelständische Lager funktionieren, weil zwei oder drei erfahrene Mitarbeiter wissen, wo alles liegt und wie die Ausnahmen behandelt werden. Das ist beeindruckend und riskant zugleich. Ein durchkonfiguriertes Lagersystem überführt dieses Wissen in Regeln, die auch dann noch gelten, wenn diese Mitarbeiter in Rente gehen oder ausfallen. In Zeiten knapper Fachkräfte ist das ein handfester Grund.
Ebenso klar sind die Fälle, in denen wir abraten. Ein Lager mit wenigen hundert Plätzen, einem überschaubaren Sortiment ohne Chargenführung, einer Handvoll Mitarbeitern in einer Schicht und ohne Automatisierungsperspektive braucht kein EWM. Die Bestandsführung des ERP-Systems, ergänzt um mobile Erfassung, leistet dort, was gebraucht wird – zu einem Bruchteil des Aufwands.
Ein zweites Ausschlusskriterium ist die fehlende Systemlandschaft. Wer kein SAP im Haus hat und keins plant, kauft mit EWM nicht nur ein Lagersystem, sondern eine ganze technische Welt mit eigenem Betriebs- und Know-how-Bedarf. In dieser Konstellation sind spezialisierte WMS-Anbieter in aller Regel der pragmatischere Weg. Die Frage ist nicht, ob EWM gut ist – sondern ob der Rahmen passt, in dem es gut ist.
Ein drittes, oft übersehenes Kriterium ist die Betreuungskapazität. EWM ist ein System, das gepflegt werden will: Strategien anpassen, Plätze umschlüsseln, Wellenprofile nachschärfen, neue Artikelgruppen einordnen. Wenn im Unternehmen niemand diese Rolle übernehmen kann und auch keine externe Betreuung dauerhaft eingeplant ist, verliert das System schleichend seinen Nutzen. Ein einfacheres System, das gepflegt wird, ist besser als ein mächtiges, das niemand betreut.
Zwischen Nichtstun und Vollausbau liegt ein Weg, der im Mittelstand häufig der richtige ist. Er beginnt mit dem Kernprozess: Lagerstruktur, Wareneingang mit Einlagerung, Kommissionierung mit mobiler Erfassung, Warenausgang, Inventur. Dieser Umfang bringt bereits den größten Teil des Nutzens – Bestandsgenauigkeit, Wegereduzierung, Fehlervermeidung – und ist in einem überschaubaren Projekt erreichbar.
Erst danach folgen die Ausbaustufen, jede mit eigener Begründung und eigenem Nutzennachweis: Wellenmanagement, wenn die Auftragszahlen es rechtfertigen. Slotting, wenn genügend Bewegungshistorie vorliegt. Yard Management, wenn Tore und Rangierflächen zum Engpass werden. Value-Added Services, wenn Konfektionierung ein relevantes Volumen erreicht. Labor Management erst, wenn Betriebsrat, Datenschutz und Führungskultur darauf vorbereitet sind – und nie als erster Baustein.
Für eine belastbare Betrachtung empfehlen wir, alle vier Blöcke über fünf Jahre zu rechnen und nicht nur den Lizenz- oder Subskriptionsanteil zu vergleichen. Der Softwareblock ist der sichtbarste, aber selten der größte. Der Einführungsblock dominiert das erste Jahr und wird von zwei Größen getrieben: der Zahl unterschiedlicher Prozessvarianten und der Qualität der vorhandenen Stammdaten. Wer falsche Maße, fehlende Barcodes und uneinheitliche Verpackungseinheiten mitbringt, zahlt diesen Zustand im Projekt – und zwar mehrfach, weil er in jedem Testzyklus erneut auffällt.
Der Betriebsblock unterscheidet sich stark je nach Variante. Im Eigenbetrieb sind es Hardware, Systembetreuung und Wartung; in Cloud-Modellen eine laufende Vertragsleistung, die planbarer, aber nicht automatisch günstiger ist. Bei dezentralem Betrieb fällt dieser Block für ein zweites System an – ein Punkt, der in Architekturdiskussionen gern übersehen wird. Der vierte Block, die interne Zeit, taucht in keinem Angebot auf und ist trotzdem real: Freistellung von Lagerfachkräften, Schulungszeiten, Produktivitätsdelle in den ersten Wochen nach der Umstellung.
Zwei Fragen gehören zusätzlich in jede Verhandlung. Erstens: Was passiert, wenn die Nutzung wächst – neue Standorte, mehr Nutzer, höheres Volumen? Die Preisdynamik bei Wachstum ist wichtiger als der Einstiegspreis. Zweitens: Was kostet ein Wechsel der Ausbaustufe, wenn sich Anforderungen ändern? Wer diese beiden Punkte vor Vertragsschluss schriftlich klärt, verhandelt aus einer deutlich besseren Position als später, wenn das System produktiv läuft.
SAP ist ein europäisches Unternehmen mit Sitz in Deutschland und unterliegt damit unmittelbar dem europäischen Rechtsrahmen. Für Unternehmen, die Wert auf digitale Souveränität legen, ist das ein realer Unterschied zu Anbietern aus Drittstaaten – insbesondere hinsichtlich der Frage, welchem Zugriffsrecht ein Anbieter im Ernstfall unterliegt. Rechenzentrumsstandorte innerhalb der EU stehen für die relevanten Angebote zur Verfügung, und SAP adressiert das Thema Souveränität zusätzlich mit eigenen Angeboten für besonders regulierte Bereiche.
Diese Ausgangslage ist gut, aber sie beantwortet nicht alle Fragen. Cloud-Varianten der SAP werden je nach Vertrag auf eigener Infrastruktur oder auf der Infrastruktur großer Hyperscaler betrieben, von denen mehrere ihren Konzernsitz außerhalb der EU haben. Der Betrieb im europäischen Rechenzentrum eines solchen Anbieters ist datenschutzrechtlich zulässig, wirft aber zusätzliche Fragen zu Unterauftragnehmern und zu möglichen Zugriffen auf. Welche Konstellation im eigenen Vertrag gilt, ist konkret zu erfragen und zu dokumentieren – pauschale Aussagen sind hier nicht möglich.
Der zweite offene Punkt betrifft Support und Betrieb. Softwarekonzerne arbeiten mit weltweit verteilten Support-Organisationen, damit rund um die Uhr Hilfe verfügbar ist. Für die Datenschutzdokumentation ist deshalb zu klären, von welchen Standorten aus im Fehlerfall auf Systeme und Daten zugegriffen werden kann, wie diese Zugriffe freigegeben und protokolliert werden und ob sich Beschränkungen auf europäische Standorte vereinbaren lassen. Diese Frage gehört in die Vertragsverhandlung, nicht in die spätere Prüfung durch die Aufsichtsbehörde.
Der sensibelste Punkt eines jeden Lagerverwaltungssystems ist die Tatsache, dass es die Arbeit von Menschen minutiös protokolliert. Jede Aufgabe hat einen Bearbeiter, einen Startzeitpunkt, einen Endzeitpunkt und ein Ergebnis. Auch ohne den Baustein Labor Management entsteht damit ein detailliertes Bild individueller Arbeitsleistung. Mit Labor Management kommt eine explizite Gegenüberstellung von Vorgabe- und Istwerten hinzu, die für Personalplanung gedacht ist, aber ebenso zur Leistungsbewertung verwendet werden kann.
Arbeitsrechtlich ist das in Deutschland eindeutig mitbestimmungsrelevant: Technische Einrichtungen, die dazu bestimmt oder geeignet sind, Verhalten oder Leistung von Beschäftigten zu überwachen, unterliegen der Mitbestimmung des Betriebsrats. Das gilt unabhängig davon, ob eine Überwachungsabsicht besteht – die Eignung genügt. Die praktische Konsequenz: Der Betriebsrat gehört nicht am Ende informiert, sondern von Beginn an eingebunden. Eine Betriebsvereinbarung, die Zweck, Auswertungstiefe, Aggregationsebene, Zugriffsberechtigungen und Aufbewahrungsfristen regelt, gehört vor den Produktivstart – nicht danach.
Datenschutzrechtlich kommen die üblichen Grundsätze hinzu: Zweckbindung, Erforderlichkeit, Datenminimierung, Transparenz gegenüber den Betroffenen. Bewährt haben sich in Projekten mehrere konkrete Maßnahmen. Auswertungen standardmäßig auf Gruppen- statt Personenebene, mit personenbezogener Auswertung nur in klar definierten Ausnahmefällen. Enge Fristen für die Aufbewahrung von Detaildaten. Getrennte Berechtigungen zwischen operativer Steuerung und personalbezogener Auswertung. Und eine klare, verständliche Information der Beschäftigten darüber, was erfasst wird und wozu.
Ein letzter Gedanke aus der Praxis, jenseits der Rechtslage: Leistungsdaten verändern die Kultur eines Lagers. Wer sie einführt, ohne den Zweck zu erklären und ohne die Beschäftigten einzubeziehen, erzeugt Misstrauen, Ausweichverhalten und im Zweifel schlechtere Daten als vorher. Wer sie als Werkzeug für bessere Planung, gerechtere Verteilung von Arbeit und faktenbasierte Diskussionen über Engpässe einführt, bekommt in aller Regel Zustimmung. Der Unterschied liegt nicht in der Software.
