Es war ein Donnerstagnachmittag im Herbst, als mir der Disponent eines mittelstaendischen Speditionsunternehmens am Telefon sagte: „Herr Buschick, wir haben ein Problem, das sich dumm anhoert, aber uns jeden Tag Geld kostet.“ Er beschrieb dann etwas, das in der Logistikbranche so alltaeglich ist, dass es die meisten Unternehmen gar nicht mehr als Problem wahrnehmen: Die Disposition wusste nicht, wann ihre eigenen LKWs an den Laderampen ankommen.
Das klingt absurd. Da hat ein Unternehmen Millionen in eine Flotte investiert, nutzt Daimler Fleetboard als Telematiksystem, kann auf dem Bildschirm sehen, wo jeder LKW gerade steht — und trotzdem ruft der Disponent den Fahrer an, um zu fragen, ob er in zwanzig Minuten da ist. Drei, vier, manchmal fuenf Mal am Tag. Pro Disponent.
Dieses Projekt ist ein gutes Beispiel dafuer, dass Automatisierung nicht immer glamouroes sein muss. Keine kuenstliche Intelligenz, kein Machine Learning, kein Cloud-Native-Stack. Sondern ein Script, das eine Webseite ausliest. Und trotzdem hat es den Alltag der Disposition grundlegend veraendert.
Das Unternehmen betreibt eine Flotte von rund 40 Fahrzeugen im nationalen Stueckgutverkehr. Die Touren fuehren ueberwiegend zu festen Kunden mit definierten Zeitfenstern an den Laderampen. Ein typischer Tag sieht so aus: Morgens um sechs gehen die ersten LKWs raus, zwischen acht und elf treffen die meisten an ihren Zielen ein, nachmittags folgt die Ruecktour.
Fleetboard ist das Telematiksystem von Daimler, das in den Fahrzeugen verbaut ist. Es erfasst Fahrzeugposition, Geschwindigkeit, Kraftstoffverbrauch und eine Reihe weiterer Parameter. Die Daten laufen auf einer Web-Applikation zusammen, die der Disponent im Browser bedient. Er kann sehen, wo jedes Fahrzeug steht, welche Route es faehrt und wann es voraussichtlich am Ziel ankommt — die sogenannte ETA, Estimated Time of Arrival.
Soweit die Theorie. In der Praxis sah es anders aus.
Die Disponenten hatten Fleetboard zwar auf dem Bildschirm, aber sie konnten nicht acht Stunden am Tag auf eine Karte starren und warten, bis sich ein Fahrzeug einem Ziel naeherte. Sie hatten nebenbei Auftraege zu disponieren, Kunden zu informieren und Aenderungen einzuarbeiten. Die Fleetboard-Oberflaeche bietet keine aktive Benachrichtigung — kein Pop-up, keine E-Mail, keine Push-Nachricht, wenn ein Fahrzeug in die Naehe einer Laderampe kommt. Alles Pull, kein Push.
Das Ergebnis: Telefonate. Viele Telefonate. Der Disponent rief den Fahrer an: „Wo bist du? Wie lange noch?“ Der Fahrer antwortete, oft genervt, weil er gerade auf der Autobahn war und das Telefon erst suchen musste. Dann rief der Disponent den Kunden an: „Der LKW kommt in circa dreissig Minuten.“ Und wenn sich etwas aenderte — Stau, Umleitung, Pause — ging das Spiel von vorne los.
Die naheliegende Loesung waere gewesen: Fleetboard-API anbinden, Positionsdaten automatisch abfragen, mit den Soll-Zeiten vergleichen und bei Annaeherung eine Benachrichtigung ausloesen. Das ist technisch sauber, skalierbar und wartungsarm.
Nur gibt es da ein Problem: Fleetboard hat fuer Drittanbieter keine offene API. Jedenfalls nicht in der Form, die man braeuchte. Es gibt eine Schnittstelle fuer ausgewaehlte Partnerfirmen, die einen aufwendigen Zertifizierungsprozess durchlaufen haben. Fuer ein mittelstaendisches Speditionsunternehmen, das einen einzelnen Automatisierungsbaustein braucht, ist das keine Option. Die Zertifizierung dauert Monate, kostet fuenfstellig und erfordert eine dedizierte Server-Infrastruktur.
Wir haben das geprueft. Gruendlich. Es gab zum Zeitpunkt des Projekts drei Wege, an die Fleetboard-Daten heranzukommen:
Weg drei war der einzig gangbare. Und damit war klar: Das wird ein RPA-Projekt. Robotic Process Automation. Ein Script, das tut, was der Disponent tun wuerde — nur automatisch und rund um die Uhr.
Wir entschieden uns fuer Microsoft Power Automate Desktop. Das war keine ideologische Entscheidung, sondern eine pragmatische. Das Speditionsunternehmen hatte bereits Microsoft 365 im Einsatz, Power Automate Desktop war in der Lizenz enthalten, und es laeuft auf dem Windows Server, der ohnehin im Unternehmen stand.
Der Plan war einfach: Ein Script, das alle 15 Minuten die Fleetboard-Webapplikation oeffnet, die aktuellen Fahrzeugpositionen ausliest, sie mit den geplanten Ankunftszeiten vergleicht und bei Unterschreitung eines definierten Umkreises eine Benachrichtigung an die Disposition schickt.
Einfach in der Idee. In der Umsetzung steckte der Teufel erwartungsgemaess im Detail.
UI-Automatisierung ist die Art der Softwareentwicklung, die sich am schlechtesten auf Folien darstellen laesst. Es gibt kein sauberes Architekturdiagramm, keine elegante API-Schnittstelle. Stattdessen gibt es einen Browser, eine Website, die nicht dafuer gebaut wurde, maschinell ausgelesen zu werden, und ein Script, das Klicks und Tastatureingaben simuliert.
Schritt 1: Login und Navigation. Das Script startet den Browser, oeffnet die Fleetboard-URL und meldet sich mit den Zugangsdaten an. Das klingt trivial, war es aber nicht. Fleetboard nutzt einen mehrstufigen Login-Prozess mit Session-Cookies, die nach einer bestimmten Zeit ablaufen. Das Script musste erkennen, ob es noch eingeloggt war oder ob ein erneuter Login noetig wurde. Wir haben das ueber eine Pruefung des DOM-Elements geloest: Wenn das Dashboard-Element vorhanden ist, sind wir drin. Wenn nicht, Login-Routine ausfuehren.
Schritt 2: Fahrzeugpositionen auslesen. Im Fleetboard-Dashboard gibt es eine Kartenuebersicht mit allen Fahrzeugen und eine tabellarische Ansicht mit Details. Wir haben die tabellarische Ansicht genutzt, weil sie strukturierter ist. Das Script navigiert zur Fahrzeugliste, iteriert ueber die Eintraege und extrahiert fuer jedes Fahrzeug: Fahrzeugkennung, aktuelle Position (Laengen- und Breitengrad), Geschwindigkeit und — wenn verfuegbar — die vom System berechnete ETA.
Das Auslesen funktioniert ueber UI-Selektoren. Power Automate Desktop identifiziert HTML-Elemente anhand ihrer CSS-Klassen, IDs oder XPath-Ausdruecke. Das funktioniert zuverlaessig — solange sich die Website nicht aendert. Dazu spaeter mehr.
Schritt 3: Abgleich mit Soll-Daten. Die geplanten Ankunftszeiten und Zieladressen lagen in einer Excel-Tabelle, die die Disposition taeglich pflegte. Das Script liest diese Tabelle ein und vergleicht fuer jedes Fahrzeug die aktuelle Position mit der Zielposition. Die Entfernung wird ueber eine vereinfachte Haversine-Berechnung ermittelt — Luftlinie, keine Strassenkilometer. Fuer den Zweck der Annaeherungserkennung war das ausreichend. Wenn ein Fahrzeug unter die definierte Schwelle von 30 Kilometern faellt, gilt es als „im Ankunftsbereich“.
Schritt 4: Benachrichtigung. Bei erkannter Annaeherung schickt das Script eine E-Mail an den zustaendigen Disponenten. Inhalt: Fahrzeugkennung, aktueller Standort, voraussichtliche Ankunftszeit und Zieladresse. Kein Schnickschnack, kein Dashboard — eine schlichte E-Mail, die in Outlook aufploppt. Die Disponenten wollten das so, und ehrlich gesagt war es die richtige Entscheidung. Ein weiteres Tool auf dem Bildschirm haette niemand genutzt.
Schritt 5: Scheduling. Das Script laeuft als Scheduled Task auf dem Windows Server. Alle 15 Minuten wird der Flow ausgeloest. Ein kuerzerer Intervall waere technisch moeglich gewesen, aber die Webapplikation reagiert bei zu haeufigen Zugriffen traege und Fleetboard haette das moeglicherweise als ungewoehnliches Zugriffsverhalten erkannt.
Ich will hier nicht beschoenigen: UI-Automatisierung ist fragil. Das ist keine Schwaeche der konkreten Umsetzung, sondern liegt in der Natur der Sache. Man baut auf einer Oberflaeche auf, die sich jederzeit aendern kann — und man hat keinen Einfluss darauf.
In den ersten drei Monaten nach Go-Live brach das Script vier Mal. Jedes Mal aus einem anderen Grund.
Bruch 1: Fleetboard-Update mit neuer Login-Seite. Daimler hat die Login-Maske ueberarbeitet. Neues Layout, neue CSS-Klassen. Unser Login-Selektor griff ins Leere. Ausfallzeit: 6 Stunden, bis wir den Selektor angepasst hatten.
Bruch 2: Cookie-Banner. Klassiker. Fleetboard hat einen neuen Cookie-Consent-Dialog eingefuehrt. Der legte sich ueber die gesamte Seite. Das Script konnte das Dashboard nicht finden, weil der Banner im Weg war. Loesung: Ein zusaetzlicher Schritt im Script, der prueft, ob ein Consent-Banner vorhanden ist, und diesen automatisch akzeptiert.
Bruch 3: Timeout bei langsamer Serverantwort. An einem Freitagmorgen war die Fleetboard-Infrastruktur offenbar unter Last. Die Seite lud langsamer als ueblich. Unser Script hatte einen festen Timeout von 20 Sekunden. Die Seite brauchte 35. Loesung: Dynamisches Warten mit exponentiellen Retry-Intervallen statt fester Timeouts.
Bruch 4: Aenderung der Tabellenstruktur. Bei einem Minor-Update hat Fleetboard eine Spalte in der Fahrzeugliste hinzugefuegt. Alle Spaltenindizes haben sich verschoben. Statt der Position las das Script die Geschwindigkeit, statt der ETA den Kraftstoffstand. Das merkten wir erst, als ein Disponent sich wunderte, warum ihm das System meldete, ein LKW sei „74 Liter“ vom Ziel entfernt.
Nach dem vierten Bruch war klar: Wir brauchten eine robustere Architektur. Nicht eine andere Technologie, sondern bessere Fehlerbehandlung innerhalb der bestehenden.
Error-Handling mit Fallback-Strategie: Jeder einzelne Schritt im Script ist jetzt in einen Try-Catch-Block gehuellt. Wenn ein Selektor nicht greift, versucht das Script einen alternativen Selektor. Fuer die wichtigsten Elemente haben wir jeweils zwei bis drei Selektoren hinterlegt: einen ueber die CSS-Klasse, einen ueber XPath und einen ueber die Textinhalte. Wenn alle drei fehlschlagen, bricht das Script kontrolliert ab und schickt eine Fehlermeldung an die IT.
Retry-Logik: Statt eines einzelnen Versuchs fuehrt das Script bei Fehlern bis zu drei Wiederholungen durch, mit steigenden Wartezeiten (5, 15, 30 Sekunden). Das faengt temporaere Netzwerkprobleme und langsame Seitenladungen ab, ohne den Server mit Anfragen zu bombardieren.
Health-Check per E-Mail: Jeden Morgen um 6:00 Uhr schickt das Script eine Statusmeldung: „Fleetboard-Monitor laeuft. Letzter erfolgreicher Durchlauf: 05:45. Ausgelesene Fahrzeuge: 38. Fehler in den letzten 24 Stunden: 0.“ Wenn diese Mail ausbleibt, weiss die IT, dass etwas nicht stimmt.
Screenshot bei Fehler: Bei jedem unerwarteten Fehler macht das Script einen Screenshot des aktuellen Browser-Zustands und speichert ihn mit Zeitstempel. Das hat uns bei der Fehleranalyse enorm geholfen. Statt im Nachhinein zu raten, was passiert sein koennte, sehen wir exakt, welcher Dialog, welches Banner, welcher Ladezustand das Problem verursacht hat.
Konfigurierbare Selektoren: Alle UI-Selektoren liegen jetzt in einer externen Konfigurationsdatei, nicht fest im Script. Wenn sich die Fleetboard-Oberflaeche aendert, muessen wir nur die Konfiguration anpassen — nicht den gesamten Flow ueberarbeiten. Das reduziert die Reaktionszeit bei Bruechen von Stunden auf Minuten.
Das Script laeuft seit ueber einem Jahr. Nach der initialen Stabilisierungsphase gab es in den letzten neun Monaten genau zwei Ausfaelle — beide durch groessere Fleetboard-Updates, beide innerhalb von zwei Stunden behoben.
Die messbaren Ergebnisse:
Die nicht messbaren, aber ebenso wichtigen Ergebnisse:
Die Disponenten arbeiten ruhiger. Statt reaktiv auf Anrufe und Nachfragen zu reagieren, koennen sie proaktiv planen. Wenn das System meldet, dass ein LKW in 30 Minuten am Ziel ist, kann der Disponent den Kunden vorab informieren und gleichzeitig die naechste Tour planen. Das klingt nach einer Kleinigkeit, veraendert aber den Arbeitsrhythmus fundamental.
1. Von Anfang an mehrere Selektoren einplanen. Wir haben das erst nach dem dritten Bruch implementiert. Das war ein Fehler. Bei jedem RPA-Projekt sollte man von Tag eins an davon ausgehen, dass sich die Zieloberflaeche aendern wird. Nicht ob, sondern wann.
2. Den Kunden auf die Fragilitaet vorbereiten. Wir haben zu Beginn kommuniziert, dass das System „stabil“ laeuft. Das war technisch korrekt, aber es hat eine Erwartungshaltung geschaffen, die bei den ersten Ausfaellen zu Frust fuehrte. Besser waere gewesen: „Das System laeuft zuverlaessig, aber es wird gelegentlich Anpassungen brauchen, weil wir von einer externen Oberflaeche abhaengig sind.“ Ehrliche Kommunikation spart spaeter Erklaerungsaufwand.
3. Monitoring von Anfang an. Der Health-Check per E-Mail war eine nachtraegliche Ergaenzung. Haetten wir das von Anfang an gehabt, waeren die ersten drei Ausfaelle schneller aufgefallen. Bei einem System, das im Hintergrund laeuft und keine sichtbare Benutzeroberflaeche hat, ist Monitoring nicht optional — es ist Pflicht.
4. RPA als Brueckentechnologie verstehen. UI-Automatisierung ist kein Dauerzustand. Es ist ein Workaround fuer fehlende APIs. Falls Fleetboard irgendwann eine offene Schnittstelle anbietet, sollte man sofort umsteigen. Das Script erledigt seinen Job, aber es ist und bleibt ein Workaround — und sollte auch so behandelt werden.
5. Excel als Datenquelle hat Grenzen. Die Soll-Daten aus der Excel-Tabelle zu lesen, war der schnellste Weg zur Loesung. Aber Excel ist keine Datenbank. Gleichzeitige Zugriffe, Formate, die sich verschieben, Dateien, die jemand gerade offen hat — das alles kann Probleme verursachen. Fuer eine Weiterentwicklung wuerde ich die Soll-Daten in eine einfache Datenbank auslagern.
Der gesamte Projektzeitraum betrug zwei Wochen. In der ersten Woche: Analyse der Fleetboard-Oberflaeche, Aufbau des Scripts, erste Tests. In der zweiten Woche: Feinabstimmung, Error-Handling, Testbetrieb parallel zum manuellen Prozess, Go-Live.
Die Kosten waren ueberschaubar. Power Automate Desktop war in der bestehenden Microsoft-365-Lizenz enthalten. Der Windows Server stand ohnehin im Unternehmen. Die Hauptkosten waren Beratung und Entwicklung — zwei Wochen Arbeitszeit. Laufende Kosten: praktisch null, abgesehen von gelegentlichen Anpassungen bei Fleetboard-Updates.
Die Amortisation war ebenfalls schnell. Die eingesparte Zeit der Disponenten — konservativ geschaetzt eine Stunde pro Tag pro Disponent bei drei Disponenten — entspricht rund 60 Arbeitsstunden pro Monat. Bei einem internen Stundensatz von 40 Euro sind das 2.400 Euro monatlich. Das Projekt hat sich innerhalb des ersten Monats gerechnet.
Dieses Projekt wird nie einen Innovations-Award gewinnen. Es gibt kein schoenes Dashboard, keine kuenstliche Intelligenz, keinen Machine-Learning-Algorithmus. Es ist ein Script, das eine Website ausliest und E-Mails verschickt. Technologisch betrachtet ist das das Gegenteil von elegant.
Aber es loest ein echtes Problem. Die Disposition arbeitet besser, die Kunden sind zufriedener, die Fahrer werden nicht mehr gestoert. Das System laeuft seit ueber einem Jahr stabil, kostet fast nichts im Betrieb und hat sich in weniger als einem Monat amortisiert.
In der Automatisierung geht es nicht darum, die technisch schoenste Loesung zu bauen. Es geht darum, das Problem zu loesen. Und manchmal bedeutet das: eine Webseite scrapen, weil es keine API gibt. Das ist nicht ideal, aber es funktioniert. Und ein funktionierender Workaround ist immer besser als eine perfekte Loesung, die nicht existiert.
Wenn Sie aehnliche Herausforderungen in Ihrer Spedition oder Logistik haben — Systeme ohne APIs, Prozesse die auf Zurufen basieren, Informationen die nicht dorthin fliessen, wo sie gebraucht werden — dann lohnt sich ein Blick auf RPA als Brueckentechnologie. Nicht als Dauerloesung, aber als pragmatischen ersten Schritt.
Fuer einen breiteren Ueberblick ueber Automatisierung in der Logistik empfehle ich unseren Artikel zur digitalen Transformation in der Logistik. Wenn Sie wissen wollen, wann RPA sinnvoll ist und wann echte KI die bessere Wahl waere, lesen Sie unseren Vergleich RPA vs. KI-Automatisierung. Und falls Sie konkret ueber Lagerautomatisierung nachdenken, haben wir auch dazu einen ausfuehrlichen Beitrag.
Oder sprechen Sie direkt mit uns. Kontaktieren Sie uns — wir schauen uns Ihre Prozesse an und sagen Ihnen ehrlich, was automatisierbar ist und was nicht. Ohne PowerPoint, ohne Strategiepapier. Nur eine realistische Einschaetzung.
