Das Wichtigste in Kürze
  • Funktionslisten unterscheiden Flottenmanagement-Software kaum noch. Die Unterschiede liegen im Datenmodell, in den Schnittstellen und darin, wie das System mit Ausnahmen umgeht.
  • Die Auswahl beginnt nicht beim Anbietervergleich, sondern bei einer schriftlichen Aufnahme der eigenen Prozesse. Wer nicht beschreiben kann, wie heute disponiert und abgerechnet wird, kauft eine fremde Prozesslogik mit.
  • Schnittstellen zu Telematik, Buchhaltung und Personalsystemen entscheiden über den laufenden Aufwand. Ein System ohne belastbare Schnittstellen verlagert Handarbeit, statt sie zu beenden.
  • Mandantenfähigkeit, Rollen und Berechtigungen werden regelmäßig unterschätzt. Sie werden erst zum Thema, wenn Werkstatt, Disposition und Controlling dasselbe System nutzen sollen.
  • Der Datenexport gehört in den Vertrag. Wer seine Stamm- und Bewegungsdaten nicht in einem dokumentierten Format zurückbekommt, hat die Wechselkosten bereits bezahlt, ohne es zu wissen.

Wer heute Flottenmanagement-Software auswählt, vergleicht Anbieter, deren Funktionslisten sich zu großen Teilen decken. Fahrzeugakte, Termine, Kosten, Telematik, Auswertungen: Das bietet praktisch jedes System. Die Unterschiede, die im Betrieb spürbar werden, stehen in keiner Broschüre. Sie liegen im Datenmodell, in den Schnittstellen, im Umgang mit Ausnahmen und in der Frage, wie die Daten wieder aus dem System herauskommen. Dieser Artikel beschreibt, welche Anforderungen eine Auswahl tatsächlich entscheiden sollten.

Zuerst die eigenen Prozesse, dann der Markt

Die häufigste Reihenfolge bei einer Auswahl ist: Anbieterliste zusammenstellen, Demos ansehen, Anforderungen aus dem ableiten, was in den Demos gezeigt wurde. Das Ergebnis ist ein Anforderungskatalog, der die Produktlogik des überzeugendsten Anbieters abbildet.

Die tragfähigere Reihenfolge kostet zwei bis drei Wochen und beginnt im eigenen Haus. Drei Fragen reichen für den Anfang:

Wer arbeitet heute womit? Nicht die Rollen laut Organigramm, sondern die tatsächlichen Bearbeiter. In vielen Fuhrparks führt die Disposition eine eigene Liste, die Werkstatt eine zweite, das Controlling zieht sich eine dritte aus der Buchhaltung. Diese drei Sichten sind selten deckungsgleich, und ein System, das nur eine davon bedient, verdrängt die anderen nicht, sondern kommt als viertes dazu.

Wo entstehen die Daten? Kilometerstände kommen aus der Telematik, aus dem Tankbeleg, vom Fahrer oder aus der Werkstattrechnung, oft aus allen vieren mit unterschiedlichen Werten. Wer die Quellen nicht kennt, kann später nicht entscheiden, welche im Zweifel gilt.

Was ist der Ausnahmefall? Der Normalfall ist in jedem Produkt abgebildet. Interessant ist, was passiert, wenn ein Fahrzeug den Halter wechselt, ein Leasingvertrag verlängert wird, ein Ersatzfahrzeug für sechs Wochen läuft oder ein Anhänger zwei Zugmaschinen zugeordnet ist. Diese Fälle sind selten genug, um in einer Demo nicht vorzukommen, und häufig genug, um den Alltag zu bestimmen.

Aus diesen drei Fragen entsteht ein Anforderungskatalog, der die eigene Arbeitsweise beschreibt statt die eines Anbieters. Er ist auch die Grundlage dafür, in der Demo die richtigen Fälle vorführen zu lassen.

Das Datenmodell entscheidet, was später möglich ist

Unter jeder Oberfläche liegt eine Annahme darüber, was ein Fahrzeug ist und woran es hängt. Diese Annahme lässt sich später nicht ändern, und sie bestimmt, welche Auswertungen überhaupt möglich sind.

Die Fragen, die das Modell offenlegen:

  • Hat ein Fahrzeug eine Historie oder nur einen Zustand? Ein System, das den aktuellen Halter, Standort und Kostenträger speichert, kann die Frage "was hat dieses Fahrzeug im letzten Jahr gekostet, aufgeteilt nach Kostenstelle" nicht beantworten, wenn die Kostenstelle im März gewechselt hat. Zeitliche Gültigkeit im Stammdatenmodell ist eine Architekturentscheidung, keine Einstellung.
  • Wie werden Fahrzeug, Fahrer und Auftrag verknüpft? Eine feste Zuordnung Fahrzeug zu Fahrer bildet einen Werksfuhrpark ab. Ein wechselnder Pool braucht ein anderes Modell, und die Nachrüstung ist teuer.
  • Wo liegen die Kosten? Wenn Kraftstoff, Wartung, Leasingrate, Versicherung und Schäden in getrennten Bereichen ohne gemeinsame Auswertungsebene liegen, entsteht die Gesamtkostenrechnung wieder in Excel, und damit war der Hauptgrund für die Einführung hinfällig.
  • Ist der Anhänger ein Fahrzeug? Eine banale Frage mit erheblichen Folgen für Prüftermine, Zuordnung und Auswertung.

Diese Punkte lassen sich in einer Demo prüfen, wenn man sie vorher aufschreibt. Sie lassen sich nicht mehr prüfen, wenn die Auswahl gelaufen ist.

Schnittstellen bestimmen den laufenden Aufwand

Ein Flottensystem steht nie allein. Es hängt mindestens an der Buchhaltung, meist an einer Telematiklösung, häufig an der Personalverwaltung und manchmal an einem ERP oder einem Dispositionssystem. Jede Verbindung, die nicht automatisiert ist, bleibt Handarbeit, nur an anderer Stelle.

Bei der Prüfung der Schnittstellen kommt es auf drei Dinge an, die in Produktunterlagen selten unterschieden werden.

Gibt es eine dokumentierte API, und ist sie vollständig? Viele Anbieter nennen eine Schnittstelle, die lesend funktioniert und schreibend nur Teilbereiche abdeckt. Für einen laufenden Abgleich mit der Buchhaltung reicht das nicht. Die Frage lautet nicht, ob eine API existiert, sondern welche Objekte über sie angelegt und geändert werden können.

Wie werden Konflikte aufgelöst? Wenn Telematik und Werkstatt unterschiedliche Kilometerstände liefern, braucht es eine definierte Regel. Systeme, die den zuletzt geschriebenen Wert übernehmen, erzeugen stille Fehler in der Wartungsplanung.

Was kostet die Schnittstelle? Bei mehreren Anbietern ist die API Teil eines höheren Tarifs oder wird pro Aufruf abgerechnet. Das gehört in den Preisvergleich, weil es die laufenden Kosten stärker bewegt als der Preis pro Fahrzeug.

Wo Standardschnittstellen fehlen oder zu grob sind, bauen wir die Verbindung zwischen Flottensystem und den umliegenden Anwendungen als eigene Integrationsschicht. Wie wir dabei vorgehen, beschreibt unsere Leistung zur Systemintegration.

Rollen, Rechte und Mandanten

Dieser Punkt wird in Auswahlprojekten regelmäßig zu spät gestellt, weil er in der Demo nie im Vordergrund steht.

Sobald mehr als eine Abteilung mit dem System arbeitet, braucht es eine Rechtelogik: Die Werkstatt soll Schäden erfassen, aber keine Leasingkonditionen sehen. Das Controlling braucht alle Kosten, aber keine Fahrerdaten. Der Standortleiter sieht seinen Standort, nicht die anderen. In Konzernstrukturen kommt die Mandantenfähigkeit dazu, mit getrennten Datenbeständen und einer gemeinsamen Auswertung darüber.

Personenbezogene Daten verschärfen die Anforderung. Fahrerzuordnungen, Positionsdaten aus der Telematik und Verstoßmeldungen sind nach DSGVO nur zweckgebunden zu verarbeiten, und der Betriebsrat wird nach der Zugriffslogik fragen, bevor er einer Einführung zustimmt. Ein System, das Rechte nur grob nach Benutzergruppe vergibt, macht diese Zusage schwer.

Die praktische Prüffrage: Lassen Sie sich in der Demo eine Rolle anlegen, die genau das sehen darf, was Ihre Werkstatt sehen soll, und nichts darüber hinaus. Der Aufwand dafür zeigt mehr über das System als jede Funktionsliste.

Standard oder Individualentwicklung

Für die meisten Fuhrparks ist Standardsoftware die richtige Antwort. Der Markt ist reif, die Produkte decken den Normalfall gut ab, und eine Eigenentwicklung bindet Ressourcen, die anderswo mehr bringen.

Es gibt Konstellationen, in denen die Rechnung kippt. Wenn die Disposition der eigentliche Wertschöpfungsprozess ist und nicht nur Verwaltung, wenn Fahrzeuge, Aufträge und Kunden in einer Logik zusammenhängen, die kein Standardprodukt kennt, oder wenn die Zahl der notwendigen Ausnahmen dazu führt, dass die Belegschaft den Standard dauerhaft umgeht, dann ist die Anpassung teurer als eine passende Lösung.

Ein belastbarer Test: Zählen Sie im Auswahlprozess die Anforderungen, für die der Anbieter eine Individualanpassung anbietet. Ab einer bestimmten Zahl kaufen Sie ein Standardprodukt und bezahlen trotzdem eine Entwicklung, ohne deren Vorteile zu bekommen. Eine gemischte Lösung, bei der ein Standardsystem die Verwaltung übernimmt und ein eigenes Modul den spezifischen Prozess abbildet, ist häufig der tragfähigere Weg. Auswertung und Kostentransparenz über beide Teile hinweg entstehen dann in einer eigenen Datenschicht, wie wir sie in unseren Projekten zur Datenanalyse aufbauen.

Die Gesamtkosten liegen nicht im Lizenzpreis

Der Preisvergleich in Auswahlprojekten läuft meist über den Preis pro Fahrzeug und Monat. Das ist die Position, die sich gut vergleichen lässt, und es ist selten die größte.

Was in eine belastbare Kostenrechnung gehört:

Einführung und Datenübernahme. Die Migration der vorhandenen Bestände ist Aufwand, unabhängig davon, wer ihn erbringt. Wenn die Stammdaten aus mehreren Listen kommen, ist die Bereinigung der größere Teil davon, und sie fällt vor der Übernahme an.

Schnittstellen. Je nach Anbieter im Grundpreis enthalten, in einem höheren Tarif, als Einrichtungspauschale oder nach Aufrufen abgerechnet. Bei einem täglichen Abgleich mit Telematik und Buchhaltung ist der Unterschied zwischen diesen Modellen über die Vertragslaufzeit erheblich.

Anpassungen. Jede zugesagte Individualanpassung hat einen Preis für die Umsetzung und einen zweiten, der selten genannt wird: Sie muss bei jedem Versionswechsel mitgeführt werden. Anbieter, die Anpassungen außerhalb des Standards halten, berechnen diese Pflege getrennt.

Schulung und Einarbeitung. Bei mehreren Bearbeitergruppen mit unterschiedlichen Rollen ist das kein Halbtagstermin.

Interner Aufwand für den Betrieb. Stammdatenpflege, Rechteverwaltung, Prüfung der Schnittstellenläufe. Das bleibt im Haus und wird in Angeboten nicht abgebildet.

Eine Gegenüberstellung über fünf Jahre statt über den Monatspreis ordnet die Anbieter regelmäßig anders. Sie ist auch das Dokument, mit dem sich eine Investitionsentscheidung begründen lässt, wenn die Geschäftsführung nach dem Nutzen fragt.

Telematik und Mitbestimmung

Sobald Positionsdaten, Fahrverhalten oder Arbeitszeiten erfasst werden, ist die Einführung nicht mehr nur ein IT-Projekt.

Telematikdaten sind personenbezogen, sobald sie sich einem Fahrer zuordnen lassen, und das ist bei fester Fahrzeugzuordnung praktisch immer der Fall. Damit gilt die DSGVO in vollem Umfang: Zweckbindung, Datenminimierung, Löschfristen und eine Rechtsgrundlage für jede Verarbeitung. Eine Auswertung, die für die Disposition erhoben wurde, darf nicht ohne weiteres für eine Leistungsbeurteilung verwendet werden.

Parallel greift die Mitbestimmung. Ein System, das Verhalten oder Leistung von Beschäftigten erfassen kann, ist nach § 87 Abs. 1 Nr. 6 BetrVG zustimmungspflichtig, und die Eignung zur Überwachung reicht aus. Auf die Absicht kommt es nicht an.

Praktisch heißt das: Der Betriebsrat gehört früh in das Auswahlprojekt, nicht in die Einführungsphase. Die Fragen, die dort kommen, sind vorhersehbar und im Auswahlprozess beantwortbar: Welche Daten werden erhoben, wie lange gespeichert, wer sieht sie, und welche Auswertungen sind technisch ausgeschlossen. Ein System, in dem sich bestimmte Auswertungen abschalten und diese Abschaltung nachweisen lässt, macht eine Betriebsvereinbarung erheblich einfacher. Das ist ein Auswahlkriterium und gehört in den Anforderungskatalog.

Der Ausstieg gehört in den Vertrag

Die letzte Frage im Auswahlprozess ist die, die am seltensten gestellt wird: Wie kommen die Daten wieder heraus?

Ein Flottensystem sammelt über Jahre Stammdaten, Wartungshistorien, Kostenbelege und Kilometerverläufe. Dieser Bestand ist der eigentliche Wert. Wenn er nur als PDF-Report oder über eine Oberfläche exportierbar ist, ist ein Anbieterwechsel praktisch ausgeschlossen, unabhängig davon, was der Vertrag zur Kündigungsfrist sagt.

Was in den Vertrag gehört: ein vollständiger Export der Stamm- und Bewegungsdaten in einem dokumentierten, maschinenlesbaren Format, auf Anforderung und nicht nur zum Vertragsende, mit einer zugesagten Frist. Das ist eine Klausel, keine technische Anforderung, und sie wird selten abgelehnt, wenn man sie früh stellt.

Ein tragfähiger Ablauf

Aus der Praxis heraus funktioniert diese Reihenfolge:

  1. Prozesse und Datenquellen im eigenen Haus aufnehmen, schriftlich.
  2. Die zehn bis fünfzehn Ausnahmefälle sammeln, die den Alltag bestimmen.
  3. Anforderungskatalog daraus ableiten, mit einer Trennung zwischen Muss und Kann.
  4. Drei Anbieter in eine Demo holen, in der ausschließlich die eigenen Fälle gezeigt werden, mit eigenen Beispieldaten.
  5. Schnittstellen technisch prüfen, nicht nach Produktblatt, sondern mit einem Testzugang.
  6. Exportklausel und Preislogik für Schnittstellen verhandeln, bevor unterschrieben wird.

Der Aufwand für die Schritte 1 und 2 wirkt hoch, gemessen an einer Auswahl, die man in vier Wochen abschließen wollte. Er ist niedrig, gemessen an einer Einführung, die im zweiten Jahr rückabgewickelt wird.

Wir begleiten Auswahl und Einführung von Flottensystemen dort, wo Datenmodell, Schnittstellen und Auswertung zusammenkommen. Was das für Ihren Fuhrpark konkret bedeutet, hängt vor allem von den Prozessen ab, die Sie heute schon fahren.

Passende Leistungen: Datenanalyse, Systemintegration

Branche: Flottenmanagement