Fuhrparkplattform

Eine operative Fuhrparkplattform für den Mittelstand

Projektbeschreibung

Für ein mittelständisches Unternehmen mit eigener Fahrzeugflotte haben wir eine Fuhrparkplattform entwickelt, die Fuhrparkverantwortliche dabei unterstützt, Fahrzeuge, Fahrer, Wartung, Telematikdaten und Betriebskosten an einer Stelle zu steuern. Die Ausgangslage war typisch für viele Flotten mit 20 bis 500 Fahrzeugen: Live-Positionen lagen in einem Telematikportal, Tankkartenabrechnungen kamen aus einem anderen System, Wartungstermine wurden in Tabellen gepflegt und Fahrzeugakten bestanden aus Dokumenten, E-Mails und Erfahrungswissen der Fuhrparkleitung.

Das digitale Produkt führt diese bisher getrennten Arbeitsbereiche in eine Web-App über. Im Tagesbetrieb beantwortet die Plattform nicht nur die Frage, wo ein Fahrzeug steht. Die Plattform zeigt, ob es einsatzbereit ist, wer es fährt, welche Kosten aktuell auffällig sind, ob Wartungen anstehen und welche Ereignisse sofort entschieden werden müssen.

Für den Kunden war das Projekt relevant, weil Fuhrparksteuerung im Mittelstand oft erst dann sichtbar wird, wenn etwas nicht funktioniert: ein Fahrzeug ist nicht verfügbar, eine Wartung wurde übersehen, ein Tankkartenumsatz wirkt auffällig oder eine elektrische Flotte erreicht zu spät den Ladepunkt. Die Plattform sollte diese Reaktionen nach vorne ziehen und aus verteilten Daten einen steuerbaren Prozess machen.

Zielbild

Das Business-Ziel war eine zentrale Steuerungsoberfläche, mit der Fuhrparkverantwortliche weniger Zeit in Abstimmung und Datenabgleich verlieren. Die Plattform sollte Kosten, Nutzung und Verfügbarkeit so zusammenführen, dass Entscheidungen nicht mehr aus einzelnen Exporten rekonstruiert werden müssen. Für den Kunden entsteht dadurch die Grundlage, weitere Module wie Ladeinfrastruktur, Versicherungsprozesse oder Werkstattpartner später anzubinden, ohne die Kernlogik neu aufzubauen.

Das Nutzerziel war ein ruhiger Startpunkt für den Arbeitstag. Eine Fuhrparkleiterin soll morgens sehen, welche Fahrzeuge aktiv sind, welche Ausnahmen Aufmerksamkeit brauchen und welche Vorgänge heute geplant werden müssen. Die Karte, der Aktivitätsfeed und die Fahrzeugakten wurden deshalb nicht als getrennte Ansichten verstanden, sondern als unterschiedliche Perspektiven auf dieselbe operative Lage.

Das technische Ziel war ein Fundament, das Live-Daten und Verwaltungsdaten gemeinsam abbildet. Telematikereignisse, Fahrzeugstammdaten, Fahrer, Kosten, Wartungen und Dokumente mussten in ein konsistentes Datenmodell überführt werden. Ziel war nicht nur eine funktionale erste Version, sondern eine Architektur, die später weitere Datenquellen, Rollen und Auswertungen aufnehmen kann, ohne zur technischen Sackgasse zu werden.

Herausforderungen

Die größte Komplexität lag weniger im Interface als in der sauberen Abbildung der zugrunde liegenden Geschäftslogik. Ein Fahrzeug kann aktiv, im Standby, in Wartung, kritisch oder außerhalb eines Geofence sein. Diese Zustände kommen aus unterschiedlichen Quellen und können sich gegenseitig überlagern. Wenn ein eVito gleichzeitig unterwegs ist, unter 20 Prozent Ladezustand fällt und einen empfohlenen Ladestopp hat, muss das System entscheiden, welcher Hinweis Priorität bekommt und wie er im Dashboard, in der Karte und im Aktivitätsfeed erscheint.

Eine zweite Herausforderung war die Qualität und Frequenz der Telematikdaten. Fahrzeugpositionen, Geschwindigkeiten, Tankstände oder Ladezustände kommen nicht immer gleich schnell, gleich vollständig oder im gleichen Format an. Für die Produktlogik war deshalb wichtig, Rohdaten nicht direkt in der Oberfläche zu zeigen. Wir haben die Zustände so modelliert, dass die App mit verzögerten Updates, fehlenden Werten und widersprüchlichen Signalen umgehen kann. Für Nutzer bleibt die Oberfläche dadurch stabil, obwohl im Hintergrund viele Datenpunkte kontinuierlich aktualisiert werden.

Auch die Kostenlogik war produktseitig anspruchsvoll. Ein Tankkartenumsatz ist nur dann hilfreich, wenn er einem Fahrzeug, einem Fahrer, einem Zeitraum und einem Kostenkontext zugeordnet werden kann. Dasselbe gilt für Werkstattrechnungen, Stromkosten und geplante Budgets. Die App musste nicht nur Beträge anzeigen, sondern Abweichungen verständlich machen: Was ist geplant, welcher Zeitraum ist relevant, welche Kosten gehören zu welchem Fahrzeug und welche Position muss geprüft werden?

Die Live-Karte brachte eine eigene UX-Herausforderung mit. Viele Marker, Statusfarben, Routenspuren, Geofences und Fahrzeugdetails können schnell unruhig werden. Die Karte musste genug Informationen zeigen, um operativ nützlich zu sein, durfte aber nicht zum Suchbild werden. Deshalb wurden Status, Filter, Fahrzeugliste und Detailkarte als gemeinsame Arbeitsfläche gestaltet. Nutzer können vom Kennzeichen zur Karte springen, den Kontext prüfen und direkt in Details oder Route wechseln.

Umsetzung

Wir haben die Produktstruktur vom Alltag der Fuhrparkleitung aus entwickelt. Der Einstieg ist das Dashboard, weil dort die wichtigsten Entscheidungen zusammenlaufen: aktive Fahrzeuge, Kilometerleistung, laufende Kosten, offene Wartungen und Ereignisse der letzten Minuten. Jede Kennzahl ist mit einem konkreten Arbeitskontext verbunden. Kennzahlen sind dabei nicht nur Reporting, sondern führen direkt in den Status der Flotte und zu den relevanten Ausnahmen.

Die Produktlogik wurde bewusst zentral modelliert, damit Dashboard, Karte, Fahrzeugdetail, Wartungsplanung und Kostenmodul auf denselben Daten und Regeln aufbauen. Fahrzeugzustände, Ereignistypen, Kostenpositionen und Wartungsfälligkeiten wurden als wiederverwendbare Konzepte angelegt. Dadurch entstehen keine widersprüchlichen Darstellungen zwischen Karte und Detailansicht, und spätere Module können dieselben Regeln verwenden.

Für die Karte haben wir die Interaktion in zwei Ebenen getrennt. Links steht die scanbare Fahrzeugliste mit Status, Kennzeichen, Modell, Fahrer und Kurzinfo. Rechts liegt die räumliche Ansicht mit Markern, Geofence-Kreis, Routenspur und Popover. Diese Trennung hilft, große Datenmengen zu kontrollieren: Nutzer suchen nicht in der Karte, sondern nutzen die Liste, um die Karte gezielt zu verstehen.

Im Fahrzeugdetail wurden Verwaltungs- und Live-Daten zusammengeführt. Ein Fahrzeug ist nicht nur ein Objekt mit Stammdaten, sondern der Bezugspunkt für Fahrer, Werkstatt, Dokumente, Kosten, Verbrauch, Historie und Statusereignisse. Diese Struktur ist wichtig, weil Fuhrparkarbeit selten in einem Modul endet. Wer einen Wartungstermin prüft, braucht oft auch Kilometerstand, letzte Kosten, Fahrer und Dokumente.

Für den Betrieb wurden Export- und Kontrollprozesse von Anfang an mitgedacht. Berichte, Kostenansichten und Fahrzeugdaten müssen nicht nur im Browser funktionieren, sondern später auch in Controlling, Buchhaltung oder Werkstattkommunikation weiterverwendet werden. Deshalb wurden Datensichten so aufgebaut, dass sie filterbar, exportierbar und in ihren Statuswerten nachvollziehbar bleiben. Monitoring und Fehleranalyse wären besonders für Telematik-Integrationen relevant, weil falsche oder ausbleibende Daten im Tagesbetrieb schnell zu falschen Entscheidungen führen können.

Ergebnis

Entstanden ist eine Fuhrparkplattform, die den Kernprozess vollständig digital abbildet: Fahrzeuge beobachten, Ausnahmen erkennen, Wartung planen, Kosten prüfen und Entscheidungen dokumentieren. Nutzer können schneller sehen, was im Betrieb passiert, ohne zwischen Telematikportal, Tabelle, Tankkartenabrechnung und Fahrzeugakte zu wechseln.

Für den Kunden schafft die Plattform eine bessere Datenlage. Fahrzeuge, Kosten und Ereignisse werden nicht mehr isoliert betrachtet, sondern in Beziehung gesetzt. Dadurch lassen sich Abweichungen früher erkennen und operative Entscheidungen sauberer begründen. Das ist besonders wichtig für Betriebe, die wachsen oder ihre Flotte elektrifizieren, weil zusätzliche Fahrzeuge, Ladepunkte und Kostenmodelle sonst schnell neue Komplexität erzeugen.

Technisch entstand eine Grundlage, die weitere Integrationen erlaubt. Neue Telematikquellen, zusätzliche Rollen, Werkstattpartner, Ladeinfrastruktur oder Versicherungsprozesse können an ein bestehendes Modell andocken. Die erste Version ist damit kein Wegwerf-Prototyp, sondern ein Produktfundament, mit dem die Plattform schnell live gehen kann, ohne spätere Erweiterungen zu blockieren.

Produktansichten