Was ein Pilotprojekt beweist – und was nicht

Die meisten Robotik-Pilotprojekte liefern keinen tragfähigen Business Case, weil Betreiber die Maschinenleistung bewerten, ohne vorher einen empirischen Bezugswert erhoben zu haben. Wenn ein Reinigungs- oder Transportroboter eintrifft, vergleicht die Leitung die tägliche Aufgabenerfüllung typischerweise mit einer groben Schätzung des manuellen Aufwands statt mit echten Betriebsdaten. Ohne eine saubere Erhebung vor dem Pilotbetrieb, die festhält, wie viele Minuten das Personal tatsächlich für einen Ablauf aufwendet, bleibt jede spätere Aussage zur Entlastung in der Geschäftsleitung oder gegenüber dem Betriebsrat unbelegbar.

Marketingangaben von Herstellern und Vertriebspartnern verstärken diese Unschärfe. Der deutsche Robotikanbieter RoboPlanet etwa veröffentlicht ein Praxisbeispiel für die Hotellerie mit einer jährlichen Entlastung von rund 1.250 bis 1.550 Stunden durch eine Kombination aus Reinigungs- und Serviceroboter^[1]. Solche Werte mögen für das Objekt, aus dem sie stammen, zutreffen. Die veröffentlichte Angabe lässt jedoch entscheidende Größen offen: Flächengröße, Auslastung, Personalbesetzung, Stundensätze und die genaue Methode, mit der die verlagerten Stunden erfasst wurden. Eine allgemeine Vergleichszahl kann die Entlastung in Ihrem Haus nicht vorhersagen, weil sie streng von Grundriss, Schichtplanung und der bisherigen Aufgabenverteilung abhängt.

Einen empirischen Bezugswert über zwei Wochen aufbauen

Bevor ein Testgerät ausgepackt wird, sollten Betriebsleitung und Objektverantwortliche die manuellen Abläufe über mindestens vierzehn Tage mit standardisierten Strichlisten erfassen. Diese Messung bildet den normalen Betriebsrhythmus, die Schichtübergaben und die üblichen Unterbrechungen an starken wie an ruhigen Tagen ab.

• Schicht und Rolle: Halten Sie fest, welche Funktionen und welche Entgeltgruppen die Zielaufgabe heute ausführen.
• Häufigkeit und Dauer: Erfassen Sie die genaue Zahl der täglichen Gänge mit Startzeiten, Wegezeiten und erledigten Quadratmetern oder Auslieferungen.
• Unterbrechungen: Dokumentieren Sie, wie oft das Personal die Aufgabe abbricht, um auf Klingelrufe zu reagieren, Gästen zu helfen oder Hindernisse im Flur zu räumen.
• Verwendung der gewonnenen Zeit: Benennen Sie die konkreten Tätigkeiten, die das Personal übernimmt, wenn die manuelle Routine entfällt, damit die gewonnenen Minuten messbar ankommen.

Ohne diese vorher erhobenen Daten lässt sich die tatsächliche Netto-Entlastung nicht berechnen. Ein Pilotprojekt, das sechzig abgeschlossene Fahrten pro Woche meldet, belegt nur, dass die Maschine gelaufen ist – nicht, dass das Haus geplante Arbeitsstunden zurückgewonnen hat.

Der wichtigste verzerrende Faktor in den meisten Pilotprojekten ist die Anwesenheit von Applikationstechnikerinnen und -technikern des Anbieters. In der Anfangsphase begleiten sie die Maschine häufig, räumen blockierte Wege frei, justieren Kartierungsparameter und starten hängende Steuerungen neu, bevor das Personal den Stillstand überhaupt bemerkt. So entsteht eine künstliche Betriebsumgebung, die den realen Betreuungsaufwand verdeckt.

Um die betriebliche Tragfähigkeit zu beurteilen, müssen Betreiber die mittlere Wiederherstellungszeit erfassen und festhalten, wer jeden Eingriff vorgenommen hat. Für die Wirtschaftlichkeit zählt nicht allein, wie oft ein Roboter stehen bleibt, sondern wie lange er steht und wessen Schicht dafür unterbrochen wird. In der Krankenhauslogistik und in der Pflege ist jede Minute, die eine Pflegekraft mit dem Flottmachen eines Transportroboters verbringt, eine Minute weniger für die Bewohnerinnen und Bewohner.

Den betrieblichen Preis von Eingriffen beziffern

Trifft ein Serviceroboter auf ein unerwartetes Hindernis, einen abgerissenen WLAN-Kontakt oder eine unpassende Aufzugsschwelle, geht er in den Sicherheitshalt. Fehlt ein geregelter Eskalationsweg, bleibt die Diagnose an der Person hängen, die gerade in der Nähe ist. Häufigkeit, Ursache und die auflösende Person zu protokollieren macht die verdeckte Reibung der Automatisierung sichtbar.

Wenn das Auflösen von Störungen pro Schicht fünfzehn Minuten aus Pflege oder Hauswirtschaft bindet, muss diese Zeit von der Brutto-Entlastung abgezogen werden. Bleiben wiederkehrende Kleineingriffe unprotokolliert, lösen sie die wirtschaftliche Begründung des Einsatzes still auf.

Robotik-Pilotprojekte werden fast durchgängig auf Werktage zwischen 09:00 und 17:00 Uhr gelegt. Diese Zeiten bieten optimale Bedingungen: gleichmäßige Beleuchtung, stabile Temperaturen, erreichbare Verwaltung und Technikteams des Anbieters in Bereitschaft. Genau in diesen Stunden wird Automatisierung jedoch am wenigsten gebraucht.

Nacht- und Wochenendschichten sind physisch und organisatorisch eine andere Umgebung. Maschinelle Reinigung und schwerer Wäschetransport sind zwischen 22:00 und 06:00 Uhr am wertvollsten, wenn öffentliche Bereiche frei von Gästen oder Bewohnerinnen sind. Diese Stunden bringen jedoch Bedingungen mit sich, die die Sensorik fordern: gedimmte Sicherheitsbeleuchtung, bewegungsgesteuerte Lichtzonen und Brandschutztüren, die nachts anders verriegelt sind.

Andere Bedingungen außerhalb der Kernzeiten

Die Besetzung ändert sich außerhalb der Kernzeiten deutlich. Pflege und Hotellerie arbeiten mit schlanken Teams, oft mit Aushilfen oder springenden Leitungen, die keine formale Einweisung in die Robotik erhalten haben und die Bedien-App nicht auf dem Gerät haben.

• Sensorik bei wenig Licht: Optische Kameras und Tiefensensoren verlieren in gedimmten Nachtfluren an Genauigkeit, die Lokalisierungsdrift nimmt zu.
• Physische Hindernisse im Flur: Reinigungswagen, Bodenmaschinen und Leitern stehen nachts regelmäßig im Gang und blockieren die programmierte Route.
• Zutrittsbeschränkungen: Türen und Aufzüge schalten nachts in eingeschränkte Betriebsarten, was eine Ausweisemulation oder eine potentialfreie Anbindung erfordert.
• Fehlende Berechtigungen: Wochenend- und Aushilfskräfte haben oft keinen Zugang zum Portal, um Softwaremeldungen zu quittieren, sodass eine Einheit bis Montag stehen bleibt.

Ein Pilotprojekt, das ausschließlich bei Tageslicht läuft, prüft die Belastbarkeit nicht. Wenn ein Roboter einen schwach beleuchteten Flur nicht bewältigt oder eine nächtlich verriegelte Tür ohne menschlichen Eingriff nicht passiert, kann er genau die Schichten nicht automatisieren, in denen der Personalmangel am größten ist.

Objektverantwortliche legen Robotik-Erprobungen häufig in belegungsschwache Zeiten, um den Betrieb möglichst wenig zu stören. Ein Test im leeren Flur belegt zwar, dass eine Einheit einer kartierten Bahn folgen kann, liefert aber keinerlei Nachweis, dass sie in einer dynamischen Betriebsumgebung funktioniert. Eine Pilotphase muss bewusst in der stärksten Auslastung geprüft werden.

Jedes Objekt hat vorhersehbare Verkehrsspitzen: Besuchszeiten im Pflegeheim, die gleichzeitigen Wellen um 11:00 Uhr beim Check-out und 15:00 Uhr beim Check-in im Hotel, Anlieferfenster an der Laderampe und die turnusmäßige Brandmeldeanlagenprüfung. In diesen Zeiten wird aus einem statischen Flur eine dichte Umgebung mit bewegten Personen, Gepäckwagen und unvorhersehbaren Wegkreuzungen.

Ausweichverhalten unter Andrang bewerten

Bei starkem Andrang muss ein autonomer mobiler Roboter seine lokale Bahn schnell neu berechnen, ohne den Flur zu verstopfen. Schlecht abgestimmte Ausweichalgorithmen erstarren entweder, sobald sich Menschen um sie herum bewegen, oder weichen so aus, dass schmale Durchgänge blockiert werden. Die Pilotphase muss zeigen, ob die Maschine ihren Zeitplan hält, ohne eine Gefährdung zu erzeugen.

Weicht ein Roboter regelmäßig so lange aus, bis sein Sicherheitszeitgeber abläuft, bricht er Aufträge genau in den Stunden ab, in denen der Transport dringend ist. Belastbarkeit ist erst belegt, wenn die Maschine auch in der Spitze einen gleichmäßigen Durchsatz hält.

Zu zeigen, dass ein Roboter einen Flur reinigen oder Mahlzeiten über einen Stationsflügel transportieren kann, belegt mechanische Funktion, nicht Skalierbarkeit. Eine systematische Übersichtsarbeit über 80 Studien zu autonomen mobilen Robotern im Facility Management benennt fünf wiederkehrende Hürden für die Einführung: unterschiedliche betriebliche Kontexte, ungünstig geplante Innenräume, wechselnde Gebäudenutzende, vielfältige Funktionen des Facility Managements und Unterschiede in der Gebäudehülle^[2]. Der Schritt von einer Etage auf mehrere Geschosse erhöht die Komplexität bei Netz, Türtechnik und vertikalem Transport überproportional.

Die Aufzugsanbindung ist in mehrgeschossigen Objekten der häufigste Schwachpunkt. Ein einzelner Pilotroboter, der den Aufzug über eine einfache Relaisschnittstelle ruft, stört den Gebäudeverkehr kaum. Konkurrieren jedoch mehrere Transport- und Reinigungseinheiten mit den Nutzenden um den vertikalen Transport, werden gemeinsam genutzte Aufzugsgruppen schnell zum harten Engpass.

Gebäudeschnittstellen, die die Flottenleistung bestimmen

Die Ausweitung über mehrere Etagen verlangt Gebäudeschnittstellen zu klären, die bei einem isolierten Test auf einer Etage gar nicht auftreten. Die Access Points müssen schnelles Roaming unterstützen, damit keine Steuerbefehle verloren gehen, während Einheiten Brandabschnitte durchfahren oder in metallische Aufzugsschächte einfahren.

Beim Ausrollen über ein ganzes Objekt verschiebt sich die Aufgabe von der Navigation hin zur Koordination der Gebäudesysteme. Ohne herstellerunabhängige Integrationsebene führen zusätzliche Einheiten zu Netzkonflikten, Aufzugsblockaden und zersplitterten Wartungsabläufen.

Ein dreißigtägiger Test vor Ort ist ein wirksames Mittel, um Navigation und die Passung zum Arbeitsablauf zu prüfen. Entscheiderinnen und Entscheider müssen jedoch die Grenzen kennen. Bestimmte langfristige kaufmännische, betriebliche und architektonische Risiken lassen sich innerhalb einer kurzen Geräteerprobung nicht bewerten, wie gründlich der Test auch angelegt ist.

Ein Pilotprojekt gibt keinen Einblick in die Bestandsfestigkeit des Lieferanten, die Durchsetzbarkeit von Garantien oder die langfristige Ersatzteilversorgung. Der Markt für Servicerobotik erlebt häufige Umstrukturierungen und Konsolidierung. Wenn ein Hersteller im dritten Jahr eines fünfjährigen Vertrags den Betrieb einstellt, schützen die Daten aus dem Pilotbetrieb nicht vor veralteter Firmware oder nicht mehr lieferbaren Antriebsmotoren.

Mehrere Einheiten und Softwarezyklen

Ein einzelner Roboter in einer abgegrenzten Zone kann nicht zeigen, wie mehrere Einheiten verschiedener Hersteller die gemeinsame Infrastruktur aushandeln. Ein Reinigungsroboter von Anbieter A und ein Room-Service-Roboter von Anbieter B haben kein gemeinsames Protokoll, um im schmalen Flur die Vorfahrt zu klären oder gleichzeitige Aufzugsanforderungen aufzulösen.

• Bestandsfestigkeit des Anbieters: Kurze Tests belegen nicht, ob ein Hersteller über eine Nutzungsdauer von vier bis sechs Jahren Ersatzteile, lokalen Service und Gewährleistung aufrechterhält.
• Stabilität von Firmware und Schnittstellen: Software-Updates können Sensorschwellen verändern oder Anbindungen brechen und verlangen wiederkehrende Regressionstests über größere Versionssprünge.
• Flottenkoordination über Hersteller hinweg: Einzelne Testgeräte laufen isoliert und prüfen weder die Verkehrssteuerung einer Flotte noch die Disposition über die Gebäudeleittechnik.
• Verschleiß und Batteriealterung: Ein Test über einen Monat misst weder den Kapazitätsverlust der Akkus noch den Abrieb der Antriebsräder unter Reinigungschemie oder die Ermüdung der Aktoren.

Diese strukturellen Risiken lassen sich nicht dadurch lösen, dass ein Pilotprojekt um zwei Wochen verlängert wird. Sie gehören über belastbare Beschaffungsverträge, eine herstellerunabhängige Architektur und verbindliche Service-Level-Vereinbarungen abgesichert.

Damit ein Robotik-Pilotprojekt eine belastbare Investitionsentscheidung liefert und keine unklare Vorführung bleibt, müssen Betreiber klare Testgrenzen und quantitative Abbruch- und Freigabekriterien festlegen, bevor das Gerät eintrifft.

• Ein definierter Ablauf: Beschränken Sie die Erprobung auf eine konkrete, messbare Aufgabe, etwa die nächtliche Lobbyreinigung oder den Tabletttransport von der Küche auf die Station, statt einen vagen Mehrzwecknutzen zu testen.
• Benannte operative Verantwortung: Beauftragen Sie eine bestimmte Schicht- oder Objektleitung damit, die Erprobung zu führen, Vorfälle zu protokollieren und die technische Abstimmung zu halten.
• Empirischer Bezugswert vorab: Erheben Sie verbindlich über vierzehn Tage die manuelle Aufgabe nach Häufigkeit, Dauer und Personalkosten, bevor Hardware eingesetzt wird.
• Spitzenzeiten verpflichtend einbeziehen: Der Testzeitraum muss die geplanten Verkehrsspitzen, Besuchszeiten und Anlieferfenster abdecken.
• Nacht- und Wochenendbetrieb: Legen Sie mindestens 30 Prozent des Testplans auf unbegleitete Nacht- und Wochenendschichten.
• Einheitliches Eingriffsprotokoll: Dokumentieren Sie jeden physischen und softwareseitigen Eingriff mit Dauer, Ursache und auflösender Person.
• Schriftliche Freigabekriterien: Legen Sie feste Zahlenwerte für Auftragserfüllung, maximal zulässige Wiederherstellungszeit und minimale wöchentliche Entlastung fest, bevor der Test startet.

Vom geprüften Pilotprojekt in den Flottenbetrieb

Bestätigt eine strukturierte Erprobung den betrieblichen Nutzen und eine positive Entlastung, verlangt der Schritt zum vollständigen Rollout den Wechsel von isolierter Hardware zu einer einheitlichen Betriebsinfrastruktur. Flotten aus mehreren Einheiten über mehrere Objekte zu betreiben heißt, Disposition, Gebäudeschnittstellen und Monitoring in einem gemeinsamen Betriebsmodell zusammenzuführen.

Genau an diesem Übergang wird professionelle Systemintegration wesentlich. Als spezialisierter Systemintegrator liefert werob die Integrationsarchitektur, um Flotten ohne Herstellerbindung zu skalieren. Über die werob Platform binden Betreiber unterschiedliche Hardware mit vorgefertigten Connectors an bestehende Unternehmenssoftware an – an Property-Management-Systeme, Pflege- und Klinikdokumentation sowie Lagerverwaltungssysteme –, während Cockpit die einheitliche Überwachung aller eingesetzten Einheiten übernimmt.

Wer Anbietervorführungen durch strukturierte Bezugswerte, konsequente Eingriffsprotokolle und eine Integrationsebene ersetzt, macht aus einem Robotik-Pilotprojekt eine klare, mit Daten belegte Entscheidung.