Vom Datensilo zur integrierten Datenbasis:

Wir wurden von unserer Leserschaft außergewöhnlich oft auf den Artikel „Liquiditätsplanung in heterogenen Systemlandschaften“ (Treasury Newsletter Nr. 140) angesprochen, in dem wir die Herausforderungen, denen sich Treasury-Abteilungen bei der Liquiditätsplanung gegenübersehen, beleuchteten: steigende Zinsen, volatile Märkte und oft eine historisch gewachsene, heterogene IT-Landschaft, die eine genaue Steuerung erschwert. Als flexible und pragmatische Lösung wurde der Einsatz moderner BI-, ETL- und Advanced Analytics-Plattformen vorgestellt, um Daten aus unterschiedlichen Quellen zu integrieren und aufzubereiten. Es besteht Interesse in unserer Leserschaft, wie dieser entscheidende erste Schritt in der Praxis aussieht. 

Demzufolge taucht dieser Artikel tiefer ein und zeigt anhand konkreter Beispiele, wie die Datenanbindung verschiedener Quellen funktioniert und wie durch eine durchdachte Datenmodellierung das Fundament für eine verlässliche und analysefähige Liquiditätsplanung geschaffen wird – auch ohne eine vollintegrierte Systemlösung. 

Das Ziel: eine zentrale, strukturierte und vertrauenswürdige Datenbasis als Ausgangspunkt für alle weiteren Analysen und Planungen.

Der erste Schritt zur Überwindung der Datensilos ist die technische Anbindung der relevanten Quellsysteme an die zentrale Datenanalyse- und Automatisierungsplattform (im Folgenden "Plattform"). Diese Plattformen bieten typischerweise eine Vielzahl von Konnektoren und Methoden, um auf unterschiedliche Datenformate und Systeme zuzugreifen. Flexibilität ist hier Trumpf.

• ERP-Systeme (z.B. SAP S/4HANA, SAP ECC, Oracle Financials): Das Herzstück vieler Finanzdaten.
  
  • Konkretes Beispiel (SAP): Statt aufwändiger Eigenentwicklungen nutzen viele Plattformen (wie Alteryx, Power BI, Tableau Prep) zertifizierte Konnektoren. Eine gängige Methode ist der Zugriff via ODP (Operational Data Provisioning), der es erlaubt, standardisierte Extraktoren (DataSources) für Finanzbuchhaltung (z.B. FI-GL, FI-AP, FI-AR) oder sogar spezifische Treasury-Module (SAP TRM) anzuzapfen. Alternativ können Remote Function Calls (RFCs) genutzt werden, um sogenannte Business Application Programming Interfaces (BAPIs) aufzurufen. Direkte Datenbankabfragen auf Tabellen sind technisch möglich, aber oft aus Performance- und Governance-Gründen nicht empfohlen. Ein pragmatischer, wenn auch weniger eleganter Weg, bleibt der automatisierte Export von Berichten oder Tabellen in Formate wie CSV oder XLSX und deren anschließender Import in die Plattform.
  • Wichtig: Klären Sie Zugriffsrechte und nutzen Sie dedizierte technische User mit minimal notwendigen Berechtigungen.
• Bankdaten (Kontoinformationen): Unverzichtbar für die IST-Cashflow-Analyse.
  • Konkretes Beispiel: Elektronische Kontoauszüge in Standardformaten wie MT940  oder camt.053 sind der Standard. Viele Plattformen bieten Module oder erlauben Skripte (z.B. Python), um diese Dateien automatisiert von einem SFTP-Server der Bank oder eines Service-Providers (z.B. TIS, Serrala) abzuholen. Die Plattform verarbeitet dann die XML- oder MT940-Struktur und extrahiert relevante Felder wie Valuta, Buchungsdatum, Betrag, Währung, Verwendungszweck und Kontrahentendaten (sofern vorhanden). Zunehmend wichtiger werden auch direkte Banken-APIs (im Rahmen von PSD2/XS2A oder spezifische Corporate-APIs), die einen zeitnahen, oft transaktionsbasierten Abruf ermöglichen und direkt über die Plattform angesprochen werden können.
• Treasury Management Systeme (TMS, z.B. Coupa Treasury, Kyriba, ION Treasury): Quelle für Finanzgeschäfte, Bankkontenverwaltung, Garantien etc.
  • Konkretes Beispiel: Viele moderne TMS bieten REST-APIs, über die Daten wie fällige FX-Geschäfte, Geldmarktanlagen oder Darlehensauszahlungen/-tilgungen abgerufen werden können. Alternativ ist oft ein direkter Datenbankzugriff (SQL) auf die TMS-Datenbank möglich oder der klassische Export von Daten in CSV-Dateien, die dann von der Plattform verarbeitet werden. Ziel ist es, z.B. zukünftige Cashflows aus bereits abgeschlossenen Finanzgeschäften in die Planung zu integrieren.
• Excel-Dateien und andere Flat Files: Oft genutzt für manuelle Planungsdaten oder Daten aus Nischensystemen.
  • Konkretes Beispiel: Das Controlling liefert monatlich eine Excel-Datei mit der Umsatzplanung pro Gesellschaft auf einem definierten Netzlaufwerk ab. Die Plattform ist so konfiguriert, dass sie diesen Ordner überwacht, neue Dateien erkennt, deren Struktur validiert (z.B. Spaltennamen, Datenformate) und die Plandaten importiert. Ähnliches gilt für HR-Daten (geplante Gehaltszahlungen) oder spezifische Projektdaten.
  • Herausforderung: Sicherstellung einer konsistenten Struktur und Benennung der Dateien und Arbeitsblätter.

Die Stärke der Plattformen liegt darin, diese unterschiedlichen Anbindungsmethoden zu kombinieren und den Prozess des Datenladens zu automatisieren und zu überwachen. Fällt eine Quelle aus oder kommt eine neue hinzu, kann dies oft mit überschaubarem Aufwand angepasst werden.

Die Rohdaten aus den verschiedenen Quellen sind selten direkt für eine kohärente Liquiditätsplanung nutzbar. Sie liegen in unterschiedlichen Strukturen, Detailgraden und Qualitäten vor. Die Datenmodellierung schafft eine einheitliche, logische Struktur, die als "Single Source of Truth" für alle Analysen und Reports dient. Ein bewährter Ansatz hierfür ist das sogenannte Star Schema (Sternschema).

• Konzept: Im Zentrum steht eine oder mehrere Faktentabellen, die die eigentlichen Messgrößen (hier: Cashflows) enthalten. Um diese Faktentabellen gruppieren sich Dimensionstabellen, die beschreibende Attribute liefern (Wer, Was, Wann, Wo?).
• Faktentabelle(n): Das Herzstück
  Konkretes Beispiel: Man benötigt mindestens eine Faktentabelle für die IST-Cashflows (aus Bankdaten/ERP) und oft eine separate für PLAN-Cashflows (aus Planungstools, Excel, TMS-Fälligkeiten).
  • Faktentabelle ActualCashflows
    Wichtig in dieser Tabelle sind die Kennzahlenfelder zu den Beträgen in lokaler und in gruppenweiter Währung. Darüber hinaus wird eine Verknüpfung zu den Dimensionstabellen aufgebaut. Im Wesentlichen zur Zeit-, Konto-, Firmen- und Währungsdimension. Nicht zu vergessen ist die Verknüpfung zu Dimension, die die Planpositionsinformationen enthält.
  • Faktentabelle PlannedCashflows
    Diese Tabelle ist ähnlich aufgebaut, wie die Tabelle ActualCashflows, jedoch enthält sie als Kennzahlfeld den jeweiligen Planungsbetrag. Als zusätzliche Dimensionsinformation kann noch das Planungsszenario hinzugefügt werden.
• Dimensionstabellen: Der Kontext
  • Zeitdimension (DimTime): Essenziell für jede zeitbasierte Analyse.
    Die Zeitdimension sollte alle trivialen Felder enthalten. Zusätzlich können hier auch unternehmensspezifische Kalenderinformationen abgelegt werden. Beispielsweise welches Datum als Monatsstichtag verwendet wird (letzter Kalendertag vs. letzter Arbeitstag) oder entity-spezifische Feiertage. Diese Tabelle wird einmalig generiert und deckt einen relevanten Zeitraum ab (z.B. 2010-2030).
  • Planpositionsdimension (DimPlanningPosition): Die zentrale Strukturierung aus Treasury-Sicht. Hier wird die im ersten Artikel erwähnte "sauber definierte Planungsposition" abgebildet.
    Neben einem Primärschlüssel und der Bezeichnung der Planungspositionen (und etwaiger weiterer Metainformationen) wird hier auch die Hierarchiestruktur der Planungspositionen abgebildet.
    Diese Dimension muss sorgfältig mit dem Treasury definiert werden und bildet die Basis für das spätere Mapping der Rohdaten im ETL-Prozess.
  • Gesellschaftsdimension (DimCompanyCode): Stammdaten der eigenen Unternehmenseinheiten.
  • Bankkontodimension (DimBankAccount): Stammdaten der eigenen Bankkonten.
  • Währungsdimension (DimCurrency): Liste der relevanten Währungen.
  • Geschäftspartnerdimension (Optional) (DimCounterparty): Falls Debitor-/Kreditor-Informationen aus den Quellen extrahiert werden können.
  • Szenarioanalysedimension (Optional) (DimSzenario): Sollten Plandaten zu verschiedenen Szenarien erstellt werden, werden hier die benötigten Informationen abgelegt. Beispielsweise: Name des Szenarios und Parameterdaten.

Dieses strukturierte Modell ist das Ziel des ETL-Prozesses (Extract, Transform, Load), der die Rohdaten aus den angebundenen Quellen extrahiert, sie bereinigt, transformiert (z.B. Mappings auf Planpositionen durchführt, Währungen umrechnet) und schließlich in dieses Zielmodell lädt. Das Modell selbst bietet dann die saubere, konsistente Grundlage für Dashboards, Reports und weiterführende Analysen wie Plan-Ist-Vergleiche oder Forecasts.

Die systematische Anbindung aller relevanten Datenquellen und die Schaffung eines durchdachten, zentralen Datenmodells sind keine trivialen Aufgaben, aber sie sind der entscheidende Grundstein für eine erfolgreiche und effiziente Liquiditätsplanung, gerade in komplexen Systemlandschaften. Sie ersetzen nicht die Notwendigkeit einer sauberen Datenerfassung an der Quelle, ermöglichen aber dem Treasury, die Kontrolle über die Daten zu gewinnen und eine einheitliche Sicht herzustellen. BI/ETL-Plattformen bieten hierfür die nötige technische Flexibilität. Zur Implementation des Datenmodells bietet es sich an, auf bereits im Unternehmen existierende Plattformen zurückzugreifen. Das könnten beispielsweise Datenbanken in SAP-BW, Oracle oder DB2/IBM sein. Da das oben dargestellte Datenmodell noch nicht sehr komplex ist, eignet es sich gut als Pilot zur Einführung einer cloudbasierten Datenbank-Lösung, die dann – je nach Hersteller – umfangreichere Analysewerkzeuge mitbringt. 

Auf dieser soliden Datenbasis können dann die nächsten, wertschöpfenden Schritte aufbauen: die Implementierung der Transformations- und Bereinigungslogik, die eigentliche Planung bzw. der Forecast sowie die Erstellung aussagekräftiger Analysen und Reports. Diese Aspekte bieten Stoff für weitere Betrachtungen und zeigen, wie aus der geschaffenen Datenbasis operative und strategische Mehrwerte für das Treasury generiert werden können. Letztlich ermöglicht dieser Ansatz eine robustere finanzielle Steuerung und stärkt die Resilienz des Unternehmens in dynamischen Zeiten.

Quelle: KPMG Corporate Treasury News, Ausgabe 154, Mai 2025
Autoren:
Börries Többens, Partner, Finance and Treasury Management, Corporate Treasury Advisory, KPMG AG
Jakob Fisahn, Manager, Finance and Treasury Management, Corporate Treasury Advisory, KPMG AG