Warum Leasing-IT-Projekte oft länger dauern als geplant

Wer in der Leasingbranche ein neues IT-System einführt, kauft im Kern keine Software. Er kauft die Fähigkeit, Konditionsmodelle, Ausnahmeregeln, gewachsene Vertragslogiken und historische Sonderstrukturen digital abzubilden und das so, dass Buchungslogik, Reporting und Refinanzierungsmeldung dabei nicht auseinanderfallen.

Das Muster, das sich wiederholt

In Projekten, bei denen neue Kernsysteme oder Refinanzierungsplattformen eingeführt werden, zeigt sich regelmäßig das gleiche Bild: Die erste Projektphase läuft reibungslos. Stammdaten, Vertragsarten, Buchungslogik, das sind bekannte Felder, die sich gut in Anforderungsdokumenten fassen lassen. Schwieriger wird es, wenn es um die Abbildung der individuellen Kundenkonditionen geht. Dann tauchen Fragen auf, die im Lastenheft noch gar nicht standen: Wie behandelt das System Sondertilgungsvereinbarungen, die mündlich mit dem Händler getroffen wurden? Was passiert mit historischen Vertragsstrukturen, die vor der Systemumstellung entstanden sind und nicht in die neue Logik passen? Welche Ausnahmen gelten für den einen Großkunden, dessen Rahmenvertrag in einer Excel-Datei lebt?

Nicht die Standardprozesse kosten Zeit, sondern die Spezialfälle, die jedes Haus über Jahre in seine Abläufe eingewoben hat und die sich als “eigentlich selbstverständlich” beschreiben lassen.

Warum das so entsteht

Leasinggesellschaften arbeiten in einem Markt, in dem Produktdifferenzierung stark über Konditionen stattfindet. Ein Hersteller-Captive hat andere Restwertstrategien als ein bankenunabhängiger Fullservice-Anbieter. Diese Individualität ist kein Fehler im System, sie ist das Produkt. Und genau deshalb lässt sie sich nicht pauschal in einen Standardkonfigurator pressen.

Flexibilität in der Software-Architektur ist nicht dasselbe wie Flexibilität in der Kundenlogik. Ein mittelgroßer Mobilitätsdienstleister stellt das spätestens beim ersten Testlauf mit echten Bestandsdaten fest: Im Lastenheft stehen drei Vertragstypen, im Bestand existieren für einen einzelnen Flottengroßkunden sieben Konditionsvarianten, entstanden über Jahre durch mündlich vereinbarte Anpassungen, keine davon im CRM hinterlegt. Das Projektteam erfährt davon kurz vor dem geplanten Go-live. Die Entscheidung: vier der sieben Varianten werden im neuen System abgebildet, die restlichen drei, volumenseitig marginal, bleiben vorerst außerhalb und werden manuell nachgehalten. Der Go-live verschiebt sich um einige Wochen, nicht um Monate. Eine bewusste Priorisierung hat das Projekt gerettet, nicht das Lastenheft.

Auf der Refinanzierungsseite zeigt sich dasselbe Muster in anderem Gewand. Unterschiedliche Pooling-Strukturen, granulare regulatorische Meldeerfordernisse oder abweichende Bewertungslogiken zwischen Refinanzierungsbank und Leasinggesellschaft produzieren bei der Datenmigration ähnliche Überraschungen, nur dass sie oft erst sichtbar werden, wenn die erste Testmeldung an die Bank zurückkommt.

Die unvollständige Sichtweise

Die gängige Reaktion auf Verzögerungen ist, bessere Anforderungsdokumente zu fordern. Detailliertere Lastenhefte, mehr Workshops im Vorfeld, schärfere Abnahmekriterien. Das ist nicht falsch, aber es greift zu kurz. Denn ein erheblicher Teil der Komplexität lässt sich gar nicht vorab dokumentieren, weil er nicht explizit ist. Die Mitarbeiterin im Backoffice, die seit acht Jahren weiß, dass bei diesem Händlertyp die Provision anders gebucht wird, hat das nie aufgeschrieben. Der Kundenbetreuer, der seinen Großkunden kennt, formuliert seine Anforderung als Sonderfall, dabei ist es bei genauerem Hinsehen eine Regel, die für eine ganze Kundengruppe gilt.

Was in der Praxis auffällt: Projektbeteiligte sagen häufig Sätze wie „ich hätte erwartet, dass ein Standardsystem das doch wohl können muss" oder „ich mache doch nur…" – und meinen damit etwas, das für sie trivial klingt, in der Systemlogik aber einen eigenen Abbildungsaufwand erzeugt. Die entscheidenden Schwierigkeiten liegen stets in den Details. Jede Leasinggesellschaft arbeitet ein wenig anders und genau diese kleinen Unterschiede summieren sich im Projekt zu den großen Verzögerungen.

Wer Leasingprojekte nur als IT-Implementierungen betrachtet, unterschätzt den Anteil an gewachsenem Betriebswissen, der erst im Projektverlauf ans Licht kommt. Das ist keine Schwäche der Beteiligten, es ist die strukturelle Eigenschaft eines Geschäfts, das über Jahre gewachsen ist und bei dem operative Ausnahmen oft schneller entstanden sind als Prozessdokumentation.

Die Komplexität eines Leasingprojekts ist nicht technischer, sondern organisatorischer Natur. Das neue System war schnell genug konfiguriert, das Problem war nicht die Software, sondern dass niemand im Projektteam wusste, was der Bestand tatsächlich enthält. Wer das nicht einpreist, plant an der Realität vorbei. Und wer es erst spät herausfindet, zahlt den Preis in Form von Zeitdruck, Nachverhandlungen und einem Go-live, der unter Vorbehalt stattfindet.

Was das für die Praxis bedeutet

Ein realistisches Leasingprojekt beginnt nicht mit der Systemkonfiguration, sondern mit einer Analyse der tatsächlichen Konditionslandschaft im Bestand. Welche Vertragskonstellationen existieren und wie viele davon weichen vom Standardmodell ab? Diese Zahl ist in den meisten Häusern größer als erwartet.

Daraus folgt eine Priorisierungsentscheidung: Welche Kundenindividualitäten sollen systemseitig abgebildet werden, und welche können außerhalb des Systems bleiben, weil der Aufwand in keinem Verhältnis zum Volumen steht? Diese Entscheidung muss bewusst und schriftlich getroffen werden, bevor die Entwicklung beginnt, nicht als Reaktion auf einen späten Testlauf.

Und schließlich: Wer im operativen Betrieb kennt Ausnahmen, die nirgendwo dokumentiert sind? Diese Person gehört in Phase 1 ans Testen, nicht erst wenn der Zeitplan bereits unter Druck steht.

Was ein erfahrener Implementierungspartner anders macht

Ein Implementierungspartner, der diese Dynamik kennt, setzt vor Projektstart auf eine strukturierte Konditionslandschaft-Analyse: Welche Vertragstypen, Ausnahmeregeln und historischen Sonderstrukturen existieren tatsächlich im Bestand? Im Anschluss folgt ein Priorisierungsworkshop mit operativen Fachkräften, nicht mit dem Projektteam allein, in dem festgelegt wird, was ins neue System muss und was nicht. Die eigentliche Implementierung läuft dann in iterativen Teststrecken auf Basis echter Bestandsdaten, nicht auf Musterfällen. Das verlagert die unvermeidlichen Überraschungen von der Schlussphase in Phase 1, wo sie noch handhabbar sind.

Leasinggesellschaften, die das verstehen, hören auf, Projektverzögerungen als Planungsfehler zu behandeln und beginnen, sie als Erkenntnisprozess zu strukturieren. Der Unterschied liegt nicht im Lastenheft. Er liegt darin, wer in Phase 1 mit am Tisch sitzt und welche Daten dabei auf dem Bildschirm liegen.