Fallstudie: Maximierung der Flottenauslastung in 3 Regionen

Ein Industriegeräte-OEM betrieb Assets über drei Regionen und konnte nicht mit Sicherheit sagen, wie stark eines davon ausgelastet war. Telemetrie war bereits ausgerollt. Das Problem lag darin, was sie lieferte: Zahlen, denen niemand traute. Jede Region definierte „in Nutzung" und „im Leerlauf" etwas anders, sodass eine Auslastungszahl aus einem Depot im nächsten etwas anderes bedeutete.

Darunter lag durchgängig eine geschlossene Plattform. Die Rohdaten blieben hinter der API des Anbieters, jeder neue Alarm und jeder neue Report wurde zum Change Request, und jeder Change Request hatte einen Preis und einen Platz in der Roadmap des Anbieters, nicht in der des OEM. Eine Schwellenanpassung, die einen Nachmittag dauern sollte, dauerte ein Quartal. Lizenz- und Feature-Gebühren stiegen weiter, während die tatsächliche Funktionalität stehen blieb.

Im Betrieb war es noch unübersichtlicher. Die Konnektivität schwankte von Standort zu Standort, von stabilem 4G an einem Service-Hub bis zu lückenhafter Abdeckung an abgelegenen Einsatzorten. Verschiedene Subunternehmer betrieben verschiedene Regionen nach verschiedenen Konventionen. Das Ergebnis war ein Nutzungsreporting, das keine echte Entscheidung darüber tragen konnte, wohin eine Maschine geschickt oder wann sie gewartet werden sollte.

Der Auftrag war konkret. Der Umstieg auf ein offenes Embedded-Linux-Gateway, das dem OEM vollständig gehört: Quellcode, Build-Images und die Daten, die diese Gateways erzeugen, ohne eine Schicht hinter einer Anbieter-API.

Eine einzige Definition von Auslastung musste über alle drei Regionen gelten. Wenn ein KPI an jedem Depot dasselbe bedeutete, endete der Streit zwischen den Regionen und Entscheidungen zur Asset-Allokation konnten darauf aufbauen. Wartungssignale und Alarmschwellen mussten vom eigenen Team des OEM editierbar sein, in Tagen, nicht als kostenpflichtige Anfrage gegen den Release-Plan eines Dritten.

Und es musste reibungslos skalieren. Wiederholbare Provisionierung, vorhersagbare Datenpipelines und eine Onboarding-Abfolge, die ein Techniker am nächsten Depot ohne Melqart-Ingenieur vor Ort durchführen kann.

Melqart Systems lieferte einen offenen Embedded-Linux-Gateway-Stack, dessen Codebasis beim OEM liegt. Das Team hatte vollen Zugriff auf die Edge-Software: lesen, ändern, Image neu bauen, per OTA ausrollen. Nichts an der Feldebene erforderte einen Anruf beim Anbieter.

Die Gateways sprachen die Protokolle, die die Flotte tatsächlich nutzte. CAN-Bus (J1939) vom Antriebsstrang und den Motorsteuergeräten, digitale und analoge I/O für Schalter, Füllstände und Sensorleitungen, die nie auf den Bus gelangten, sowie externe Sensoren, die dort verdrahtet wurden, wo ein Signal fehlte. Eine gemischte Flotte aus mobilen Geräten, Begleitfahrzeugen und Spezialmaschinen kam auf eine einzige Erfassungsschicht. Jedes Gateway pufferte lokal und übertrug nach der Wiederverbindung, sodass eine Abdeckungslücke die Daten verzögerte, statt sie zu verlieren.

Ein einziges Telemetrieschema lag über der gesamten Flotte. Feldnamen, Einheiten und die Formeln hinter jedem KPI wurden einmal definiert und gehörten dem OEM. Diese Definitionen waren versioniert: Änderte sich „Motorstunden" oder „Leerlauf", war die Änderung explizit und datiert, statt unbemerkt zwischen den Regionen abzudriften. Genau dieser eine Vertrag machte eine Zahl aus einem Depot mit einer Zahl aus einem anderen vergleichbar.

Darüber lag eine einzige Betriebssicht für Disposition und Wartung: Live-Asset-Status, Auslastungs-KPIs, Leerlauferkennung und Ausnahmealarme, die nur auslösten, wenn ein Mensch gebraucht wurde. Wöchentliche und monatliche Aggregate exportierten direkt, ohne Tabellenkalkulation von Hand.

Die Disposition spürte es zuerst. Ein einziger Bildschirm zeigte nun jedes Asset als verfügbar, in Nutzung oder im Leerlauf, gezogen aus überall denselben Definitionen. Der Dauerstreit darüber, wessen Zahlen stimmten, hörte schlicht auf, und eine Entscheidung, die früher eine Runde Telefonate brauchte, brauchte nun einen Blick.

Weil die Zahlen regionsübergreifend hielten, wanderten Maschinen dorthin, wo sie ihr Geld verdienten. Ein Asset, das in einer Region im Leerlauf stand, während eine andere für dasselbe Gerät Miete zahlte, wurde früh erkannt, und diese Überschneidung verschwand. Die Wartung gewann etwas, das sie unter der geschlossenen Plattform nie hatte: Sie konnte eine Alarmschwelle selbst nachjustieren, direkt im Gateway-Stack, am selben Tag, an dem sich ein Muster im Feld zeigte. Kein Ticket, kein Warten auf ein Anbieter-Release. Die Wartung richtete sich danach, wie die Maschinen tatsächlich genutzt wurden, ungeplante Ausfallzeiten sanken und die Verfügbarkeit stieg.

Die Umsetzung lief in drei Phasen, am Anfang bewusst klein. Wochen eins bis drei waren ein Pilot: ein repräsentativer Ausschnitt von Assets über alle drei Regionen, instrumentiert, um eine Baseline zu erfassen. Echte Auslastung, echte Ausfallzeitmuster, echte Dispositionsverzögerungen, die Zahlen, die später sagen würden, ob sich etwas verbessert hatte.

Wochen vier bis acht skalierten den Rollout Depot für Depot und Region für Region, jede Installation nach denselben Provisionierungsschritten, sodass das zehnte Gateway lief wie das erste. Rollenbasierte Dashboards kamen in diesem Fenster hinzu, eines für Disposition, eines für Operations, eines für Wartung, jedes mit den Daten, auf die diese Rolle reagiert, und kaum mehr.

In den Wochen neun bis zwölf ging es um Signalqualität. Schwellen wurden justiert, um Alarmrauschen zu senken, die wöchentlichen KPI-Reports in eine Vorlage gegossen und die Workflows auf Ausnahme-zuerst umgestellt: Das System blieb still, bis wirklich etwas Aufmerksamkeit brauchte, dann eskalierte es. Weniger zu beobachten, nichts Wichtiges verpasst.

Nach dem vollständigen Rollout und der Optimierungsphase meldete der Kunde eine Steigerung der Asset-Auslastung um rund 25 %. Sie kam aus weniger Leerlaufmaschinen, schnelleren Allokationsentscheidungen und Anmietungen, die nicht länger Assets ersetzten, die andernorts ohnehin ungenutzt standen. Eine vertrauenswürdige, gemeinsame Definition von Auslastung leistete die Arbeit.

Die Disposition wurde straffer. Mit einer abgestimmten Sicht auf den Asset-Status fiel das Hin und Her weg, und Assets bewegten sich schneller über die Depots, mit weniger Unklarheit darüber, was tatsächlich verfügbar war.

Die Anbieterabhängigkeit sank deutlich. Alarm- und KPI-Änderungen, die früher ein Quartal warteten, gingen nun in Tagen live, weil der OEM sie selbst vornahm. Feature-Change-Gebühren und die laufende Lizenzposition fielen weg, und der Telematik-Stack bewegte sich auf der Roadmap des OEM statt auf der eines Dritten. Die klarste Lehre: Der Gewinn kam aus besseren Signalen und einer gemeinsamen operativen Wahrheit, nicht aus mehr gesammelten Daten.

Das Eigentum am Gateway-IP trug das Projekt. Mit voller Kontrolle über den Edge-Stack konnte der OEM ihn nach eigenem Zeitplan ändern, und genau das machte aus dem Quartalswarten eine Korrektur am selben Tag.

Das einheitliche Telemetrieschema leistete die stille, strukturelle Arbeit. Ein Satz Definitionen über die Flotte hinweg bedeutete, dass keine zwei Dashboards widersprachen und keine zwei Regionen über einen KPI stritten.

Ausnahme-zuerst-Workflows hielten das System tragfähig. Niemand musste ein Dashboard bewachen; das System forderte Aufmerksamkeit nur, wenn sie berechtigt war, und genau das lässt eine solche Lösung über den ersten Monat hinaus bestehen.

Konnektivitätsresistentes Design hielt das Vertrauen zusammen. Lokale Pufferung und Store-and-Forward-Transport bedeuteten, dass eine Abdeckungslücke die Daten verzögerte, statt sie zu verlieren, und ein Telematiksystem, das stillschweigend Messwerte fallen lässt, glauben die Anwender bald nicht mehr.

Messen Sie, bevor Sie etwas ändern. Ohne eine im Piloten erfasste Baseline wären die 25 % eine Behauptung gewesen, kein Ergebnis. Die frühen Zahlen des Piloten erlaubten dem Team, die Veränderung zu beweisen, statt sie zu behaupten.

Das Eigentum an der Edge kauft Geschwindigkeit. Weil der OEM den Stack besaß, landeten Änderungen in Tagen, statt auf ein Anbieter-Release zu warten, ein Unterschied, den keine proprietäre Plattform bot.

KPIs zählen nur, wenn sie zur Arbeitsweise der Menschen passen. Metriken, die den Dispositionsablauf spiegelten, wurden täglich genutzt; Metriken, die das nicht taten, wurden stillschweigend ignoriert, ganz gleich, wie ihr Dashboard aussah. Passen Sie die Telemetrie an den Prozess an, dann rechnet sich die Investition.

Für jeden OEM, der Assets über mehrere Standorte betreibt, wiederholt sich das Muster. Beginnen Sie mit einem offenen Gateway-Stack, der Ihnen gehört, das klärt die IP-Frage und beendet das Lock-in, bevor es entsteht.

Definieren Sie das Telemetrieschema einmal, sodass eine Zahl in jeder Region dasselbe bedeutet und nichts mehr strittig bleibt. Bauen Sie die Dashboards dann um den Dispositionsablauf herum, nicht um die Daten, damit die Telemetrie Entscheidungen treibt, statt ungelesen zu bleiben.

Halten Sie die Alarmierung ausnahmebasiert. Aufmerksamkeit geht dorthin, wo Handlung nötig ist, nicht auf eine Wand grüner Kacheln, und genau das hält ein Flotten-Telematiksystem lange nach dem Start nützlich, solange es echte Arbeit an Auslastung und Verfügbarkeit leistet.