Agile Softwareprojekte bei Finanzdienstleistern: Agil am Vertrieb vorbei?

Zunehmend werden auch Vertriebseinheiten von Finanzdienstleistern mit agiler Softwareentwicklung konfrontiert. Diese Nutzergruppe hat jedoch spezifische Anforderungen, die beim Einsatz agiler Software-Entwicklung zu neuen Herausforderungen führen. Für den Projekterfolg spielt richtiges Rollout-Management eine umso zentralere Rolle.

von Dirk Schleuder, Principal Consultant
Digital Unit PPI

Eingriffe in die Ver­triebs­soft­ware von Fi­nanz­dienst­leis­tern stel­len im­mer ei­ne Her­aus­for­de­rung dar. Dies gilt für un­ter­neh­mens­in­ter­ne Ver­triebs­ap­pli­ka­tio­nen oder -por­ta­le und in noch stär­ke­rem Ma­ße für An­ge­bo­te im B2B-Be­reich, wie sie im Be­reich von Han­dels­ver­tre­tern und cap­ti­ve oder non-cap­ti­ve Au­to­ban­ken üblich sind.

Bei gro­ßen Fi­nanz­kon­zer­nen um­fas­sen die­se An­wen­der­grup­pen schnell meh­re­re tau­send Nut­zer mit zum Teil ho­hen va­ria­blen, um­satz­ab­hän­gi­gen Ge­halts­an­tei­len.

Eine den Vertriebszielen adäquate Software stellt für diese Gruppen einen Hygienefaktor dar. Die Fehlerakzeptanz oder die Bereitschaft, MVP zu akzeptieren, tendiert daher gegen Null. Geringfügige Defizite bei der zur Verfügung gestellten Software ohne entsprechende Steuerung der Erwartungen führen innerhalb kürzester Zeit zu Demotivation und Ablehnung.”

Damit stellt die Akzeptanzsicherung bei diesen Nutzergruppen eine zentrale Herausforderung dar, die in Projekten entsprechend berücksichtigt werden muss.

Dies gilt umso mehr bei agilen Projektvorgehen, die aufgrund ihres iterativ inkrementellen Vorgehens in der Softwareentwicklung schnell mit der Erwartungshaltung des Vertriebs nach einer sofort vollumfänglich einsatzbaren und fehlerfreien Software kollidieren.

Hinzu kommt oft, dass sich agile Teams noch oft in eher traditionellen Umfeldern bewegen und die Etablierung der agilen Strukturen und Methoden einen wesentlichen Teil der Projektressourcen bindet. Dennoch gilt es zu vermeiden, dass ein nicht optimal durchgeführter Rollout die Vorteile der agilen Softwareentwicklung konterkariert, indem pro Sprint-Inkrement etwas („Ein Stück Software“) „über den Zaun“ geworfen und darauf vertraut wird, dass bestehende Standardprozesse innerhalb der Unternehmen – um im Bild zu bleiben – diesen Ball aufnehmen und verlängern. Bestenfalls sind in der Definition of Done je Sprint Übergabedokumente vorgesehen, die diese Übergabe strukturieren. Für den Erfolg dieser Vorgehensweise gilt dabei: „…the fewer people who work on those systems the better“ (Water-Scrum-Fall is the realitiy of agile for most organizations today. West, Dave. Forrester Research, S. 2017, 6.).

Im Hinblick auf die eingangs skizzierten Nutzergruppen ist dieses Verfahren allerdings nicht zielführend. Gerade hier ist gut durchdachtes Einführungsmanagement entscheidend für den Projekterfolg und die Akzeptanz bei den Nutzern. Daneben gibt es aber auch aufsichtsrechtliche Themen, die eine frühzeitige Beschäftigung mit den Fragen des Einführungsmanagements erforderlich machen.

Wesentliche Aspekte des Einführungsmanagements

Bevor nun auf die Einbindung der Rollout-Maßnahmen im agilen Projektumfeld eingegangen werden soll, sind die wesentlichen Aktivitäten für eine nachhaltige Einführung neuer Softwarelösungen zu definieren. Denn allzu schnell dreht sich in diesem Kontext die Diskussion nur um Fragen nach der operativen Einführungsdurchführung: Big Bang Verfahren, sukzessive Einführung nach Regionen oder nach Funktionen gestaffelt mit oder ohne vorgelagerter Pilotierungsphase.
Im Hinblick auf die o.g. Thematik greift dieses Vorgehen jedoch zu kurz, denn Rollout-Management sollte grundsätzlich alle Aspekte berücksichtigen, die nötig sind, einen ordnungsgemäßen und vertriebsorientierten Softwareeinsatz sicherzustellen.

So verstanden zählen hierzu

1. alle Fragen rund um Kommunikation und Training
2. der Aufbau und die Etablierung eines effizienten Anwender-Supports
3. die Klärung aller organisatorischen und rechtlichen Fragen zur Sicherung eines ordnungsgemäßen Betriebs der Software und natürlich
4. die operative Durchführung der Software-Einführung bei den Nutzern.

In einem erweiterten Verständnis sind auch die Themen Migrations- sowie Rollen und Rechtekonzepte zu beleuchten, da diese in ihren Auswirkungen von den betroffenen Nutzergruppen oft unterschätzt werden und sie außerdem für den Rollout-Prozess wichtige Eckparameter definieren.

1. Kommunikation und Training

Neben der erwartbaren Relevanz dieses Themenkomplexes für die Nutzerakzeptanz sind es im Wesentlichen aufsichtsrechtliche Aspekte in Form von Verfahrensdokumentationen, die die Kommunikation und das Training in den Fokus rücken. Denn relevant sind hier sowohl die Grundsätze ordnungsgemäßer Buchführung als auch die Richtlinien für projektbegleitende Prüfungen im Rahmen von IT Projekten und die Mindestanforderungen für das Risikomanagement.

Das Vorhandensein eines Trainingskonzepts mit detaillierter Klärung der relevanten Zielgruppen, Trainingsinhalten und –vorgehen samt Klärung von Trainingsinfrastruktur und Zeitplan ist Basis des weiteren Vorgehens.

Aus Vertriebssicht ist dabei zu berücksichtigen, dass Trainingszeit grundsätzlich zu Lasten der Vertriebszeit der Nutzer geht. Daher ist möglichst nach vertriebsschonenden Lösungen zu suchen, die meist einen entsprechend langen Vorlauf benötigen.
Ein nicht zu unterschätzender Aspekt ist außerdem, dass Schulungsmaßnahmen für angestellte Mitarbeiter mitbestimmungspflichtig sind und daher in enger Abstimmung mit Personalabteilung und Mitarbeitervertretern geplant werden müssen.

Abhängig von den gewählten Trainingsmaßnahmen sind darauf abgestimmte Trainingsunterlagen zu erstellen, die interne oder externe Trainer in die Lage versetzen, die Nutzer zu schulen. Hierbei spielen unterschiedliche Nutzergruppen ebenso eine Rolle wie die ausgewählte Form der Umsetzung wie bspw. klassische Präsenztrainings, Webinar oder Selbstlernprogramme.

Eine fundierte Benutzerdokumentation erstellt aus Nutzer- und nicht aus Entwickler- oder Business Analysten Sicht ergänzt die erforderlichen Dokumente, und sie können bei zielgruppengerechter Umsetzung unschätzbare Hilfe bei der Akzeptanz neuer Vertriebsapplikationen leisten. Oft genug wird diese notwendige Dokumentation leider in dynamischen Entwicklungsprojekten vor sich her geschoben bis hin zu ungeliebten Nachdokumentationen, die dann meist für die Nutzer deutlich zu spät kommen.

Projektkommunikation

Daneben zählt die Projektkommunikation zu diesem Themenkomplex. Im Hinblick auf große Nutzergruppen ist diese als Projektmarketing zu verstehen, das über das Finden blumiger Projektnamen weit hinausgeht. Hierbei ist wichtig, über die diversen Iterationszyklen hinweg, von Anfang an einen roten Faden der Kommunikation zu finden.

Empfehlenswert ist dabei, die in großen Konzernen vorhandenen Kommunikations- und Marketingabteilungen frühzeitig zu involvieren und den gesamten zur Verfügung stehenden Medienmix zu bespielen, statt zu versuchen, dies autark aus dem Projekt heraus zu leisten.”

Soll auf den positiven Effekt der Beteiligung des Top Managements an Motivationsveranstaltungen (Kickoffs, Besuch direkt bei den betroffenen Nutzern o.ä.) gesetzt werden, sind – ganz operativ betrachtet – langfristige Terminplanungen empfehlenswert, da erfahrungsgemäß die Terminkalender dieser Zielgruppe nur begrenzt Agilität zulassen. Dass diese Termine mit den wichtigen Meilensteinen des Projekts abzugleichen sind, versteht sich von selbst.

2. Anwender-Support

Trotz guter Kommunikations-, Trainings- und Dokumentationsmaßnahmen ist in den Anfangsphasen von Software-Einführungen mit einer deutlich erhöhten Support-Nachfrage zu rechnen. Diese speist sich zum einen aus Incidents (Bugs), die ggf. in vorgeschalteten Tests nicht gefunden wurden und daneben aus Service Requests, die sich wiederum in Bedienungsfragen unterschiedlichster Art und neue Anforderungen (u.a. Change Requests) grob clustern lassen.

Vor allem Letztere stellen einen stetigen Fluss für neue Inkremente dar, die so schnell wie möglich mit in die Sprint Planungen einfließen sollten. An dieser Stelle können gegenüber Vertriebseinheiten die Vorteile der Agilität voll zum Tragen kommen, da bei der Softwareauslieferung ggf. noch bestehende Defizite schnell aufgegriffen, umgesetzt und implementiert werden können.

Voraussetzung hierfür ist allerdings eine entsprechende Vorbereitung des Supports. D.h. konkret die Anpassung des Incident- und Service Request Managements an die ausgelieferte Software. Da die Support-Einheiten oftmals outgesourct sind, sind hierzu zuerst die bestehenden Vertragskonstellationen zu prüfen und ggf. zu erweitern. Abhängig von der konkreten Rollout-Planung müssen außerdem Ressourcen und Einsatzzeiten angepasst werden.

Auch in diesem Themenkomplex sind Anforderungen der Verfahrensdokumentation relevant, hier namentlich das Vorliegen eines Service- und Support-Konzepts, in dem neben dem Incident Management auch Problem-, Release und Eventmanagement u.a.m. definiert werden.

In Hinblick auf die eingesetzten Tools im Support sind meist Anpassungen vorzunehmen, die eine adäquate Ticketaufnahme und idealerweise Kategorisierung zulassen, die über die Supportlevel hinweg eine schnelle Identifikation und Zuordnung zu den an der Softwareentwicklung beteiligten Teams sowohl fachlich als auch technisch zulassen. Da im Zuge der Digitalisierung die Schnittstellenkomplexität in diverse Richtungen deutlich ansteigt, sind hier alle beteiligten Module zu berücksichtigen und in die Prozesse einzubinden. Frühzeitige Prozessintegrationstests sichern die definierten Verfahrensweisen anschließend ab.

Die frühzeitige Beschäftigung mit Fragen des Anwendersupports einschließlich Schulung der Support-Mitarbeiter ist auch deshalb wichtig, weil Vertriebsorganisationen dazu neigen, ihre berechtigte oder unberechtigte Kritik über diverse Kanäle und hierarchieübergreifend zu kommunizieren.”

Ein optimal vorbereiteter Support dient daher auch dazu, eine Kakophonie der Stimmen aus dem Vertrieb zu kanalisieren und schnell an die richtigen Stellen zu lenken. Nur so haben agile Projektteams die Chance, ihre Arbeit erfolgreich abzusichern, da andernfalls die Gefahr besteht, in einer Flut von Anforderungen, über diverse Kanäle in unterschiedlichster Qualität gestellt, unterzugehen.

3. Klärung organisatorischer und rechtlicher Fragen zur Sicherung eines ordnungsgemäßen Betriebs der Software

Eine in modernen agilen Projekten meist ungeliebte Tätigkeit besteht in der organisatorischen und vertraglichen Absicherung des Regelbetriebs.
Zu trennen sind dabei externe Vertragskonstellationen und intern organisatorische Fragestellungen.

Nicht erst mit Einführung der Datenschutzgrundverordnung ist auf eine formal-juristische einwandfreie Vertragsbasis aller Beteiligten zu achten. Hierbei sind zuvorderst die bei Web-Lösungen üblichen Nutzervereinbarungen unter Berücksichtigung der Auftragsdatenverarbeitung zu betrachten. Risikogesichtspunkte sind für die Entscheidung zwischen papierhaften und online Vereinbarungen zu klären und ggf. sind hieraus abgeleitet entsprechende Kommunikationsmaßnahmen in Richtung der Endnutzer abzuleiten.
Daneben sind natürlich alle notwendigen Serviceverträge (SLA und OLA), falls vorhanden modulübergreifend, zu definieren. Hierbei ist darauf zu achten, die in Großunternehmen vorhandenen Rechtsabteilungen und Service-Management-Einheiten so früh wie möglich einzubinden.

Intern sind vorhandene relevante Arbeitsanweisungen und Prozessdokumentationen auf Anpassungsbedarf hin zu prüfen bzw. ggf. auch neu zu erstellen. Dabei sind Schnittstellen zum Kontext Kommunikation und Training zu beachten.

4. Operative Einführungsdurchführung

Im Rahmen der operativen Einführungsdurchführung sind alle Aktivitäten zu bündeln, die operativ notwendig sind, den Einsatz der Software bei den Nutzern zu ermöglichen.

Hierzu zählt im besten Falle schon die Organisation und Teilnahme am Feldtest mit Vertretern der betroffenen Vertriebseinheiten, die herkömmlicher Weise aus dem Entwicklungsprojekt heraus ohne Beteiligung von Linienorganisationen durchgeführt wird. Allerdings können sich aus der ersten Konfrontation von Software und Nutzern wichtige Erkenntnisse ergeben, die für die Vorbereitung der Supporteinheiten und für Kommunikation und Training relevant sind, daher sollten die für den Rollout zuständigen Projektmitglieder hieran beteiligt werden.
Spätestens im Falle einer Pilotierungsphase sollten allerdings alle Regelbetriebsprozesse greifen und auf Schwachstellen abgeklopft werden. Je nach Länge dieser Phase sind Lessons Learned Sequenzen vorzusehen und die dort erarbeiteten Ergebnisse zügig umzusetzen.

Die Durchführung der Trainingsmaßnahmen sowie die Umsetzung der jeweiligen Go-Live-Termine mit Überwachung ggf. notwendiger Datenmigrationen und Go-Live-Unterstützung fallen auch in diese Kategorie von Tätigkeiten. Vor allem bei der sequenziellen Umstellung größerer Vertriebs-/Filialorganisationen ist Sorge dafür zu tragen, jederzeit Transparenz über den Umsetzungsstand gegenüber dem Management schaffen zu können. Das hierfür notwendige Reporting ist vorab entsprechend zu planen und abzustimmen.

Je nach Komplexität des Umstellungsprozesses der jeweiligen Vertriebseinheit ist unter Umständen ein technischer Sonder-Support bereitzustellen, der schnell auf Probleme bis hin zu Fallback-Lösungen reagiert.”

Last but not least ist auch die finale Abschaltung des Alt-Systems zu betrachten. Neben den hierfür notwendigen Maßnahmen im IT-Betrieb und der Nutzerkommunikation sind auch die vertraglichen Vereinbarungen in Bezug auf die Datenhoheit im Alt-System zu prüfen. Sind Datenmigrationen nicht oder nur teilweise erfolgt, müssen abhängig von der konkreten Konstellation Wege geprüft werden, Nutzern diese Daten auch nach Ablösung des Alt-Systems zur Verfügung zu stellen.

Einbindung des Rollout-Managements in agile Projekte

Das in diesem Verständnis definierte Rollout-Management kann in klassischen Wasserfall-Modellen als Teilprojekt entweder integriert in das Gesamtprojekt oder aber nachgelagert aufgesetzt werden.  Insbesondere im zweiten Fall besteht allerdings die Gefahr einer verlängerten Projektdauer und im schlechtesten Falle eines missglückten Rollouts, da evtl. die bei Projektstart definierte Finanzierung nicht mehr zur Verfügung steht. Hinzu kommt, dass nach Entwicklungsschluss Ressourcen meist anderweitig verplant sind und für Bugfixing und Changes nicht mehr zur Verfügung stehen.

Für agil durchgeführte Projekte sollte das Einführungsmanagement dagegen so eng wie möglich integriert werden, eng mit der Realisierung jedes Inkrements verzahnt und mit dem Entwicklungsteam kooperierend. Die erarbeiteten Lösungen können auf diese Weise zügig in Produktion kommen und das über einen effizienten Support aufgenommene Feedback der Nutzer kann direkt mit in die Sprints eingeplant werden. Die Vorteile agiler Projektvorgehen werden damit für die unter Umsatzdruck stehenden Vertriebseinheiten spürbar. Voraussetzung ist hierzu natürlich, dass die produktiven Infrastrukturen vorab skalierbar vorhanden sind.

Die oben beschriebenen Bestandteile des Rollouts sind adäquat in die Definition of Done aufzunehmen. Um über die diversen Inkremente dauerhaft eine Kohärenz der Ergebnisse sicherzustellen, ist mit Projektstart die Konzeption des Einführungsverfahrens über alle notwendigen Aspekte des Rollouts zu definieren. Nicht zu vergessen sind dabei auch Fallback-Szenarien, falls ausgelieferte Inkremente einmal „zurückgedreht“ werden müssen.

Wichtig für dieses Rahmenkonzept ist, vorab detailliert die von der Einführung betroffenen Zielgruppen zu definieren: welche Nutzer sind betroffen, wie sind diese Nutzer verteilt, wie lassen sich Cluster bilden, wie groß sind diese Gruppen, können Priorisierungen in Abstimmung mit dem Vertrieb gebildet werden (z.B. nach den jeweiligen Vertriebsumsätzen) u.a.m. Daneben sind auch die betroffenen Prozesse genau zu prüfen, wie verändern sich diese Prozesse auf Basis der Produktvision durch die Einführung und welche konkreten Auswirkung wird dies voraussichtlich auf die Nutzer haben. Daneben ist auch die regionale/räumliche Verteilung der Nutzer zu klären, welche etablierten Kommunikationswege sind vorhanden und welche Trainingsmedien stehen zur Verfügung.

Fazit

Sind diese und mehr Fragen geklärt und in einen konzeptionellen Rahmen für die Auslieferung von Inkrementen überführt, der jeweils bei Auslieferung die oben genannten Kernbestandteile des Rollout-Managements berücksichtigt, so ist gewährleistet, dass das iterativ inkrementelle Projektvorgehen auch große Vertriebseinheiten mit auf die Reise nimmt und nicht agil an den eigentlichen Nutzern des Systems vorbei entwickelt wird.aj