Thomas, Portfoliomanager bei einem Private Equity Haus, hat eine vielversprechende Idee für ein neues Risikoreporting. Er braucht dafür nur drei zusätzliche Datenfelder im zentralen IBOR-System – beispielsweise „Liquidity Buffer“, „Vintage Category“ oder „FX Exposure Adjusted“. Eine kleine fachliche Anpassung, so denkt er. Er ahnt nicht, dass er damit gerade ein mehrstufiges Projekt mit IT, Vendor, Data Engineering und Testmanagement angestoßen hat. Warum ist das so? Und warum bleiben viele IBOR-Systeme – trotz moderner Architekturversprechen – erstaunlich unflexibel?

Haftungsausschluss: Dieser Artikel dient ausschließlich Informationszwecken und stellt keine Anlageberatung, Rechtsberatung oder verbindliche Handlungsempfehlung dar. Die Ausführungen basieren auf meiner Erfahrung als unabhängiger Senior Business Consultant und Analyst.

1. IBOR-Systeme sind kein freies Datenmodell

Ein IBOR (Investment Book of Record) ist konzeptionell kein Reporting-Tool, sondern die vorkontierende operative Buchführung für das Portfolio- und Cashflow-Management. Es verwaltet:

• Positionen, Instrumente und Bewegungen (Pre-Accounting)
• Bewertungen (Mark-to-Market, Amortized Cost)
• Cash und FX Exposure
• Commitments, Drawdowns, Distributions

Die ABOR (Accounting Book of Record) übernimmt erst danach die eigentliche Verbuchung im Hauptbuch. Das bedeutet: Felder in einem IBOR sind eng mit Buchungslogik, Preisquellen, Eventtypen und Feedstrukturen verknüpft. Neue Felder greifen also nicht nur in ein Schema ein – sie verändern Prozesse, Aggregationen und Kontrollpunkte.

2. Warum drei neue Felder schnell zu einem IT-Projekt werden

a) Vendor-Abhängigkeit

Viele IBOR-Systeme basieren auf geschlossenen, proprietären Datenmodellen. Neue Felder sind dort nicht einfach Konfiguration, sondern eine Schemaänderung – oft mit Codeanpassung oder Erweiterung des Mapping-Layers. Der typische Ablauf: Vendor Request → Impact Assessment → Schema Update → Test → Roll-out. Die Ursache: Der Datenkern ist nicht metadatenbasiert, sondern fest modelliert. Ein neues Feld ist also keine Business-Erweiterung, sondern ein technisches Objekt.

b) IT-Abhängigkeit

Selbst wenn der Vendor nichts anpassen muss, hängt der Feed- und Reportingfluss an der internen IT. Neue Felder erfordern: Anpassung von ETL-Prozessen, Erweiterung von JSON/XML/CSV-Mappings, Regressionstests auf konsistente Aggregation und ein Deployment über das Release-Management. Damit entsteht die paradoxe Situation: Ein Business-Feld wird technisch verankert, obwohl es semantisch nur beschreibend wirkt.

c) Organisatorische Bremse

Da jede Schemaänderung eine Governance-Schleife auslöst (Change Board, QA, UAT), wird ein kleiner Änderungswunsch automatisch zu einem „Major Change“. Die Folge: Das Business kann Feldlogiken nicht mehr selbst steuern – und verliert Agilität im Reporting.

3. Beispielhafte Abhängigkeit

Ebene	Beispiel-Feld	Typische Abhängigkeit	Grund	Mögliche Lösung
Vendor	FX Exposure Adjusted	Vendor Schema	Geschlossenes Datenmodell	External Calculation Layer
IT / Data Engineering	Liquidity Buffer %	ETL-Prozesse	Starres Feed-Design	Data Dictionary Layer
Business	Vintage Category	keine	Nur Reporting	Lokal konfigurierbar (Frontend oder BI)

4. Warum es so ist, wie es ist

Die Wurzel liegt in der Architekturhistorie vieler Systeme: IBORs wurden entwickelt, um buchhalterisch stabile, transaktionsbasierte Datenstrukturen abzubilden – nicht, um semantisch flexible Business-Attribute zu verwalten. Diese Strenge ist kein Designfehler, sondern ein historisch gewachsenes Feature: Sie garantiert buchhalterische Stabilität und Auditierbarkeit, indem sie unkontrollierte Änderungen an der Kernlogik verhindert. In der heutigen, agileren Welt wird dieses Stabilitätsmerkmal jedoch zur Flexibilitätsbremse. Das Design folgt meist einer Batch-getriebenen Logik, bei der jedes zusätzliche Feld in jedem Prozessschritt (Import → Validation → Accounting → Export) bekannt sein muss.

5. Was fehlt: Eine Business-gesteuerte Datenebene

Was den meisten IBOR-Systemen fehlt, ist eine konfigurierbare Metaebene zwischen Business und IT – eine Art „Field Governance Layer“. Diese Ebene definiert jedes Feld im Data Dictionary, hält Format, Typ und Gültigkeit, erlaubt Versionierung und ist unabhängig von der physischen Speicherung. Damit könnten Business-User semantische Erweiterungen selbst definieren, ohne Eingriff in die Kernlogik oder ETL-Ketten.

6. Wie eine moderne Architektur das Problem löst

Ein metadatengetriebenes Modell kann das klassische IBOR-Schema ergänzen, nicht ersetzen. Der Ansatz kombiniert eine stabile Header-Tabelle für Kerndaten mit einer flexiblen Tabelle für dynamische Business-Felder (z.B. über ein EAV-Modell oder eine JSONB-Tabelle). Ein EAV-Modell (Entity-Attribute-Value) kann man sich dabei wie flexible „Etiketten“ vorstellen, die man an einen Datensatz heftet, anstatt feste Spalten zu benötigen. Eine JSONB-Tabelle ist ein flexibler Datencontainer, der direkt in der Datenbank gespeichert wird und keine starre Tabellenstruktur erfordert. So bleiben Systemintegrität und Performance erhalten, während Business-seitige Attribute flexibel verwaltet werden können. Änderungen an Business-Feldern werden zu Metaänderungen, nicht zu Schemaänderungen.

Hinweis: EAV-Modelle können bei sehr großen Datenmengen Performance-Nachteile haben. In der Praxis empfiehlt sich daher oft ein Hybrid-Ansatz: Kern-Performance-Felder bleiben im klassischen Schema, reine Business-Attribute wandern in die flexible Ebene.

7. Beispiel: Feldänderungen als Prozess

1. Business identifiziert ein neues Feld („Liquidity Reserve %“).
2. Prüfung im Data Dictionary: existiert oder ableitbar?
3. Falls neu → Definition mit Typ, Format, RegEx, Verantwortlichem.
4. Deployment über eine „Schema Registry“ → Das System liest die neue Definition beim Start.
5. Governance-Freigabe und Auditlog-Eintrag
6. Deployment über Schema Registry
7. Validierung der Rückwärtskompatibilität bestehender Reports

Resultant: Codeänderung, kein ETL-Rebuild – das Feld steht im Frontend zur Verfügung. So wird eine organisatorische Aufgabe zu einem konfigurativen Schritt – ohne Eingriff in Kernsystem oder Feed.

8. Praxisbezug: IBOR ist keine Allzweck-Datenbank

Viele Front-Office- oder Reporting-Teams erwarten, dass das IBOR flexibel wie Excel funktioniert. Doch das IBOR ist primär ein operatives System mit vorkontierendem Charakter: Jede Änderung wirkt sich potenziell auf Buchungs- oder Bewertungslogik aus, daher sind Felddefinitionen sensibel und kontrollpflichtig. Reporting-Systeme (z.B. Data Warehouse oder BI) sind die richtige Ebene für rein explorative Felder. Ein Meta-Layer kann jedoch helfen, diese Welten zu verbinden – ohne Redundanz und ohne Vendor-Abhängigkeit.

9. Praktische Hürden bei der Umsetzung

Die Idee eines metadatengetriebenen Modells klingt überzeugend – doch die Realität zeigt: Der Weg dorthin ist nicht trivial. Drei zentrale Hürden prägen typischerweise solche Transformationsprojekte:

a) Kostenrealität

Vendor-Schema-Änderungen kosten je nach System zwischen 20.000 und 150.000 Euro – pro Change Request. Bei drei bis fünf Änderungswünschen pro Jahr summiert sich das schnell zu sechsstelligen Beträgen. Ein metadatengetriebenes Modell erfordert zwar eine initiale Investition (Aufbau Data Dictionary, Schema Registry, ggf. API-Layer), amortisiert sich jedoch bereits nach wenigen vermiedenen Vendor-Projekten. Die Business-Case-Rechnung ist meist eindeutig – dennoch scheitern viele Initiativen am fehlenden Budget für „Infrastruktur statt Feature“.

b) Organisatorisches Change Management und Governance-Risiken

Eine flexible Datenarchitektur verschiebt Verantwortung: Business-Teams müssen Felddefinitionen selbst pflegen, Data Governance wird zur aktiven Aufgabe statt zur Kontrollinstanz. Das erfordert neue Skills, klare Rollen (Data Owner, Data Steward) und einen grundlegenden Mindset-Shift: von „IT liefert Felder“ zu „Business definiert semantische Logik“.

Doch genau hier liegt die größte Gefahr: Flexibilität ohne Kontrolle wird schnell zur organisatorischen Falle. Wenn plötzlich jedes Team eigene Felder anlegen kann, entstehen typischerweise:

• Semantischer Wildwuchs: Drei Abteilungen definieren „Liquidity Ratio“ auf unterschiedliche Weise
• Redundanzen: „FX_Exposure“, „Currency_Risk“, „ForEx_Delta“ – alles meint dasselbe Konzept
• Inkonsistente Datenqualität: Felder ohne Validierungsregeln, lückenhafte Dokumentation, diffuse Verantwortlichkeiten

Besonders kritisch wird es, wenn die interne Machtstruktur die fachliche Governance überlagert. In Organisationen mit ausgeprägten Silos oder unklaren Entscheidungswegen beobachtet man regelmäßig:

• Politische Feldkriege: Abteilung A blockiert Feldänderungen von Abteilung B aus territorialen Gründen, nicht aus fachlicher Notwendigkeit
• Shadow IT 2.0: Teams umgehen das Data Dictionary und pflegen Parallelstrukturen in Excel, Access-Datenbanken oder lokalen Tools
• Eskalationsdynamik: Jede Felddiskussion wird zum Machtkampf zwischen Front Office, Risk Management und Finance – fachliche Argumente treten in den Hintergrund

Die gewonnene technische Flexibilität kann so paradoxerweise zur größeren Starrheit führen, weil politische Blockaden die Datenarchitektur lähmen.

Die Lösung liegt daher nicht primär in mehr Technologie, sondern in robuster Governance:

1. Verbindliche Namenskonventionen mit klaren Approval-Workflows – idealerweise über ein Data Council mit Vertretern aller Fachbereiche
2. Technische Guardrails: Automatische Duplikatsprüfung im Data Dictionary, Pflichtfelder für Business-Definition und Owner-Zuweisung, regelbasierte Validierung
3. Neutrale Eskalationsmechanismen: Bei Konflikten entscheidet ein übergeordnetes Gremium nach objektiven Kriterien, nicht die politisch stärkste Abteilung
4. Regelmäßige Data-Hygiene: Quartalsweise Reviews identifizieren nicht genutzte, verwaiste oder redundante Felder – mit verbindlichen Bereinigungsprozessen
5. Training und kultureller Wandel: Business-Teams brauchen nicht nur Tool-Schulungen, sondern ein Verständnis für die Auswirkungen von Dateninkonsistenz auf nachgelagerte Prozesse

Ohne diese organisatorischen Schutzmechanismen kann die gewonnene Flexibilität schnell in Datenchaos umschlagen – besonders in Unternehmen mit historisch gewachsenen Strukturen und konkurrierenden Bereichsinteressen.

c) Legacy-Integration

Bestehende IBOR-Systeme laufen oft seit 10+ Jahren produktiv. Eine nachträgliche Einführung eines Meta-Layers bedeutet nicht nur technische Migration, sondern auch:

• Rückwärtskompatibilität zu Hunderten bestehender Reports und Dashboards
• Mapping-Komplexität: Alte Feldlogiken müssen auf neue Strukturen abgebildet werden
• Parallelbetrieb: Während der Transition laufen beide Systeme gleichzeitig – mit dem Risiko von Dateninkonsistenzen
• Testaufwand: Jede Änderung erfordert umfassende Regressionstests über alle abhängigen Prozesse hinweg

Die pragmatische Lösung ist meist ein Hybrid-Ansatz: Kernfelder mit buchungsrelevanter Logik bleiben im klassischen, stabilen Schema. Nur neue, explorative oder rein beschreibende Business-Attribute laufen über den flexiblen Meta-Layer. So bleibt das Risiko kalkulierbar, während gleichzeitig erste Quick Wins erzielt werden können – etwa bei Reporting-Feldern ohne Auswirkung auf die Buchungslogik.

Diese schrittweise Migration erlaubt es, Erfahrungen zu sammeln, Governance-Prozesse zu etablieren und die Organisation behutsam an die neue Arbeitsweise heranzuführen, bevor kritische Kernprozesse umgestellt werden.

10. Fazit: Flexibilität ist eine Frage der Architektur – und der Governance

Solange Business-Felder technisch fest verdrahtet sind, bleibt jede fachliche Anpassung ein IT- oder Vendor-Projekt. Die technische Lösung liegt in datengetriebener Konfiguration statt Schema-Änderung: Business definiert Was und Warum, das Data Dictionary definiert Wie, und das System implementiert automatisch das Wo.

Doch Technologie allein reicht nicht. Die Praxis zeigt: Der Übergang von starren IBOR-Strukturen zu flexiblen, metadatengetriebenen Modellen erfordert mehr als ein technisches Upgrade. Es ist ein organisatorischer Transformationsprozess, der drei kritische Erfolgsfaktoren vereinen muss:

1. Initiale Investitionsbereitschaft: Die Kosten für Aufbau und Migration müssen gegen wiederkehrende Vendor-Kosten aufgerechnet werden – der Business Case ist meist eindeutig, aber langfristig.
2. Robuste Data Governance: Flexibilität ohne Kontrolle führt zu semantischem Wildwuchs und politischen Feldkriegen. Klare Prozesse, neutrale Eskalationsmechanismen und technische Guardrails sind unverzichtbar.
3. Kultureller Wandel: Business-Teams müssen von passiven Konsumenten zu aktiven Datenverantwortlichen werden – eine Rolle, die Training, Mindset-Shift und organisatorische Rückendeckung erfordert.

Der pragmatischste Weg ist ein Hybrid-Ansatz: Buchungsrelevante Kernfelder bleiben im stabilen, geprüften Schema. Explorative Business-Attribute wandern schrittweise in den flexiblen Meta-Layer. So entsteht Flexibilität dort, wo sie gebraucht wird – ohne die Stabilität des operativen Kerns zu gefährden.

Die Vision bleibt richtig: Eine Architektur, in der Business, IT und Vendor keine Gegenspieler mehr sind, sondern Schichten eines einheitlichen Datenverständnisses. Doch der Weg dorthin verlangt mehr als technische Eleganz – er erfordert organisatorische Reife, klare Governance und die Bereitschaft, Verantwortung neu und klar zu verteilen.

Eine letzte, oft übersehene Wahrheit: Der Vendor liefert das System – aber nicht die Strategie. Ein IBOR-Anbieter kann Ihnen sagen, wie sein System funktioniert, aber nicht, wie es in Ihre spezifische Organisation, Ihre Prozesse und Ihre Machtstrukturen passt. Die Entscheidung zwischen starrem Schema und flexiblem Meta-Layer, die Definition von Governance-Prozessen, das Design eines Hybrid-Ansatzes – das sind konzeptionelle Aufgaben, die fachliches Consulting erfordern, nicht Produktdokumentation. Der Vendor ersetzt nicht das Consulting. Wer glaubt, mit dem Kauf eines modernen IBOR-Systems automatisch auch die organisatorische Lösung eingekauft zu haben, wird am Ende ein technisch leistungsfähiges Tool besitzen – und dennoch dieselben strukturellen Probleme wie zuvor.Governance und die Bereitschaft, Verantwortung neu zu verteilen.