Was ist SAP EWM (Extended Warehouse Management)?

SAP EWM bildet ein Lager als Hierarchie ab. Die Lagernummer ist die oberste Einheit und entspricht meist einem physischen Lagerstandort. Darunter liegen Lagertypen, die Bereiche mit gleicher Technik oder gleichem Zweck zusammenfassen: das Hochregallager, die Kommissionierzone, der Wareneingangsbereich, das Blocklager. Lagertypen gliedern sich in Lagerbereiche und Lagerplätze; der Lagerplatz ist die kleinste adressierbare Einheit, auf der ein Bestand liegt. Aktivitätsbereiche fassen Lagerplätze für die Wegeoptimierung zusammen, unabhängig von der Technik.

In automatisierten Lägern bewegt SAP EWM in der Regel nicht die Ware, sondern die Handling Unit (HU): eine Palette, ein Behälter oder ein Karton mit eindeutiger Nummer, der Bestände enthält und selbst wieder in einer anderen HU stecken kann. Jede Bewegung einer HU oder eines Bestands ist eine Lageraufgabe (Warehouse Task) mit Quelle und Ziel. Mehrere Lageraufgaben werden zu einem Lagerauftrag (Warehouse Order) gebündelt, der einer Ressource zugewiesen wird – einem Mitarbeiter mit RF-Gerät, einem Stapler oder einem Regalbediengerät. Welche Schritte ein Bestand auf seinem Weg durchläuft, legt die Lagerprozessart fest; sie steuert etwa, ob eine Einlagerung über eine Identifikationsstelle und einen Konturencheck läuft oder direkt ins Regal geht.

Diese Struktur ist der Grund, warum SAP EWM für komplexe Läger geeignet ist und SAP WM nicht: Lageraufgabe, Lagerauftrag, Ressource und Prozessart erlauben es, Arbeit zu planen, zu priorisieren und zu verteilen, statt nur Bestände zu buchen. Sie ist zugleich der Grund, warum eine EWM-Einführung Projektarbeit ist – die Struktur muss zum Lager passen, und ein gewachsenes Lager passt selten in eine Standardstruktur.

MFS steht für Material Flow System, auf Deutsch Materialflusssystem. Es ist der Teil von SAP EWM, der direkt mit den Steuerungen der Lagertechnik kommuniziert – ohne einen zwischengeschalteten Materialflussrechner. SAP EWM MFS tauscht mit den speicherprogrammierbaren Steuerungen (SPS) der Fördertechnik und der Regalbediengeräte Telegramme aus: Fahraufträge nach unten, Quittierungen, Positionsmeldungen und Störungen nach oben. Die Kommunikation läuft in aktuellen Releases direkt über TCP/IP-Sockets: SAP EWM MFS baut als Client die Verbindung zur SPS auf, die als Socket-Server antwortet; technisch übernimmt das der ABAP Push Channel. SAP Plant Connectivity (PCo), das bis EWM 9.3 als Umsetzer zwischengeschaltet war, ist heute eine Alternative, kein Standard mehr.

Fachlich übernimmt MFS damit die Aufgaben, die sonst ein Materialflussrechner hat: Es kennt die Topologie der Anlage als Netz aus Förderelementen und Kommunikationspunkten, entscheidet an jeder Verzweigung über den Weg einer Palette, verwaltet die Belegung der Fördertechnik, steuert das Regalbediengerät in der Gasse und meldet Störungen an den Lagerverwaltungsmonitor. Der Vorteil: Lagerverwaltung und Materialflusssteuerung liegen in einem System, mit einer Datenbasis und einer Oberfläche. Der Preis: MFS erwartet, dass die Steuerungen der Anlage das Kommunikationsprotokoll von SAP EWM MFS beherrschen – Socket-Server, Sequenznummern, Quittungstelegramme – und die im Projekt definierten Telegrammstrukturen umsetzen.

Genau daran scheitern Bestandsprojekte. Eine Anlage, die seit fünfzehn Jahren mit einem eigenen Materialflussrechner und einer eigenen SPS-Logik läuft, spricht nicht die Sprache von SAP EWM MFS. Sie kann sie lernen – dann müssen SPS-Programme und MFS-Konfiguration aufeinander abgestimmt werden – oder sie behält ihre Sprache, und ein externer Materialflussrechner übersetzt. Beides ist möglich; welcher Weg der richtige ist, hängt von der Anlage ab. Der Abschnitt zu den Anbindungsmodellen weiter unten beschreibt die drei Varianten.

Ein automatisches Lager besteht aus mehreren Steuerungsebenen, und SAP EWM kann jede davon übernehmen oder einem anderen System überlassen. Um zu verstehen, was angebunden wird, hilft ein Blick auf die Komponenten, aus denen eine Lagersteuerung besteht:

• Materialstammdatenverwaltung – welche Materialien im Betrieb bekannt sind
• Bestandsverwaltung – welche Materialien in welcher Menge mit welchen Eigenschaften auf welchem Ladungsträger liegen
• Stellplatzverwaltung – welcher Ladungsträger auf welchem Platz steht
• Materialflusssteuerung – der Transport eines Ladungsträgers vom Quell- zum Zielplatz
• Regalbediengeräte-, Fördertechnik-, Hängebahn- und Transportrobotersteuerung – die Maschinen selbst

Die ersten drei sind Datenverwaltung und liegen weit weg von der Maschine; die letzten sind steuerungsnah. SAP EWM enthält die Stammdaten-, Bestands- und Stellplatzverwaltung immer, die Materialflusssteuerung als Option MFS. Daraus ergeben sich drei Anbindungsmodelle, zwischen denen je Anlage zu entscheiden ist:

Kein Modell ist das bessere; jedes passt zu einer Art von Anlage. Die tiefe Anbindung ist die sauberste, wenn die Anlage neu ist und ihre Steuerungen für SAP EWM MFS ausgelegt werden können. Die flache Anbindung ist die pragmatischste, wenn eine bewährte Anlage weiterlaufen soll und nur die Lagerverwaltung nach SAP wechselt. Die mitteltiefe Anbindung ist der Regelfall bei Anlagen, deren Fahrzeugsteuerung Spezialwissen erfordert, das nicht in SAP nachgebaut werden soll – etwa bei fahrerlosen Transportsystemen mit eigenem Flottenmanager. Wie A+K Bestandsanlagen konkret an SAP EWM MFS anbindet, beschreibt die Seite Lagerintegration in SAP EWM MFS.

Die meisten SAP-EWM-Projekte in der Industrie sind keine Neubauten, sondern Umstellungen: Ein bestehendes Lager mit eigener Lagerverwaltung, eigenem Materialflussrechner und Steuerungen aus mehreren Generationen soll nach SAP EWM wechseln – meist im Zuge einer S/4HANA-Einführung, oft, weil Ersatzteile und Hersteller-Support für die alte Software knapp werden. Solche Brownfield-Projekte folgen einem Muster, das sich von Greenfield-Projekten grundlegend unterscheidet.

1. Rückdokumentation. Gewachsene Anlagen haben selten eine aktuelle Beschreibung ihrer Abläufe. Der erste Schritt ist deshalb, aus SPS-Programmen, Materialflussrechner und Betriebserfahrung zu rekonstruieren, was die Anlage tatsächlich tut – einschließlich der Sonderfälle, die nur im Störungsfall sichtbar werden.
2. Zielarchitektur. Aus der Bestandsaufnahme ergibt sich das Anbindungsmodell: Welche Ebenen wechseln nach SAP, welche bleiben? Was passiert mit dem Materialflussrechner? Welche SPS werden erneuert, welche bleiben und werden angepasst? Ein Retrofit der Steuerungstechnik ist häufig Teil des Projekts, weil alte SPS-Generationen die nötigen Schnittstellen nicht bieten.
3. Emulation und Test. Bevor die reale Anlage angefasst wird, läuft SAP EWM MFS gegen eine Emulation der Anlage: eine Software, die sich an den Schnittstellen verhält wie Fördertechnik und Regalbediengeräte. So werden Telegramme, Prozessarten und Störfälle getestet, ohne den Betrieb zu unterbrechen.
4. Stufenweise Migration. Umgestellt wird in Abschnitten – Gasse für Gasse, Bereich für Bereich – mit Rückfallmöglichkeit auf das alte System. Die Alternative, ein Stichtag mit Komplettumstellung, kommt nur infrage, wenn eine Betriebspause ohnehin geplant ist.
5. Betrieb und Nachjustierung. Nach dem Go-live zeigt sich, welche Prozesse in der Emulation nicht sichtbar waren. Die ersten Wochen dienen dem Feinschliff von Strategien, Prioritäten und Störungsbehandlung.

Der kritische Punkt in jedem dieser Schritte ist die Grenze zwischen SAP und Anlage. Wer sie zu tief in die Anlage legt, baut SPS-Logik in SAP nach; wer sie zu hoch legt, verschenkt die Integration. Die richtige Stelle ist die, an der beide Seiten ihre Stärken behalten.