Inhaltsverzeichnis
< Alle Themen
Drucken

Legacy Software im Private Markets Management: Refactoring, Neubau oder Standardlösung?

1. Wenn der technologische Maßanzug einengt

Viele etablierte Kapitalverwaltungsgesellschaften (KVGen) im Private Markets (PMI) Sektor stehen vor einer strategischen Herausforderung: Ihre über Jahre gewachsene, oft maßgeschneiderte Individualsoftware stößt an ihre Grenzen. Einst als perfekte Lösung für spezifische Bedürfnisse entwickelt – mangels adäquater Standardalternativen oder zur Wahrung vermeintlicher Unabhängigkeit – erweist sich die Legacy-Software heute oft als technologische Bremse. Steigende Wartungskosten, mangelnde Skalierbarkeit, Schwierigkeiten bei der Integration neuer regulatorischer Anforderungen (z.B. SFDR, AIFMD II) und Inflexibilität gegenüber modernen Datenanalyse- und Reporting-Anforderungen zwingen zum Handeln. Doch welche strategischen Optionen existieren, um den technologischen „Maßanzug“, der nicht mehr passt, zu ersetzen oder anzupassen?

Disclaimer: 

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

2. Die Genese des Problems: Warum Legacy-Systeme zur Herausforderung werden

Die Gründe für die heutige Situation sind oft historisch bedingt:

  • Mangel an frühen Standardlösungen: In der Vergangenheit gab es oft keine ausgereiften Branchenlösungen, die die spezifischen Anforderungen des PMI (komplexe Wasserfall-Logiken, LP-Reporting, illiquide Asset-Bewertung) adäquat abbilden konnten.
  • Wunsch nach Kontrolle & Differenzierung: Die Entwicklung einer eigenen Lösung versprach volle Kontrolle über Funktionalität und Daten sowie die Abbildung einzigartiger Prozesse als Wettbewerbsvorteil.
  • Organisches Wachstum & „Flickenteppich“: Über Jahre wurden die Systeme durch Ad-hoc-Anpassungen, Workarounds und Schnittstellen zu anderen Tools erweitert, oft ohne übergreifende Architekturplanung. Dies führte zu hoher Komplexität, mangelnder Dokumentation und steigender technischer Schuld (Technical Debt).
  • Veraltete Technologien: Die zugrundeliegenden Programmiersprachen, Datenbanken oder Architekturen entsprechen oft nicht mehr modernen Standards, was Wartung, Weiterentwicklung und die Integration mit neuen Technologien erschwert und Sicherheitsrisiken birgt.

3. Strategische Handlungsoptionen: Ein kritischer Vergleich

Bevor eine Entscheidung getroffen wird, ist eine gründliche interne Ist/Soll-Analyse und Anforderungsdefinition (wie in unserer Artikelserie zur Softwareeinführung beschrieben) unerlässlich. Erst auf dieser Basis können die folgenden Optionen sinnvoll bewertet werden:

Option 1: Refactoring / Modernisierung der bestehenden Software („Den Maßanzug sorgfältig anpassen“)

  • Ansatz: Gezielte Überarbeitung kritischer Komponenten, Austausch veralteter Technologien (z.B. Datenbank-Upgrade, UI-Modernisierung), Verbesserung der Code-Qualität und Dokumentation, ohne die Kernlogik komplett neu zu schreiben.
  • Vorteile: Potenziell geringere initiale Kosten und kürzere Umsetzungszeit als Neubau/Standardeinführung; Nutzervertrautheit bleibt teilweise erhalten; bewährte Kernlogik kann weiter genutzt werden.
  • Nachteile & Risiken: Hoher Aufwand für Analyse des Altsystems (oft schlecht dokumentiert); Risiko, grundlegende Architekturprobleme nicht zu beheben; weiterhin hohe Abhängigkeit von internem Know-how oder spezifischen Entwicklern; adressiert möglicherweise nicht zukünftige Skalierbarkeits- oder funktionale Anforderungen; kann teurer werden als erwartet („never-ending story“). PMI-Kontext: Besonders kritisch, wenn komplexe, aber veraltete Berechnungslogiken (Fees, Carry) nur „geflickt“ werden oder die Integration moderner Reporting-/Compliance-Anforderungen (ESG-Daten, Look-Through) nur oberflächlich möglich ist.
  • Sourcing: Erfordert tiefes Know-how des Altsystems, oft nur durch interne Entwickler oder spezialisierte (teure) externe Experten möglich.

Option 2: Komplette Neuentwicklung einer Individualsoftware („Maßanfertigung 2.0“)

  • Ansatz: Entwicklung einer komplett neuen Software basierend auf aktuellen Technologien und den neu definierten Anforderungen.
  • Vorteile: Maximale Flexibilität und Passgenauigkeit für spezifische, differenzierende Prozesse; volle Kontrolle über Technologie und Roadmap; keine Kompromisse durch Standard-Workflows.
  • Nachteile & Risiken: Sehr hohe initiale Entwicklungs- und Testkosten; langer Time-to-Market; hohes Projektrisiko (Budget-/Zeitüberschreitungen); Notwendigkeit exzellenter interner oder externer Entwicklungsressourcen und eines sehr reifen Anforderungsmanagements; volle Verantwortung für zukünftige Wartung, Weiterentwicklung und Compliance-Anpassungen. Risiko, alte Logikfehler in neuem Gewand nachzubauen. PMI-Kontext: Nur sinnvoll, wenn die Prozesse so einzigartig sind, dass keine Standardlösung passt und die Kosten/Risiken tragbar sind.
  • Sourcing: Erfordert starke interne IT-/Entwicklungskapazitäten oder eine sehr enge Partnerschaft mit einem spezialisierten Softwareentwicklungshaus.

Option 3: Einführung einer Standardsoftware (+ Konfiguration/Anpassung)/ („Konfektionslösung mit Änderungen“)

  • Ansatz: Auswahl einer etablierten PMI-Branchenlösung (z.B. IMS/PMS wie eFront, Investran, Allvue) und deren Anpassung an die eigenen Bedürfnisse durch Konfiguration und ggf. minimales Customizing.
  • Vorteile: Nutzung erprobter Funktionalitäten und Prozesse; profitiert von der Weiterentwicklung durch den Vendor (Updates, neue Module z.B. für ESG/SFDR); oft schnellere Implementierung als Neubau; geringere interne Entwicklungsressourcen nötig; Anbieter-Support und Community.
  • Nachteile & Risiken: Erfordert oft Anpassung interner Prozesse an die Software-Logik („Software diktiert Prozess“); Abdeckung sehr spezifischer Anforderungen kann schwierig oder teuer sein (Customizing); Vendor Lock-in und Abhängigkeit von der Roadmap des Anbieters; Lizenzkosten können erheblich sein. PMI-Kontext: Die Herausforderung liegt oft darin, eine Standardlösung zu finden, die die spezifischen komplexen Berechnungen (Carry, Wasserfall) und Reporting-Anforderungen flexibel genug abbildet.
  • Sourcing: Implementierung erfolgt oft durch den Vendor selbst oder zertifizierte Implementierungspartner. Starke interne Projektleitung und Key User sind dennoch entscheidend für die Konfiguration und Prozessanpassung.

Option 4: Hybrid-Ansatz / Best-of-Breed („Garderobe neu zusammenstellen“)

  • Ansatz: Kombination aus Kernsystemen (ggf. wird das alte System für bestimmte Kernfunktionen weitergenutzt oder durch eine Standardlösung ersetzt) und spezialisierten Einzellösungen (z.B. CRM, Datenanalyse-Tool, ESG-Plattform, LP-Portal), die über Schnittstellen (APIs) integriert werden.
  • Vorteile: Hohe Flexibilität durch Auswahl der jeweils besten Lösung für eine spezifische Aufgabe; schrittweise Modernisierung möglich; potenziell geringere Abhängigkeit von einem einzigen Anbieter.
  • Nachteile & Risiken: Hohe Komplexität bei der Integration und Wartung der Schnittstellen; Sicherstellung der Datenkonsistenz über Systemgrenzen hinweg ist anspruchsvoll; Management mehrerer Vendor-Beziehungen erforderlich; potenziell unklare Verantwortlichkeiten bei Problemen. Besondere Herausforderung im Hybrid-Ansatz: Die Orchestrierung der End-to-End-Prozesse über mehrere Systeme hinweg wird kritisch. Ohne eine zentrale Steuerungsebene kann es zu Ineffizienzen, Daten-Silos und mangelnder Prozesstransparenz kommen.
  • Rolle von BPM/Workflow-Lösungen: Genau hier setzt die Bedeutung von Business Process Management (BPM)-Systemen oder Workflow-Automatisierungs-Tools an. Sie können als zentrale Orchestrierungsschicht dienen, um Prozesse systemübergreifend zu modellieren, zu steuern, zu überwachen und zu automatisieren. Die Investition in eine solche Lösung kann im Hybrid-Ansatz entscheidend sein, um die Komplexität zu beherrschen und die Vorteile der spezialisierten Systeme tatsächlich zu heben, erfordert aber zusätzliche Implementierungs- und Integrationsaufwände.
  • Sourcing: Erfordert starke interne IT-Architektur- und Integrationskompetenz oder spezialisierte Integrationspartner. Bei Einsatz einer BPM-Lösung kommt zusätzliche Expertise für deren Konfiguration und Prozessmodellierung hinzu.

Zusammenfassende Tabelle (Illustrativ)

LösungKernvorteileKernnachteile/Risiken (PMI-Fokus)Typ. Sourcing
Refactoring LegacyNutzervertrautheit, evtl. geringere InitialkostenTechnische Schuld bleibt oft, Skalierbarkeits-/Compliance-Grenzen (ESG, Reporting), hohe WartungIntern / Spezialisten
Neubau IndividualPerfekter Fit für Uniques, volle KontrolleHohe Kosten/Zeit/Risiko, Wartungslast, Talentbedarf, Zukunftsfähigkeit?Intern / SW-Haus
Standard + ConfigErprobt, Vendor-Updates (Compliance!), schneller startklarProzessanpassung nötig, Vendor Lock-in, Customizing teuer/riskant, passt evtl. nicht 100% für komplexe LogikVendor / Partner
Hybrid / Best-of-BreedFlexibilität, schrittweise ModernisierungIntegrationskomplexität, Datenkonsistenz, multiples Vendor Management, benötigt oft BPM/Workflow-LösungIntern (Architektur!) / Integrator

4. Kritische Entscheidungsfaktoren im PMI-Kontext

Die Wahl der richtigen Strategie hängt von einer Vielzahl unternehmensspezifischer Faktoren ab:

  • Strategische Differenzierung vs. Standardisierung: Welche Prozesse sind wirklich wettbewerbsdifferenzierend und erfordern eine maßgeschneiderte Lösung? Welche Prozesse können effizient durch Standards abgedeckt werden?
  • Komplexität der Fondsstrukturen & Strategien: Multi-Asset-Klassen, komplexe Wasserfallmodelle oder Gebührenstrukturen sprechen eher für flexible (Individual-/Hybrid-) oder sehr anpassungsfähige Standardlösungen.
  • Datenmigrations-Komplexität: Der Zustand, die Struktur und die Dokumentation der Altdaten sind oft ein K.O.-Kriterium. Ist eine Migration aus der Legacy-Software in eine neue Struktur (insbesondere Standardsoftware) überhaupt realistisch und wirtschaftlich darstellbar?
  • Skalierbarkeitsanforderungen: Wie stark sollen die AUM, die Anzahl der Fonds oder die LP-Basis in den nächsten 5-10 Jahren wachsen? Die gewählte Lösung muss dies unterstützen können.
  • Regulatorische & Reporting-Anforderungen: Kann die Lösung aktuelle und absehbare zukünftige Anforderungen (AIFMD, SFDR, ILPA-Reporting etc.) effizient abbilden?
  • Interne IT-Kompetenz & Ressourcen: Verfügt das Unternehmen über das nötige Know-how und die Kapazitäten, eine Individualentwicklung oder komplexe Integrationen (inkl. BPM) langfristig zu betreiben und zu warten?
  • Total Cost of Ownership (TCO): Betrachtung der Gesamtkosten über den Lebenszyklus (Lizenzen, Implementierung, Migration, Customizing, Wartung, interne Ressourcen) statt nur der initialen Investition.

5. Aktuelle Technologietrends als Einflussfaktor

Bei der Modernisierung sollten aktuelle technologische Entwicklungen berücksichtigt werden:

  • Cloud-Native Architekturen: Bieten Skalierbarkeit, Flexibilität und potenziell schnellere Innovationszyklen (SaaS).
  • API-Economy & Interoperabilität: Offene Schnittstellen sind entscheidend für Hybrid-Ansätze und die Integration in das weitere Ökosystem (Datenprovider, Banken etc.).
  • Low-Code/No-Code Plattformen: Können für spezifische Zusatzanwendungen oder zur schnellen Anpassung von Workflows sinnvoll sein, ersetzen aber selten Kernsysteme im regulierten Umfeld.
  • KI & Automatisierung: Können zur Datenextraktion, Prozessautomatisierung (RPA) und für analytische Zwecke genutzt werden, beeinflussen aber eher die Funktionalität als die Kernarchitektur-Entscheidung.

6. Fazit und Handlungsempfehlungen für Entscheider

Die Entscheidung über die Zukunft einer in die Jahre gekommenen Individualsoftware im PMI-Sektor ist eine weitreichende strategische Weichenstellung. Es gibt keine pauschal richtige Antwort; jede der vier Hauptoptionen – Refactoring, Neubau, Standardeinführung, Hybrid – hat spezifische Vor- und Nachteile sowie erhebliche Implikationen für Kosten, Zeit, Risiko und operative Flexibilität. Insbesondere der Hybrid-Ansatz erfordert eine sorgfältige Planung der Prozess-Orchestrierung, wobei BPM- oder Workflow-Lösungen eine kritische Rolle zur Beherrschung der systemübergreifenden Komplexität spielen können.

Strategische Empfehlungen für Experten:

  • Startpunkt: Ehrliche Ist-Analyse: Führen Sie eine tiefgehende Analyse der Legacy-Software (technische Schuld, Risiken) und der aktuellen sowie zukünftigen Geschäftsprozesse und Anforderungen durch.
  • Strategisches Alignment: Bewerten Sie die Optionen klar anhand Ihrer Unternehmensstrategie, Ihrer Kernkompetenzen und Ihrer Bereitschaft zur Prozessanpassung vs. Individualisierung.
  • TCO-Betrachtung: Analysieren Sie die Gesamtkosten über einen Lebenszyklus von mindestens 5-7 Jahren.
  • Datenmigrations-Machbarkeit prüfen: Die Komplexität und die Kosten der Datenmigration können oft die technisch eleganteste Lösung unwirtschaftlich machen.
  • Integrationsstrategie definieren: Insbesondere bei Hybrid-Ansätzen ist eine klare Strategie für Schnittstellenmanagement und Prozess-Orchestrierung (ggf. mit BPM) unerlässlich.
  • Unabhängige Expertise nutzen: Ziehen Sie bei komplexen Auswahl- und Implementierungsprojekten erfahrene, unabhängige Berater hinzu, um interne Betriebsblindheit zu vermeiden und von Best-Practice-Erfahrungen zu profitieren. Eine gründliche interne Vorbereitung und klare Anforderungsdefinition vor der Einbindung von Softwareanbietern ist unerlässlich, um Kostenexplosionen und ineffiziente Lösungen zu verhindern.

Die Modernisierung der IT-Landschaft ist eine Investition in die Zukunftsfähigkeit. Eine sorgfältig abgewogene Entscheidung, basierend auf einer gründlichen Analyse und einer klaren Strategie, ermöglicht es PMI-Akteuren, operative Exzellenz zu erreichen und sich im Wettbewerb erfolgreich zu positionieren.