Asset & Wealth Management Technologie: Warum Veränderung nicht von Software handelt sondern von Ergebnissen

Heutige Asset Manager leben in einem Paradox.

Einerseits war Technologie noch nie so leistungsfähig. Plattformen wie SimCorp Dimension versprechen eine durchgängige Front-to-Back-Lösung von der Trade-Erfassung bis zur NAV-Berechnung, von Risikoanalysen bis zum Compliance-Reporting. Andererseits erzielen viele Unternehmen, die solche Plattformen implementieren, nicht die erwarteten Ergebnisse. Implementierungszeitpläne verlängern sich. Die Reibung zwischen Teams nimmt zu. Daten fließen weiterhin nicht sauber durch die Systeme. Mitarbeitende arbeiten parallel mit Tabellenkalkulationen neben „modernen“ Systemen.

Wer ein solches Projekt bereits erlebt hat, weiß, wie vertraut sich dieses Szenario anfühlt.

Und die Wahrheit ist einfach: Technologie ist der einfache Teil. Ergebnisse sind schwierig.

Das Kernproblem

Im Asset & Wealth Management (AWM) ist Komplexität nicht theoretisch sie ist real. Jedes Portfolio ist anders. Jede Anlageklasse hat ihre Besonderheiten. Trade-Lifecycles variieren. Regulatorische Reporting-Anforderungen nehmen jedes Jahr zu. SimCorp Dimension kann all das als Plattform unterstützen jedoch nur, wenn das Fundament darunter (Menschen, Prozesse und Daten) entsprechend vorbereitet ist.

Viele Unternehmen beginnen bei den Funktionen „Wir brauchen NAV, wir brauchen Performance-Attribution, wir brauchen Compliance-Feeds“ und überspringen den entscheidenden Schritt für Erfolg oder Misserfolg: zu verstehen, wie das Geschäft im Tagesablauf tatsächlich funktioniert. Ohne dieses gemeinsame Verständnis werden Designentscheidungen zu Annahmen. Tests geraten zur Nebensache. Teams bauen das System, von dem sie glauben, dass sie es benötigen nicht das System, das sie tatsächlich nutzen.

Deshalb geraten Implementierungen ins Stocken oder liefern Ergebnisse, die technisch korrekt, operativ jedoch kaum nutzbar sind.

Wie ein erfolgreiches Setup aussieht

Ein einfaches Beispiel: Corporate Actions. Für manche Teams sind sie lediglich ein Datenfeed eines externen Anbieters. In der realen AWM-Praxis lösen Corporate Actions jedoch mehrere parallele Prozesse aus:

• Neubewertungen in der Bewertung

• Anpassungen im Audit-Trail

• Auswirkungen auf das Kundenreporting

• Risikokennzeichnungen bei Limitverletzungen

Wenn die Anforderungsaufnahme diese Schritte nicht vollständig abbildet, erzeugt das System NAV-Werte, die nicht den Erwartungen des Finanzbereichs entsprechen und Portfolios, die sich nicht abstimmen lassen.

An diesem Punkt scheitert das Projekt nicht weil die Plattform es nicht leisten könnte, sondern weil der tatsächliche Prozess nicht von Anfang an modelliert wurde.

Die Rolle von Daten und Testing

Selbst bei einer soliden fachlichen Konzeption liegt der zweite Stolperstein häufig in den Daten.

Im AWM verschlechtert sich Datenqualität schnell:

• Instrumente mit fehlenden Identifikatoren

• Nicht übereinstimmende Felder im Security Master

• Unvollständige Corporate-Action-Historien

• Inkonsistente Referenzdaten zwischen Systemen

Ohne saubere Ausgangsdaten wird Automatisierung fragil. Validierungsregeln schlagen fehl. Abstimmungszyklen verlängern sich erheblich. Genau das, was manuell reduziert werden sollte, erzeugt neue, schwer erkennbare Zusatzaufwände.

Testing ist das Gegenmittel allerdings nicht in der Art und Weise, wie viele Teams es heute praktizieren.

Zu viele Projekte betrachten Testing als reines Abnahme-Gate: „Wir testen, sobald die Konfiguration abgeschlossen ist.“ Erfolgreiche Organisationen nutzen Testing hingegen als Designinstrument von Beginn des Projekts an. Stringente Szenarien, Simulationen mit Echtdaten, systemübergreifende Kontrollpunkte, automatisierte Regressionstests all das transformiert Testing vom Kostenfaktor zur Fähigkeit zur Risikominimierung.

Was das für AWM-Führungskräfte bedeutet

Unternehmen, die nachhaltig Mehrwert aus AWM-Plattformen ziehen, beherrschen drei Dinge:

1. Sie richten Business und IT an realen Workflows aus.

Nicht an Feature-Listen. Nicht an Wunschkatalogen. Sondern an tatsächlichen Arbeitsabläufen.

2. Sie behandeln Daten von Anfang an als strategisches Asset.

Nicht als Nachgedanken. Nicht als späte Bereinigungsmaßnahme.

3. Sie verstehen Testing als Teil des Designs, nicht der Auslieferung.

Testing wird zur Strategie für Vertrauen nicht nur zum Meilenstein für den Go-Live.

Hier entsteht der tatsächliche Mehrwert eines Beratungspartners nicht durch den Verkauf von Lizenzstunden, sondern durch die Unterstützung bei der präzisen Problemdefinition, der Stakeholder-Alignment und der systematischen Verankerung von Sicherheit im Veränderungsprozess.

Denn am Ende zählt nicht die gewählte Software sondern die Ergebnisse, die sich nachweislich erzielen lassen.