Warum Leasing-IT oft unnötig komplex ist
Warum Leasing-IT oft unnötig komplex ist
Leasing ist ein Geschäft, in dem Struktur entscheidend ist.
Vertragslogik, Restwertannahmen, Risiko und Refinanzierung greifen eng ineinander. Schon kleine Änderungen wirken sich oft an mehreren Stellen gleichzeitig aus.
Wer eine Leasinggesellschaft führt, weiß deshalb: Das Geschäft lässt sich nicht in einfache Standardstrukturen pressen.
Umso erstaunlicher ist eine Beobachtung aus vielen Projekten:
In vielen Leasinggesellschaften entsteht die größte Komplexität nicht im Markt, sondern im eigenen System.
Und das liegt selten an der fachlichen Logik, sondern an der Art, wie Systeme über Jahre erweitert wurden.
Komplexität entsteht schleichend
Kaum jemand entscheidet bewusst: „Wir bauen ein überkomplexes System."
Stattdessen kommt ein neues Restwertmodell hinzu, weil eine bestimmte Objektklasse anders bewertet werden muss. Ein großer Händler erhält eine Gebührenlogik, die im Standard nicht vorgesehen war. Eine Refinanzierungsbank fordert zusätzliche Vertragskennzeichen für ihr Pool-Reporting.
Jede dieser Anpassungen ist für sich genommen plausibel. Das Problem entsteht nicht durch die einzelne Entscheidung, sondern durch ihr Nebeneinander.
Nach einigen Jahren existieren mehrere Definitionen dessen, was eigentlich eindeutig sein sollte. Der Vertragsbestand im Managementreport basiert auf einer anderen Logik als der Bestand, der an eine Refinanzierungsbank gemeldet wird, obwohl beide angeblich dieselben Verträge beschreiben.
In vielen Häusern ist die Systemlandschaft kein Ergebnis einer Architektur, sondern der Ausnahmen der letzten zehn Jahre.
Warum Komplexität konserviert wird
Komplexität wird aktiv erhalten, weil sie Interessen schützt. Die Fachabteilung, die vor Jahren eine Sonderlogik für ihre Objektklasse durchgesetzt hat, verteidigt diese Logik, weil sie ihre Berichtswelt strukturiert. Die IT vermeidet Bereinigungen, weil Nebenwirkungen in historischen Produktlogiken schwer abzuschätzen sind. Und niemand übernimmt freiwillig Verantwortung für Entscheidungen, die vor acht Jahren jemand anderes getroffen hat.
Das Ergebnis ist ein stiller Konsens zur Konservierung: Niemand baut ab, weil jeder etwas zu verlieren hat. Dieser organisatorische Anreiz ist mindestens so wirkmächtig wie jede technische Ursache.
Mehr Features schaffen keine bessere Steuerung
In vielen Leasinggesellschaften wird jede neue Anforderung technisch beantwortet. Das Ergebnis wirkt leistungsfähig. Operativ zeigt sich jedoch häufig ein anderes Bild.
Beispielsweise wird vor der Übermittlung eines Reports an eine Refinanzierungsbank ein Export gezogen, in Excel plausibilisiert und an einzelnen Stellen manuell korrigiert. Offiziell ist der Prozess systemgestützt. Faktisch gibt es eine stille Qualitätssicherung außerhalb des Systems.
Oder bei der Einführung einer neuen Servicekomponente stellt sich heraus, dass die Abgrenzung zwischen Finanz- und Serviceleistung im System je nach Vertragsgeneration unterschiedlich codiert ist. Das Reporting weist damit systematisch falsche Werte aus, ohne dass dies im Tagesgeschäft auffällt.
Solange diese Routinen funktionieren, gelten sie als normal. Doch sie sind ein Hinweis darauf, dass die Steuerungslogik nicht vollständig konsistent ist. Mehr Funktionen erhöhen nicht automatisch die Qualität der Steuerung. Sie erhöhen oft nur die Komplexität des Systems - nicht die Klarheit der Entscheidungen.
Diagnosefragen für die eigene Organisation
Bevor ein Systemwechsel diskutiert oder eine Neuimplementierung beauftragt wird, lohnen sich fünf konkrete Fragen:
Gibt es in Ihrem Haus mehr als eine operative Definition von „Vertragsbestand"? Wer hat sie autorisiert und wann wurde sie zuletzt überprüft?
Wie viele manuelle Korrekturen finden zwischen Systemexport und externer Meldung statt? Werden diese dokumentiert, oder sind sie stilles Erfahrungswissen einzelner Mitarbeiter?
Wenn ein neuer Refinanzierungspartner morgen einen standardisierten Datensatz anfordert: Könnten Sie diesen aus dem System heraus reproduzierbar liefern, oder würde zuerst eine interne Klärungsrunde stattfinden?
Wie lange würde es dauern, einem neuen Mitarbeiter zu erklären, warum die Ausfalldefinition im Risikocontrolling von der Definition im Kundensystem abweicht?
Wer mehrere dieser Fragen nicht klar beantworten kann, hat ein Strukturproblem – kein Softwareproblem.
Refinanzierung als Belastungstest
Besonders deutlich wird das im Austausch mit Refinanzierungsbanken.
Eine Refinanzierungsbank interessiert sich nicht für interne Historien. Sie interessiert sich für belastbare, reproduzierbare Zahlen. Wenn sich das gemeldete Portfolio-Volumen zwischen zwei Perioden ohne klar dokumentierte Ursache verändert oder wenn Definitionen von Ausfall und Überfälligkeit nicht konsistent hergeleitet werden können, entsteht nicht nur Rückfragebedarf. Es entsteht Zweifel an der Systemstabilität.
Refinanzierung wirkt deshalb wie ein Stresstest. Sie legt offen, ob die interne Komplexität fachlich notwendig ist, oder historisch gewachsen.
Regulatorische Konsequenzen inkonsistenter Definitionen
Was intern als beherrschbare Unschärfe gilt, wird im regulatorischen Kontext zum strukturellen Risiko.
Refinanzierungspartner verlangen reproduzierbare, revisionssichere Datensätze, eine Anforderung, die eine Gesellschaft mit mehreren parallelen Berechnungslogiken strukturell nicht erfüllen kann. BaFin-Anforderungen an das Risikodatenmanagement verlangen eindeutige Datendefinitionen und eine dokumentierbare Herleitung aller risikorelevanten Kennzahlen. Und IFRS 16 setzt eine konsistente Abgrenzung von Leasing- und Servicekomponenten voraus, wer das im System nicht sauber abbildet, schafft Grundlagen für Prüfungsrisiken.
Strukturelle Bereinigungen sind deshalb keine IT-Projekte. Sie sind Governance-Entscheidungen.
Differenzierung rechtfertigt keine Fragmentierung
Leasing lebt von Produktvielfalt: Kilometerverträge, Restwertmodelle, Servicekomponenten, Sale-and-Lease-Back-Strukturen. Diese Vielfalt verlangt Flexibilität im Produktdesign, aber keinen unstrukturierten Datenkern.
Ein professionelles Leasing-System zeichnet sich nicht durch die Anzahl seiner Sonderlogiken aus, sondern durch die Stabilität seines Datenkerns. Produktvarianten dürfen diese Struktur nutzen, aber nicht unterlaufen. Wenn jede Abteilung ihre eigene Sicht auf denselben Vertrag entwickelt, entsteht keine höhere Professionalität, sondern Fragmentierung, die sich im Exposure-Reporting systematisch niederschlägt.
Wachstum verstärkt Schwächen
In kleineren Beständen lassen sich Unschärfen kaschieren. Mit wachsendem Vertragsvolumen, zusätzlichen Objektklassen und mehreren Refinanzierungspartnern funktioniert das nicht mehr.
Was früher eine erklärbare Ausnahme war, wird bei 50.000 oder 100.000 Verträgen zum strukturellen Muster. Unterschiedliche Definitionen skalieren mit. Manuelle Plausibilisierungen skalieren mit. Wachstum legt oft nicht neue Chancen frei, sondern alte Systemprobleme.
Spätestens wenn neue Refinanzierungslinien angebunden oder regulatorische Anforderungen verschärft werden, zeigt sich, ob die Systemarchitektur tragfähig ist. Wenn jede Erweiterung zunächst analysiert werden muss, weil niemand sicher sagen kann, welche Nebenwirkungen sie in historischen Produktlogiken auslöst, ist nicht das Geschäft zu komplex, sondern die Struktur.
Die IT bildet ab, sie entscheidet nicht
In solchen Situationen wird schnell die Software infrage gestellt. Doch selten liegt die Ursache im System selbst.
Die IT bildet Entscheidungen ab. Wenn über Jahre hinweg Ausnahmen zugelassen, Definitionen nicht vereinheitlicht und parallel weitergeführt wurden, entsteht zwangsläufig eine fragmentierte Landschaft.
Die entscheidende Frage lautet daher nicht, ob die Leasing-Software leistungsfähig genug ist. Sondern ob die Organisation bereit ist, strukturelle Entscheidungen zu treffen und historische Sonderlogiken zu hinterfragen.
Reduktion bedeutet Führung
Weniger Komplexität bedeutet nicht weniger Marktkompetenz. Eine Leasinggesellschaft kann hoch differenzierte Produkte anbieten und dennoch einen stabilen, konsistenten Datenkern haben.
Entscheidend ist, dass zentrale Begriffe eindeutig definiert und systemweit identisch interpretiert werden. Das ist keine Detailfrage der IT. Es ist eine Entscheidung der Führung. Sie bedeutet, Ausnahmen bewusst zu begrenzen, historische Konstrukte zu bereinigen und neue Produkte nicht nur vertrieblich, sondern auch architektonisch zu denken.
Fazit
Leasing wird immer komplex bleiben.
Die strategische Frage lautet jedoch:
Ist Ihre Komplexität eine notwendige Folge Ihres Geschäftsmodells, oder das Ergebnis historisch gewachsener und nicht harmonisierter Systementscheidungen?
Wenn Sie morgen eine weitere Refinanzierungsbank anbinden oder ein zusätzliches Portfolio strukturieren müssten, würde Ihr System diese Erweiterung tragen?
Oder würde vor allem Ihr interner Abstimmungs- und Erklärungsaufwand wachsen?

