Vom Halbjahres-Release zu Neuerungen im Monatszyklus

In Zeiten der digitalen Transformation gilt es in der Finanzbranche, nicht mehr auf Altbewährtes zu setzen, sondern neue Wege zu gehen, um den Kontakt zum Kunden zu halten. Neue Produkte, Beratungskonzepte und innovative Arbeitsprozesse helfen dabei, dies zu erreichen.

Eigentlich kann man es nicht mehr hören: Überall sprechen die Unternehmenslenker nur noch von digitaler Transformation, agiler Produktentwicklung und Kundenzentriertheit. Dies gilt nicht zuletzt auch für den Finanzsektor. Es mangelt nicht an Absichtserklärungen, Ankündigungen in Geschäftsberichten oder neuen Kursen im Weiterbildungsprogramm. Was aber oft fehlt, ist das Loslegen, der Schritt vom Planen hin zum Machen, um wirklich von der digitalen Business Transformation zu profitieren. Aber woran liegt es, dass viele Ansätze zu spät oder gar nicht starten?

Es ist die urdeutsche Angst vor dem Scheitern beim Betreten neuer und unbekannter Pfade, die lähmend wirkt. Insbesondere bei einem so fundamentalen Wandel von zeitlich begrenzten Projekten zu einem fortlaufenden Product Engineering-Prozess und den damit einhergehenden Implikationen für Organisationen. Aufgrund fehlender Best Practices existieren oft (noch) keine Vorbilder, die als Blaupause für eine erfolgreiche Transformation dienen können. Entscheider sollten also damit rechnen, dass ihre Projekte nicht gleich im ersten Ansatz fruchten werden. Vielmehr müssen sie sich agil an den für die jeweilige Bank oder Sparkasse richtigen Ansatz herantasten: ausprobieren, Fehler machen, lernen, Kurs korrigieren, ausprobieren – und das Ganze wieder von vorne.

Ein so iteratives Vorgehen widerspricht vielem, was Verantwortliche im Bankensektor bisher getan und gelebt haben. Schließlich war ein detaillierter Plan und dessen rigorose Umsetzung immer der beste Garant für Risikominimierung und manchmal auch für den Erfolg: Fehler machen bedeutete bisher nicht lernen, sondern scheitern. Und der Grund dafür: schlechte Planung. Genau deshalb nähern sich viele Finanzdienstleister heute auch der digitalen Transformation wie einem komplexen Projekt – mit maximaler Planung. Nur merken sie nicht, wie sehr sie sich dabei selbst im Wege stehen. Daher gilt: loslegen statt totplanen. „Loslegen“ bedeutet dabei aber nicht, dass man die neuen Pfade vollkommen unvorbereitet betritt. Wie bei einer Expedition braucht es vorab Training und die richtige Ausrüstung.

Ziele des Product Engineerings

Klassische IT-Projekte haben ein klares Start- und ein hartes Enddatum. Während des Projektes werden zunächst die Anforderungen so detailliert wie möglich beschrieben, dann umgesetzt und schließlich getestet. Ein Projekt ist erfolgreich, wenn die beschriebenen Anforderungen fehlerfrei und pünktlich als fertiges Produkt geliefert werden. Diese Vorgehensweise eignet sich hervorragend dazu, Aufträge auszuschreiben und an Dritte zu vergeben. Maximale Planung zu Beginn reduziert das Risiko. Gleichzeitig ignorieren klassische Projektstrategien aber häufig, welcher tatsächliche Wert (Wachstum, Effizienz, Kundenzufriedenheit) überhaupt geschaffen werden soll. Der Endnutzer ist üblicherweise von der Entwicklung ausgeschlossen und es ist keine flexible Reaktion auf wechselnde Rahmenbedingungen möglich.

Im Gegensatz dazu setzt Product Engineering darauf, in einem kontinuierlichen Prozess mit kurzen Zyklen von jeweils zwei bis drei Wochen inkrementelle Veränderungen an einem digitalen Produkt oder Service vorzunehmen, diese umgehend dem Endkunden zur Verfügung zu stellen und so direkt zu testen. Datenspezialisten analysieren die so generierten Nutzungsinformationenim Rahmen eines „Sense & Respond“-Ansatzes, um die gelieferten Lösungen kontinuierlich zu verbessern. Häufige Releases und ein agiles Vorgehen in kurzen Sprints ermöglichen es Verantwortlichen, flexibel auf sich ändernde Rahmenbedingungen zu reagieren – gleich, ob Veränderungen im Wettbewerb, im Kundenverhalten oder anderen Faktoren.

6 Voraussetzungen für die Transformation hin zum Product Engineering

Unternehmenslenker im Finanzsektor können sich an folgenden sechs Hebeln orientieren, um Product Engenieering erfolgreich zu etablieren:

1. Autonome und selbstbestimmte Teams,
2. Schnelle und häufige Releases im Frontend,
3. Automatisiertes Testing,
4. Entkoppelung vom Backend,
5. Daten sowie
6. Trainings und Agile Coaching.

1. Autonome und selbstbestimmte Teams

Teams sind dann am erfolgreichsten, wenn sie unabhängig (autonomy), sinnstiftend (purpose) und gemäß ihrer Fähigkeiten (mastery) arbeiten können. In großen Unternehmen – insbesondere bei Banken und Sparkassen – stellt die Autonomie von Teams eine besondere Herausforderung dar. In starren Hierarchien sind zwingend Freigaben durch Gremien und Vorgesetzte notwendig. In solchen Organisationen existieren keine unabhängigen Product Owner, die eigenständig Verantwortung übernehmen können und dürfen. Weiterhin werden Teams häufig entlang der bestehenden Abteilungen gebildet (Marketing, Sales, IT), was zu zahlreichen weiteren Abhängigkeiten führt. Deshalb sind multidisziplinäre Teams (Fachseite, IT, Experience-Experten, ggf. auch Datenschutz und Compliance) für einen abgegrenzten Teil der Customer Journey ein zentraler Schritt hin zum Product Engineering, der oftmals nicht einfach umzusetzen ist.

2. Schnelle und häufige Releases im Frontend

Während Unternehmen wie Amazon alle paar Sekunden neue Software „deployen“, kämpfen deutsche Banken weiter damit, von Halbjahres-Releases auf quartalsweise oder kürzere Auslieferungszyklen zu kommen. Funktionale Änderungen am Online-Auftritt oder der App werden alle paar Jahre als Big-Bang angekündigt. Dies entspricht aber nicht mehr den Nutzererwatungen, da gerade junge Menschen heute von Facebook und Netflix ein permanentes Optimieren in kleinen Schritten gewohnt sind – und dies auch schätzen. Grundlage für das schnelle Ausspielen – und ggf. Zurückrollen – von neuer Software ist die Einführung einer stabilen CI/CD Pipeline, idealerweise in einer (Private) Cloud-Umgebung. Hierzu wird eine Kette von modernen Software-Entwicklungstools (siehe Abbildung 1) benötigt. Die Tools werden über Skripte automatisiert und sorgen damit für eine automatische Bereitstellung (Deployment) der Software in den für eine geordnete Entwicklung erforderlichen Staging-Servern.

3. Automatisiertes Testing

Eine deutlich erhöhte Release-Frequenz führt unweigerlich zu einem steigenden Testaufwand. Daher ist häufiges und schnelles Ausspielen von Software nur bei maximaler Testautomatisierung möglich. Behaviour driven development (BDD) sowie eine automatisierte „Tool Chain“ (siehe Abbildung 1) sind die Schlüssel zum Erfolg. Das automatisierte Zusammenspiel verschiedener Tools in der Cloud reduziert die Zeit für die Überprüfung von Code-Qualität dramatisch. Voraussetzung hierfür ist ein für den Test vorbereiteter Datenhaushalt. So konnte Publicis Sapient beispielweise für eine große Retail-Bank die Dauer für Softwarequalitätsprüfungen von zunächst zwei Tagen auf knapp zwei Minuten reduzieren. Erreicht wurde dies durch ein entsprechendes Set-up im Rahmen eines IT-Modernisierungsprojektes.

4. Entkoppelung vom Backend

In einer streng regulierten und auf maximale Sicherheit angewiesenen Industrie wie der Finanzwirtschaft besteht eine weitere Herausforderung: die Abkoppelung des Frontends von den Core-Banking-Systemen. Das bedeutet: Um im Frontend neue Funktionen ausprobieren und jederzeit neue Releases einspielen zu können, müssen IT-Verantwortliche in Banken eine abgetrennte Abstraktionsschicht (siehe Abbildung 2) einführen. Diese sollte es ermöglichen, im separierten User Interface Fehler zu machen, ohne das Core-Banking-System zu beeinflussen. Die Fehler sind dann durch schnell verfügbare neue Releases direkt zu beseitigen.

Um solche Abstraktionsschichten einzuführen, bieten sich Programmierschnittstellen, sogenannte API-Layer, in Verbindung mit darunterliegenden Microservices an. Dabei gilt, dass die Systeme der Steuerungs- und Produktionsdatenbank möglichst standardisiert und kostenoptimiert zum Einsatz kommen. Die Systeme in den Vertriebskanälen hingegen sind möglichst flexibel zu gestalten und über offene Schnittstellen mit externen Anwendungen und Services zu ergänzen. PSD2 (bspw. mit AISP- und PISP-APIs) und Open Banking liefern hier die Blaupause für eine sinnhafte Integrationsarchitektur.

5. Daten

Nutzungsdaten sind der Schlüssel für ein schnelles Lernen und permanentes Verbessern von Produkten und Services – insbesondere für die Finanzbranche. Daher müssen gleich zu Beginn der Einführung von Product Engineering die technischen und organisatorischen Rahmenbedingungen festgelegt werden. Banken müssen dafür sorgen, dass die Daten zunächst erfasst und in einem Data Lake zentral verfügbar und auswertbar sind. Neben den analytischen Daten aus den Frontend-Systemen (Kanälen) verfügen Banken in ihren operativen Plattformen bereits über weitere umfangreiche Datenbestände. Diese können etwa anonymisiert in den zentralen Analyse-Systemen weiter bearbeitet werden und so neue Erkenntnisse über die Zielgruppen und deren Anforderungen generieren. Data Analytics und Machine Learning bilden die Basis, um aus Daten Insights und damit Nutzen für die Bank und ihre Kunden zu erzeugen.

6. Trainings und Agile Coaching

So wie man bei einer Wanderung in schwierigem Gelände auf einen Bergführer zurückgreift, so kann auch ein Agile Coach dabei unterstützen, Product Engineering-Strategien erfolgreich einzuführen. Durch seine externe Sicht und umfassende Erfahrung darin, agile Prozesse bei unterschiedlich aufgestellten Unternehmen zu etablieren, kann ein Coach die Teams an die Hand nehmen und auf ihrem transformativen Weg begleiten. Dies hilft insbesondere, Abläufe individuell anzupassen sowie Methoden zu entwickeln, die passgenau zu den Rahmenbedingungen und Bedürfnissen konkreter Abteilungen und Organsiationen passen.

Sind diese Schritte getroffen, steht dem Start der Transformation nichts mehr im Weg. Eine detaillierte und aufschiebende Planung ist aufgrund der fundierten Vorbereitung nicht mehr nötig.

Loslegen statt totplanen

Die digitale Business Transformation ist längst in der Bankenbranche angekommen, doch die Umsetzung bleibt weiterhin eine besondere Herausforderung. Schließlich handelt es sich nicht um die Implementierung eines einfachen Prozesses, sondern vielmehr um die Kreation einer komplett neuen Unternehmenskultur – weg vom klassischen Projektdenken hin zur Produktentwicklung mit dem Fokus auf „Speed, Value and Quality“. Finanzdienstleister können eine solche Strategie des Product Engineerings erfolgreich etablieren.

Jetzt gilt es, schnell und entschlossen den Pfad ins Unbekannte zu betreten. Das Motto lautet: „Loslegen statt totplanen“ – in kleinen Schritten, mit regelmäßigen Reviews und Kurskorrekturen.

---

Klaus Schilling ist Koautor des Beitrags. Er ist Director Strategy & Consulting bei Publicis Sapient und im Beratungsgeschäft für digitale Business Transformation tätig. Seine Projektschwerpunkte liegen im Umfeld der Mobile- und Internet-Banking-Anwendungen, in der Durchführung von Strategieprojekten zum Multikanalvertrieb, zu Blockchain und zu Digital Banking sowie in der Erarbeitung neuer Softwarekonzepte für die Kundenberatung im Multikanal. Stationen seiner Karriere waren die Management- und Technologieberatung Steria Mummert Consulting und die IZB Soft, der IT-Dienstleister der bayerischen Sparkassen.