Wenn der Projektplan zur Kulisse wird Warum Projektpläne in Refinanzierungsprojekten oft zur Kulisse werden und was Entscheidungsarchitektur stattdessen leistet

Das Muster, das sich wiederholt

In Projekten rund um ABS-Strukturierungen, Warehouse-Linien oder die Neuverhandlung von Refinanzierungsrahmenverträgen zeigt sich immer wieder dasselbe: Projektteams arbeiten mit Zeitplänen, die implizit annehmen, dass regulatorische Rahmenbedingungen stabil bleiben, Ratingagenturen nach bekanntem Muster urteilen und die Investorenbasis reagiert wie in der letzten Transaktion.

Tritt dann eine dieser Annahmen nicht ein, die EBA veröffentlicht ein Konsultationspapier, das die Risikogewichtung in der laufenden Struktur berührt, oder ein Kerninvestor signalisiert geänderte Allokationspräferenzen, gerät der Projektplan nicht ins Wanken. Er bleibt formal intakt. Nur die dahinterliegenden Entscheidungen werden stillschweigend aufgeschoben, umformuliert oder an neue Arbeitspakete delegiert, die selbst keinen klaren Entscheidungsrahmen haben.

Das Ergebnis: Projekte laufen weiter, aber sie laufen leer.

In Projekten, die wir systemseitig begleiten, beobachten wir dieses Muster mit einer spezifischen Ausprägung: Der Moment, in dem eine Entscheidung faktisch getroffen wurde, weil ein Zeitfenster geschlossen ist oder eine Vertragsklausel gegriffen hat, lässt sich im Nachhinein oft nicht auf einen Statusbericht zurückführen. Er war nie als Entscheidungspunkt markiert, also wurde er nie als solcher behandelt. Die Entscheidung hat sich durch Unterlassen vollzogen.

Warum das so passiert

Der Grund liegt nicht in schlechtem Projektmanagement. Er liegt in einem strukturellen Missverständnis darüber, was Planung in einem unsicheren Umfeld leisten kann.

Leasinggesellschaften und Refinanzierungsbanken operieren in einem Marktumfeld, das zwei konkurrierende Logiken gleichzeitig bedient: Auf der einen Seite steht die Steuerungslogik institutioneller Investoren und Aufsichtsbehörden, die Planbarkeit, Konsistenz und dokumentierte Entscheidungsprozesse verlangen. Auf der anderen Seite steht die operative Realität, in der Spread-Niveaus innerhalb von Wochen kippen, ESMA-Leitlinien zu laufenden Strukturen nachträglich interpretiert werden und Servicer-Anforderungen sich zwischen Term Sheet und Closing ändern.

Ein Projektplan, der unter diesen Bedingungen so tut, als könnte er Unsicherheit durch Detaillierung auflösen, schafft keinen Halt, er schafft eine Kulisse. Teams agieren dann nicht mehr auf Basis von Lageeinschätzungen, sondern auf Basis von Planabweichungen. Der Unterschied ist erheblich: Planabweichungen erklären Vergangenheit. Lageeinschätzungen ermöglichen Entscheidungen.

Die gängige Reaktion. Wo sie hilft, und wo nicht

Die häufigste Antwort auf dieses Problem lautet: mehr Szenarienplanung. Best Case, Base Case, Stress Case - dokumentiert, versioniert, im Governance-Bericht hinterlegt.

Das ist in bestimmten Projektphasen das richtige Werkzeug. In der frühen Strukturierungsphase, wenn Investorenmandate noch sondiert werden und die Frage offen ist, welche Tranchenstruktur überhaupt platzierbar ist, schafft Szenarienplanung den gemeinsamen Referenzrahmen, ohne den Gespräche mit Arrangeur und Rating-Analysten nicht sinnvoll geführt werden können. Auch in der Investorenansprache, wenn ein neues Investorensegment erschlossen werden soll, das andere Rendite- und Risikoerwartungen mitbringt als die Bestandsinvestoren, ist ein ausgearbeitetes Szenarienset keine bürokratische Übung, sondern Kommunikationsmittel.

Das Problem beginnt, wenn Szenarienplanung nicht als Kommunikationswerkzeug, sondern als Entscheidungsersatz genutzt wird. In der Praxis führt eine überbordende Szenarienlandschaft in späteren Projektphasen oft dazu, dass Entscheidungsträger nicht schneller entscheiden, sondern später, weil sie auf Klärung warten, die der Szenarienrahmen als erreichbar suggeriert hat.

Was dann fehlt, ist keine weitere Dokumentationsschicht. Was fehlt, ist die explizite Unterscheidung zwischen Entscheidungen, die heute getroffen werden können, und Entscheidungen, die heute getroffen werden müssen, auch wenn relevante Parameter noch offen sind.

Eine unbequeme These

Unsicherheit in Projekten zu managen bedeutet nicht, sie zu reduzieren. Es bedeutet, handlungsfähig zu bleiben, während sie anhält.

Das ist keine Selbstverständlichkeit und sie trifft nicht alle Marktteilnehmer gleich. Captive-Leasinggesellschaften, die in Konzernstrukturen mit Mutterbank-Backup operieren, haben in Engpasssituationen einen Rückkanal: Die Mutterbank kann temporäre Liquidität bereitstellen, Entscheidungsfristen verlängern oder als stiller Ankerinvestor fungieren. Das verändert den Druck, unter dem Entscheidungen getroffen werden müssen und manchmal auch die Qualität dieser Entscheidungen, weil der Puffer Aufschübe möglich macht, die strukturell nicht sinnvoll sind.

Unabhängige Leasinggesellschaften mit direkter Kapitalmarktexposition haben diesen Puffer nicht. Für sie ist die Fähigkeit, bei offenen Parametern zu entscheiden, keine Frage der Projektdisziplin, sie ist eine Frage der Refinanzierungsfähigkeit. Wer in einem engen Platzierungsfenster auf Klärung wartet, die nicht kommt, verliert nicht nur Zeit, sondern Konditionen.

Leasinggesellschaften mit mehreren parallelen Refinanzierungslinien - ABS, bilaterale Kreditrahmen, Pfandbriefbanken - tragen dabei zusätzlich das Koordinationsproblem: Diese Linien laufen mit unterschiedlichen Laufzeiten, unterschiedlichen Covenantstrukturen und unterschiedlichen Investorenlogiken. Wer Handlungsfähigkeit davon abhängig macht, dass Unsicherheiten sich auflösen, bevor Entscheidungen getroffen werden, wird unter diesen Bedingungen systematisch zu spät agieren.

Was eine Entscheidungsarchitektur konkret bedeutet

Der Begriff Entscheidungsarchitektur meint hier keine Methode, sondern eine operative Struktur: die vorab definierte Zuordnung von Entscheidungspunkten, Informationsminima (die Datenpunkte, die mindestens vorliegen müssen, damit eine Entscheidung getroffen werden kann) und Zuständigkeiten, eingebettet in den Projektplan, nicht nachträglich an ihn angehängt.

Die Projekte, die unter Unsicherheit funktionieren, haben eine andere Struktur als die, die an ihr scheitern: Sie definieren nicht nur Meilensteine, sondern für jeden relevanten Entscheidungspunkt drei Dinge, welche Informationen mindestens vorliegen müssen, wer entscheidet, und was bei einer Fehlentscheidung reparierbar ist und was nicht. „Wir entscheiden, sobald wir mehr wissen" ist kein Entscheidungsrahmen. „Wir entscheiden am 14. März auf Basis dieser drei Parameter, unabhängig davon, was noch offen ist" - das ist einer.

Das zeigt sich an einem typischen Fall: Eine Leasinggesellschaft steht vor der Entscheidung, eine Warehouse-Ankaufslinie zu aktivieren, während das Ratingmandat für die geplante ABS-Transaktion noch aussteht. Der Entscheidungspunkt ist nicht „Rating abwarten". Er ist: Ist der Puffer zwischen erwartetem Asset-Yield und Worst-case-Finanzierungskosten größer als der historische Spread-Bewegungsspielraum? Wenn ja, ist die Aktivierung ökonomisch vertretbar, unabhängig vom Rating-Ergebnis. Wer entscheidet, ist vorab benannt: Treasury und Strukturierung gemeinsam, mit Sign-off der Geschäftsführung. Was bei Fehlentscheidung passiert, ist vorab bewertet: ein Konditionsproblem, kein Liquiditätsproblem, solange die Warehouse-Linie ausreichend Laufzeit hat. Das ist die Frage, die vor Aktivierung zwingend beantwortet sein muss. Alle anderen können offen bleiben.

Welche Systemanforderungen hart terminierte Entscheidungspunkte erzeugen

Damit das in der Praxis funktioniert, stellt sich unmittelbar eine weitere Frage: Woher kommen die Informationen, auf denen der Entscheidungspunkt aufbaut?

Eine Entscheidungsarchitektur funktioniert nur, wenn die Informationsminima zum definierten Entscheidungszeitpunkt tatsächlich verfügbar sind, in der richtigen Granularität, aus einer belastbaren Quelle, ohne manuelle Aufbereitungsschritte, die ihrerseits Zeit kosten.

Genau die Datenpunkte, die für strukturierte Kreditentscheidungen im Leasing zentral sind - Over-Collateralisation-Level, Eligibility-Status der einzelnen Forderungen, Covenant-Schwellen — sind in ihrer Kombination deshalb kritisch, weil sie nicht unabhängig voneinander bewertet werden können: Ein Pool, der vom Übersicherungsniveau her komfortabel aussieht, aber Eligibility-Ausreißer enthält, kann eine Warehouse-Entscheidung kippen, die auf Basis einer Einzelkennzahl vertretbar gewirkt hätte. Das sind keine abstrakten Datenanforderungen, es sind Abfragen, die in vielen Häusern heute noch manuell aus mehreren Quellsystemen zusammengezogen werden: Vertragsdatenhaltung, Forderungsmanagement, Treasury-Systeme, teilweise noch Excel-basierte Covenant-Tracker.

Wer Entscheidungspunkte hart terminiert, macht damit implizit Aussagen über seine Datenbasis. Ein Entscheidungsrahmen, der auf Informationen aufbaut, die erst zwei Wochen nach dem Entscheidungsdatum vollständig vorliegen, ist kein Entscheidungsrahmen, er ist eine nachträgliche Rationalisierung. Die Konsequenz ist nicht, auf Entscheidungsarchitektur zu verzichten, sondern sie mit einer ehrlichen Bestandsaufnahme der eigenen Daten- und Systemlandschaft zu beginnen.

Was das für die Praxis bedeutet

Konkret bedeutet das, die Projektvorbereitung um eine Komponente zu erweitern, die in den meisten Steuerungsframeworks fehlt: die eben beschriebene Entscheidungsarchitektur, mit expliziten Punkten, benannten Informationsminima, klaren Zuständigkeiten und einer nüchternen Einschätzung, welche Fehlentscheidungen reversibel sind und welche nicht.

Das erfordert auch eine andere Rolle der Projektsteuerung. Statt Abweichungen zu dokumentieren, muss sie aktiv markieren, welche Annahmen der laufenden Planung noch valide sind und welche stillschweigend ungültig geworden sind, ohne dass das im Statusbericht auftaucht. In Projekten, die wir systemseitig begleiten, ist das der Punkt, an dem der größte Nachholbedarf besteht: nicht bei der Dokumentation von Entscheidungen, die getroffen wurden, sondern bei der Sichtbarkeit von Annahmen, die still entschieden wurden.

Zum Schluss

Wenn Sie in Ihrem nächsten Steuerungskreis den aktuellen Projektplan aufschlagen, wie viele der dort eingetragenen Meilensteine sind echte Entscheidungspunkte mit benannten Informationsminima und klarer Zuständigkeit, und wie viele sind Koordinationstermine, die so aussehen wie Entscheidungspunkte?

Wenn die Antwort unbequem ist, liegt das meistens nicht an fehlender Disziplin. Es liegt daran, dass die Infrastruktur, systemseitig wie prozessual, bisher nicht darauf ausgelegt war, Entscheidungen zu erzwingen, bevor alle Unsicherheiten beseitigt sind. Das zu ändern ist kein Kulturprojekt. Es beginnt damit, beim nächsten Projekt einen einzigen Entscheidungspunkt so zu bauen, wie er gebaut sein sollte: mit Datum, Parametern, Zuständigkeit und einer expliziten Antwort auf die Frage, was bei einer Fehlentscheidung passiert. Der Rest ergibt sich, nicht aus Planung, sondern aus dem, was dieser erste Punkt sichtbar macht.