SAP EWM MFS vs. WCS: Wann SAP EWM MFS sinnvoll ist – Architektur, Grenzen & Praxiserfahrungen

Einleitung: Das reale Problem hinter der Architekturentscheidung

In nahezu jedem automatisierten Lagerprojekt mit SAP EWM kommt früher oder später die gleiche Frage: „Brauchen wir SAP EWM MFS – oder setzen wir einen externen Materialflussrechner (WCS/MFR) ein?“

Diese Entscheidung wird häufig zu spät getroffen. Oder sie wird isoliert aus IT-Sicht entschieden – ohne Berücksichtigung von:

• realer Anlagenkomplexität
• Durchsatzanforderungen
• Betreiberorganisation
• vorhandener Systemlandschaft

Die Folge sehen wir in Projekten regelmäßig:

• instabile Go-Lives durch unklare Verantwortlichkeiten
• unnötig hohe Komplexität (hybride Schattenarchitekturen)
• ineffiziente Fehlersuche zwischen SAP, WCS und SPS
• oder eine SAP-EWM-MFS-Implementierung an Stellen, wo sie technisch nicht sinnvoll ist

Dieser Artikel liefert eine klare, praxisnahe Einordnung. Einen Überblick über die Steuerung automatisierter Lagertechnik direkt aus SAP EWM finden Sie auf unserer Leistungsseite SAP EWM Materialflusssteuerung.

Technische Grundlagen: Was SAP EWM MFS wirklich ist

SAP EWM MFS ist kein „klassischer“ Materialflussrechner im Sinne eines eigenständigen Systems. Es ist eine in SAP EWM integrierte Steuerungsschicht, die direkt mit der SPS kommuniziert.

Technisch bedeutet das:

• Direkte Kommunikation zwischen SAP EWM und SPS
• Austausch über Telegramme (Byte-Streams)
• Kommunikation über TCP/IP Channels (CP Channels)
• Verarbeitung von Lageraufgaben (Warehouse Tasks) in steuerbare Bewegungen
• Steuerung entlang von Meldepunkten, Segmenten und Ressourcen

Kernprinzip: SAP EWM zerlegt logistische Bewegungen in kleine Schritte und sendet diese sequenziell an die SPS.

Typische technische Bausteine:

• Queue Management (MFS-relevante Queues)
• Telegram Handling (Send / Acknowledge / Retry)
• CP Channels (Kommunikationskanäle)
• Exception Handling bei Anlagenfehlern
• Monitoring im /SCWM/MON

Wie sich die Telegrammkommunikation im Betrieb überwachen und Störungen eingrenzen lassen, beschreibt unser Beitrag „Telegrammmonitoring in SAP EWM MFS: Retry, CP Channels, Queue-Staus und Debugging in der Praxis“.

Architekturvarianten im Vergleich

Grundmodelle

Grob lassen sich drei Architekturansätze unterscheiden:

Die Begriffe White, Grey und Black Box beschreiben dabei die Sicht aus dem SAP-System: Bei EWM-MFS ist die komplette Steuerungslogik in SAP sichtbar und nachvollziehbar. Beim externen WCS bekommt EWM nur Ergebnisse zurück – was dazwischen passiert, bleibt aus SAP-Sicht eine Black Box.

Entscheidende Unterschiede

SAP EWM MFS reduziert Systemkomplexität durch Wegfall von Middleware – auf Kosten von Flexibilität und Spezialisierung.

Typische Einsatzszenarien aus Projekten

SAP EWM MFS ist sinnvoll bei

Aus unserer Projekterfahrung spielt SAP EWM MFS seine Stärken vor allem hier aus:

• Fördertechnik mit linearem Routing
• Klassische Hochregallager (RBG/ASRS)
• Shuttle-Systeme mit klaren Fahrstrategien
• Behälterfördertechnik (Case Conveyor)
• Produktionsversorgung mit stabilen Prozessen

Warum?

• Direkte Steuerung ohne WCS reduziert Schnittstellen
• End-to-End-Sicht in SAP
• geringere Lizenz- und Betriebskosten

→ SAP EWM bleibt das führende System für Steuerung und Monitoring

SAP EWM MFS ist kritisch bei

Anders sieht es bei diesen Szenarien aus:

• hochdynamischen Sortern
• komplexen Crossbelt-Systemen
• AGV/AMR Flotten (dynamisches Routing)
• KI-basierter Optimierung
• stark wechselnden Layouts

Warum?

• Echtzeit-Optimierungslogik gehört nicht nach SAP
• Komplexe Steueralgorithmen (Stauvermeidung, dynamische Priorisierung) werden im MFS schwer wartbar
• MFS ist nicht für autonome Entscheidungslogik gebaut

Das ist keine Schwäche des Produkts, sondern eine Frage des Einsatzzwecks: MFS ist eine Steuerungsschicht für definierte Abläufe, kein Optimierungssystem.

Typische Fehler und Risiken

Egal für welche Architektur man sich entscheidet – bestimmte Fehler tauchen in Projekten immer wieder auf. Sie lassen sich in drei Kategorien einteilen:

Architekturfehler

• SAP EWM MFS wird als vollwertiger WCS-Ersatz betrachtet
• Verantwortlichkeiten zwischen SAP und SPS nicht sauber definiert
• Mischung aus LOSC, Routing und MFS ohne klare Strategie

Technische Risiken

• schlechte Queue-Steuerung → Deadlocks
• fehlende Retry-Mechanismen → Telegrammverlust
• falsches Timeout-Handling → Systemblockaden
• unzureichende Performance-Tests → Go-Live-Probleme

Projekt-Risiken

• fehlende Simulation vor Integrationstest
• zu späte Einbindung der SPS-Entwicklung
• fehlende Lasttests (Durchsatz / Latenz)

Lessons Learned aus Projekten

Was nehmen wir aus den Projekten mit? Fünf Erkenntnisse:

MFS ist kein Prozessoptimierer – sondern ein Prozessausführer

Es führt definierte Bewegungen zuverlässig aus. Wer Optimierungsintelligenz erwartet, sucht sie auf der falschen Ebene.

Die SPS-Logik entscheidet über Stabilität

Die beste SAP-Implementierung nützt nichts, wenn die Anlagenseite Zustände anders interpretiert. Stabilität entsteht im Zusammenspiel – und die SPS ist dabei mindestens gleichberechtigter Partner.

Routing gehört bewusst definiert (SAP vs. Anlage)

Welche Wegentscheidung trifft SAP, welche die Anlage? Diese Frage darf sich nicht implizit im Projektverlauf beantworten, sondern gehört explizit entschieden und dokumentiert.

Teststrategie ist kritisch (Simulation + End-to-End)

Simulation und End-to-End-Tests sind keine optionalen Qualitätsmaßnahmen, sondern der einzige Weg, Integrationsfehler vor dem Go-Live zu finden.

Monitoring muss vor Go-Live stehen, nicht danach

Wer erst im Betrieb anfängt, Sichtbarkeit aufzubauen, analysiert die ersten Störungen im Blindflug.

Best Practices & Empfehlungen

Architektur

• Früh klären: Wer trifft Routing-Entscheidungen?
• Für den MFS-Einsatz selbst gilt eine einfache Faustregel: MFS nur dort einsetzen, wo die Steuerlogik überschaubar ist und keine hochdynamische Optimierung gebraucht wird. Wo eine der beiden Bedingungen nicht erfüllt ist, gehört ein externer WCS zumindest ernsthaft geprüft.

Technische Umsetzung

• Die Basis bilden klare Telegrammdefinitionen – inklusive der Fehlerfälle
• saubere Queue-Struktur
• Retry-Mechanismen implementieren
• CP Channels stabil auslegen

Testing

• Simulation (z. B. PLC Emulator oder 3D Emulation) zwingend notwendig
• Integrationstest ≠ Lasttest: Dass die Prozesse funktionieren, sagt nichts darüber, ob sie auch unter realem Durchsatz funktionieren. Beides gehört getestet, mit realistischen Durchsatzszenarien.

Für Simulation und Telegrammverarbeitung im Projekt stellen wir mit der Qinlox Toolbox für SAP EWM MFS bewährte Frameworks bereit.

Betrieb

• Monitoring in SAP (MFS Monitor) aktiv nutzen
• klare Incident-Prozesse definieren
• Verantwortlichkeiten SAP vs. Automation fixieren

Grenzen von SAP EWM MFS

So klar die Stärken sind, so klar sind die Grenzen. SAP EWM MFS stößt an sie bei:

• dynamischer Verkehrssteuerung, etwa von AGV-Flotten
• komplexer Sequenzoptimierung
• hochfrequenten Sortierprozessen
• KI-gestützter Materialflusssteuerung

Genau hier spielt ein klassischer Materialflussrechner seine Stärken aus:

• Echtzeitoptimierung
• regelbasierte und heuristische Algorithmen
• eine von SAP entkoppelte Steuerlogik, die sich unabhängig weiterentwickeln lässt

Der MFR übernimmt in solchen Anlagen die Rolle der operativen Steuerungsschicht – EWM bleibt führend für Bestand und Auftrag, die Optimierung findet darunter statt.

Entscheidungsmatrix

Für die Entscheidung im eigenen Projekt hilft ein Blick auf die wichtigsten Kriterien im Überblick: