KPMG Corporate Treasury News, Ausgabe 64, Februar 2017

Corporate Treasury News
Aktuelle Entwicklungen und Trends im
Bereich Treasury kompakt zusammengefasst
Ausgabe 64 | Februar 2017
Inhalt
Liebe Leserinnen und Leser,
wir freuen uns, Ihnen die neueste Ausgabe unserer
Corporate Treasury News präsentieren zu können.
Wenn Sie Fragen oder Anregungen zu Themen haben, die hier kurz behandelt werden sollen, dann
schreiben Sie uns: [email protected]
Aktuelle Meldungen rund um das Finanz- & TreasuryManagement finden Sie bei uns im Internet oder
über Twitter: www.twitter.com/KPMG_DE_FTM
Mit besten Grüßen
Prof. Dr. Christian Debus
Carsten Jäkel
Testen bei agiler Softwareentwicklung – Automatisierung als Lösung?
Seite 2
PSD2 ante portas – werden Amazon,
Google & Co. jetzt die neuen Hausbanken?
Seite 4
Treasury 4.0: Von der Standardisierung zur Digitalisierung – wie sich
die Treasury-Organisation aufstellen
muss
Seite 6
Veranstaltungen und Termine
In unseren kostenfreien Webinaren nehmen wir zu
aktuellen Themen aus dem Bereich Finanz- und
Treasury-Management Stellung und informieren Sie
über Strategien und die konkrete Implementierung.
Wählen Sie sich online ein und nehmen Sie an unseren thematischen Expertenrunden teil.
Von jedem Webinar fertigen wir einen Mitschnitt des
Vortrages an. Sie finden ihn in unserem WebinarArchiv.
© 2017 KPMG AG Wirtschaftsprüfungsgesellschaft, ein Mitglied des KPMG-Netzwerks unabhängiger Mitgliedsfirmen, die KPMG International Cooperative („KPMG International“),
einer juristischen Person schweizerischen Rechts, angeschlossen sind. Alle Rechte vorbehalten.
Corporate Treasury News | 2
Testen bei agiler Softwareentwicklung – Automatisierung
als Lösung?
“The days when clients could wait for multiple years between projects and upgrades are
long gone. Clients want to be agile and need
the ability to react quickly to changing business needs, implement a new policy and
comply with the latest legislation and regulation. Test automation is an essential element
of being able to execute regular cost effective
and repeatable upgrades.
At ION, as part of our development lifecycle, test automation and acceptance test driven development
are rigorously implemented while we build our software in continuous integration environments. Furthermore our clients can use the same test tools and
Test Automation Service for their own testing, this
minimises the need for manual, error prone and labour intensive testing, which in turn significantly reduces the number and duration of downstream test
cycles.”
David Atzeni, Director Research&Development bei
ION Trading - mittlerweile Eigner von mehreren
Treasury- und Commodity-Management-Systemen fasst die Folgen der Umstellung auf agile Softwareentwicklung für das Testen zusammen. Aber nicht
nur ION-Kunden sehen sich mit dieser Änderung konfrontiert, denn immer mehr Softwarehersteller auch
aus dem Umfeld von Treasury-Management-Systemen wie etwa SAP oder FIS stellen auf agile Entwicklung um. So beschreiben Dirk Joachim Henn,
Produktmanager für SAP Treasury, und Jean-Philippe
Lombardi, Direktor für Agile Transformation, den Ansatz von SAP: ”SAP started its agile journey to
succeed in the cloud many years ago. First and foremost, SAP applies SCRUM@SCALE in all programs in
order to receive early feedback – also from end users
in the course of design thinking projects. Further, the
teams put criteria in place to ensure not only external, but also internal quality of the software. The
latter is particularly important to keep productivity
high.”
Was bedeutet agile Softwareentwicklung?
Eine detaillierte Beschreibung, was agile Softwareentwicklung kennzeichnet und deren Auswirkungen
finden Sie in unserem Dezember Newsletter unter
dem Titel „Die Auswirkungen agiler Softwareentwicklung auf TMS-Projekte“.
Zusammengefasst lässt sich sagen, dass es das Ziel
der Hersteller ist, in Form von kürzeren Entwicklungszyklen (Sprints), die zu Blöcken zusammengefasst werden, schneller auf Anforderungen durch
Kunden oder von gesetzlicher Seite reagieren zu können und somit neue Funktionalitäten zur Verfügung
zu stellen. Im Allgemeinen dauert ein Sprint zwei bis
vier Wochen. Am Ende eines Sprints erfolgen zwei
Dinge:
1. Den Kunden wird die Entwicklung präsentiert, sodass diese ihr Urteil direkt abgeben
können.
2. Auf Basis der vorhandenen Entwicklungskapazitäten und der vorgefilterten Themen
(„User Stories“) entscheidet der Hersteller,
was im nächsten Sprint entwickelt wird. Dabei werden Korrekturen oder Änderungen auf
Basis von Kundenwünschen, die bei der Präsentation geäußert wurden, ebenfalls berücksichtigt.
Zum Beispiel werden sechs derartige Sprints zu einem Block zusammengefasst und an die Kunden
ausgeliefert. Das bedeutet, dass Unternehmen alle
paar Monate (zum Beispiel bei sechs Sprints zu je
zwei Wochen alle drei Monate) ein Bündel an neuen
Funktionalitäten erhalten, das letztendlich in den Produktivbetrieb integriert werden sollte. In Zukunft werden daher große Upgrade-Projekte für ein TreasuryManagement-System (TMS) immer seltener. Diese
werden durch laufende Aktivitäten ersetzt, sodass
das TMS auch immer auf dem aktuellsten Stand ist.
Das bedeutet ein permanentes Testen – im Wesentlichen auch für den Fachbereich, der jede neue Funktionalität abnehmen muss.
Wie sieht das Testen bisher aus?
Bevor eine neue Funktionalität in den Produktivbetrieb übernommen werden kann, muss diese getestet werden. In klassischen Projekten werden dabei
folgende Testphasen unterschieden und durchlaufen:
© 2017 KPMG AG Wirtschaftsprüfungsgesellschaft, ein Mitglied des KPMG-Netzwerks unabhängiger Mitgliedsfirmen, die KPMG International Cooperative („KPMG International“),
einer juristischen Person schweizerischen Rechts, angeschlossen sind. Alle Rechte vorbehalten.
Corporate Treasury News | 3





Entwicklertest beim Hersteller: Damit stellt
dieser sicher, dass die Software mit entsprechender Qualität ausgeliefert wird. Alle weiteren Testphasen finden beim Kunden statt.
Funktional- oder Unit-Test, bei dem nur die
unterschiedlichen Funktionalitäten modular
für sich getestet werden.
Integrationstests, um sicher zu stellen, dass
alle übergreifenden Abläufe inkl. Schnittstellen weiterhin reibungslos funktionieren.
System-Performance und technische Sicherheits-Tests, bei denen auf der einen Seite die
Systemkapazitäten verifiziert und auf der anderen Seite das korrekte Verhalten bei Systemausfällen geprüft werden.
Abnahmetests („User Acceptance Tests“),
die letztendlich darüber entscheiden, ob die
neue Version bzw. einzelne Funktionalitäten
des TMS in die Produktion übergehen. Diese
letzte Testphase wird häufig auch dazu verwendet, die Anwender zu schulen.
Es ist offensichtlich, dass diese klassischen, vollumfänglichen Testzyklen nicht alle drei Monate durchlaufen werden können – zumindest nicht, wenn sie primär manuell durchgeführt werden, was bei vielen
Unternehmen der Fall ist.
Welche Veränderungen sind beim Testen daher
notwendig?
Hier treffen nun die Anforderungen aus der Umstellung der TMS-Hersteller auf agile Entwicklung mit
dem häufig getroffenen guten Vorsatz bei Unternehmen, das Testen zu verbessern (dieser wird im Allgemeinen dann getroffen, wenn es darum geht, die
notwendigen Testfälle zu erstellen), zusammen. Im
Rahmen eines TMS-Upgrade- oder -Einführungsprojektes stellt sich immer wieder heraus, dass Unternehmen für das Testen und insbesondere dessen
Vorbereitung nicht ausreichend Zeit einplanen. Als
Konsequenz leidet insbesondere die Testdokumentation und damit verbunden ihre Wiederverwendbarkeit.
Um in kurzen Abständen neue Funktionalitäten in
Produktion nehmen zu können, sind standardisierte
Testfälle unumgänglich. Diese können aber auch
nicht jedes Mal manuell durchgearbeitet werden,
denn dies würde auf Dauer zu viele Ressourcen binden. Darüber hinaus sind neue Testfälle aufgrund von
neu hinzugefügter Funktionalität zu ergänzen. Damit
wird der notwendige Testkatalog stetig erweitert. Daher ist eine Automatisierung des Testens die logische Konsequenz. Ein Verringerung des Testumfanges oder gar ein Verzicht auf einzelne Testphasen
erhöht das Risiko, dass Fehler im produktiven Betrieb
auftreten, was tunlichst vermieden werden sollte.
Vorerst bedeutet dies einen erhöhten Aufwand in
Form eines separaten Projekts zur Einführung eines
Tools zur Testautomatisierung. Dieses gliedert sich in
folgende drei Schritte:
1. Es wird entschieden, welches Testtool zum
Einsatz kommen soll. Häufig ist der TMSHersteller, insofern er selbst automatisiert
testet, der erste Ansprechpartner. Andernfalls läuft man Gefahr, dass das Treasury-Management-System mit dem Testtool nicht
kompatibel ist. In der Folge können dann
große zusätzliche Aufwände bei der Integration dieser beiden Komponenten entstehen.
2. Anschließend sind die fachlichen Geschäftsvorfälle, welche abgebildet werden müssen,
zu definieren. Das erfolgt nach klaren Kriterien, wie der Häufigkeit des Auftretens, der
Bedeutung für den gesamten Geschäftsbetrieb und der Komplexität. Diese fachlichen
Geschäftsvorfälle werden anschließend in
einzelne Testfälle übertragen, welche automatisiert werden. Beispiele dafür sind die
Deal-Erfassung und dessen Verarbeitung in
einzelnen Schritten bis hin zur Auslösung von
Zahlungen und Verbuchungen, Ermittlung
von Kennzahlen, Auswertungen, Limitüberschreitungen, Hedging, etc.
3. Im letzten Schritt werden diese Testfälle für
das gewählte Testtool aufbereitet. Jedes
Tool hat seine individuellen Vorgaben, wie Informationen zum Beispiel zu Transaktionen
(Instrument, Kontrahent, Betrag, Preis, etc.)
für die automatische Verarbeitung vorzubereiten sind. Als Ergebnis liefern diese Systeme im Allgemeinen Berichte, die farblich
(Grün vs. Rot) anzeigen, ob ein Testfall erfolgreich abgeschlossen werden konnte. Dabei wird das Ergebnis mit definierten Kriterien, abhängig vom Ziel eines Tests
verglichen. Kriterien können zum Beispiel
sein, dass ein Deal ohne Fehlermeldung prozessiert wurde, berechnete Kennzahlen werden mit erwarteten Werten verglichen, LimitWarnungen werden ausgelöst. Folglich muss
man beim eigentlichen Testen nur die fehlerhaften Testfälle analysieren, um die Ursache
zu finden und sie zu beheben.
Es ist offensichtlich, dass zumindest Unit-, Integrations- und Performancetests automatisiert werden
können. Wie bereits erwähnt, werden Abnahmetests
zusätzlich zur Schulung der Anwender verwendet.
© 2017 KPMG AG Wirtschaftsprüfungsgesellschaft, ein Mitglied des KPMG-Netzwerks unabhängiger Mitgliedsfirmen, die KPMG International Cooperative („KPMG International“),
einer juristischen Person schweizerischen Rechts, angeschlossen sind. Alle Rechte vorbehalten.
Corporate Treasury News | 4
Aber auch hier ist ein grundsätzliches Umdenken notwendig. Aufgrund der kurzen Intervalle, in denen
neue Funktionalität zur Verfügung gestellt wird, gibt
es nicht mehr die großen Veränderungen zwischen
dem alten und neuen Release des Treasury-Management-Systems. Es ist ein laufender Prozess bestehend aus vielen kleinen Schritten. Damit erfolgt das
Lernen ständig am laufenden System. Es ist hilfreich,
wenn die betroffenen Anwender bereits an den Präsentationen des Herstellers teilnehmen. Natürlich ist
eine entsprechende Dokumentation und Kommunikation durch die Hersteller unumgänglich.
PSD2 ante portas – werden
Amazon, Google & Co. jetzt die
neuen Hausbanken?
Und warum ist das Treasury davon betroffen?
Der Trend der Umstellung auf agile Softwareentwicklung macht wie zu Beginn ausgeführt auch vor Herstellern von Treasury-Management-Systemen nicht
halt. Das Treasury sollte die Veränderungen, die
dadurch entstehen, rechtzeitig annehmen. Die Einführung der Testautomatisierung ist ein eigenständiges Projekt, welches idealerweise nicht mit einem
Upgradeprojekt oder einer Neueinführung kombiniert
werden sollte, da dies die Projektrisiken signifikant
erhöhen würde.
So fasst Andrew Owens, Group CTO bei FIS für Treasury-Lösungen, die aktuelle Situation und Vorgehensweise zusammen, was auch als Appell an das Treasury verstanden werden kann, sich mit diesem
Thema aktiv auseinanderzusetzen: “FIS uses agile
development across our Treasury and Payments development groups. We also have a high degree of
alignment across these groups. The combination of
agile processes with our ‘Continuous Integration’
frameworks is helping us to increase software quality
and development velocity, whilst providing our product management team with a large amount of flexibility on setting and adjusting the product roadmaps.
FIS has a mature ‘Continuous Integration’ framework
in place for our treasury and payments solutions. The
scope of this framework includes automated build
and testing, where we run many thousands of tests
at least daily. We use a variety of tooling to assist
with unit testing, GUI testing, integration testing,
end-to-end testing and security vulnerability testing
(static code scanning). The FIS testing framework is
in place internally and we are also offering it to our
clients in case they want to utilize it for their testing
requirements.”
Autor: Karin Schmidt, Senior Manager,
Finance Advisory,
[email protected]
Treasurer sollten sich den 13. Januar 2018 rot
im Kalender markieren. Auch wenn dieses
Datum auf einen Samstag fällt, tritt an diesem Tag die neue EU-Zahlungsdiensterichtlinie (Payment Service Directive 2, kurz PSD2)
in Kraft. „2“ deshalb, weil die Neufassung
der Richtlinie auf der Grundlage einer grundlegenden Prüfung der Payment Services Directive 1 (PSD1) selbige nun ersetzt und in
wesentlichen Bereichen ergänzt und erweitert.
Zur Erinnerung: Die PSD1 aus dem Jahr 2007, welche zum 31. Oktober 2009 in deutsches Recht umgesetzt wurde, bildet einen EU-weiten einheitlichen
Rechtsrahmen für alle Arten von Zahlungsaufträgen
und die Basis für den Zahlungsverkehr im Rahmen
des SEPA-Verfahrens.
Weniger als ein Jahr bleibt den EU-Mitgliedsstaaten
also noch Zeit, die Inhalte und Regelungen der neuen
Richtlinie in nationales Recht umzusetzen. Wer sich
noch an die langwierigen Diskussionen im Zuge der
Umsetzung der PSD1 von 2008 bis 2009 erinnert,
wird erahnen, dass es auch bei der Neuauflage zu
Schwierigkeiten und Verzögerungen kommen wird.
In Deutschland liegen seit Ende 2016 mittlerweile
erste Gesetzesentwürfe der jeweiligen Ministerien
vor, eine Verabschiedung noch vor der Bundestagswahl wird allgemein erwartet. Primär hapert es aber
derzeit noch bei den finalen technologischen Vorgaben und Standards, die von der europäischen Bankenaufsicht für Fragen der Authentifizierung und
Identifizierung vorzugeben sind, um die Zahlungsprozesse und damit verbundenen Dienstleistungen von
Banken und Drittanbietern entsprechend abzusichern.
© 2017 KPMG AG Wirtschaftsprüfungsgesellschaft, ein Mitglied des KPMG-Netzwerks unabhängiger Mitgliedsfirmen, die KPMG International Cooperative („KPMG International“),
einer juristischen Person schweizerischen Rechts, angeschlossen sind. Alle Rechte vorbehalten.
Corporate Treasury News | 5
PSD2 als Revolution der Bankenwelt oder nur ein
weiteres Brüsseler Regulierungsmonster?
auf das Cash Management und die Zahlungsverkehrsprozesse ergeben.
Hintergrund und Auslöser der Überarbeitung der
PSD1 bzw. der Ende 2015 veröffentlichten PSD2 war
das Ziel, neben der Steigerung des Wettbewerbs und
der Innovationen im europäischen Zahlungsverkehr
den Verbraucherschutz und die Sicherheit von Zahlungsprozessen weiter zu verbessern. So greift die
PSD2 nun auch für sogenannte dritte Zahlungsdienstleister (also Nicht-Banken). Zusätzlich zu neuen Regelungen von Haftungsfragen und technischen Neuerungen für die Kundenauthentifizierung enthält sie ein
Kernelement, welches das etablierte Geschäftsmodell vieler Banken zumindest einmal in Frage stellt:
den Kontozugang für Drittanbieter. Mit diesem
„Access-to-Account“-Prinzip (XS2A) ist es Dienstleistern ohne das Vorhalten eines Bankkontos für den
Kunden möglich, Zahlungsdienste anzubieten und
Kontoinformationen über standardisierte Schnittstellen auf der Basis von Softwarelösungen einzuholen.
Damit fällt de facto das Monopol der Banken in diesem Bereich. Die kontoführenden Institute müssen
Dritten nach Einverständnis des Kontoeigentümers
grundsätzlich den Zugang zu dessen Konto ermöglichen (ausgenommen hiervon sind lediglich nicht autorisierte und betrügerische Zugangsversuche). Die
Banken müssen dabei sicherstellen, dass die Daten
technisch nach außen freigegeben werden. Es ist
leicht vorstellbar, welche technischen Umstellungen
hierfür auf Bankenseite erforderlich sein werden und
welche Sicherheitsmaßnahmen bezüglich der Zugriffsmechanismen und der Vermeidung von Manipulationen umgesetzt werden müssen. Entscheidende
Fragen, welche Prüfungen bei Drittdiensten durchgeführt werden, um die Schnittstellen nutzen zu dürfen
oder wer diese am Ende durchführen darf sind noch
offen.
Was habe ich als Treasurer nun davon?
Insbesondere für Banken und Zahlungsdienstleister
bedeuten die neuen ab 2018 geltenden Regelungen
daher einen signifikanten Einschnitt in die Art und
Weise, welche und vor allem wie ihre Services den
Kunden angeboten werden können. Nicht wenige Experten sehen in der PSD2 bzw. ihrer Umsetzung und
den sich daraus ergebenden Möglichkeiten im Hinblick auf innovative Services eine disruptive Änderung der Bankenwelt, die es in dieser Form noch
nicht gegeben hat. An dieser Stelle soll nicht weiter
auf die erheblichen Auswirkungen bei Banken und Finanzdienstleistern eingegangen werden – man denke
etwa nur an die Komplexität der IT-Projekte, welche
sich in 2017 mit der Umsetzung und Absicherung der
externen Kontozugangsschnittstellen beschäftigen
müssen. Vielmehr haben wir ja die Brille eines Treasurers auf und fragen uns, welche Potenziale sich
aus der Perspektive eines Firmenkunden im Hinblick
Es ist immer ratsam, bei sich ändernden Rahmenbedingungen die Zukunft proaktiv mitzugestalten, als
sich zurückzulehnen und passiv abzuwarten, wie sich
Inhalte und Geschäftsmodelle entwickeln. Diese
Empfehlung gilt im Zusammenhang mit der PSD2
auch für den gemeinen Treasurer. Denn nicht nur das
Leben der Banker wird sich grundlegend ändern,
auch auf Kunden- sprich auf Corporate-Seite ergeben
sich neue Möglichkeiten und Chancen.
Im Fahrwasser der PSD2 und ihres Prinzips des „offenen“ Bankkontozugangs zur Auslösung von Zahlungen und dem Zugriff auf Kontoinformationen wird
sich an der Schnittstelle (Corporate-)Kunde zu Bank in
Zukunft einiges ändern. Die neuen Geschäftsmodelle
in diesem Umfeld führen für den Endkunden zu der
Frage, wer die jeweiligen Dienste mit dem größten
Mehrwert anbieten kann und wer die Rolle des Zahlungsauslösedienstleisters (sog. Payment Initiation
Service Provider = PISP) und des Informationsdienstleisters (sog. Account Information Service Provider =
AISP) wahrnimmt.
Es ist davon auszugehen, dass sich im Markt der
Zahlungsauslösedienstleister zusätzlich zu den traditionellen Bankpartnern mit ihren neuen Angeboten
auch Drittanbieter positionieren werden, die dann allerdings den Regularien der PSD2 genügen und sich
als Zahlungsinstitut im Sinne der PSD2 bei der europäischen Bankenaufsichtsbehörde (EBA) registrieren
lassen müssen. Neben spezialisierten Fintechs oder
auch Online-Händlern ergeben sich hier unter Umständen auch Potenziale für die Anbieter von Treasury-Management-Systemen, welche über in ihre
Plattform integrierte Zahlungsverkehrsmodule Zahlungen unmittelbar über die definierten Schnittstellen
mit den Banken auslösen und damit die „klassischen“ Kanäle der Bankkommunikation wie EBICS
oder SWIFT umgehen können. Analog gilt dies für
den Bereich der Kontoinformationen, wo sich neue
Dienstleister im Zusammenhang mit dem Abruf von
Kontensalden und -umsätzen etablieren können, als
potenzielle Player kommen hier vermutlich die gleichen Anbieter wie im Zahlungsumfeld in Frage. Dass
Funktionalitäten zur Auslösung von externen wie internen Zahlungen sowie die Zusammenführung von
Kontensalden in einem einheitlichen und bankübergreifenden System gebündelt werden, ist sicherlich
keine besondere Innovation im Cash Management.
Neu im Zusammenhang mit der PSD2 sind aber die
Möglichkeiten zur technischen Integration und der
© 2017 KPMG AG Wirtschaftsprüfungsgesellschaft, ein Mitglied des KPMG-Netzwerks unabhängiger Mitgliedsfirmen, die KPMG International Cooperative („KPMG International“),
einer juristischen Person schweizerischen Rechts, angeschlossen sind. Alle Rechte vorbehalten.
Corporate Treasury News | 6
damit verbundene Komfort im Treasury sowie die Potenziale zur Effizienzsteigerung.
Die Bandbreite der möglichen neuen Services als Resultat der PSD2 ist sicherlich so groß, dass heute
noch gar nicht absehbar ist, welche Anbieter sich hier
in den kommenden Jahren versuchen werden zu
etablieren. Man denke etwa nur an die Möglichkeiten, welche sich AISPs auf der Basis der erhaltenen
Konto- und Transaktionsinformationen im Hinblick auf
weiterführende Analysen und zusätzliche Dienstleistungen ergeben. Daher ist es auch für eine Prognose,
ob in diesem Zusammenhang ein Abgesang auf klassische Kanäle der Bankkommunikation für die Übermittlung von Zahlungen oder den filebasierten Empfang von elektronischen Kontoauszügen via
MT940/camt erfolgen kann, definitiv zu früh. Nicht
zuletzt, weil elementare Fragen der Sicherheit mangels verabschiedeter technischer Standards noch
nicht abschließend geklärt sind.
Oberste Maxime aus Treasury-Perspektive sollte es
daher in den nächsten Monaten sein, die Entwicklungen am Anbietermarkt sehr genau zu beobachten.
Was tut(n) die Hausbank(en) in diesem Umfeld, was
machen andere Banken, welche neuen Services sollen angeboten werden, wie entwickeln sich die Sicherheitsstandards für die Umsetzung der PSD2,
welche neuen Player kommen an den Markt und, last
but not least, welche Kostenstrukturen liegen dahinter – Fragen, die allesamt vor dem Hintergrund gestellt und beantwortet werden müssen, wie die Prozesse im Cash Management und Zahlungsverkehr
noch effizienter, sicherer und kostenoptimaler betrieben werden können. Die Tatsache, dass weitere innovative Themen wie Instant Payments oder Blockchain bereits am Horizont auftauchen, zeigt welche
Dynamik derzeit am Markt für Zahlungsverkehrsdienste herrscht und wie komplex es in Zukunft sein
wird, aus Treasury-Sicht ein entsprechendes Portfolio
aus Services und Anbietern zusammenzustellen.
Autor: Michael Baum, Senior Manager,
Finance Advisory, [email protected]
Treasury 4.0: Von der Standardisierung zur Digitalisierung –
wie sich die Treasury-Organisation aufstellen muss
Steigende Dynamik in der Produktentwicklung, das Internet der Dinge sowie disruptive
Technologien verändern bislang bewährte
Geschäftsmodelle. Ein wesentlicher Baustein
dessen ist Digitalisierung, ein Game Changer.
Das gilt auch für das Treasury und es ist
längst kein Geheimnis mehr.
Doch welche Konsequenzen hat dies und, vor allem,
was müssen Treasurer tun, um das Treasury als eine
Instanz zu positionieren, die als auf Augenhöhe agierender Berater die durch Industrie 4.0 induzierten
Veränderungsprozesse hinsichtlich der Steuerung
von Liquidität und Finanzrisiken führt? Wie in Ausgabe 63 unseres Newsletters thematisiert, muss sich
der Treasurer bereits heute damit beschäftigen, wie
das Treasury von Morgen aussehen wird. Und welche Aktivitäten und Technologien notwendig sind,
um die Leistungsfähigkeit und Flexibilität des Unternehmens mit entsprechen Produkten zu unterstützen. Am Beispiel der Treasury-Organisation sowie
der Anforderungen an die Treasury-Mitarbeiter werden im Folgenden diese Fragen beleuchtet.
Die Konsequenzen von Industrie 4.0 –
Digitalisierung des Treasury
Ein aktuelles Beispiel für durch Digitalisierung angestoßene Veränderungsprozesse und die Auswirkungen auf Treasury: In vielen Unternehmen streben
Vertrieb und Kunden gemeinsam an, Rechnungsbeträge via elektronischem Geld und entsprechende
Plattformen auszugleichen (zum Beispiel PayPal,
Apple Pay). Was bedeutet dies, neben den aktuell
viel diskutierten operationellen Risiken, für den Verantwortungsbereich des Treasury? Ist Treasury in
© 2017 KPMG AG Wirtschaftsprüfungsgesellschaft, ein Mitglied des KPMG-Netzwerks unabhängiger Mitgliedsfirmen, die KPMG International Cooperative („KPMG International“),
einer juristischen Person schweizerischen Rechts, angeschlossen sind. Alle Rechte vorbehalten.
Corporate Treasury News | 7
diese strategischen Entscheidungen eingebunden
und welche Auswirkungen hat dies auf Liquidität und
Finanzrisiken? Welche Liquiditätseffekte oder Kontrahenten- und Settlementrisiken bestehen eigentlich,
ehe Gegenwerte als Buchgeld in die klassischen
Treasury-Prozesse überführt werden? E-Geld-Anbieter bzw. -Plattformen sind häufig nicht Mitglied von
Einlagensicherungseinrichtungen und auch klassische Treasury-Instrumente, beispielsweise zur Kreditrisikoabsicherung, sind nur bedingt einsetzbar. Das
Treasury muss also seine Produkte inhaltlich auf
neue Technologien und Prozesse ausrichten. Für den
oben beschriebenen Fall bedeutet dies beispielsweise, dass das Endprodukt „Überwachung von Kontrahentenrisiken“ eben auch E-Geld-Bestände und
deren spezifische Risiken berücksichtigen muss (zum
Beispiel im entsprechenden Risikobericht). Dies ist
leicht formuliert, doch in der Umsetzung stellen sich
durchaus wesentlich komplexerer Fragestellungen. In
einer sich immer schneller verändernden Welt muss
sich das Treasury also derart aufstellen, dass Prozesse, Datenmodelle und Berichte möglichst modular
strukturiert und flexibel hinsichtlich Anpassungen und
Erweiterungen sind.
Das Treasury muss seine Prozesse und Produkte daher regelmäßig auf den Prüfstand stellen und aktualisieren. Dies bedingt standardisierte, klar definierte
Prozesse, für welche die erforderlichen Daten und
Schnittstellen sowie die erzeugten Endprodukte und
Verantwortlichkeiten eindeutig und transparent festgelegt sind. Standardisierung ist die Voraussetzung
für Digitalisierung. Und standardisierte, digitalisierte
Prozesse sind die Basis für das Andocken von entsprechenden Apps und modularen Prozesserweiterungen, um bei Veränderungsprozessen kurzfristig
agieren zu können (also zum Beispiel die Erweiterung
der Kreditrisikoanalyse um E-Geld-Aspekte).
Grenzen werden der Standardisierung von TreasuryProdukten durch rechtliche und steuerliche Rahmenbedingen gesetzt. Und natürlich durch hoch individuelle Prozesse, die eine Problemanalyse und Lösungsfindung bedingen und nicht in standardisierten,
automatisierten Prozessen ablaufen können. In der
Konsequenz wird sich also auch der Schwerpunkt der
Tätigkeiten der Treasury-Teams auf die Lösung anspruchsvoller und komplexer Fragestellungen beziehen, da die standardisierten Prozesse nach dem Prinzip des „Management by Exception“ weitestgehend
automatisiert laufen. Hier kommt das Thema Mitarbeiterqualifikation ins Spiel: Der Treasurer wird künftig deutlich stärker als ein Finanzberater auftreten,
der seine Kunden mit den bestmöglich passenden
Produkten versorgt. Dazu gehört insbesondere die
qualitativ hochwertige Beratung: Welche Produkte
sind notwendig (warum ist eigentlich nicht das Standard-Produkt anwendbar?) und wie muss die Dienstleistung konkret gestaltet werden? Der Treasury-Spezialist muss also bestens vertraut sein mit den
Treasury-Produkten, den Spezifika in den einzelnen
Märkten und Regionen sowie rechtlichen und steuerlichen Rahmenbedingungen.
Was muss das Treasury also tun?
Standardisierung und Automatisierung von Prozessen
und Endprodukten erfordern ein grundlegendes
Durchdenken der Treasury-Organisation: Welche Produkte bietet Treasury an? Welche Prozesse produzieren diese Produkte? Wer ist für diese Prozesse verantwortlich? Welche Ressourcen werden für diesen
Prozess ge- und verbraucht? Welche Daten und Methoden sind notwendig? Welcher Ertrag/Nutzen steht
dagegen? Im Ergebnis steht in der Regel eine je nach
Ausgangssituation mehr oder weniger umfangreiche
Anpassung des Betriebsmodells des Treasury. Kernelement dabei ist eine Strukturierung der Prozesse
entsprechend ihres Charakters in strategische bzw.
steuernde, ausführende und überwachende Prozesse. Compliance-Aspekte (unter anderem Funktionstrennung und interne Kontrollen) werden implizit
berücksichtigt. Im zweiten Schritt erfolgen die Evaluierung hinsichtlich des Standardisierungs- und Automatisierungspotenzials und anschließend eine Zuordnung zu den entsprechenden Plattformen, bestehend
aus Datenbanken und Systemen. Durch die Berücksichtigung auch der lokalen Prozesse und Besonderheiten entsteht somit ein konzernweites, klar strukturiertes Betriebsmodell im Sinne von Treasury 4.0. Auf
diese Weise wird insbesondere transparent gemacht,
welche Treasury-Dienstleistungen als Standard-Leistung angeboten werden. Oder zu welchen Produkten
die Treasury-Berater ihre Kunden in Einkauf, Vertrieb,
Personal etc. mit hochspezialisiertem Wissen individuell beraten müssen.
Für die Kompetenzprofile der Mitarbeiter hat dies
ebenfalls wesentliche Bedeutung. Wenn Prozesse digitalisiert sind, nimmt der Anteil operativer, manueller
Tätigkeiten massiv ab – dagegen sind IT-Kompetenzen sowie analytische Fähigkeiten die neuen Erfolgsfaktoren. Die Strukturierung und Auswertung von Daten, das Anwenden von Methoden der Datenanalyse
und das Ableiten von Handlungsmaßnahmen werden
wesentliche Aufgabengebiete.
Auch soziale Kompetenzen im Bereich der Kommunikation, Konfliktlösung und Moderation wie auch Verhandlungsführung sind von wesentlicher Bedeutung.
Die Rolle der Treasury-Mitarbeiter erfordert sehr viel
© 2017 KPMG AG Wirtschaftsprüfungsgesellschaft, ein Mitglied des KPMG-Netzwerks unabhängiger Mitgliedsfirmen, die KPMG International Cooperative („KPMG International“),
einer juristischen Person schweizerischen Rechts, angeschlossen sind. Alle Rechte vorbehalten.
Corporate Treasury News | 8
mehr Kommunikation mit Kollegen aus anderen Regionen und Kulturkreisen. Die Fokussierung auf diesen
Themenkomplex ist von daher bedeutsam, da das
Angebot am Aus- und Fortbildungsmarkt für Treasury-Management-Schulungen weiterhin die Schwerpunkte auf die fachlichen Themenstellungen legt.
Qualifizierung und Weiterbildung, Austausch im Netzwerk und die Analyse technologischer Entwicklungen
stehen also ganz oben auf der Entwicklungsagenda
für die Treasury-Mitarbeiter.
Fazit
Digitalisierung ist einer der Game Changer unserer
Zeit, mit der entsprechenden Bedeutung auch für das
Treasury. Basis für die Digitalisierung stellen standardisierte, klar strukturierte Treasury-Prozesse und
-Produkte dar. Damit verbunden sind entsprechende
Investitionen in Technologie und Methoden. Da wo
Verantwortlichkeiten für Prozesse, die Endprodukte
sowie deren Kosten und Nutzen transparent vorliegen, lassen sich Veränderungserfordernisse und deren Auswirkungen auch klar abgrenzen – und leichter
umsetzen. Das Treasury wird manövrierfähig und
kann schneller reagieren – vom Einphasen neuer Finanzprodukte bis hin zur Abbildung neuer Berichtsanforderungen. Nebenbei wird das Treasury fit gemacht
für die Anforderungen der Zukunft – welcher Art
diese auch sein mögen im nächsten Jahrzehnt.
Impressum
Herausgeber
KPMG AG
Wirtschaftsprüfungsgesellschaft
THE SQUAIRE, Am Flughafen
60549 Frankfurt
Redaktion
Prof. Dr. Christian Debus
(V.i.S.d.P.)
Partner, Finance Advisory
T + 49 69 9587-4264
[email protected]
Carsten Jäkel
Partner, Finance Advisory
T + 49 221 2073-1522
[email protected]
Newsletter kostenlos
abonnieren
www.kpmg.de/newsletter/
subscribe.aspx
Autor: Stephan Plein, Senior Manager,
Finance Advisory, [email protected]
www.kpmg.de
www.kpmg.de/socialmedia
Die enthaltenen Informationen sind allgemeiner Natur und
nicht auf die spezielle Situation einer Einzelperson oder einer juristischen Person ausgerichtet. Obwohl wir uns bemühen, zuverlässige und aktuelle Informationen zu liefern,
können wir nicht garantieren, dass diese Informationen so
zutreffend sind wie zum Zeitpunkt ihres Eingangs oder
dass sie auch in Zukunft so zutreffend sein werden. Niemand sollte aufgrund dieser Informationen handeln ohne
geeigneten fachlichen Rat und ohne gründliche Analyse der
betreffenden Situation. Unsere Leistungen erbringen wir
vorbehaltlich der berufsrechtlichen Prüfung der Zulässigkeit
in jedem Einzelfall.
© 2017 KPMG AG Wirtschaftsprüfungsgesellschaft, ein
Mitglied des KPMG-Netzwerks unabhängiger Mitgliedsfirmen, die KPMG International Cooperative („KPMG International“), einer juristischen Person schweizerischen Rechts,
angeschlossen sind. Alle Rechte vorbehalten. Der Name
KPMG und das Logo sind eingetragene Markenzeichen von
KPMG International.