Treasury Evolution

“At least 40 % of all businesses will die in the next ten years…if they don‘t figure out how to change their entire company to accommodate new technologies.”¹ Dieses Zitat von John Chambers, dem ehemaligen CEO von Cisco Systems unterstreicht, dass sich Unternehmen und insbesondere Treasury-Abteilungen wandeln müssen. Die kritischen Funktionen der Treasury-Abteilung, wie die Abwicklung des Zahlungsverkehrs und das finanzielle Risikomanagement sind für den Fortbestand eines Unternehmens essenziell und erfordern eine kontinuierliche Anpassung an neue Technologien. 

So ist der Einsatz eines Treasury Management Systems ab einem gewissen Umfang und einer gewissen Komplexität der Treasury-Aktivitäten unverzichtbar. Dabei unterliegt auch das System, wie jedes Unternehmen, jeder Mensch oder jede Idee einem Lebenszyklus, der im Detail individuell ist, jedoch übergeordnet einem Muster folgt. Dieser Artikel gibt Aufschluss darüber, welche Phasen durchlaufen werden, welche konkreten Aktivitäten anfallen, und bietet wertvolle Hinweise, um jede Phase bestmöglich zu nutzen und den Gesamtprozess optimal zu managen.

In dieser Artikelserie werden wir uns umfassend mit dem Lebenszyklus eines TMS beschäftigen. Der erste Artikel legt die Grundlagen, indem er die Notwendigkeit und die Auswahl eines geeigneten Systems beleuchtet. In dem darauffolgenden Artikel wird die Implementierungsphase und die Hypercare-Phase detailliert betrachtet, um die Herausforderungen und Chancen während der Systemeinführung zu verstehen. Abschließend wird der Fokus auf den laufenden Betrieb und die Auslaufphase gelegt, um sicherzustellen, dass das TMS den hohen Ansprüchen des Unternehmens dauerhaft gerecht wird. Leser können sich auf praxisnahe Tipps und bewährte Strategien freuen, die helfen, das TMS optimal zu nutzen und den langfristigen Erfolg des Systems sicherzustellen.

Der gesamte Lebenszyklus ist auf folgender Grafik dargestellt:

„Die Treasury-Funktion muss wie alle anderen Unternehmensfunktionen angemessen mit IT ausgestattet sein. […] Für diese Zwecke ist bei der Ausgestaltung der IT-Systeme und der zugehörigen Kernprozesse im Treasury grundsätzlich auf gängige Standards, sogenannte Treasury-Management-Systeme, abzustellen².“ konstatiert der Verband deutscher Treasurer.

Grundsätzlich ist dieser Aussage zuzustimmen, denn die Nutzung eines State of the Art-Systems ermöglicht nicht nur die reibungslose Anbindung und Kommunikation mit anderen Abteilungen, sondern durch die Verlagerung von manuellen und repetitiven Tätigkeiten die Möglichkeiten im Arbeitsalltag eines Treasurers, sich auf spezifische fachliche und besonders wertstiftende Aufgaben zu fokussieren. Jedoch finden sich in der unternehmerischen Praxis zahlreiche Beispiele, in denen kein Treasury-Management-System (TMS) im Einsatz ist. Dieses Kapitel fokussiert sich auf die zahlreichen Gründe, die für die Einführung eines TMS sprechen. 

Wenn ein Unternehmen wächst und die Arbeitsabläufe und Aufgaben an Komplexität gewinnen, muss der finanzwirtschaftliche Prozess zur Unterstützung der betriebswirtschaftlichen Wertschöpfung ebenfalls professionalisiert werden. Ab einem gewissen Punkt können manuelle Prozesse mit Excel-Listen und Online-Banking-Portalen den steigenden Anforderungen an die Treasury-Abteilung nicht ausreichend Rechnung tragen. Dabei steht neben der Reduktion des operationellen Risikos auch die Effizienzsteigerung durch Automatisierung im Fokus.

Auch Unternehmen, in denen bereits ein TMS im Einsatz ist, sehen sich mit der Entscheidung für ein neues System konfrontiert, z.B. wenn sich die Anforderungen an das Treasury so stark gewandelt haben, dass das aktuelle TMS diese nur noch unzureichend abdeckt, z.B. der Handel mit komplexeren Instrumenten wie Swaptions, die Abbildung von Supply-Chain-Finance-Programmen oder die Versionierung/Historisierung von Liquiditätsplänen. Wie eingangs erwähnt sollte die IT-Ausstattung stets angemessen sein.

Einen weiteren Anlass für einen Wechsel kann die angekündigte Einstellung des Supports und der Weiterentwicklung eines bestehenden Systems bzw. System-Releases darstellen (beispielsweise SAP R/3, WSS 6.5 oder andere). Wird das System über diesen Zeitraum hinaus eingesetzt, können neue Risiken z.B. hinsichtlich der IT-Sicherheit entstehen. Dann ist entweder ein Upgrade auf die neue Version durchzuführen, das sich je nach Anbieter ähnlich aufwändig darstellen kann, wie die ursprüngliche Einführung. In jedem Fall sollten unabhängig von der Motivation einer Systemeinführung/eines System-Upgrades oder -wechsels die verschiedenen Handlungsalternativen einer gründlichen Kosten-Nutzen-Analyse in Form eines detaillierten Business Cases unterzogen werden.

In diesem Zusammenhang lässt sich ebenfalls eine sinkende Qualität des Supports durch den Hersteller als Auslöser anführen. Wenn kritische Störungen mehrfach nicht zeitnah behoben werden können und es beispielsweise im Zahlungsverkehr zu einer Gefährdung der operativen Zahlungsfähigkeit kommt, ist in Frage zu stellen, ob der Anbieter noch der richtige strategische Partner ist.

Andere Gründe umfassen die M&A-Aktivitäten einer Unternehmung, wenn im auszugliedernden Teil eine neue Treasury-Abteilung aufzubauen oder wenn die Eingliederung zu einer starken Veränderung des Anforderungsprofils führt (siehe oben), und auch unternehmensinterne Veränderungen der IT-Landschaft oder der gesamten IT-Strategie. Weiterhin können im Zeitverlauf gestiegene Lizenz- oder Betriebskosten den ursprünglichen Business Case negativ beeinflussen³.

Nachdem die Entscheidung getroffen wurde, verschiedene Handlungsalternativen in Bezug auf das TMS zu evaluieren, gilt es den weiteren Auswahlprozess zu strukturieren und festzulegen, wer in diese Entscheidungen involviert werden sollte.

Zunächst sind die Anforderungen an das System oder den Systemanbieter selbst zu formulieren, um ein Fit-for-Purpose-System auszuwählen. Hier gilt es sowohl funktionale (z.B. Cash Management Aktivitäten) wie auch nicht-funktionale Aspekte (z.B. kommerzielle oder IT-spezifische Anforderungen) zu berücksichtigen. Es ist von essenzieller Bedeutung, diese Anforderungen möglichst vollständig und präzise zu formulieren. Zu knapp formulierte Anforderungen bergen das Risiko von Missverständnissen, z.B. ist die „Erfassung und Bearbeitung von Krediten“ sehr generisch und wird von den meisten Anbietern in mehr oder weniger sophistizierter Ausprägung angeboten. Besteht der Bedarf, komplexe Gebührenstrukturen, konditionale Kündigungsoptionen oder einen Marktwertausgleich bei frühzeitiger Rückzahlung abzubilden, sollte sich dies in den Requirements wiederfinden. Idealerweise und so weit antizipierbar, sollten auch zukünftige Anforderungen berücksichtigt werden, beispielsweise wenn neue Instrumente im Risiko-Management zum Einsatz kommen sollen oder das Unternehmen eine ESG-Strategie entwickelt, nach der künftige Geschäftspartner ein ESG-Rating auf einem bestimmten Niveau aufweisen müssen. 

Neben der Treasury-Abteilung sollten die folgenden Abteilungen ihre Anforderungen an ein System oder einen Anbieter adressieren können: das Rechnungswesen (z.B. für die Verbuchung der mit den Treasury Aktivitäten einhergehenden Geschäftsvorfälle), die HR-Abteilung (z.B. für die Abwicklung von HR-Zahlungen), die IT-Abteilung (z.B. für die Berücksichtigung von strategischen Partnerschaften oder für Schnittstellen zur Einbettung in die Gesamt-Unternehmens-IT-Landschaft), das Controlling (z.B. für die Übernahme von Plandaten) oder die Compliance-Abteilung (z.B. für die Erstellung von AWV-Meldungen). Sind die Anforderungen aller potenziellen Anspruchsgruppen berücksichtigt, müssen diese priorisiert bzw. gewichtet werden, um sicherzustellen, dass essenzielle Anforderungen nicht unter- und wenig wertstiftende Anforderungen nicht überbewertet werden. Einen Ansatz bietet hier die MSCW-Methode, bei der die Anforderungen in vier Gruppen eingeteilt werden: Must (Anforderungen, die in jedem Fall erfüllt sein sollten), Should (ebenfalls wichtige Anforderungen, die aber nicht oberste Priorität besitzen), Could (sogenannte Nice-to-Have-Kriterien, deren fehlende Abdeckung keinen entscheidenden Nachteil bedeuten) und Won’t (Kriterien die voraussichtlich nicht erfüllt werden, was sich aber nicht auf den Nutzen bzw. die Akzeptanz auswirkt).

Auf Basis der definierten Kriterien erfolgt im nächsten Schritt eine erste Analyse des Anbieter- und Lösungsmarktes. Hier sind neben der Validierung der im Unternehmen vorhandenen Kenntnisse auch der Austausch mit anderen Treasurern, einschlägige Marktanalysen (z.B. von Gartner oder Forrester), Recherche im Internet und in Fachpublikationen (z.B. Der Treasurer) sowie externes Expertenwissen als Quelle heranzuziehen. Das Resultat ist eine „Market List“. An dieser Stelle können bereits erste, übergreifende Filterkriterien verwendet werden, z.B. der grundsätzliche Funktionsumfang, der Komplexitätsgrad oder die Größe des Herstellers, um den weiteren Auswahlprozess möglichst effizient zu gestalten. Nach dieser groben Filterung erhält man eine „Longlist“.

Anschließend ist diese Longlist durch Anwendung individueller Anforderungskriterien auf eine „Shortlist“ zu reduzieren. Diese sollte im Idealfall zwei bis fünf Systeme enthalten. Wenn die Kriterien hinreichend detailliert sind und die Informationen zu ihrer Erfüllung frei verfügbar sind, kann die Shortlist gegebenenfalls direkt nach der Marktanalyse erstellt werden. Alternativ kann auf objektives Expertenwissen zurückgegriffen werden.

In einem Ausschreibungsverfahren (Request for Proposal), das auf den eingangs formulierten Anforderungen basiert, sind entsprechende Unterlagen zu erstellen, die neben der Spezifikation auch Informationen zum Unternehmen selbst, zum weiteren Prozess, einen Zeitplan zur Beantwortung der Fragen, und andere Angaben enthält. An dieser Stelle sollten – wenn nicht bereits geschehen – die Einkaufsabteilung und die Rechtsabteilung eingebunden werden, um den Prozess zu organisieren, die Grundlagen für eine spätere zielgerichtete Verhandlung zu legen und sicherzustellen, dass rechtliche Rahmenbedingungen berücksichtigt sind. Die Ausschreibungsunterlagen werden an die Anbieter versandt und häufig wird die Möglichkeit eingeräumt, Fragen zu platzieren, deren Antworten mit allen Teilnehmern geteilt werden können. Es empfiehlt sich, die Ausschreibungsunterlagen derart auszugestalten, dass die Antworten effizient ausgewertet werden können. Außerdem ist zu berücksichtigen, dass die Erfüllung der Anforderungen von den Anbietern oft sehr optimistisch eingeschätzt wird. Hier bietet Hands-On-Expertenwissen einen großen Mehrwert. Auf Basis der Antworten ist der Abdeckungsgrad der am Anfang gewichteten Anforderungen zu bewerten.

Häufig verbleiben zwei bis drei Systeme in der engeren Auswahl, die dann zu einem sogenannten „Beauty Contest“ eingeladen werden, zu dessen Vorbereitung verschiedene, essenzielle End-to-End Use Cases definiert werden, z.B. vom Empfang eines Kontoauszuges über den Abgleich mit Forecasts, gegebenenfalls mit manueller Nachbearbeitung, über die Verbuchung bis hin zur Erstellung eines Tagesfinanzstatus. Der Eindruck zur Präsentation kann ebenfalls in die Bewertung einfließen. Gegebenenfalls finden parallel oder im Anschluss weitere Vertragsverhandlungen statt, um das kommerzielle Angebot zu optimieren.

Unter Berücksichtigung aller Parameter ist das objektiv beste System auszuwählen und gegenbenenfalls ein Systemintegrator, wenn die Leistung nicht vollständig von den Treasury- und IT-Abteilungen sowie dem Systemanbieter erbracht werden kann. In diesem Kontext sind die entsprechenden Verträge zu unterzeichnen. 

Die Einführung eines TMS ist ein komplexer Prozess, der weit über die initiale Entscheidung hinausgeht. Nach der Auswahl eines TMS ist die Implementierungsphase entscheidend, da sie die Basis für einen reibungslosen Betrieb schafft. Eine sorgfältige Planung, Organisation und Dokumentation sind notwendig, um alle technischen und organisatorischen Anforderungen zu erfüllen. Die Wahl des Projektmanagement-Ansatzes und die Integration in die bestehende IT-Landschaft spielen dabei eine zentrale Rolle.

Im Anschluss folgt die Hypercare-Phase, die auf den erfolgreichen Go Live folgt und eine kurzfristige und engmaschige Überwachung des Betriebs und die schnelle Behebung von auftretenden Problemen umfasst. Diese Phase dient dazu die Stabilität des TMS sicherzustellen. Die Etablierung eines klar definierten Change-Request-Prozesses spätestens während dieser Phase ist unerlässlich, um zukünftige Anpassungen effizient umzusetzen und die kontinuierliche Verbesserung des Systems zu gewährleisten.

Der kommende Artikel wird detailliert auf die Implementierungs- und Hypercare-Phase des TMS-Lebenszyklus eingehen und wertvolle Einblicke in die Herausforderungen und Chancen bieten, die sich während der Systemeinführung und -stabilisierung ergeben. 

Quelle: KPMG Corporate Treasury News, Ausgabe 154, Mai 2025
Autoren:
Nils Bothe, Partner, Finance and Treasury Management, Corporate Treasury Advisory, KPMG AG
Philipp Knuth, Senior Manager, Finance and Treasury Management, Corporate Treasury Advisory, KPMG AG

________________________________________________________________________________________________________________

¹ https://research.wu.ac.at/en/projects/internationale-diversifizierung-digitale-transformation-und-die-l-4 
² VdT, „Mindestanforderungen an das Unternehmenstreasury“, 4. Auflage, 2024, S. 27, https://www.vdtev.de/artikel?/media/mindestanforderungen-an-das-unternehmenstreasury/1983
³ Vgl. DerTreasurer Studie: Treasury-Management-Infrastruktur – DerTreasurer, https://www.dertreasurer.de/research/studien/dertreasurer-studie-treasury-management-infrastruktur/