Warum die Akkulaufzeit in der Beschaffung in die Irre führt

Wenn Sie gerade Angebote für humanoide Roboter vergleichen oder eine Ausschreibung vorbereiten, stolpern Sie fast zwangsläufig zuerst über die Akkulaufzeit. Unitree nennt für den G1 nach Herstellerangaben rund zwei Stunden Batterielaufzeit. Figure gibt für Figure 03 fünf Stunden bei Spitzenleistung an, mit einer 2,3-kWh-Batterie und 2 kW Schnellladeleistung. Apptronik stellte Apollo 2023 mit einem wechselbaren Akku für rund vier Stunden vor. Agility bewirbt für den neuen Digit 5 nur 90 Minuten Laufzeit pro Akku, dafür aber eine Ladezeit von neun Minuten und daraus nach eigener Rechnung mehr als 20 produktive Stunden pro 24-Stunden-Tag. UBTECH wirbt für den Walker S2 mit einem autonomen Batteriewechsel in rund drei Minuten und einem Dauerbetrieb rund um die Uhr.

Für eine Beschaffungsentscheidung ist diese Zahlenreihe fast wertlos, weil die Werte aus unterschiedlichen Lastzuständen, Aufgaben und Testbedingungen stammen und sich nicht gegeneinander aufrechnen lassen. „Fünf Stunden bei Peak Performance“ beschreibt eine Laborbedingung, keinen Schichtbetrieb mit Materialvarianz und Störungen. Ein Roboter kann fünf Stunden eingeschaltet sein und davon nur vierzig Minuten wirtschaftlich verwertbare Arbeit leisten, während ein anderer alle 90 Minuten nachlädt und trotzdem fast die gesamte Schicht produktiv bleibt, weil der Ladevorgang kurz und automatisiert ist.

Der Grund liegt darin, dass Akkulaufzeit eine Energiegröße ist und keine Wirtschaftlichkeitsgröße. Sie beschreibt, wie lange ein Energiespeicher einen Betriebszustand versorgt, nicht, wie viel akzeptierte Arbeit in dieser Zeit entsteht. Für Ihre Entscheidung zählt aber die zweite Größe: wie viele gute Einheiten, Bewegungen oder Prüfungen ein Roboter je geplanter Schichtstunde liefert, und wie viel Mensch, Energie und Geld dafür nötig sind. Deshalb braucht ein seriöser Vergleich einen eigenen Nenner statt einer einzelnen Batteriezahl.

Der Verlust-Trichter von der Kalenderstunde zur produktiven Stunde

Zwischen „Roboter ist vorhanden“ und „gute Arbeit wurde erledigt“ liegen mehrere Verlustebenen, die einzeln benannt werden müssen, sonst verschwinden sie in einer einzigen unscharfen Prozentzahl. Die Fertigungswelt kennt diese Logik seit Langem: Die Normfamilie ISO 22400 trennt für Maschinenkennzahlen Referenzzeit, geplante Zeit, tatsächliche Zeit sowie Qualitäts- und Energiegrößen und beschreibt, wie daraus Kennzahlen entstehen. Sie definiert damit kein humanoidenspezifisches Modell, liefert aber das Grundprinzip: Man beginnt mit einer Referenzzeit und zieht Verluste systematisch ab, statt direkt eine Enderfolgsquote zu behaupten.

Für einen humanoiden Roboter reicht dieses Prinzip allein nicht, weil ein Roboter anders als eine CNC-Maschine oder ein Förderband häufig auf menschliche Unterstützung angewiesen bleibt, sei es als Teleoperation, als manueller Reset oder als seltene Bergung. Genau diese Kontextabhängigkeit betont auch NIST in seinen Arbeiten zur Robotik-Messung: Leistung muss im Zusammenhang von Aufgabe, Umgebung und Systemkonfiguration bewertet werden, nicht als abstrakter Einzelwert. Wir übernehmen deshalb die Stufenlogik der Fertigungswelt und erweitern sie um eine eigene, redaktionelle Zeitkette für Physical AI.

Der entscheidende Bruch liegt zwischen TAH und TRH. Ein Roboter kann technisch einwandfrei laufen und trotzdem keinen Task erledigen, etwa weil er lädt, weil eine Palette fehlt oder weil ein Aufzug belegt ist. Wer nur „Uptime“ meldet, vermischt genau diese beiden Ebenen und lässt offen, ob ein Roboter wirklich arbeitsbereit war oder nur eingeschaltet.

Ein durchgerechnetes Beispiel: von 16 Scheduled Hours zu Cost per PRH

Damit die Kette nicht abstrakt bleibt, rechnen wir sie einmal an einem zusammenhängenden, bewusst hypothetischen Fall durch. Es handelt sich um keine reale Anlage und keine Herstellerangabe, sondern um eine Näherung mit plausiblen, aber frei gewählten Blockgrößen, die zeigen soll, wie die einzelnen Stufen ineinandergreifen. Für eine echte Ausschreibung ersetzen Sie jede Zeile durch die Zahl, die Ihr Pilot tatsächlich liefert.

Ausgangspunkt sind zwei Schichten à acht Stunden, also 16 Scheduled Robot Hours (SRH) pro Tag, in einer Materialhandling-Zelle mit einer vereinbarten Referenzrate von 60 akzeptierten Behälterbewegungen pro Stunde. Technische Störungen wie ein Software-Neustart oder eine Sicherheitsabschaltung kosten an diesem Tag zusammen eine Stunde, sodass 15,0 Technical Available Hours (TAH) übrig bleiben. Laden, ein Batteriewechsel und eine Wartezeit auf Nachschub verbrauchen weitere 2,5 Stunden, wodurch 12,5 Task-Ready Hours (TRH) verbleiben. Nach einer Störung braucht das System zusätzlich eine Stunde, um wieder anzulaufen und die Umgebung neu zu erfassen, sodass sich 11,5 Task-Engaged Hours (TEH) ergeben, in denen der Roboter tatsächlich am Prozess arbeitet.

Bei ungebremster Referenzrate würden 11,5 TEH rechnerisch 690 Bewegungen erlauben. Weil der Roboter im Schnitt etwas langsamer fährt als der Zielwert und ein kleiner Teil der Bewegungen wegen falscher Positionierung nachgearbeitet werden muss, zählen am Ende 552 akzeptierte Bewegungen als Good Units. Daraus folgt: PRH = 552 ÷ 60 = 9,2 produktive Roboterstunden. Die Productive-Hour Yield als PHY = PRH ÷ SRH beträgt damit 9,2 ÷ 16 ≈ 58 Prozent: Von einer geplanten Roboterstunde kommen im Schnitt gut 34 Minuten äquivalente gute Arbeit heraus, der Rest verteilt sich auf Technik, Laden, Wiederanlauf und Tempoverlust.

Nimmt man an, dass an diesem Tag insgesamt 25 Minuten roboterspezifische Unterstützung anfielen, etwa ein manueller Reset und eine kurze Bergung, ergibt sich HSM/PRH = 25 ÷ 9,2 ≈ 2,7 Minuten Support je produktiver Stunde. Rechnet man die Jahreskosten dieser Zelle überschlägig mit 42.000 Euro für Abschreibung, Wartung, Software und den Supportanteil und geht von 250 Betriebstagen im Jahr aus, ergibt sich eine Jahresmenge von 9,2 × 250 = 2.300 PRH und damit Cost per PRH = 42.000 ÷ 2.300 ≈ 18,3 Euro. Auf die Stückebene heruntergebrochen wären das bei 552 × 250 = 138.000 Bewegungen im Jahr rund 0,30 Euro je akzeptierter Bewegung. Jede dieser Annahmen lässt sich in der Praxis ersetzen; entscheidend ist, dass die Kette überhaupt einmal komplett steht, statt an der ersten fehlenden Zahl abzubrechen.

Wie empfindlich das Ergebnis auf einzelne Annahmen reagiert, zeigt eine einfache Gegenprobe: Würde die Referenzrate statt 60 nur 50 Bewegungen pro Stunde betragen, stiege PRH bei gleichem Output auf 552 ÷ 50 ≈ 11,0 Stunden und die Yield auf rund 69 Prozent, obwohl der Roboter keinen einzigen Handgriff anders ausgeführt hätte. Umgekehrt würde eine zusätzliche halbe Stunde Materialwartezeit die Task-Ready Hours auf 12,0 senken und damit tendenziell auch die Good Units, weil weniger Zeit für den eigentlichen Task bliebe. Genau deshalb gehört die Referenzrate vor Pilotbeginn fixiert und jede Verlustursache einzeln dokumentiert, statt sie am Ende der Kette pauschal zu schätzen.

Warum ein einziger Produktivitäts-Score in die Irre führt

Nach diesem Beispiel liegt ein Gedanke nahe: Warum nicht gleich einen einzigen „Humanoid-Produktivitätsindex“ von null bis hundert veröffentlichen? Der Grund, warum wir davon abraten, liegt in der Gewichtung, die ein solcher Score zwangsläufig verstecken müsste. Ist eine zehnsekündige Intervention schlimmer als zehn Minuten Ladezeit? Wiegt ein Prozent Qualitätsverlust genauso schwer wie fünf Prozent Tempoverlust? Die Antwort hängt vollständig vom Prozess ab: In einer Lebensmittelverpackung zählt Hygiene anders als Tempo, in der Kabelmontage zählt Präzision anders als in der Palettenübergabe.

Dazu kommt, dass PRH ausdrücklich nicht über Aufgabenfamilien hinweg vergleichbar ist. Eine produktive Stunde bei der Kabelmontage ist keine gleichwertige Leistung wie eine produktive Stunde beim Behältertransport, weil Referenztempo und wirtschaftlicher Wert je Aufgabe verschieden sind. NIST und ASTM betonen für Roboterleistung genau diese Kontextabhängigkeit: Testumgebung, Taskkonfiguration und Messbedingungen müssen dokumentiert sein, damit Ergebnisse überhaupt interpretierbar werden. Ein einziger Score würde diese Dokumentation ersetzen, statt sie einzufordern, und genau deshalb bleibt unser Modell ein Bündel von Einzelkennzahlen ohne zusammengefassten Sieger.

BMW und Figure in Spartanburg: was die Zahlen zeigen — und was sich in Leipzig ändert

Der bislang öffentlich am besten dokumentierte Fall ist der Einsatz von Figures Humanoid Figure 02 im BMW-Werk Spartanburg. BMW berichtete über den Einsatz mehr als 90.000 bewegte Komponenten, rund 1.250 Betriebsstunden und einen Schichtbetrieb von zehn Stunden Montag bis Freitag, bei dem der Roboter mehr als 30.000 X3-Fahrzeuge unterstützte. Figure ergänzte dazu die eigentliche KPI-Definition des Einsatzes: eine Zykluszeit von 84 Sekunden als Ziel, eine Ladezeit von 37 Sekunden als Zielwert, eine Platzierungsgenauigkeit von über 99 Prozent pro Schicht als Ziel und null menschliche Eingriffe pro Schicht als Zielmarke. Nach eigenen Angaben protokollierte Figure zudem jede Intervention und nutzte die Zeit auch, um die Zuverlässigkeit der Hardware zu verbessern; als wichtigsten Lernpunkt nennt das Unternehmen die Elektronik und Verkabelung im Unterarm.

Diese Kombination aus Task, Laufzeit, Output und Qualitätszielen ist deutlich aussagekräftiger als ein kurzer Demo-Clip, weil sie zumindest die Bausteine zeigt, aus denen eine produktive Roboterstunde bestehen müsste. Trotzdem reicht sie für eine vollständige PRH-Rechnung nicht: Weder die tatsächlich erzielte Intervention Rate noch die Human Support Minutes, die genaue Scheduled-Hour-Basis über den Messzeitraum oder der Energieverbrauch sind veröffentlicht. Die 1.250 Betriebsstunden sind ein solider Nenner für Zuverlässigkeitsaussagen, aber kein vollständiger Produktivitätsnenner, solange diese Größen fehlen.

Ein Punkt gehört zu diesem Fall zwingend dazu, weil er sonst wie eine andauernde Partnerschaft wirkt, die so nicht mehr besteht: BMW selbst ordnet den Spartanburg-Einsatz in seiner Mitteilung zum Werk Leipzig vom 9. März 2026 rückblickend als „2025 pilot project“ über rund zehn Monate ein, also als abgeschlossenen Pilotversuch und nicht als laufenden Regelbetrieb. In derselben Mitteilung kündigt BMW an, im Werk Leipzig stattdessen den humanoiden Roboter AEON von Hexagon zu testen. Für Ihre Einordnung heißt das: Die beeindruckenden Spartanburg-Zahlen sind real und öffentlich belegt, sie beschreiben aber einen befristeten Pilotabschnitt mit einem bestimmten Anbieter, nicht eine fortlaufende BMW-Figure-Kooperation. Wer den Fall in einer eigenen Ausschreibung als Referenz zitiert, sollte diesen Zeitrahmen und den Anbieterwechsel mitnennen.

Agility und GXO: kommerzieller Betrieb, aber ohne sauberen Nenner

Der Logistikdienstleister GXO und Agility Robotics schlossen bereits 2024 einen mehrjährigen Robots-as-a-Service-Vertrag, wodurch Digit dort nicht nur getestet, sondern in einen laufenden kommerziellen Prozess eingebunden wurde. Der Roboter übernimmt unter anderem Totes von fahrerlosen Transportsystemen und setzt sie auf Fördertechnik ab. Agility meldete für diesen und weitere Standorte inzwischen mehr als 100.000 bewegte Totes und rund 98 Prozent Genauigkeit, während der Roboter aktiv am Task war.

Für unseren Zweck fehlt trotzdem die entscheidende Zahl: die Zeitbasis. Ob 100.000 Totes über einen Monat, ein Jahr oder mehrere Standorte gleichzeitig entstanden sind, lässt sich aus der veröffentlichten Meldung nicht sauber ableiten, weshalb sich daraus keine standortspezifische Kennzahl „Totes je produktiver Stunde“ berechnen lässt. Ähnliches gilt für die beim Digit-5-Launch genannten mehr als 65.000 Betriebsstunden der Vorgängergeneration: Es handelt sich um eine Flotten-Summe über mehrere Kundenstandorte, die sich nicht auf den GXO-Standort allein zurückrechnen lässt. Interessant ist dagegen, welche Kennzahlen Agility für seine Flottenplattform Arc selbst führt: Verfügbarkeit, Durchsatz und die mittlere Zeit zwischen Vorfällen. Das sind betriebliche Größen, die deutlich näher am realen Kaufproblem liegen als Höchstgeschwindigkeit oder Batteriekapazität, auch wenn ihnen bislang der Bezug zur produktiven Stunde fehlt.

Siemens und Ford: starke Zahlen aus kurzen Testfenstern

Siemens berichtete für den Humanoiden HMND 01 Alpha am Standort Erlangen von 60 Behälterbewegungen pro Stunde, mehr als acht Stunden Uptime und über 90 Prozent autonomer Erfolgsrate bei Pick-and-Place-Aufgaben unter den dortigen Testbedingungen. Das ist eine ungewöhnlich saubere Kombination aus Durchsatz, Dauer und Qualität für einen frühen Proof of Concept. Offen bleibt auch hier der Human-Support-Anteil: Wie oft und wie lange musste jemand eingreifen, und wie wurde „Uptime“ gegenüber Task-Ready-Zeit genau abgegrenzt?

Beim Ford Innovation Centre in Köln berichtete der Hersteller Humanoid von einer Stunde ununterbrochenem Betrieb mit 97 Prozent Zuverlässigkeit im vollautonomen Pick-and-Place und 83 erledigten Einheiten pro Stunde gegenüber einem Zielwert von 50. Das ist ein starkes Ergebnis für einen Proof of Concept, aber eine Stunde ist keine Schicht. Über acht Stunden treten andere Probleme auf, etwa Wärmeentwicklung, Akkuverhalten, Sensordrift und wachsende Materialvarianz, sodass ein einstündiger Testlauf allein noch nichts über Schichttauglichkeit aussagt. Jede belastbare Kennzahl braucht deshalb eine erkennbare Testdauer, denn 97 Prozent Zuverlässigkeit über eine Stunde und 97 Prozent über eine Woche sind wirtschaftlich zwei verschiedene Aussagen.

Neun Herstellerakten, kein einziger Nenner

Die drei Fälle oben sind Einzelfälle. Die Frage ist, ob das Muster trägt, wenn man einen ganzen Schwung Hersteller nebeneinanderlegt. Wir haben im September 2026 neun Anbieter einzeln durchgearbeitet — Humanoide, Serviceroboter, Exoskelette, einen Datenlieferanten — und dabei jede öffentlich zugängliche Betriebsangabe geprüft. Das Ergebnis ist eindeutig und ernüchternd: Angaben zum Zähler gibt es reichlich, der Nenner fehlt praktisch überall.

Standortzahlen, Bestellzahlen, installierte Basis, Schrittzahlen, Dauerbetriebsversprechen — all das steht auf Produktseiten und in Mitteilungen. Was dort nicht steht, ist die Angabe, aus der sich eine produktive Stunde rechnen ließe: wie viele Stunden ein Gerät eingeplant war, wie viele es davon gearbeitet hat, wie oft ein Mensch eingreifen musste und was die Stunde gekostet hat. Wer eine dieser vier Größen nicht hat, kann Cost per PRH nicht bilden, und keine noch so große Standortzahl ersetzt sie.

Zwei Zeilen der folgenden Übersicht verdienen besondere Aufmerksamkeit, weil sie die beiden Enden des Problems markieren. Richtech nennt für einen benannten Standort zwanzig Minuten Wartung am Tag — das ist die einzige Angabe im ganzen Feld, die den Zähler direkt berührt, und sie stammt aus einem einzelnen Fall. Galbot nennt die größte Betriebsbehauptung überhaupt, hundert Lager im Betrieb rund um die Uhr über mehr als anderthalb Jahre, und veröffentlicht zu Laufzeit, Eingriffen und Kosten je Aufgabe nichts. Die stärkste Zahl und die schwächste Prüfbarkeit liegen hier beim selben Anbieter.

Neun Anbieter, geprüft im September 2026. Die mittlere Spalte führt nur, was öffentlich zugänglich ist; die rechte Spalte nennt, was zur Bildung von Cost per PRH fehlt. Belege stehen jeweils im verlinkten Beitrag.

Für eine Ausschreibung folgt daraus eine einfache Konsequenz: Keine dieser Angaben ist als Wirtschaftlichkeitsnachweis verwendbar, und keine ist deshalb wertlos. Sie taugen zur Vorauswahl — wer hundert Lager betreibt, hat Betriebserfahrung, auch wenn er sie nicht in Stunden ausdrückt. Den Nenner müssen Sie sich aber selbst holen, und zwar bevor Sie unterschreiben. Wie eine solche Klausel aussieht, steht weiter unten.

Vier Akku-Architekturen im Vergleich

Innerhalb des Verlust-Trichters lässt sich Akkulaufzeit endlich dort einordnen, wohin sie gehört: als eine von mehreren Ursachen für Verlustzeit zwischen technischer Verfügbarkeit und Aufgabenbereitschaft, nicht als eigenständige Produktivitätskennzahl. Vier Architekturen zeigen dabei unterschiedliche Strategien, denselben Verlust klein zu halten. An einem gemessenen Fall lässt sich das nachrechnen: Bei der Energiebilanz eines Vierbeiners über eine Marathondistanz stand der Roboter 15 Prozent der Zeit praktisch still und nahm dabei 101,7 Watt auf.

Welche Architektur „gewinnt“, entscheidet sich nicht an der Laufzeitzahl, sondern an den Power Loss Hours je produktiver Stunde bei vertretbaren Batterie- und Infrastrukturkosten. Ein System mit kurzer Laufzeit, aber vollautomatischem Tausch kann in der Praxis weniger Zeit verlieren als ein System mit langer Laufzeit und manuellem Wechsel, weil bei Letzterem jede Unterbrechung eine Person bindet. Für Ihre Bewertung zählt deshalb weniger die Kapazität in kWh als die Frage, wie viele Minuten Ladeverlust pro Schicht tatsächlich anfallen und ob dafür Personal gebraucht wird.

Typische Fehler beim ersten PRH-Bericht

Wer zum ersten Mal einen PRH-Bericht aus einem eigenen Pilotprojekt erstellt, stolpert meist über dieselben vier Fehler. Der erste ist die Vermischung von Flotten- und Standortzahlen: Eine Herstellerangabe wie „mehr als 65.000 Betriebsstunden“ bezieht sich häufig auf mehrere Kundenstandorte gleichzeitig und lässt sich nicht ohne Weiteres auf die eigene Anlage herunterbrechen, selbst wenn der eigene Standort Teil dieser Summe ist.

Der zweite Fehler besteht darin, Wiederanlaufzeiten nach einer Störung stillschweigend aus der Rechnung zu lassen. Ein Roboter, der nach einem Fehler zehn Minuten braucht, um die Umgebung neu zu erfassen, verliert in dieser Zeit produktive Stunden, auch wenn kein Mensch eingreifen musste. Wird diese Zeit nicht als Task-Ready- oder Task-Engaged-Verlust gebucht, wirkt die Anlage produktiver, als sie ist, und der spätere Vergleich mit einem ehrlicher gemessenen Wettbewerber fällt entsprechend schief aus.

Der dritte Fehler ist eine im Nachhinein angepasste Referenzrate. Wenn ein Pilot schlechter läuft als erhofft, sinkt manchmal nachträglich die vereinbarte Zielrate, wodurch dieselbe Leistung plötzlich als Erfolg erscheint, obwohl sich am Roboter nichts geändert hat. Deshalb gehört die Referenzrate schriftlich vor Pilotbeginn fixiert, mit Datum und Unterschrift beider Seiten, nicht als mündliche Verabredung, die sich im Projektverlauf verschiebt.

Der vierte und häufigste Fehler ist, eine einzelne starke Stunde oder Schicht als Beleg für Schichttauglichkeit zu verwenden. Ein einstündiger Testlauf mit 97 Prozent Zuverlässigkeit sagt wenig über eine komplette Acht-Stunden-Schicht mit wechselnder Materialqualität, Werkverkehr und Wärmeentwicklung aus, weil sich viele Fehlerquellen erst über mehrere Stunden zeigen. Für eine belastbare RFP-Entscheidung sollten Sie deshalb mindestens einen vollen Schichttag verlangen, besser eine Woche mit unterschiedlichen Materialchargen, bevor Sie eine Zahl aus einem Pilotbericht ungeprüft in Ihre eigene Kalkulation übernehmen.

Human Support gehört in die Zahl, nicht in eine Fußnote

Ein Roboter kann formal autonom laufen und trotzdem regelmäßig eine Person binden, etwa für Teleoperation, einen manuellen Reset, eine Bergung oder Fehlerdiagnose. Wenn ein Mensch alle 30 Minuten anderthalb Minuten eingreifen muss, ist das wirtschaftlich etwas anderes als ein Eingriff pro Woche, auch wenn beide Systeme dieselbe Task-Erfolgsquote ausweisen. Genau deshalb führen wir Human Support Minutes per Productive Robot Hour (HSM/PRH) als eigene Kennzahl statt als Abzugsfaktor in einem verdeckten Autonomiewert, denn menschliche Unterstützung ist wirtschaftlich eine eigene Ressource mit eigenen Personalkosten.

Dabei zählen nur Minuten, die durch den Roboterbetrieb zusätzlich anfallen, etwa Teleoperation, manueller Reset oder Exception-Handling, nicht die normale Prozessarbeit, die auch ohne Roboter angefallen wäre. Betreut ein Operator mehrere Systeme gleichzeitig, muss dessen Zeit anteilig zugeordnet werden: Verbringt er an einem Tag 80 Minuten tatsächlich mit einem Roboter und 40 Minuten mit einem zweiten, gehört jeweils nur der zurechenbare Anteil in dessen HSM/PRH. Ebenso wichtig ist die Unterscheidung zwischen automatischer und menschlicher Fehlerbehebung: Ein Roboter, der einen Fehler selbst erkennt und neu plant, verliert dabei PRH, weil die Zeit ungenutzt bleibt, erhöht aber nicht die HSM, weil kein Mensch gebraucht wurde. Das ist der Unterschied zwischen einem robusten autonomen System und einem System, das bei jedem Fehler auf Hilfe angewiesen ist.

Für ehrliche Pilotberichte gehört dazu außerdem eine Trennung zwischen der Stabilisierungsphase, in der oft noch Entwickler des Herstellers vor Ort sind, und einer Phase, in der der Roboter nur mit dem später vertraglich vorgesehenen Support arbeitet. Nur die zweite Phase sollte für eine spätere Kosten- und Personalplanung als Referenz dienen, weil sonst ein Engineering-Demonstrator wie ein fertiges Produkt gemessen wird.

Was eine produktive Stunde tatsächlich kostet

Aus PRH lässt sich die wirtschaftliche Kernkennzahl bilden: Cost per Productive Robot Hour, kurz CPRH, als vollständig zurechenbare Jahreskosten geteilt durch die im Jahr erzielten PRH. In diese Kosten gehören mehr als der reine Kaufpreis oder die RaaS-Gebühr: Integrationskosten für Engineering, Schnittstellen und bauliche Anpassung, laufende Betriebskosten für Software, Cloud und Flottenmanagement, Wartung und Ersatzteile sowie der zurechenbare Anteil an Human Support. Erst wenn all das zusammenkommt, entsteht ein belastbarer Euro-je-Stunde-Wert.

Ein Robots-as-a-Service-Vertrag wie im GXO-Fall verwandelt Investitionskosten in laufende Gebühren und senkt damit das Budgetrisiko, ändert aber nichts an der Notwendigkeit, CPRH zu kennen: Eine günstige Monatsgebühr für einen Roboter, der häufig stillsteht, kann teurer pro Arbeitseinheit sein als ein teurerer Vertrag mit hoher Auslastung. Für viele Prozesse ist außerdem eine einfachere Zahl aussagekräftiger als CPRH, nämlich Cost per Good Unit als Gesamtkosten geteilt durch die Zahl akzeptierter Einheiten. Übernimmt ein Roboter mehrere Aufgaben, sollte diese Rechnung pro Aufgabenfamilie getrennt geführt werden, weil eine einzelne „Euro pro Bewegung“-Zahl sonst einen hochwertigen, aber langsamen Task mit einem einfachen, schnellen Task vermischt und das Bild verzerrt.

Die Referenzrate entscheidet über den Business Case

Die PRH-Formel wirkt schlicht: Good Units geteilt durch eine vereinbarte Referenzrate. Genau in dieser Referenzrate lässt sich ein Business Case aber leicht verschieben. Setzt ein Anbieter sie niedrig an, wirkt derselbe Roboter plötzlich außergewöhnlich produktiv; setzt ein Betreiber sie unrealistisch hoch an, wirkt ein technisch solider Roboter schwach. Deshalb sollte die Referenzrate vor dem Pilotbeginn festgelegt und begründet werden, etwa anhand des heutigen menschlichen Prozesses, eines bestehenden Automationssystems, einer vertraglich geforderten Taktzeit oder eines gemeinsam definierten Zielwerts.

Der Mensch muss dabei nicht zwingend der Maßstab bleiben: Ein Roboter darf langsamer arbeiten, wenn er dafür nachts läuft, ergonomische Belastung reduziert oder gleichmäßigere Qualität liefert, solange diese Abweichung offen ausgewiesen wird. Ein Materialhandling-Zyklus lässt sich beispielsweise über eine feste Prozessdefinition statt über die schnellste oder langsamste Person im Werk festlegen, weil Menschen je nach Schicht, Erfahrung und Tagesform unterschiedlich schnell arbeiten und ein Vergleich gegen einen Einzeltag das Bild verzerren würde. Übernimmt ein Roboter mehrere Aufgabenfamilien, braucht jede Familie ihre eigene Referenzrate und damit ihr eigenes PRH-Konto, weil sich sonst der Taskmix unbemerkt zugunsten der leichteren Aufgabe verschieben lässt und ein Test dadurch besser aussieht, ohne dass sich an der eigentlichen Fähigkeit etwas geändert hat.

Was eine Ausschreibung oder ein Pilotvertrag stattdessen verlangen sollte

Für Ihre nächste Anfrage oder Ihren nächsten Pilotvertrag lohnt sich eine andere Fragenreihe als Preis, Traglast, Akku und Freiheitsgrade. Wichtiger sind: Wie viele produktive Roboterstunden garantiert der Anbieter im definierten Workflow, und auf welcher Scheduled-Hour-Basis? Welche Task-Success-Definition und welche Interventionsrate liegen zugrunde? Welche Supportzeit, welche Wartung und welcher Charge Loss sind eingerechnet? Wie wird Uptime von Task-Readiness abgegrenzt, und kann der Betrieb Rohdaten aus dem Flottenmanagement exportieren?

Ein weiterführender Service-Level-Vertrag könnte künftig drei Ebenen getrennt garantieren: die technische Verfügbarkeit als Herstellerverantwortung, die PRH-Ausbeute bei ordnungsgemäß bereitgestelltem Prozess als gemeinsame Verantwortung von Integration und Robotik, und eine Obergrenze für Human Support Minuten je PRH. Damit lässt sich auch klären, wer prozessbedingte Stillstandszeit trägt, etwa wenn kein Material bereitsteht oder ein Aufzug blockiert ist: Ein reiner PRH-Vertrag ohne diese Trennung würde das gesamte Prozessrisiko einseitig dem Robotikanbieter zuschieben. Zur Auswertung selbst hilft ein einfaches Verlustraster, das jede verlorene Minute oder Einheit einer Ursache zuordnet, etwa Robotertechnik, Energie, Infrastruktur, Material, Mensch, Qualität oder Tempo. Ein solches Raster zeigt, wo der größte Hebel liegt, ohne dass jemand dem anderen die Schuld zuweisen muss: Wenn ein Drittel der Verluste auf Materialwartezeit entfällt, hilft kein neues Robotermodell, sondern eine bessere Materialversorgung.

Fazit: Eine Stunde zählt erst, wenn etwas Brauchbares herauskommt

Der Humanoidenmarkt wird sichtbar erwachsener. Figure veröffentlicht Betriebsstunden und Teilezahlen, Agility meldet sechsstellige Tote-Zahlen und Zehntausende Betriebsstunden über die Flotte, Siemens nennt Durchsatz, Dauer und Erfolgsrate gemeinsam, und Ford zeigt belastbare PoC-Werte. Das ist deutlich mehr, als die Branche vor wenigen Jahren offenlegte. Bei der wirtschaftlich wichtigsten Frage bleibt sie aber weiterhin lückenhaft: wie viel akzeptierte Arbeit pro geplanter Stunde entsteht, und wie viel Mensch, Energie und Geld dafür nötig sind.

Deshalb ist Akkulaufzeit fast die falsche Kennzahl: Sie beantwortet eine technische Teilfrage, nicht den Business Case. Wenn Sie das nächste Mal Herstellerangaben zu Betriebszeit oder Verfügbarkeit prüfen, lohnt sich die Frage, die keine Batteriezahl beantwortet: Wie viele produktive Roboterstunden entstehen pro Schicht, wie viele menschliche Minuten braucht jede davon, und was kostet eine davon vollständig? Sobald diese drei Zahlen auf dem Tisch liegen, vergleichen Sie keine Demos und keine Batterien mehr, sondern tatsächlich geleistete Arbeit — und genau dort beginnt Robotik als planbares Betriebsmittel.