ERP, WMS und Leitsteuerung: Wer weiß was?
Ein ERP organisiert betriebliche Vorgänge; ein Warehouse Management System (WMS), auf Deutsch Lagerverwaltungssystem, führt lagerbezogene Aufgaben. Die Flottensteuerung organisiert die Ausführung durch Fahrzeuge. In einer realen Anlage können weitere Ebenen hinzukommen. Für ein Projekt ist deshalb wichtiger, wer eine konkrete Entscheidung trifft, als wie eine Softwarekategorie genannt wird.
Die Information „an Station A steht eine Palette“ genügt beispielsweise für eine lokale Abholung, wenn Ziel und Freigabe eindeutig sind. Für eine Bestandsumbuchung können zusätzlich Artikel, Ladungsträger, Charge und Lagerplatz nötig sein. Der gleiche physische Transport stellt dann andere Anforderungen an den Datenaustausch.
Drei mögliche Einführungsstufen
| Stufe | Auftragsquelle und Rückmeldung | Voraussetzung | Wann sinnvoll |
|---|---|---|---|
| Lokaler Ablauf | Bedienung oder Sensor erzeugt Bedarf; der Prozess bestätigt die Übergabe. | Quelle, Ziel, Freigaben und Störungen sind lokal eindeutig. | Ein begrenzter Nachschub- oder Leergutprozess ohne notwendige automatische Bestandsbuchung. |
| Begrenzte Anbindung | Bestandssystem liefert ausgewählte Daten und erhält einen Abschluss. | Stabile Kennungen und ein klarer fachlicher Abschluss. | Vorhandene Software soll erhalten bleiben; nur der Transport wird automatisiert. |
| Durchgängige Kopplung | Aufträge, Prioritäten, Lastdaten, Buchungen und Ausnahmen werden abgestimmt. | Verantwortlichkeiten und Wiederanlauf über alle beteiligten Systeme sind geklärt. | WMS-geführte Abläufe, bei denen physische Bewegung und Datenbestand eng zusammengehören. |
Die Stufen sind Planungsmodelle, keine Produktpakete. Ein Projekt muss nicht zwangsläufig alle Stufen durchlaufen. Ein einfacher Ablauf darf dauerhaft lokal bleiben, wenn seine betrieblichen Anforderungen damit erfüllt sind. Umgekehrt ist ein absichtlich isolierter Pilot wenig aussagekräftig, wenn der spätere Betrieb zwingend eine komplexe Buchungslogik braucht.
Was bedeutet „Altsystem anbinden“ konkret?
Ein Altsystem ist nicht automatisch ungeeignet. Entscheidend sind erreichbare Schnittstellen, verlässliche Daten und eine betreubare Anwendung. Ein älteres System mit dokumentierter Schnittstelle kann einfacher einzubinden sein als eine neue, stark angepasste Anwendung mit unklaren Verantwortlichkeiten.
Mögliche technische Wege sind ein vorhandener Dienst, ein freigegebener Dateiaustausch oder eine zwischengeschaltete Adapteranwendung. Das sind allgemeine Architekturvarianten, keine Zusage, dass jede verglichene Plattform jeden Weg unmittelbar unterstützt. Die gewählte Verbindung muss lesende und schreibende Zugriffe, Aktualität und Fehlerbehandlung passend zum Prozess abdecken.
Direkte Änderungen in einer Produktivdatenbank sollten nicht als bequemer Ersatz für eine fehlende fachliche Schnittstelle eingeplant werden. Zuerst ist mit dem verantwortlichen Systemteam zu klären, welche Verfahren vorgesehen und dauerhaft betreubar sind. Sonst kann ein technisch erfolgreicher Datenaustausch fachliche Prüfungen der Anwendung umgehen.
Welche Daten gehören zum Transportauftrag?
| Information | Zweck | Vorab zu entscheiden |
|---|---|---|
| Eindeutige Auftragskennung | Anforderung und Rückmeldung zuordnen | Bleibt die Kennung bei Wiederholung und Wiederanlauf gleich? |
| Quelle und Ziel | Transportrelation festlegen | Wer übersetzt Prozessorte in physische Stationen? |
| Last beziehungsweise Ladungsträger | Geeignetes Fahrzeug und Übergabe auswählen | Welche Merkmale sind Pflicht, welche nur Information? |
| Freigabe und Bereitschaft | Nur zulässige Transporte starten | Wer bestätigt Last vorhanden, Quelle zugänglich und Ziel frei? |
| Termin oder Priorität | Konkurrierende Anforderungen behandeln | Welche Stelle darf Prioritäten nachträglich verändern? |
| Status und Abschluss | Ausführung von bloßem Empfang unterscheiden | Gilt erst die bestätigte Übergabe als abgeschlossen? |
| Fehler und Abbruch | Offene Arbeit nachvollziehbar behandeln | Wer entscheidet über Wiederholung, Ersatztransport oder manuelle Bearbeitung? |
Nicht jeder Prozess benötigt alle Felder. Der Datensatz sollte so klein wie möglich und so vollständig wie nötig sein. Ein unnötig großes Modell erhöht den Abstimmungsaufwand; ein zu kleines Modell verlagert fehlende Entscheidungen auf Mitarbeiter und nachträgliche Sonderregeln.
Warum Empfang nicht gleich Erledigung ist
Ein robustes Auftragsmodell unterscheidet mindestens angefordert, angenommen, in Ausführung und fachlich abgeschlossen. Dazu kommen definierte Fehler- und Abbruchzustände. Eine technische Antwort der Schnittstelle bestätigt zunächst nur den Empfang beziehungsweise die Annahme; sie darf nicht ohne Weiteres als erfolgreiche Lastübergabe interpretiert werden.
Besonders wichtig ist der unklare Zwischenzustand: Die Palette wurde bereits abgegeben, aber die Abschlussmeldung erreicht das WMS nicht. Ein blind wiederholter Transport könnte dann eine zweite Palette bewegen. Der Wiederanlauf muss deshalb den bekannten Auftragszustand und die physische Situation abgleichen, bevor erneut ausgeführt wird.
Bei einem lokalen Einstieg kann das zunächst in einem einzigen System gelöst werden. Mit einer späteren Unternehmensanbindung muss derselbe Zustand über eine zusätzliche Grenze hinweg verständlich bleiben. Darum lohnt sich die Festlegung stabiler Kennungen auch schon im kleinen Pilotprojekt.
Sensoren ersetzen nicht jede Prozessentscheidung
Ein Sensor kann einen Zustand erkennen, etwa einen belegten Bereitstellplatz. Für einen Transport muss zusätzlich feststehen, ob die Last vollständig, freigegeben und dem richtigen Ziel zugeordnet ist. Eine Kameraerkennung oder Lichtschranke kann diese Fragen je nach Aufbau unterstützen; sie beantwortet sie nicht automatisch vollständig.
- Belegter Platz: Welche Last wird erkannt und ist sie bereits transportbereit?
- Freies Ziel: Ist der Platz wirklich verfügbar oder für einen anderen Auftrag reserviert?
- Wiederholtes Signal: Entsteht ein neuer Bedarf oder wird derselbe Zustand nochmals gemeldet?
- Unsichere Erkennung: Wird gewartet, nachgefragt oder ein klarer Fehler angezeigt?
Die Erprobung sollte deshalb einen verspäteten Mitarbeiter, eine kurzzeitig verdeckte Last und eine belegte Station umfassen. Entscheidend ist der verlässliche Arbeitsablauf, nicht allein eine erfolgreiche Erkennung im idealen Bildausschnitt.
Was die fünf Anbieter dazu veröffentlichen
SyncroBot nennt einen lokalen Einstieg ab einem Roboter und eine optionale ERP-/WMS-Anbindung. [Quelle]
SYNAOS beschreibt lokale Auslöser ohne ERP-/WMS-Anbindung. [Quelle]
Bei Idealworks zeigt der Noerpel-Bericht die Einbindung eines vorhandenen WMS. [Quelle] MiR dokumentiert eine REST-API für Unternehmenssysteme. [Quelle] InOrbit BES verbindet betriebliche Aufträge mit der Ausführung durch Roboter. [Quelle]
Diese Nachweise beantworten unterschiedliche Fragen. Eine Projektbeschreibung zeigt eine real beschriebene Umsetzung; eine API beschreibt einen technischen Zugang; eine optionale Anbindung beschreibt die mögliche Aufgabenverteilung. Für die Beschaffung sind alle drei Ebenen relevant. Zum direkten Anbietervergleich.
Ein kompakter Abnahmelauf für jede Schnittstelle
- Einen gültigen Auftrag anlegen und seine Kennung bis zur bestätigten Übergabe verfolgen.
- Dieselbe Nachricht nochmals senden; das vereinbarte Verhalten bei Wiederholung prüfen.
- Einen unbekannten Zielplatz und eine unzulässige Last anfordern; die Ablehnung muss verständlich sein.
- Die Verbindung vor, während und nach der physischen Übergabe unterbrechen.
- Ein Ziel belegen und später freigeben; Reservierung und wartende Aufträge beobachten.
- Einen Auftrag während der Ausführung abbrechen; Lastort und verbleibende Arbeit abgleichen.
- Ein System neu starten und kontrollieren, ob offene Zustände erhalten bleiben.
- Eine Station ändern und prüfen, welche Daten und Freigaben auf beiden Seiten angepasst werden müssen.
Protokollieren Sie erwartetes Ergebnis, tatsächliche Beobachtung, Softwarestand und verantwortliche Person. Eine Funktion, die erst entwickelt werden soll, wird separat von einer vorgeführten Funktion festgehalten. So entsteht ein belastbarer Vergleich ohne erfundene Testnoten oder pauschale Versprechen.
Quellen & Einordnung
Prüfstand: 18. September 2026. Herstellerinformationen sind Anbieterbeschreibungen. Die redaktionelle Empfehlung ist kein unabhängiger Produkttest.
- SyncroBot: AMR and AGV Fleet ManagementHerstellerangaben zum Start mit einem Roboter, optionaler ERP-/WMS-Anbindung und Verbindungen zu Altsystemen.
- SYNAOS Academy: Frequently asked questionsAuftragsauslöser ohne ERP/WMS und Schnittstellen. Nicht durchgehend versionierte FAQ; aktuellen Lieferumfang bestätigen lassen.
- Idealworks: Noerpel, WMS-Anbindung mit AnyFleetHerstellerbericht zum Projekt aus Juli 2024; bestehendes WMS und Fremdfahrzeuge.
- MiR: MiR Fleet und MiR Fleet EnterpriseREST-API, zentrale Flottensteuerung und editionsabhängige Enterprise-Funktionen.
- InOrbit: Business Execution SystemVerbindung betrieblicher Aufträge aus ERP/WMS mit Robotermissionen.