Die Auswirkungen agiler Softwareentwicklung auf TMS-Projekte

Auswirkungen Softwareentwicklung auf TMS-Projekte

In den vergangenen Jahren hat sich die agile Software- und Systementwicklung zu einer Alternative zu den klassischen Methoden entwickelt.

1000

Verwandte Inhalte

FTM Bildwelt: Haus im Schnee

In den vergangenen Jahren hat sich die agile Software- und Systementwicklung zu einer Alternative zu den klassischen Methoden entwickelt.

Hierzu zählt zum Beispiel das Wasserfallmodell, welches Entwicklungsprojekte nach den fundamentalen Phasen wie Analyse, Spezifikation, Design, Implementierung und Test einteilt. Agile Entwicklungsmethoden verfolgend dagegen einen anderen Ansatz: kurze Release-Zyklen und inkrementelle Entwicklung, basierend auf der engen Zusammenarbeit und der zeitnahen Rückmeldung der Kunden.

Auch im Treasury beobachten wir mittlerweile immer mehr agile Methoden und Scrum1-Projekte. Vor allem beim Einsatz komplexerer Treasury-Management-Systeme (TMS) reicht der Einsatz eines Produktes von der Stange meist nicht aus. Bei der Umsetzung größerer TMS-Projekte summieren sich oft technisch notwendige Aktualisierungen zu unterschiedlichen Anforderungen aus den eigenen Fachbereichen, nebst externen (regulatorischen) Neuerungen.

Ergibt die Analysephase eines solchen Projektes, dass die angebotene Lösung des Herstellers Lücken zu den eigenen Anforderungen aufweist, es also einen Bedarf an Neuentwicklung seitens des Herstellers gibt, werden zunehmend agile Arbeitsweisen angewandt.

Was aber sind die Auswirkungen agiler Systementwicklung auf die Prozesse und die Projekte im Treasury, insbesondere bei einer Neueinführung oder einem Upgrade des eingesetzten Treasury-Management-Systems? Wie stark sind Projektstruktur, geplantes Vorgehen (Projekt-, Aufgaben- und Ressourcenplan) und nicht zuletzt die gesamte Unternehmensorganisation hiervon betroffen? Auf welche grundlegenden Herausforderungen müssen Unternehmen sich einstellen?

Was kennzeichnet agile Systementwicklung?

Sofern die Anforderungsanalyse zu Beginn eines Projektes ergibt, dass bei Einführung oder Upgrade eines TMS an der einen oder anderen Stelle Entwicklungsbedarf im Hinblick auf die Standardlösung besteht, so würde sich im Sinne einer agilen Systementwicklung nach Scrum eine Entwicklungsphase in sogenannten Sprints anschließen.

Während eines Sprints entwickelt ein Team einen voll funktionsfähigen Anwendungsteil auf Basis eines vorab definierten Arbeitspaketes (Inkrements). Sprints dauern in der Regel zwei Wochen und werden sinnvollerweise in Blöcken von Entwicklungs- und Korrektursprints zusammengefasst. Am Ende eines Sprints bzw. Blocks wird das Inkrement, sprich die implementierte Funktionalität, in Form eines Sprint Review Meetings dem Kunden präsentiert. Basierend auf dessen Feedback und neuer Anforderungen findet dann die Detailplanung für die nächsten Sprints statt.

Zum Wesen der agilen Methodik gehört es also, dass kürzere Entwicklungszyklen zu mehr Deliverables (Sprints) in kleineren Zeitabschnitten führen. Die klassische Trennung in Aufnahme der Anforderungen und Umsetzung beim Hersteller mit anschließender Auslieferung an den Kunden (mit nachfolgender Integration, Test und Abnahme bis hin zur Produktivsetzung), weicht einer iterativen Vorgehensweise, die den Kunden im Gesamtverlauf stärker einbezieht.

Was sind die Konsequenzen für Kunden?

Agile Systementwicklung erfordert einerseits eine intensive Kommunikation und enge Kollaboration des Kunden mit dem Hersteller, andererseits auch einen erhöhten Aufwand an Integration und Test der inkrementell entwickelten Bestandteile der Gesamtlösung. Bezüglich des Testings werden Regressionstests an Bedeutung zunehmen, da stets gewährleistet sein muss, dass zuvor getestete und freigegebene Komponenten nach wie vor fehlerfrei funktionieren.

Hierbei empfiehlt es sich, einen hohen Grad an Automatisierung von Testfällen anzustreben, um diese Tests möglichst ohne großen manuellen Aufwand wiederholt durchführen zu können. Aber auch entscheidende Testphasen durch die Endanwender wie User Acceptance Tests, werden sich – auf mehrere Abschnitte aufgeteilt – in den Projektverlauf einfügen müssen und nicht mehr klassischerweise am Ende des Projekts als eine Phase geplant werden können.

Die agile Arbeitsweise erfordert auch eine Umstellung der Organisation bei den Kunden. Durch den Schwerpunkt auf schnelle Bereitstellung funktionierender Softwarebestandteile und den Verzicht auf Bürokratismus sind Auswirkungen auf die Projektplanung und das Projekt- bzw. Budgetcontrolling zu erwarten.

Bezüglich der Projektteams werden Fachexperten des Kunden und Entwickler auf Seiten der Hersteller eng miteinander kooperieren und mit entsprechenden Entscheidungsbefugnissen ausgestattet sein müssen.

Welche Vor- und Nachteile ergeben sich?

Zu den Vorteilen zählen sicherlich die rasche Umsetzung von Anforderungen durch kürzere Entwicklungszyklen und schnellere Auslieferung von Funktionen an den Kunden. Das Risiko, einen falschen Weg eingeschlagen zu haben, wird im Projektverlauf schnell erkannt und kann relativ unbürokratisch beseitigt werden.

Dies macht sich vor allem dann bezahlt, wenn die Qualität der umgesetzten Anforderungen erst am Prototyp wirklich sinnvoll beurteilt werden kann. Durch frühzeitiges Einbeziehen des Kunden und eng getaktete Demonstrationen neuer Funktionalitäten der Software kann flexibel auf erkannte Fehler, Gaps oder neu zu berücksichtigende Änderungen reagiert werden. Der Kunde kann frühzeitig auf wesentliche Entwicklungsschritte einwirken und nimmt aktiv am Entscheidungsprozess teil.

Je nachdem inwieweit eine agile Struktur im Unternehmen bzw. in der Abteilung bereits Einzug gehalten hat, geht die Einführung von Scrum, Kanban & Co. jedoch mit einem nicht zu unterschätzenden Umstellungsaufwand einher. Agile Methoden setzen eine enge Zusammenarbeit des Kunden (in idealerweise eher kleineren Teams) mit dem Lieferanten voraus, die sich in häufigen Meetings, Abstimmungen und vermehrten Tests der Software widerspiegelt.

Dieser iterative Prozess kann eine große Umstellung hinsichtlich der Projektplanung, der Projektstruktur, der Zeit- und Ressourcenplanung sowie der Feedback-Kultur, bis hin zu einer grundlegenden Änderung der Denkweise bei Management und Mitarbeitern bedeuten. Wenn der Hersteller agil denkt und handelt, so müssen auch die Kunden entsprechend flexibel reagieren, um die Potenziale der agilen Arbeitsweise voll auszuschöpfen und einen beiderseitig entsprechenden Nutzen daraus zu ziehen.

Auch für die projektbegleitende Prüfung von TMS-Projekten hat dieser Ansatz Auswirkungen. Durch die Tatsache, dass viele Anforderungen vorab nicht klar definiert sind und erst im Projektverlauf genau spezifiziert und implementiert werden, wird eine Nachvollziehbarkeit von Anforderungen und deren Umsetzung immer schwieriger. Der Wirtschaftsprüfer sollte dementsprechend in den Prozess der Abstimmung zwischen Hersteller und Kunde kontinuierlich einbezogen sein, um die Entwicklung einzelner Items adäquat mitverfolgen und prüfen zu können.

Letztendlich muss gewährleistet sein, dass alle Anforderungen berücksichtigt, korrekt umgesetzt und entsprechend dokumentiert wurden – auch wenn der Schwerpunkt der agilen Methodik auf dem funktionsfähigen Produkt und nicht auf ausgefeilten Spezifikationen/Lastenheften liegt. Nur durch konsequente Dokumentation und geeignete Reporting-Mechanismen können auch kurzfristige Änderungen, die in kleinen, übergreifenden Teams besprochen und abgestimmt wurden, nachvollziehbar dargestellt werden.

Was sind die Herausforderungen?

Je nachdem wie weit agiles Projektmanagement, agiles Denken und entsprechende Strukturen im Unternehmen gegeben und entwickelt sind, stellen agile TMS-Projekte eine mehr oder weniger große Herausforderung an die Steakholder und Mitarbeiter im Unternehmen dar.

Je komplexer die Einbindung eines TMS innerhalb der Unternehmensorganisation und -struktur (wie zum Beispiel die Vernetzung mehrerer Abteilungen und Tochtergesellschaften, eine Vielzahl an Schnittstellen zu anderen Systemen, Lieferanten und Banken), desto größer wird auch die Auswirkung sein.

Nichtsdestotrotz wird man um agile Methoden in TMS-Projekten nicht mehr herumkommen, da neben den sich ändernden fachlichen Gegebenheiten auch vermehrt regulatorische Anforderungen (geänderte Accounting-Standards, neue Richtlinien und Gesetze, etc.) eine hohe Flexibilität und eine zeitnahe Umsetzung erfordern.

Hierbei können kürzere Projektphasen und kleinere Software-Entwicklungsschritte mit zeitnaher Validierung der Ergebnisse signifikant beitragen. Außerdem ist ein enger Schulterschluss mit dem Softwareprovider und seinen Methoden und Ansätzen unabdingbar, um gemeinsame Projekte erfolgreich „in time“ abwickeln zu können.

Die wesentlichen Gesichtspunkte der agilen Entwicklung sollten frühzeitig zwischen allen Beteiligten transparent gemacht, klar definiert und abgestimmt werden, um von Anfang an eine übereinstimmende Planung und Vorgehensweise und einen möglichst reibungslosen Projektablauf zu ermöglichen.

Quelle: KPMG Corporate Treasury News, Ausgabe 62, Dezember 2016
Autor: Tobias Riehle, Manager, Finance Advisory, triehle@kpmg.com

 

1 Scrum ist ein in der Praxis häufig angewandtes Modell für agiles Projektmanagement und agile Softwareentwicklung. Kennzeichen sind eine empirische, iterative Vorgehensweise und inkrementelle Entwicklungen. Über wenige fest definierte Rollen und Werkzeuge wird der Schwerpunkt auf Flexibilität und Team-Dynamik gelegt.

Finanz- & Treasury Management

Das Expertenteam vom KPMG weist Ihnen den richtigen Weg im Finanz- und Treasury-Management.

 
Lesen Sie mehr

KPMG Corporate Treasury News

So kontaktieren Sie uns

 

Angebotsanfrage (RFP)

 

Absenden

KPMG's neue digitale Plattform

KPMG hat einen neuen Webauftritt entwickelt, der einen möglichst einfachen, nutzerfreundlichen Zugang zu den Inhalten von KPMG bieten soll.

 
Lesen Sie mehr