Suche
Unsere Reise durch das Digi-Tal

Bank meets Start-up: Eine agile Reise durch die App-Entwicklung

Volkmar Klaußer, Robert Angrisani

© Shutterstock / trekandshoot

 

Während etablierte Banken ihren primären Fokus auf das Erfüllen rechtlicher Auflagen und auf Kosteneinsparungen legen, drängen neue Wettbewerber mit digitalen Technologien und Plattformen in den Markt – die so genannten FinTechs. Eine Lösungen diesen Disruptoren zu begegnen ist, sich mit ihnen zusammenzutun. Genau das hat eine Bank in einem App-Projekt getan. Sie traf auf agile Methoden und kundenzentrierte App-Entwicklung.

Um Kundenabwanderungen, Umsatzeinbußen und den Verlust von Marktanteilen zu vermeiden, müssen sich etablierte Finanzinstitute mit den Entwicklungen des FinTech-Markts auseinandersetzen und neue Strategien entwickeln. Zum einen können sie Kooperationen mit ausgewählten FinTech-Unternehmen eingehen. Zum anderen können deren Vorgehensweisen analysiert, adaptiert und im Entwicklungsprozess neuer Produkte angewandt werden. Allein in Deutschland waren Ende 2015 über 300 FinTechs aktiv. Unter diesen kommt es aber auch regelmäßig zu Fusionen und Einstellungen der Geschäftstätigkeit.

Ein Beispiel aus der Praxis zeigt, wie sich etablierte Player für die Herausforderungen des Markts wappnen: In der Wertpapierberatung verfügt die regional verwurzelte Baden-Württembergische Bank (BW-Bank) über eine lange Tradition. Mit ihren rund hundertvierzig Filialen übernimmt sie innerhalb der Landesbank Baden-Württemberg (LBBW) das Privat- und Unternehmenskundengeschäft. Um die hohen fachlichen Ansprüche ihrer Privatkunden in der Wertpapierberatung zu erfüllen, führte die BW-Bank 2001 ein Direktbrokerage-Angebot ein. Im Jahr 2006 wurde es auf eine neue technologische Basis gestellt. Die Webanwendung ist für klassische PCs optimiert und wird seit ihrer Einführung kontinuierlich weiterentwickelt. Jedoch sind die Marktanteile klassischer PCs aufgrund der steigenden Beliebtheit von Smartphones rückläufig. So stieg zwischen 2013 und 2016 die Anzahl der Smartphonenutzer in Deutschland von 33 auf 49 Millionen. Der Anteil der PC-Nutzer wiederum stieg lediglich von 53 auf circa 55 Millionen an. Aus den sich wandelnden Marktverhältnissen leitete die BW-Bank einen akuten Handlungsbedarf ab. Gemeinsam mit ihrem strategischen IT-Partner, der Finanz Informatik Solutions Plus (FI-SP), begann die Planung des mobilen Brokerageangebots AssetGo. Die zu entwickelnde App sollte auf die Anforderungen bestehender und potenzieller Kunden optimiert werden.

Neue Vorgehensweisen gestalten

Aus vorangegangenen Digitalisierungsprojekten brachte das Projektteam Erfahrungen in der Kooperation mit FinTechs ein. In diesen Projekten bewährten sich agile Vorgehen, die das frühzeitige Erproben eines Minimum Viable Products (MVP) ermöglichten. Unter einem MVP verstand das Projektteam ein funktionsfähiges Produkt, das die Mindestanforderungen der Kunden erfüllt. Beim Erstellen des Produkts wurde deutlich, dass die Erwartungen der Kunden an FinTech-Start-ups meist nicht so hoch sind wie an etablierte Banken. Die Anwendung AssetGo musste daher bereits bei Markteinführung einen breiteren Funktionsumfang mitbringen, um von Kunden akzeptiert zu werden.

Schon vor Projektstart war abzusehen, dass das in der BW-Bank als Standard etablierte, praxisbewährte und leistungsfähige LBBW-Vorgehensmodell für dieses Projekt strukturell weiterentwickelt werden musste. Es basiert auf dem phasenorientierten und weit verbreiteten Wasserfallmodell (Abb. 1). Die Phasen werden nacheinander durchlaufen. Eine Rücksprungmöglichkeit in die unmittelbar vorhergehende Phase ist zwar möglich, jedoch zu vermeiden. Um sicherzustellen, dass alle Phasen vollständig durchlaufen werden, erfolgen zum Ende jeder Phase qualitätssichernde Maßnahmen. Hierbei ist die Dokumentation besonders wichtig. Ihr Erstellen wird als zentrales Element zur erfolgreichen Softwareentwicklung gesehen. Insbesondere bei der Umsetzung regulatorischer Anforderungen bewährte sich dieses Vorgehensmodell.

Abb. 1: Schematische Darstellung des Wasserfallmodells

Im Projekt AssetGo hätte ein Vorgehen nach diesem Modell jedoch das frühzeitige Validieren des MVP verhindert. Aus diesem Grund modifizierte das AssetGo-Projektteam das bestehende Vorgehensmodell. Dabei wurden Aspekte des agilen Manifests aufgegriffen. Trotzdem mussten fest gesetzte Rahmenbedingungen erfüllt werden. Es mussten die Phasen und Dokumentationen des LBBW-Vorgehensmodells eingehalten, es musste auf Veränderungen von Anforderungen schnell reagiert und das Softwareprodukt früh und regelmäßig ausgeliefert werden (Abb. 2).

Abb. 2: Projektvorgehen bei der Erstellung von AssetGo

Das neu gestaltete Modell ist in Test- und Produktionsversionen untergliedert und weist Aspekte des Feature-driven Developments auf. Zu jeder Produktionsversion werden mehrere Testversionen realisiert. Diese wiederum setzen sich aus einem oder mehreren Features zusammen, die entwickelt und dokumentiert werden. Mit der frühen Entwicklung eines MVP lassen sich Rückmeldungen von Anwendern bereits im Entwicklungsprozess einholen und die Umsetzung neuer Features priorisieren.

Lesen Sie auch: Von der kreativen Zerstörung: Wie digitale Güter den Markt aufmischen

Nutzerorientierte Softwareentwicklung

Nachdem der organisatorische Rahmen für das Projekt geschaffen war, begann die nutzerzentrierte Entwicklung. Zu Beginn stand das Identifizieren der Zielgruppen und ihrer spezifischen Bedürfnisse an. Das Team identifizierte verschiedene Kundengruppen als potenzielle Nutzer der App (Abb. 3). Für jede der identifizierten Kundengruppen erfolgte anschließend das Erstellen einer Persona. Personas sind konkrete fiktive Anwender. Sie basieren auf realen und zuverlässigen Daten. Die Struktur der erstellten Personasteckbriefe zeigt Abbildung 4.

Abb. 3: Exemplarische Darstellung der Zielgruppen von AssetGo

Abb. 4: Inhalte eines Personasteckbriefs

Im nächsten Schritt wurden die individuellen Bedürfnisse der jeweiligen Personas an eine mobile Wertpapier-App strukturiert im Rahmen einer Umfrage erhoben. So wünschte sich etwa die junge Persona Gamification-Elemente, um spielerisch Anlagethemen kennenzulernen, etwa über virtuelle Belohnungssysteme. Hinzu kam der Wunsch nach Social Features wie Diskussionsforen zu Anlagethemen, die von der mittelalten Persona nachgefragt wurde. Die ältere Persona war demgegenüber insbesondere an aktuellen Börsendaten und Wertpapierentwicklungen interessiert, um sich ausführlich zu informieren. Dabei zeigte sich auch, dass etwa die jüngere und mittelalte Persona aufgrund des geringeren Zeitaufwands ihr Vermögen bevorzugt in Fonds und ETFs (Exchange Traded Fund) anlegt, während die ältere Persona verstärkt in einzelne Aktien investiert. Weitere Wünsche der älteren Persona bezogen sich auf Usabilityaspekte wie gute Lesbarkeit und entsprechende Farbkontraste.

Allen drei Personas gemein war der Wunsch nach interaktiven Grafiken, aussagekräftigen Informationen sowie eine einfache und klare Nutzerführung. Diesen Wünschen nach Einfachheit stehen aber in der Finanzwirtschaft umfangreiche regulatorische, sicherheitstechnische und wirtschaftliche Anforderungen diametral gegenüber. Allen Beteiligten war klar, dass Kompromisse im Hinblick auf das Kundenoptimum einzugehen sind.

Native App oder Web-App?

Das Spannungsfeld zwischen Usability und Wirtschaftlichkeit wird an einer zentralen Entscheidung deutlich, die zu Beginn der Umsetzungsphase im Projekt geklärt werden musste und weitreichende Auswirkungen auf den weiteren Softwareentwicklungsprozess hatte: Welche App-Architektur ist für AssetGo die richtige? Denn es gibt zwei grundsätzlich unterschiedliche Herangehensweisen: native Entwicklung und Webentwicklung.

Bei der nativen Entwicklung werden Apps speziell für das jeweilige mobile Betriebssystem entwickelt, also beispielsweise für iOS oder Android. Programmiert werden sie in den jeweiligen Programmiersprachen wie Swift oder Java. Diese Apps bieten eine gute Performance und sind auf alle Schnittstellen des Betriebssystems abgestimmt, sodass diese Apps die Hardware des Handys, wie den Fingerabdrucksensor, in ihre Funktionalitäten einbeziehen können. Gleichzeitig muss eine Anwendung für jedes Betriebssystem neu programmiert und fortlaufend gepflegt werden.
Mit modernen Webtechnologien wie Angular und Ionic programmierte Anwendungen sind ebenfalls für die Darstellung auf mobilen Endgeräten abgestimmt. Ein Zugriff auf die Ressourcen des Handys wie den Fingerabdrucksensor ist nicht möglich. Zudem sind sie nicht so performant wie native Apps. Dafür sind der Entwicklungs- und auch der nachgelagerte Administrationsaufwand geringer, da die Anwendung lediglich einmal für alle gängigen Betriebssysteme und Browser zu erstellen ist.

Schnell war im Projektteam klar, dass eine rein native App die Anforderungen aller Personas am besten erfüllt (Abb. 5). Gleichzeitig ist aus technischer und wirtschaftlicher Sicht die Web-App die bessere Wahl. Auf diesem Weg wird geschäftskritische Logik nur einmalig programmiert. Das minimiert das Risiko von Fehlern. Letztlich fiel die Entscheidung zugunsten einer hybriden App-Entwicklung, die Vorteile von beiden Modellen vereint. Dabei wird die Web-App in einer nativen Hülle eingebettet. Zusätzlich können Teile der hybriden App nativ entwickelt werden, um die Darstellung und somit das Nutzererlebnis zu verbessern.

Abb. 5: Auszug aus dem Bewertungsframework der App-Architekturen

Aufgrund der hohen sicherheitstechnischen Anforderungen wurden geschäftskritische Funktionen als Web-App realisiert. Neben der Reduzierung möglicher Fehlerquellen durch eine doppelte Umsetzung, hat dieses Vorgehen organisatorische Vorteile. So müssen die Webteile nicht den Reviewprozess der App-Store-Betreiber durchlaufen, der bis zu mehrere Tage lang dauern kann. Im Fall eines Produktionsfehlers kann so in kurzer Zeit eine neue Version des Webteils veröffentlicht und auf Endgeräte ausgespielt werden. Das absolvierende Update erfolgt innerhalb der App automatisiert und der Endanwender muss nicht aktiv werden.

Sehen Sie auch im JAX-TV: Deine Firma wird niemals agil werden

Gemeinsam zum Ziel

Über den gesamten Projektverlauf hinweg zeigte sich, dass im Projektteam weitere IT-Partner zum Erreichen der hochgesteckten Ziele von AssetGo eingebunden werden mussten. Mit ihrer Unterstützung wurde fehlendes Wissen im Bereich der Ausgestaltung von Personas und der nativen Entwicklung kompensiert. So wurde bereits zu den Konzeptionsworkshops eine Strategieberatung einbezogen, die in Bezug auf die veränderten Kundenbedürfnisse umfangreiches Know-how mitbrachte. Der Kreativprozess wurde somit deutlich beschleunigt und qualitativ auf eine neue Ebene gehoben. Auch die LBBW als Konzernmutter der BW-Bank war in das Projekt eingebunden, da sie die zentralen Aufgaben Compliance, Recht und Revision verantwortet. Für die Entwicklung diverser Komponenten der App sowie für den Betrieb der Infrastruktur wurden weitere Partner ins Boot geholt.

Deswegen mussten Kommunikationsstrukturen, die einen transparenten und schnellen Austausch zwischen allen Beteiligten über verteilte Standorte schaffen, eingeführt werden. Als zentrales Projektsteuerungstool wurde – wie bereits in vielen Projekten zuvor – JIRA Agile verwandt, um aufkommende Probleme frühzeitig zu identifizieren. Das Tool zeigte allen Beteiligten den Status der Teilprojekte, sodass die gesamte Projektstruktur schlank bleibt. So konnte die Projektleitung schnell erkennen, an welcher Stelle sie gegensteuern musste. Insbesondere die technische Fusion der Web-App mit der nativen App erforderte eine besonders enge Abstimmung.

Das Erstellen der Web- und der iOS-Teile erfolgte parallel. Ein Augenmerk lag in dieser Phase auf der Integration der Schnittstellen, um Daten unterbrechungsfrei in beiden Teilen der App darzustellen. Zudem wurde frühzeitig Nutzerfeedback eingeholt. Erst nachdem in der iOS-Version die Datenübergabe an den Schnittstellen weitgehend reibungslos lief und das Nutzerfeedback positiv ausfiel, wurden die Android-Teile realisiert.

Mit der kundenzentrierten Produktentwicklung kam den benötigten Testverfahren eine neue Bedeutung zu. Auf wenigen Testgeräten ausgeführte funktionale Tests erfüllten nicht mehr die neuen Anforderungen. So unterscheiden sich die im Markt angebotenen Endgeräte stark und müssen gesondert beispielweise im Hinblick auf Betriebssystemversionen und Displaygrößen geprüft werden.

Wohin geht die Reise?

Mit der Veröffentlichung von AssetGo hat die FI-SP gemeinsam mit der BW-Bank und ihren Partnern wesentliche Grundlagenarbeit innerhalb der LBBW zur kundenzentrierten Entwicklung von Anwendungen geleistet. Aber die Reise ist noch nicht beendet. In den nächsten Schritten gilt es, auf Basis des Nutzerfeedbacks neue Funktionalitäten zu definieren und für die Weiterentwicklung zu priorisieren. Dabei geht es sowohl um die Verbesserung bestehender Funktionalitäten als auch die Integration neuer Funktionen.

Zeitgleich bewährte sich die Adaption eines agileren Vorgehens in einem Umfeld, in dem auf Basis des Wasserfallmodells vorgegangen wird. Es wurde dabei deutlich, dass der Trend in der kundenzentrierten Entwicklung stark zu agileren Methoden tendiert. Gleichzeitig sind jedoch insbesondere im Bankenumfeld erhöhte Anforderungen im Bereich des Datenschutzes, der Sicherheit und der Regulatorik zu erfüllen. Aufgrund dieser Anforderungen wird sich die Adaption agiler Vorgehensweisen zu einer zentralen Herausforderung hin entwickeln.

Tipps für die Zukunft

Bei dieser Reise in und durch das Digi-Tal hat das Softwareentwicklungsteam unternehmensübergreifend viele Erfahrungen gesammelt. Für das gesamte Team ist klar, dass die Zeiten der Softwareentwicklung in einem abgeschotteten Silo ohne Blick auf den Kunden vorbei sind. Kunden und ihre Bedürfnisse stehen heute im Zentrum und müssen aktiv in Projekte eingebunden werden.

Abb. 6: Unsere Tipps für die Zukunft

Bewährt hat sich, die Projektmitarbeiter aktiv auf neue Entwicklungsprozesse einzuschwören. Gleichzeitig ist die Bereitschaft erforderlich, weitreichende Anpassungen vorzunehmen und Features gegebenenfalls neu zu entwickeln oder zu verwerfen. Daher sind die Projektverantwortlichen gefordert. Sie müssen die Motivation der Teammitglieder hochhalten und bei Problemen frühzeitig gegensteuern. Bestehende Verfahren sind zudem kritisch zu hinterfragen. Blindes Folgen eines bekannten Pfades führt nicht zwangsläufig zum Ziel. Vielmehr braucht es Querdenker, die bereit sind, neue Wege zu gehen.

Eine weitere wichtige Erkenntnis ist, dass die Zusammenarbeit mit Partnern die Arbeit erleichtert, um etwa zusätzliche Funktionen zu integrieren oder zu verifizieren. Das spart sowohl Entwicklungszeit als auch Kosten. Und ganz wichtig: Digitalisierungsprojekte enden nicht an einem definierten Datum. Die Reise geht über immer neue Wege weiter, die vorab nicht gänzlich zu definieren sind. Deshalb gilt es, den Kontakt zum Kunden aufrechtzuhalten, um dessen sich ändernden Bedürfnisse dauerhaft und schnell antizipieren zu können. Nur so ist man in der Lage, durch attraktive Angebote die Gunst der Kunden langfristig zu gewinnen. Insofern ist unsere Reise durch das Digi-Tal auch kein Projekt im eigentlichen Sinne. Sie ist vielmehr ein Weg, auf den es gilt, sich einzulassen.

Geschrieben von
Volkmar Klaußer
Volkmar Klaußer
Volkmar Klaußer verantwortet als Testmanager bei der FI-SP den Aufbau einer Testumgebung für Apps und steuert IT-Projekte als Teilprojektleiter. Schon während seines Studiums der Wirtschaftsinformatik hat er aktiv digitale Innovationen vorangetrieben. Darüber hinaus studiert er derzeit berufsbegleitend Technologie- und Innovationsmanagement.
Robert Angrisani
Robert Angrisani
Robert Angrisani verantwortet als Projektleiter seit fast zwei Jahrzehnten Projekte im Wertpapier- und Privatkundenumfeld bei Banken. In den letzten vier Jahren trieb er insbesondere die Einführung innovativer Lösungen im Rahmen der Digitalisierung voran.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.