Automatisierungsprojekte scheitern selten an der Hardware - sie scheitern an der Anbindung ans WMS. Ungeprüfte Schnittstellen, Batch-Systeme ohne Echtzeitfähigkeit und fehlende Rollback-Pläne verwandeln einen sauberen Projektplan in ein monatelanges IT-Vorhaben. Dieser Artikel erklärt, welche Schnittstellen-Typen es gibt, wie eine WMS-Integration in fünf Phasen abläuft und welche Risiken Sie vor Vertragsabschluss entschärfen sollten.
Warum die WMS-Anbindung der kritische Pfad ist
Wenn ein Lagerautomatisierungsprojekt sein Budget sprengt oder den Zeitplan reißt, liegt die Ursache selten bei Robotern oder Regalen. Die Hardware fährt, die Station kommissioniert. Das Problem sitzt tiefer: in der Verbindung zwischen dem neuen System und dem bestehenden Warehouse Management System.
Das WMS ist das Gedächtnis des Lagers. Es kennt jeden Artikel, jeden Lagerplatz, jeden offenen Auftrag. Eine Automatisierungslösung, die davon abgeschnitten ist, kommissioniert blind. Deshalb ist die WMS-Anbindung bei jedem Automatisierungsprojekt der kritische Pfad - sie entscheidet, ob das System im Regelbetrieb zuverlässig läuft, und sie ist zugleich der Bereich mit den größten Unterschieden zwischen den Technologien.
Für den IT-Verantwortlichen im Buying Committee ist das die zentrale Frage: Wie viel Integrationsaufwand bringt die Lösung mit, und kann mein Team das neben dem Tagesgeschäft stemmen? In der Praxis hat der IT-Lead ein Vetorecht. Ein Projekt, das die Logistikleitung begeistert und die IT abschreckt, kommt nicht durch die Freigabe. Die IT-Integration gehört damit zu den am häufigsten unterschätzten intralogistischen Herausforderungen - sichtbar wird sie oft erst im Projektverlauf, und dann als Kostentreiber.
Schnittstellen-Typen: REST-API, Middleware, Flat-File
Drei Anbindungsmuster dominieren in gewachsenen Lagerlandschaften. Welches davon ein Anbieter voraussetzt, sagt mehr über den Integrationsaufwand aus als jede Marketingfolie.
REST-APIs sind der heutige Standard für Systemkommunikation. Das WMS sendet einen Kommissionierauftrag als strukturierte Anfrage, das Automatisierungssystem antwortet mit Status und Bestandsdaten - in Echtzeit, dokumentiert, versioniert. Moderne WMS-Systeme bringen diese Fähigkeit mit; bei älteren Installationen muss sie geprüft werden.
Middleware und Materialflussrechner (MFR) sind der klassische Weg bei AKL- und Shuttle-Anlagen. Weil deren Steuerung auf SPS/PLC-Ebene arbeitet, vermittelt eine eigene Softwareschicht zwischen WMS und Anlagentechnik. Diese Schicht muss entwickelt, gewartet und bei jedem Update auf beiden Seiten mitgezogen werden - und sie ist häufig anbietergebunden. Jede zusätzliche Schicht ist eine zusätzliche Fehlerquelle und ein Stück Vendor-Lock-in.
Flat-File-Austausch überträgt Daten als Dateien in festen Intervallen, etwa CSV-Exporte über SFTP alle 15 Minuten. Das Muster stammt aus einer Zeit, in der Systeme nicht direkt miteinander sprechen konnten, und es lebt in vielen gewachsenen ERP- und WMS-Landschaften fort. Für Automatisierung ist es problematisch: Zwischen zwei Übertragungen kennt das Automatisierungssystem den echten Bestand nicht. Bei niedriger Taktung entstehen Fehlkommissionierungen und Bestandsdifferenzen.
| Schnittstellen-Typ | Latenz | Wartungsaufwand | Typisch bei |
|---|---|---|---|
| REST-API | Echtzeit | Niedrig (versionierte Schnittstelle) | AMR-Systemen, modernen WMS |
| Middleware / MFR | Nahezu Echtzeit | Hoch (eigene Softwareschicht) | AKL, Shuttle-Systemen |
| Flat-File / Batch | Minuten bis Stunden | Mittel (Formatpflege, Monitoring) | Älteren ERP-/WMS-Landschaften |
NEO:os nutzt den ersten Weg: Die Orchestrierungssoftware dockt über standardisierte REST-APIs direkt an das bestehende WMS an, ohne Materialflussrechner und ohne Sub-WMS. Drei Datenströme genügen - das WMS übergibt Kommissionieraufträge, NEO:os meldet jeden abgeschlossenen Pick zurück, und Bestandsänderungen werden fortlaufend abgeglichen. Das WMS bleibt dabei das führende System. Ob das vorhandene WMS die nötigen Echtzeit-Schnittstellen mitbringt, klärt die Discovery-Phase vor dem Projekt, nicht die Implementierung mittendrin.
Klassische Automatisierung und AMR: zwei Integrationswelten
Wie stark sich der Integrationsaufwand zwischen den Architekturen unterscheidet, zeigt der direkte Vergleich:
| Dimension | AKL / Shuttle | Cube-basierte AS/RS | AMR / Goods-to-Person |
|---|---|---|---|
| Typische Schnittstelle | SPS/PLC + Materialflussrechner | Standard-API + integrator-spezifische WCS | REST-API |
| Anbindungsmodell | Indirekt über MFR als Middleware | Direkt oder über Sub-WMS/Connector | Direkt an das bestehende WMS |
| WMS-Anpassung nötig | Oft grundlegend | Teilweise (zusätzliche Softwareschicht) | Nein - WMS bleibt führend |
| Vendor-Lock-in (IT) | Mittel bis hoch | Mittel bis hoch | Niedrig |
| Rollback auf manuellen Betrieb | Schwierig (Infrastruktur umgebaut) | Eingeschränkt | Ja - Regalstruktur unverändert |
Zwei Punkte aus dieser Tabelle verdienen einen zweiten Blick. Erstens die WMS-Anpassung: Monolithische Systeme verlangen oft, dass das WMS ihre Steuerungslogik abbildet - das bindet IT-Ressourcen über Monate und ist ein wesentlicher Grund, warum klassische Automatisierungsprojekte 12-36 Monate bis zum Go-live brauchen. Zweitens der Rollback: Bei AKL und Shuttle gibt es nach dem Umbau keinen einfachen Weg zurück zum manuellen Betrieb. Bei einem AMR-Retrofit bleibt die Regalstruktur unverändert - fällt die Integration beim Go-live aus, kommissioniert das Team manuell weiter, während der Fehler behoben wird.
Wie die verschiedenen AMR-Varianten sich untereinander bei WMS-Anbindung, Eingriffstiefe und Betriebsmodell unterscheiden, vertieft unser Whitepaper AMR-Tiefenvergleich - inklusive der Frage, welche Variante zu welchem Lagerprofil passt.
Ablauf einer WMS-Integration in fünf Phasen
Eine gut geführte Integration folgt einem festen Ablauf. Bei NEO umfasst der gesamte Prozess typischerweise 10-15 IT-Entwicklungstage auf Kundenseite, verteilt über einen Kalenderzeitraum von ~4 Wochen - parallel zum Tagesgeschäft, ohne dediziertes Projektteam.
Phase 1: Discovery (1-2 IT-Tage)
Am Anfang steht die Bestandsaufnahme der Systemlandschaft: Welches WMS läuft in welcher Version, welche Schnittstellen existieren bereits, wo liegen Artikelstamm und Auftragsdaten, und unterstützt das System Echtzeitkommunikation? Hier fällt auch die Entscheidung, welche Datenströme die Integration braucht und wer auf Kundenseite verantwortlich ist. Eine ehrliche Discovery deckt Probleme auf, bevor sie Geld kosten - ein WMS, das nur Batch-Verarbeitung kann, ist in Phase 1 eine Planungsinformation, in Phase 4 ein Projektabbruchrisiko.
Phase 2: Mapping (3-5 IT-Tage)
Im Mapping werden die Datenfelder beider Systeme aufeinander abgebildet: Artikelnummern, Auftragsformate, Lagerplatzlogik, Behälterzuordnung. Klingt banal, ist aber die Phase mit den meisten Detailfallen. Feldlängen, Zeichensätze und Nummernkreise, die im Sales-Prozess niemand bespricht, kosten hier Tage, wenn sie nicht vorab dokumentiert wurden.
Phase 3: Test (3-4 IT-Tage)
Gegen ein Testsystem werden die realen Abläufe durchgespielt: Auftragsübergabe, Pick-Bestätigung, Bestandsabgleich, Storno, Fehlerfälle. Wichtig ist, nicht nur den Normalfall zu testen, sondern gezielt die Ausnahmen - was passiert bei einem abgebrochenen Auftrag, einem doppelt gemeldeten Pick, einem Verbindungsabbruch? Und: Der Test sollte das Peak-Volumen simulieren, nicht das Pilotvolumen. Eine Schnittstelle, die bei 100 Picks pro Stunde funktioniert, ist noch nicht bewiesen für das Zehnfache.
Phase 4: Parallelbetrieb (2-3 IT-Tage)
Vor dem Go-live läuft das System im Mischbetrieb: Ein Teil der Aufträge geht über die Automatisierung, der Rest weiter über die manuelle Kommissionierung. In dieser Phase wird der Bestandsabgleich unter realen Bedingungen validiert, und das Team an der Station arbeitet sich ein, während das Sicherheitsnetz des manuellen Prozesses gespannt bleibt. Dass dieser Parallelbetrieb ohne Betriebsunterbrechung möglich ist, ist eine Eigenschaft des Retrofit-Ansatzes - wie das im Detail funktioniert, beschreibt unser Artikel zur Lagerautomatisierung ohne Stillstand.
Phase 5: Go-live und Hypercare (1 IT-Tag plus Begleitung)
Der Go-live selbst ist bei sauberer Vorarbeit unspektakulär: Das Auftragsvolumen wird schrittweise auf die Automatisierung verlagert. In den ersten Wochen danach beobachten beide Seiten die Schnittstelle engmaschig - Bestandsdifferenzen, Antwortzeiten, Fehlerraten. Der gesamte NEO-Rollout inklusive Roboterflotte und Kommissionierstation erreicht den Go-live in 6-8 Wochen; die WMS-Integration ist darin der IT-seitige Anteil, kein eigenes Großprojekt davor.
Risiko-Katalog: sechs Fallstricke und ihre Gegenmaßnahmen
Integrationen scheitern selten an der Technologie und häufig an Annahmen, die vor dem Projekt niemand geprüft hat. Sechs Muster tauchen immer wieder auf:
| Risiko | Woran es sich zeigt | Gegenmaßnahme |
|---|---|---|
| API-Kompatibilität ungeprüft | Feldlängen, Zeichensätze, Nummernformate passen nicht zusammen; Mapping-Phase eskaliert | Dokumentierte API-Spezifikation vor Vertragsabschluss anfordern und von der eigenen IT prüfen lassen |
| WMS kann keine Echtzeit | Batch-orientiertes WMS liefert Bestände nur in Intervallen | In der Discovery klären; falls Middleware nötig ist, bewusst entscheiden statt improvisieren |
| Kein Rollback-Plan | Beim Go-live-Fehler steht das Lager | Architektur wählen, bei der der manuelle Betrieb weiterlaufen kann; Rückfallprozess vorab dokumentieren |
| Bestandsdrift | WMS und Automatisierung zeigen unterschiedliche Bestände | Führendes System eindeutig festlegen, jeden Pick einzeln zurückmelden, zyklischen Abgleich einrichten |
| Schnittstelle skaliert nicht | Pilotbetrieb läuft, Peak-Volumen bricht ein | Lasttest mit realistischem Spitzenvolumen in der Testphase, nicht erst im Hochlauf |
| WMS-Update bricht die Anbindung | Nach einem Release-Wechsel bleiben Aufträge hängen | Versionierte Schnittstellen voraussetzen; Update-Prozess und Regressionstests vertraglich klären |
Der gemeinsame Nenner: Jedes dieser Risiken lässt sich vor Vertragsabschluss entschärfen - danach nur noch teuer reparieren. Wer die Punkte in den Anbietergesprächen systematisch abfragt, verlagert das Risiko dorthin, wo es hingehört: in die Auswahlphase.
Woran Sie einen integrationsfreundlichen Anbieter erkennen
Jeder Anbieter beschreibt seine Integration als einfach. Belastbar wird die Aussage erst, wenn sie konkret wird. Diese Punkte trennen in der Praxis die Anbieter, bei denen die IT-Integration planbar bleibt, von denen, bei denen sie zum Projekt im Projekt wird:
- Der Anbieter legt vor Vertragsabschluss eine dokumentierte API-Spezifikation vor - nicht erst nach dem Kick-off.
- Das bestehende WMS bleibt das führende System. Kein Sub-WMS, keine zusätzliche Orchestrierungsschicht, die künftig mitgewartet werden muss.
- Der Integrationsaufwand wird in konkreten IT-Tagen beziffert, nicht mit Adjektiven umschrieben.
- Referenz-Integrationen mit vergleichbaren WMS-Systemen lassen sich benennen und auf Nachfrage erläutern.
- Parallelbetrieb ist ab dem ersten Tag möglich, sodass der Umstieg schrittweise erfolgen kann statt als Stichtags-Umstellung.
- Ein Rollback-Szenario ist beschrieben: Was passiert, wenn die Integration beim Go-live nicht funktioniert?
- Die Schnittstellen sind versioniert, und der Umgang mit WMS-Updates ist geregelt.
NEO ist an diesen Kriterien entlang gebaut. NEO:os arbeitet als Orchestrierungsschicht zwischen dem bestehenden WMS und der Roboterflotte - das WMS führt, NEO:os übersetzt Aufträge in Roboterlogistik und meldet jeden Pick zurück. Die Integration benötigt typischerweise 10-15 IT-Entwicklungstage, und weil die Schnittstelle einmal aufgesetzt wird, skaliert sie beim Ausbau von einer auf mehrere Stationen ohne zusätzlichen Integrationsaufwand mit. Wie die NEO-Plattform im Ganzen aufgebaut ist - Software, Roboterflotte und Goods-to-Person-Station - zeigt die Plattform-Seite.
FAQ: Häufige Fragen zur WMS-Integration bei Lagerautomatisierung
Muss ich mein WMS wechseln, um Lagerautomatisierung einzuführen?
Bei NEO nicht. NEO:os ist als Ergänzung zum bestehenden WMS konzipiert, nicht als Ersatz - das WMS bleibt das führende System, NEO:os orchestriert die Roboterlogistik und kommuniziert über standardisierte REST-APIs. Bei klassischen Systemen (AKL, Shuttle) sind dagegen oft tiefe WMS-Anpassungen oder ein Systemwechsel Teil des Projekts.
Wie viel IT-Kapazität braucht die Integration?
Typischerweise 10-15 IT-Entwicklungstage auf Kundenseite, verteilt über ~4 Wochen. Das umfasst Discovery, Datenmapping, Tests, Parallelbetrieb und Go-live. Die meisten Unternehmen stemmen das mit dem bestehenden IT-Team neben dem Tagesgeschäft.
Ist NEO:os mit meinem WMS kompatibel?
NEO:os integriert sich über offene REST-APIs und ist damit mit jedem WMS kompatibel, das API-basierte Kommunikation unterstützt. Ob Ihr System die nötigen Schnittstellen mitbringt, klärt die Discovery-Phase vor Projektstart - nicht erst die Implementierung.
Was passiert, wenn die Integration beim Go-live nicht funktioniert?
Beim AMR-Retrofit bleibt die Regalstruktur unverändert, deshalb ist der Rückfall einfach: Die manuelle Kommissionierung läuft weiter, während der Fehler behoben wird. Zusätzlich reduziert der Parallelbetrieb vor dem Go-live das Risiko, dass ein Fehler überhaupt erst im Livebetrieb auffällt.
Bricht die Integration bei einem WMS-Update?
NEO:os kommuniziert über versionierte APIs; Standard-Updates des WMS beeinträchtigen die Anbindung in der Regel nicht. Bei größeren WMS-Migrationen unterstützt NEO bei der Anpassung der Schnittstelle.
Nächster Schritt: Integration prüfen lassen
Wie schnell sich Ihre WMS-Landschaft anbinden lässt, klärt ein kostenloser Fit-Check - inklusive Blick auf Schnittstellen, Datenflüsse und den realistischen Zeitplan für Ihr Lager.
