Die Entscheidung für und die Einführung einer neuen Kernsoftwarelösung (z.B. Investment Management System, CRM, Datenplattform) ist für jede Kapitalverwaltungsgesellschaft (KVG) im Private Markets (PMI) Sektor eine hochstrategische Initiative. Sie beeinflusst nicht nur die operative Effizienz, sondern auch die Fähigkeit zur Skalierung, das Risikomanagement, die Compliance und die Qualität der Beziehungen zu Limited Partners (LPs). Eine erfolgreiche Implementierung beginnt lange vor der technischen Umsetzung. Dieser erste Teil eines zweiteiligen Artikels fokussiert auf die kritischen Phasen der strategischen Vorbereitung, der Anforderungsanalyse, der Vendor-Evaluierung und der Vertragsgestaltung – Fundamente, die über den späteren Projekterfolg entscheiden.

Disclaimer: 

Dieser Artikel dient ausschließlich zu Informationszwecken und stellt keine Rechts-, Steuer- oder Finanzberatung dar. Die hierin enthaltenen Informationen sollten vor einer Entscheidungsfindung unabhängig überprüft werden.

Phase 1: Strategische Vorbereitung und Projekt-Setup – Die Weichen richtigstellen

Eine unzureichende Vorbereitung ist eine der häufigsten Ursachen für das Scheitern von Softwareprojekten. Folgende Schritte sind essenziell:

1.1. Definition des Business Case und messbarer Projektziele

Warum wird die neue Software benötigt? Die Antwort muss über vage Wünsche hinausgehen. Ein robuster Business Case quantifiziert den erwarteten Nutzen (z.B. Reduktion manueller Prozesse um X%, Verbesserung der Datenqualität zur Erfüllung von SFDR-Reporting, Verkürzung der Reporting-Zyklen um Y Tage, Erhöhung der Deal-Pipeline-Transparenz) und stellt ihn den geschätzten Gesamtprojektkosten (Lizenz, Implementierung, interne Ressourcen) gegenüber. Die Projektziele müssen SMART (Spezifisch, Messbar, Akzeptiert, Realistisch, Terminiert) sein und mit der übergeordneten Unternehmensstrategie im Einklang stehen.

1.2. Sicherstellung des Executive Sponsorships

Ein aktiver, sichtbarer Sponsor aus dem Top-Management ist unabdingbar. Seine Rolle geht über die reine Budgetfreigabe hinaus: Er muss das Projekt strategisch verankern, bei funktionsübergreifenden Konflikten vermitteln, notwendige Ressourcen durchsetzen und als Eskalationsinstanz dienen. Ohne dieses Commitment von oben fehlt dem Projekt oft die nötige Durchschlagskraft.

1.3. Etablierung einer klaren Projektgovernance

Eine definierte Struktur schafft Klarheit über Rollen und Verantwortlichkeiten:

• Steering Committee (SteCo): Das strategische Entscheidungsgremium, besetzt mit dem Sponsor und Führungskräften der betroffenen Bereiche (z.B. Head of Operations, Head of IT, Head of Investment Team, CFO, CCO). Überwacht Fortschritt, Budget und strategische Ausrichtung.
• Interner Projektleiter: Die zentrale operative Figur. Verantwortlich für Planung, Steuerung, Koordination des internen Teams und Kommunikation mit dem Vendor. Benötigt sowohl Fach- als auch Projektmanagement-Kompetenz.
• Kernprojektteam: Engagierte Vertreter (Key User) aus den Fachbereichen (Operations, Finance, Investment Controlling, Compliance, IT), die Anforderungen definieren, Prozesse mitgestalten und später testen. Ihre Freistellung von operativen Aufgaben ist ein kritischer Erfolgsfaktor.

1.4. Strategische Entscheidung: Interne vs. Externe Projektunterstützung

Die Frage, ob und in welcher Form externe Beratung hinzugezogen wird, ist frühzeitig zu klären. Während interne Projektleiter das Unternehmens-Know-how einbringen, bieten erfahrene, unabhängige Berater oft Vorteile durch ihre Marktübersicht, methodische Expertise im Projektmanagement von Softwareeinführungen, Objektivität bei der Vendor-Auswahl und Erfahrung im Umgang mit typischen Implementierungsrisiken. Mögliche Modelle reichen von einer externen Gesamtprojektleitung über Co-Projektleitung bis hin zum gezielten Coaching oder Sparring für den internen Projektleiter. Die Entscheidung sollte auf einer realistischen Einschätzung der internen Ressourcen, Erfahrungen und der Projektkomplexität basieren.

1.5. Auswahl der Projektmethodik

Die Wahl der Methodik (z.B. klassisches Wasserfallmodell, agil nach Scrum/Kanban, oder ein hybrider Ansatz) beeinflusst den gesamten Projektablauf. Während Wasserfall bei klar definierten Anforderungen und Standardsoftware oft angewendet wird, bieten agile/hybride Methoden mehr Flexibilität bei komplexen Integrationen oder sich ändernden Anforderungen. Die Methodik muss zur Unternehmenskultur, zur Komplexität des Projekts und zur Arbeitsweise des ausgewählten Vendors passen.

Phase 2: Detaillierte Anforderungsanalyse und strukturierte Vendor-Evaluierung

2.1. Tiefgehende Ist-Analyse und Soll-Konzeption

Eine oberflächliche Anforderungsliste reicht nicht aus. Es bedarf einer detaillierten Aufnahme und Analyse der bestehenden End-to-End-Prozesse (inkl. manueller Workarounds!), der genutzten Systeme, der Datenflüsse und der identifizierten Schwachstellen („Pain Points“). Darauf aufbauend wird das Soll-Konzept entwickelt: Wie sehen die optimierten Zielprozesse aus? Welche spezifischen funktionalen Anforderungen ergeben sich daraus (z.B. Unterstützung spezifischer Waterfall-Modelle, automatisierte Berechnung von Carried Interest, Integration von ESG-KPIs, spezifische LP-Reporting-Formate)? Welche non-funktionalen Anforderungen (Performance, Security Audits, Disaster Recovery, Skalierbarkeit) sind kritisch?

2.2. Erstellung eines präzisen Request for Proposal (RFP)

Das RFP ist das zentrale Dokument für die Vendor-Auswahl. Es muss die funktionalen und non-funktionalen Anforderungen klar, detailliert und priorisiert (z.B. Must-have, Should-have) beschreiben. Es sollte auch spezifische Use Cases oder Szenarien enthalten, anhand derer die Anbieter ihre Lösungen demonstrieren sollen. Wichtig sind zudem Fragen zur Technologie, Architektur, Roadmap, zum Support-Modell, zu Referenzkunden und zum Preismodell des Anbieters. Ein internes Bewertungsraster mit klaren Kriterien und Gewichtungen sollte parallel zum RFP entwickelt werden.

2.3. Systematische Marktrecherche und Vendor Shortlisting

Eine breite initiale Marktrecherche (unter Nutzung von Analystenberichten, Plattformen wie PE Stack, Berater-Input, Netzwerk) führt zu einer Long List. Die Antworten auf das RFP und ggf. erste Qualifizierungsgespräche ermöglichen die Reduktion auf eine Short List von typischerweise 2-4 Anbietern, die in die Tiefenprüfung gehen.

2.4. Strukturierte Vendor-Demonstrationen und Proof of Concepts (PoCs)

Die Vendor-Demos müssen über Standardpräsentationen hinausgehen. Sie sollten auf den im RFP definierten Use Cases basieren und die tatsächliche Leistungsfähigkeit des Systems für die spezifischen Anforderungen des Asset Managers zeigen. Bei kritischen, komplexen Anforderungen (z.B. Datenintegration, spezifische Berechnungslogik) kann ein dedizierter, ggf. kostenpflichtiger PoC sinnvoll sein, um die technische Machbarkeit zu validieren, bevor eine finale Entscheidung getroffen wird.

2.5. Umfassende Vendor Due Diligence

Neben der Produktprüfung ist die Bewertung des Anbieters selbst entscheidend: Finanzielle Stabilität, Marktposition und Reputation, Erfahrung im PMI-Sektor, Qualität des Implementierungs- und Support-Teams, Entwicklungs-Roadmap und strategische Ausrichtung (z.B. Übernahmerisiken durch Konsolidierung).

Phase 3: Sorgfältige Vertragsverhandlung und rechtliche Prüfung

Die Vertragsphase legt den rechtlichen und kommerziellen Rahmen für die gesamte Partnerschaft fest und erfordert hohe Sorgfalt.

• Vertragsstruktur: Üblich sind separate Verträge für Softwarelizenzen/-subscriptions (oft Master Subscription Agreement – MSA), Implementierungsleistungen (Statement of Work – SoW, oft auf Werkvertragsbasis für klar definierte Ergebnisse) und laufende Wartung/Support (Service Level Agreement – SLA).
• Kritische kommerzielle Klauseln: Genaue Definition der Lizenzmetrik (Nutzer, AUM, Module etc.), Preisstaffeln, Regelungen für zukünftige Preisanpassungen, Zahlungsmodalitäten (oft meilensteinbasiert für Implementierung).
• Kritische Leistungsklauseln: Detaillierte Beschreibung des Leistungsumfangs (SoW), Abnahmekriterien für Meilensteine, klare Definition von In-Scope vs. Out-of-Scope (Change Request Prozess), Garantien/Gewährleistungen.
• Kritische operative Klauseln (SLAs): Garantierte Verfügbarkeit (Uptime), Reaktions- und Lösungszeiten für Support-Anfragen (nach Schweregrad), Eskalationspfade, Regelungen zu Updates/Upgrades (inkl. Kompatibilität von Customizing).
• Kritische rechtliche Klauseln: Haftungsbegrenzungen, Datenschutz (AV-Vertrag gemäß DSGVO), Vertraulichkeit, Rechte an geistigem Eigentum (insb. bei Customizing), Vertragsdauer und Kündigungsbedingungen, Exit-Management (Datenherausgabe, Übergangsunterstützung).
• Einbindung spezialisierter Rechtsberatung: Angesichts der Komplexität und der finanziellen Tragweite ist die Hinzuziehung von auf IT- und Lizenzrecht spezialisierten Anwälten dringend anzuraten.

Nach erfolgreichem Vertragsabschluss ist die Grundlage für die technische und organisatorische Umsetzung gelegt, die im zweiten Teil dieses Artikels detailliert beleuchtet wird, einschließlich Datenmigration, Testing, Dokumentation und Change Management.