Das Betriebssystem für physische Arbeit: ein Auftrag zwischen Agent, Roboter und Mensch

21:40 Uhr, Störmeldung aus einer Wohnanlage. Der Eingangsbereich ist verschmutzt, morgen früh ist Besichtigung. Heute passiert Folgendes: Jemand ruft an, jemand notiert, jemand disponiert am nächsten Morgen, und irgendwann fährt ein Auto los.

Mit drei Arten von Arbeitskraft auf einem Auftragsbuch passiert etwas anderes. Ein Agent nimmt die Meldung an, fragt zurück, qualifiziert und legt den Auftrag an. Ein Reinigungsroboter, der ohnehin im Haus steht, fährt die Fläche in der Nacht. Was übrig bleibt, weil eine Schwelle im Weg ist oder nass gewischt werden muss, geht an einen Menschen in der Frühschicht, mit Foto, Ort und Restaufwand.

Nichts davon ist eine Prognose. Jedes der drei Teile existiert einzeln und ist heute beschaffbar. Das IFR World Robotics 2025 zählt für 2024 knapp 200.000 verkaufte professionelle Serviceroboter, ein Plus von 9 Prozent, und eine Robot-as-a-Service-Flotte, die um 31 Prozent gewachsen ist. Es fehlt nicht die Maschine. Es fehlt das Auftragsbuch, das alle drei zusammen führt.

Field-Service-Software modelliert eine Person, ein Fahrzeug und ein Zeitfenster. Sie disponiert, trackt, verwaltet Anlagen und rechnet ab. Y Combinator beschreibt in seiner Request for Startups zu Betriebssystemen für die physische Welt genau das als den Stand der Dinge und weist darauf hin, dass diese Branchen das Zehn- bis Hundertfache ihres Softwarebudgets für Arbeit ausgeben.

Eine Maschine passt in dieses Datenmodell nicht, und die Abweichungen sind nicht kosmetisch.

• Sie hat keine Anfahrtszeit, sondern eine Ladekurve.
• Sie meldet sich nicht krank, sondern geht in einen Fehlerzustand, und beides verlangt völlig verschiedene Reaktionen.
• Sie arbeitet nachts umsonst und steht tagsüber im Weg.
• Und sie kann einen Auftrag zu 70 Prozent erledigen, was für eine Personalplanung ein undefinierter Zustand ist.

Ein KI-Agent bricht das Modell von der anderen Seite auf. Er erzeugt Arbeit schneller, als ein menschlicher Disponent sie prüfen kann, wodurch die Prüfung selbst zum Engpass wird, solange das System nicht bewusst festlegt, welche Entscheidungen ungeprüft durchlaufen und wie das protokolliert wird.

Das interessante Engineering steckt nicht in der Zuteilung. Es steckt darin, was passiert, wenn sich die Zuteilung auf halber Strecke als falsch erweist.

Ein Auftrag, den ein Roboter zur Hälfte erledigt, muss als brauchbares Teilergebnis in der Welt ankommen: was ist erledigt, was nicht, warum nicht, und was muss der Mensch mitbringen, der es zu Ende bringt. Ohne das wird jeder Maschinenausfall zu einem Telefonat, und der Koordinationsaufwand übersteigt still die eingesparte Arbeit. An Koordinationskosten sind mehr Automatisierungsprojekte gestorben als an Technik.

Deshalb wird der Rückfallpfad zuerst spezifiziert und die Autonomie danach. Praktisch heißt das: vor jeder Beschaffung aufschreiben, welche Ausnahme an welche Person geht, mit welchem Nachweis und in welchem Zeitfenster.

Sobald Mensch und Maschine dieselbe Fläche benutzen, ist das keine Betriebsfrage mehr, sondern eine Nachweisfrage.

Fahrerlose Flurförderzeuge und autonome mobile Roboter fallen unter ISO 3691-4, die seit Mai 2024 als harmonisierte Norm im Amtsblatt der EU gelistet ist. Es ist eine Typ-C-Norm, die Personendetektion ist auf Performance Level d nach ISO 13849 auszulegen. Darüber steht die Maschinenverordnung (EU) 2023/1230, veröffentlicht am 29. Juni 2023, geltend ab dem 20. Januar 2027 anstelle der Richtlinie 2006/42/EG; vorher in Verkehr gebrachte Maschinen genießen Bestandsschutz.

Zwei Normen, die man damit nicht verwechseln sollte: ISO 10218 wurde 2025 überarbeitet und betrifft Industrieroboter, ISO 13482 betrifft Roboter mit körperlichem Personenkontakt. Beide werden regelmäßig für Maschinen zitiert, für die sie nicht gelten, und wer das in der Präsentation falsch hat, hat es in der Konformitätsakte nicht richtig.

Für Betreiber ist die praktische Folge enger, als es klingt: Die Frage, wer welche Fläche wann benutzt und wie das dokumentiert ist, wird jetzt beantwortet, zum Zeitpunkt der Beschaffung, und nicht 2027.

Für Flotteninteroperabilität gibt es in diesem Feld genau einen belastbaren Standard. VDA 5050 definiert die Schnittstelle zwischen Leitsteuerung und fahrerlosen Transportfahrzeugen, und nur deshalb lässt sich eine gemischte Flotte aus FTF und AMR überhaupt aus einer Leitsteuerung fahren.

Was der Standard nicht leistet, ist die Vereinheitlichung all dessen, was ein Betreiber tatsächlich braucht. Lokalisierungsgüte, Beladungszustand, Degradation von Teilsystemen und herstellerspezifische Fehlercodes stecken weiterhin in proprietärer Software, und sie in ein einziges brauchbares Alarmmodell zu überführen, ist Integrationsarbeit, je Flotte, jedes Mal. Wer Ihnen erzählt, Flotteninteroperabilität sei gelöst, hat noch nie zwei Fabrikate zusammengeschaltet.

Roboterverfügbarkeit ist die falsche Kennzahl. Ein Gerät kann zu 99 Prozent verfügbar sein und trotzdem nichts erledigen, weil die Tür zu war, der Aufzug belegt oder die Fläche zugestellt. Verfügbarkeit misst den Lieferanten. Sie misst nicht den Betrieb.

Die Kennzahl, die zählt, ist die abgeschlossene Aufgabe je Schicht, unabhängig davon, welche Art von Arbeitskraft sie abgeschlossen hat. Einen Branchenstandard dafür gibt es nicht, und wir behaupten auch nicht, einen zu besitzen. Was möglich ist: je Standort und vor dem ersten Einsatz festschreiben, was als erledigte Aufgabe gilt, damit hinterher über das Ergebnis diskutiert wird und nicht über die Messmethode.

Wer physische Arbeit betreibt, erzeugt die Aufzeichnung, wie diese Arbeit tatsächlich abläuft. Diese Aufzeichnung hat kein Modellanbieter und kein Robotikhersteller. Sie ist der Grund, warum Betreiber in dieser Umstellung strukturell besser dastehen, als es zunächst aussieht.

Bedingungslos gilt das nicht. Sobald Wearables, Kameras oder Ortung Beschäftigte betreffen, ist das in Deutschland mitbestimmungspflichtig: § 87 Absatz 1 Nummer 6 Betriebsverfassungsgesetz erfasst technische Einrichtungen, die dazu geeignet sind, Verhalten oder Leistung zu überwachen, und die Eignung genügt, eine Absicht ist nicht erforderlich. Die DSGVO gilt ohnehin. Wer den Betriebsrat erst nach dem Pilotbetrieb einbezieht, baut den Pilotbetrieb zweimal, und das ist der häufigste vermeidbare Fehler in dieser Kategorie.

Nichts von alldem verlangt eine Plattformentscheidung. Es verlangt eine saubere Aufgabe.

• Eine einzelne wiederkehrende Aufgabe mit definierter Route und definiertem Zeitfenster auswählen.
• Den Rückfallpfad vor der Beschaffung aufschreiben, nicht danach.
• Die erledigte Aufgabe schriftlich definieren, je Standort.
• Die Normfrage bei der Spezifikation klären, nicht bei der Lieferung.
• Mit dem Betriebsrat vor dem Pilotbetrieb sprechen, nicht danach.

Das ist die Reihenfolge, die werob als Integrator fährt: eine Spezifikation aus einer Beschreibung in Klartext, Hardwareauswahl über mehr als 44 Hersteller, Anbindung an die Systeme, die ohnehin laufen, und ein Cockpit, in dem der Einsatz sichtbar ist. Es lohnt sich, präzise zu sein, was das nicht ist. werob verkauft keine autonome Disposition, und es gibt in diesem Markt kein Produkt, das Arbeit ohne Betreiber in der Schleife zwischen Agenten, Robotern und Menschen verteilt. Die Seite zur gemischten Belegschaft führt das Argument vollständig aus, die werob console zeigt das Cockpit als öffentliche Demo.