Revenue-per-Flight mit Leon und Grafana verlässlich steuern: von der KPI-Definition zur prüfbaren Datenkette

Revenue-per-Flight klingt nach einer einfachen Steuerungsgröße: ein Wert, der Leistungen über Flüge, Kunden, Flugzeuge und Zeiträume vergleichbar macht. In der Praxis scheitert die Kennzahl jedoch häufig nicht an der Idee, sondern an der Datenbasis. Wenn Flugbetrieb und Abrechnung aus unterschiedlichen Systemständen, Excel-Exports oder uneinheitlichen Filtern zusammengeführt werden, entstehen Diskussionen über Zahlen – statt Entscheidungen über Maßnahmen.

Zielbild für Entscheider ist daher klar: eine durchgängige, prüfbare Datenkette vom Journey Log bis zur Rechnung – und ein Reporting, das bei jedem Monatsabschluss reproduzierbar dieselben Ergebnisse liefert.

Warum Revenue-per-Flight als KPI oft enttäuscht

Revenue-per-Flight wird schnell zur „gefühlten“ Kennzahl, wenn es keine verbindliche Logik und keine stabile Datenbereitstellung gibt. Typische Symptome:

• Unterschiedliche Report-Filter und Exportzeitpunkte führen zu abweichenden Ergebnissen

• Korrekturen (Credit Notes, Stornos, Nachbelastungen) verändern rückwirkend die Zahlen, ohne dass Reports sauber nachziehen

• Unklare Definitionen (Leg vs. Trip vs. Rotation) machen Vergleiche wertlos

Für Geschäftsführung und Bereichsleiter ist das kritisch: Ohne belastbare Basis bleibt unklar, ob ein Effekt operativ, vertrieblich oder rein rechnerisch ist.

Saubere Definition: Was „Revenue-per-Flight“ wirklich meint

Bevor Daten und Dashboards gebaut werden, braucht es eine eindeutige KPI-Definition. Zwei Punkte sind dabei entscheidend.

1) Umsatz ist nicht Deckungsbeitrag

„Umsatz pro Flug“ ist nicht automatisch „Profit pro Flug“. Beide Perspektiven sind sinnvoll – sollten aber getrennt geführt werden.

• Revenue-per-Flight (Umsatz): zeigt Vermarktungs- und Preisleistung

• Contribution-per-Flight (Deckungsbeitrag): zeigt Wirtschaftlichkeit (erfordert Kostenlogik)

2) Was ist ein „Flug“?

In der Praxis muss festgelegt werden, welche Einheit zählt:

• Leg (ein Abschnitt)

• Trip/Rotation (mehrere Legs als zusammenhängender Auftrag)

Ohne diese Festlegung sind Werte zwischen Teams, Zeiträumen oder Flugzeugen nicht vergleichbar.

Mindeststandard für eine belastbare KPI

Damit Revenue-per-Flight führungsfähig wird, sollte die Definition mindestens enthalten:

• Zeitraumlogik: nach Flugdatum, Rechnungsdatum oder klarer Abgrenzungsregel

• Währungslogik: Umrechnung und Stichtag eindeutig

• Statuslogik: welche Stati zählen (z. B. geflogen, abgerechnet, storniert)

• Eindeutige Flug-ID: als Klammer zwischen Journey Log und Billing

Wo Zahlen typischerweise auseinanderlaufen (und warum)

In Flight Ops und Billing entstehen Abweichungen meist an denselben Stellen:

• Periodenverschiebung: Flugdatum und Rechnungsdatum liegen in unterschiedlichen Monaten – der Umsatz „wandert“ im Reporting

• Stornos und Korrekturen: Umsatz wird rückwirkend geändert, aber Exporte bilden nur Momentaufnahmen ab

• Dubletten und Versionsstände: gleiche Flüge oder Rechnungen werden mehrfach exportiert oder unterschiedlich gefiltert

• Uneinheitliche Kennzeichnung von Empty Legs: erschwert Vermarktungs- und Auslastungsanalysen

• Fehlender stabiler Flottenbezug: Umsatz ist nicht sauber mit Registration/Typ verknüpft

Geschäftlicher Effekt: Teams verbringen Zeit mit Abstimmung, statt Maßnahmen abzuleiten (Pricing, Vermarktung, Flotteneinsatz).

Leon Software als Datenquelle: Was Sie wirklich brauchen

Leon Software liefert die operative Basis (Fluglisten, Journey-Log-Daten) und – je nach Setup – auch die Abrechnungssicht. Für Revenue-per-Flight sind typischerweise relevant:

• Operations-Daten: Legs, Zeiten, Flugzeug/Registration, Status

• Billing-Daten: Invoices inkl. Positionen sowie Quotes, Recharges und Credit Notes

• Stammdaten/Strukturdaten: Flotte, Kunden, Statusdefinitionen

Entscheidend ist weniger „ob die Daten existieren“, sondern ob sie strukturiert, historisierbar und wiederholbar abrufbar sind – damit Reporting nicht vom Zufall eines Exports abhängt.

Lösungsbaustein: Leon2DB als belastbare Datenpipeline

Hier setzt das Arkcanis Tool Leon2DB an: eine automatisierte Datenpipeline, die Daten aus der Leon GraphQL API in eine PostgreSQL-Datenbank importiert. Das Ziel ist eine stabile Reporting-Basis, auf der Revenue-per-Flight reproduzierbar berechnet werden kann.

Damit die Zahlen im Management-Reporting belastbar bleiben, sind drei Prinzipien zentral:

• Stabiler Zugriff: automatisiertes Token-Handling für verlässliche API-Abfragen

• Kontrollierte Imports: Zeitfenster-Importe (Slices), um Daten gezielt und wiederholbar zu laden

• Saubere Ergebnisse: Deduplizierung über IDs, damit Mehrfachimporte keine Doppelzählungen erzeugen

Zusätzlich entsteht Mehrwert durch konsistente Nachverarbeitung, z. B. die Verknüpfung von Stornos/Korrekturen und die saubere Zuordnung von Umsatz zu Flügen.

Visualisierung mit Grafana: aus Daten wird Steuerung

Wenn die Datenkette steht, wird Revenue-per-Flight mit klaren Dashboards wirklich führungsfähig. Grafana ermöglicht eine einheitliche Sicht für Geschäftsführung, Ops und Finance – statt paralleler Excel-Logiken.

Bewährte Dashboard-Bausteine:

• Revenue-per-Flight nach Zeitraum, Kunde, Route, Flugzeugtyp/Registration

• Empty-Leg-Transparenz: Quote, Entwicklung, Vermarktungspotenzial je Base/Flotte

• Korrekturmonitoring: Credit Notes, Nachbelastungen, Stornos – inklusive nachvollziehbarer Logik

Wichtig für Entscheider: wenige, entscheidungsrelevante Visuals – und dokumentierte Definitionen direkt im Dashboard, damit die KPI in Reviews konsistent interpretiert wird.

Umsetzungsplan in 4 Schritten (pragmatisch, ohne Overhead) 1) KPI-Definition festziehen

Leg/Trip-Logik, Umsatzlogik, Periodenlogik und Verantwortlichkeiten zwischen Ops und Finance verbindlich festlegen.

2) Datenpipeline aufsetzen

Leon2DB konfigurieren (Zeitfenster, Deduplizierung, Import-Intervalle) und Datenmodell/Zuordnungen prüfen.

3) Qualitätsregeln etablieren

Plausibilitäten definieren (z. B. fehlende Flug-IDs, auffällige Abweichungen, Storno-Ketten) und einen Freigabeprozess für KPI-Versionen festlegen.

4) Dashboard & Review-Rhythmus einführen

Grafana-Boards aufbauen, Monatsabschluss-Checks planen und eine Maßnahmenliste führen (Pricing, Empty-Leg-Vermarktung, Flotteneinsatz).

Ergebnis: ein reproduzierbares Revenue-per-Flight statt Ad-hoc-Auswertung.

Welche Entscheidungen mit sauberem Revenue-per-Flight möglich werden

Mit konsistentem Revenue-per-Flight werden Management-Entscheidungen deutlich belastbarer:

• Pricing & Angebotsqualität: Welche Kunden/Segmente unterperformen systematisch?

• Flotteneinsatz: Welche Flugzeuge liefern schwache Umsatzleistung je Leg/Flugstunde (als Basis für die nächste Stufe: Kostenbetrachtung)?

• Empty-Leg-Vermarktung: Wo lohnt sich Priorisierung nach Base/Flotte wirklich?

• Prozessqualität: Credit Notes als Signal für Fehler in Angebot, Ops oder Billing erkennen

Zusätzlicher, oft unterschätzter Nutzen: weniger Abstimmungsaufwand zwischen Geschäftsführung, Ops und Finance – weil die KPI nicht jeden Monat neu erklärt werden muss.

Fazit: Revenue-per-Flight ist nur so gut wie die Datenkette dahinter

Revenue-per-Flight kann eine starke Steuerungsgröße sein – wenn Definition, Datenkette und Reporting-Logik zusammenpassen. Mit Leon als operativer Quelle, einer stabilen Pipeline (z. B. Leon2DB) und klaren Grafana-Dashboards wird aus einer „Diskussionskennzahl“ ein verlässliches Führungsinstrument.

Nächster Schritt

Wenn Sie Revenue-per-Flight in Ihrem Unternehmen belastbar etablieren wollen, starten Sie mit einem klar abgegrenzten KPI-Workshop (Definition + Abgrenzungslogik) und einem Datencheck in Leon. Darauf aufbauend lässt sich ein Pilot-Dashboard in kurzer Zeit umsetzen – inklusive Roadmap zur Skalierung.

---

Über die Arkcanis Consulting

Die Arkcanis Consulting GmbH ist die spezialisierte Beratungseinheit der Arkcanis Gruppe. Wir entwickeln skalierbare Prozess- und Datenarchitekturen für Airlines, AOCs, Operator und technologiegetriebene Unternehmen – mit einem klaren Fokus auf Aviation Engineering, Leon-Integrationen, Atlassian-Architekturen, ETL-Pipelines und Echtzeit-Dashboards.

Als Gründer der catworkx GmbH, einem der größten Atlassian-Partner im DACH-Raum, verfügt Oliver Groht über mehr als 25 Jahre Erfahrung in Jira- & Confluence-Architekturen, Prozessberatung und organisationsweiter Skalierung. Er verbindet diese Expertise heute mit tiefem technischem Know-how in Leon GraphQL, Data Engineering, Grafana und Flight Ops-Workflows.

Das Ergebnis: messbare, transparente und belastbare Strukturen, die operative Exzellenz ermöglichen und strategische Entscheidungen auf Management- und C-Level stärken.

Kontakt aufnehmen