KPMG Corporate Treasury News 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: de-corporate-treasury@kpmg.com 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, karinschmidt@kpmg.com

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, michaelbaum@kpmg.com

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 cdebus@kpmg.com Carsten Jäkel Partner, Finance Advisory T + 49 221 2073-1522 cjaekel@kpmg.com

Newsletter kostenlos abonnieren www.kpmg.de/newsletter/ subscribe.aspx

Autor: Stephan Plein, Senior Manager, Finance Advisory, splein@kpmg.com

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.