Was die Allianz Deutschland im Silicon Valley gelernt hat

Die historische Rolle der IT war in den meisten Unternehmen die des internen Dienstleisters, doch durch die Digitalisierung ändert sich das. Welche Rolle spielt die IT bei der Allianz Deutschland?

Andreas Nolte: Es gibt in der Tat eine veränderte Positionierung. Vor ein paar Jahren noch war die IT ein reines Cost Center, ein interner Dienstleister. Dann sind immer mehr neue Geschäftsideen und Business-Felder aufgetan worden, die wir als Enabler unterstützt haben - immer unter einem starken Kosteneffizienz-Gedanken. Inzwischen hat sich unsere Positionierung noch einmal stark gewandelt. Wir werden heute auch als Urheber neuer Geschäftsideen und Verfahrensweisen wahrgenommen.

Wie haben Sie diesen Change eingeleitet?

Andreas Nolte: Ich war in den vergangenen Jahren immer wieder im Silicon Valley, um zu lernen, wie man von der traditionellen Vorgehensweise nach dem Wasserfall-Modell hin zu neuen Methoden kommt, die von den Startups vorgelebt wurden. Vor anderthalb Jahren haben wir uns entschieden, innerhalb der Allianz Deutschland eine Digital Factory aufzubauen, mit der wir den Change-Prozess vorantreiben können. Es gibt weitere Digital Factories in anderen Ländern und die Global Digital Factory der Gruppe, die für das Alignment sorgt.

Was genau bezwecken Sie mit der Digital Factory?

Andreas Nolte: Wir sind dabei - zunächst mit einem Fokus auf die Frontends, später dann auch weit ins Backend hinein - die Art und Weise, wie wir Software entwickeln, komplett umzukrempeln. Agile Softwareentwicklung haben wir schon vor einigen Jahren gemacht, aus der IT heraus. Das hat mal funktioniert, mal auch nicht. Der Ansatz, den wir jetzt verfolgen, ist wesentlich radikaler. Die Digital Factory versteht sich ganz bewusst als Motor für die kundenorientierte Digitalisierung der gesamten Allianz Deutschland.

Wir haben in der Digital Factory mehrere Hebel identifiziert. Der vielleicht wichtigste ist die Customer Experience: Wir wollen Produkte und Services nahe am Kunden entwickeln. Dazu haben wir vor zwei Jahren eine Firma unter das Dach der Allianz Deutschland geholt, die Kaiser X Labs, damals der deutsche Ableger der Design-Agentur Teague mit Sitz in Seattle. Die Firma ist relativ klein, hat aber inzwischen rund 40 Mitarbeiter, und ist darauf spezialisiert, anhand der Design-Thinking-Methode neue Produkte am Kundenbedarf entlang zu entwickeln. Dabei wird in den agilen Teams immer wieder intensiv mit Kundenfeedback gearbeitet - in Sprints. Den Stand der Software testen wir mit den Kunden und holen Feedback ein.

Dann arbeiten Sie sicher auch mit Prototypen oder "Minimal Viable Products" (MVPs)?

Andreas Nolte: Genau, und das ist auch schon das Stichwort für einen anderen wichtigen Hebel: Lean Startup. Gewerke, Projektvorhaben oder was auch immer werden nach der Lean-Startup-Methode umgesetzt. Wir definieren erstmal ein MVP und implementieren das dann in 100 Tagen. Dazu haben wir ein Review-Board geschaffen, vergleichbar mit einem Venture-Capital-Board, vor dem Startups mit ihrer Geschäftsidee auftreten und dafür pitchen müssen. Unsere Teams bewerben sich sozusagen für das Geld, das ihnen - wenn alles gut geht - für diese 100 Tage zur Verfügung gestellt wird.

Das Team möchte zum Beispiel eine App entwickeln und sagt uns konkret, was es nach 100 Tagen erreicht haben will. Das können beispielsweise Downloads im AppStore sein oder ein bestimmtes Kundenfeedback oder ein anderer Score. Wenn das Team überzeugend ist, sagt das Board: Jawohl, ihr dürft in unser Agile Training Center und dort für 100 Tage arbeiten. Das sind in der Regel Teams von zehn bis zwölf Leuten, ein Product Owner, ein bis zwei Designer und der Rest Entwickler. Außerdem gibt es noch Fach-Owner und Business Analysten.

Kommen die Product Owner aus den Fachabteilungen?

Andreas Nolte: Meistens ja. Aber bei den Rollen kommt es mir weniger auf die funktionale Herkunft an, als darauf, ob die Person diese Rolle beherrscht. Es gibt zum Beispiel auch einen Product Owner für ein Business-Projekt in Stuttgart, der kommt aus der IT. Weil er es kann. Es gibt auch Entwickler, die kommen aus der Betriebsorganisation. Die Team-Mitglieder arbeiten mindestens zu 80 Prozent ihrer Zeit zusammen an dem Produkt. Früher waren Mitarbeiter üblicherweise in fünf, sechs oder mehr Projekten aktiv, aber durch die Fokussierung, die wir jetzt haben, bekommen wir viel bessere Arbeitsergebnisse.

Zum Pitching-Prozess: Brauchen die Teams eine Art Business-Plan?

Andreas Nolte: Ja, aber der fällt je nach Produkt mehr oder weniger individuell aus. Messbarkeit ist in jedem Fall ein wesentliches Kriterium, weil man nach diesen 100 Tagen dem Review-Board schon sagen muss: Hat man sein Ziel erreicht oder nicht? Dann kommt ja gleich der nächste Pitch und man muss Farbe bekennen: Führt man's fort oder hat sich die These, wie ein Kundenproblem zu lösen ist, als nicht stichhaltig erwiesen?

Wie setzt sich das Review-Board zusammen? Sind auch unternehmensexterne Experten zugelassen?

Andreas Nolte: Das ist intern besetzt, mit Entscheidern aus verschiedenen Teams. Je nach Themenstellung haben wir aber auch schon Gäste von auswärts hinzugenommen, zum Beispiel Venture Capitalists.

"Es gibt keine Telefone"

Ihr Unternehmen ist ja normalerweise klassisch funktional aufgestellt …

Andreas Nolte: ... ja, aber an dieser Stelle haben wir das aufgebrochen. Das Team sitzt eng zusammen, es gibt keine Telefone, so dass die Kollegen aus dem Tagesgeschäft nicht anrufen und die Kollegen aus dem Team herausreißen können, wenn es irgendwo brennt. Die sollen sich voll auf ihre Aufgabe konzentrieren.

Wie sieht die Infrastruktur aus, auf der die Entwickler programmieren?

Andreas Nolte: Wir arbeiten auf einer elastischen Infrastruktur, setzen dabei schwerpunktmäßig die Cloud Foundry von Pivotal ein und sind praktisch mit dem DevOps-Konzept unterwegs. Früher hatten wir das Staging über verschiedene Stufen, was oft mehrere Tage gedauert hat, mit vielen manuellen Tests dazwischen. Heute sind wir in der Lage, Produktiv-Deployments innerhalb von Minuten umzusetzen.

Fühlen Sie sich von Pivotal abhängig?

Andreas Nolte: Nein. Cloud Foundry ist ja ein Open-Source-Produkt, da bin ich selbst im Board und vertrete die Interessen der gesamten Allianz Gruppe. Die Software ist zudem die Grundlage für verschiedene elastische Cloud-basierte Entwicklungs-Frameworks, darunter Bluemix von IBM, die SAP-Cloud und demnächst wohl auch ein Angebot von Suse. Ein Shift zwischen diesen Welten ist relativ einfach. Und ich könnte sogar, wenn es denn notwendig wäre, die Open-Source-Edition der Cloud Foundry selbst betreiben. Der Vendor-Lock-in ist also relativ gering.

Stichwort DevOps: Konnten Sie Ihre Entwickler aus dem Dev- und dem Ops-Bereich schnell auf Kurs bringen oder war das ein längerer Prozess?

Andreas Nolte: Das ist in mehreren Dimensionen ein Riesen-Change. Er ist auch noch bei weitem nicht beendet. Wir haben dort Leute gezielt weitergebildet und auch Externe eingestellt, es ist ein völlig anderes Prinzip als das vorherige. Der Vorteil ist, dass wir eine stark erhöhte Reaktionsgeschwindigkeit haben.

"Durch das Pairing hat man einen schnellen Know-how-Transfer"

Wir arbeiten immer im Pair Programming: Zwei Bildschirme, zwei Tastaturen, aber eine CPU, so dass immer der gleiche Code gezeigt wird. Einer von beiden ist der Lead, der programmiert, der andere checkt die Arbeit des ersten, und die beiden diskutieren über die beste Lösung. Das mag erstmal nach doppeltem Aufwand für die gleiche Geschichte klingen. Es hat aber den großen Vorteil, dass man viel mehr Qualität reinbekommt und am Ende wartbare Software hat. Zwei Leute bringen in der Regel einfachere und bessere Lösungen zustande als einzelne. Ein weiterer Vorteil: Durch das Pairing hat man einen relativ schnellen Know-how-Transfer. Damit kann ich weniger erfahrene Kollegen mit erfahrenen zusammenbringen und erstere schneller lernen lassen.

Wichtig an der Neuaufstellung unserer Entwicklung ist auch, dass nun alles Test-driven ist. Wir können manuelle Testfälle zu 95 Prozent vermeiden. Zu der nötigen Geschwindigkeit kommt man nämlich nur dann, wenn man das, was man vorher programmiert hat, durch automatisierte Testfälle absichert. So laufen die Deployments tatsächlich in Minuten durch und niemand muss noch manuell eingreifen.

Wie haben Sie die agilen Entwicklerteams räumlich separiert?

Andreas Nolte: Wir haben ein Agile Training Center hier in München, dort arbeiten rund 150 Kolleginnen und Kollegen. Ein zweites mit 90 Mitarbeitern haben wir in Stuttgart geschaffen. Das sind Experten aus allen Disziplinen: Mitarbeiter aus Fachstab, Design, Betriebsorganisation. Kollegen vom Vertrieb sind dabei, von Marktmanagement etc. Das Funneling der Ideen geht, wie beschrieben, vorab über das Review Board.

Sie haben gesagt, diese Arbeitsweise wollen Sie auf die gesamte Entwicklung ausweiten …

Andreas Nolte: Das ist tatsächlich die Idee, wie ich später gerne die komplette Entwicklung bei der Allianz Deutschland transformieren würde. Heute haben wir bereits 250 Leute so weit, in Summe werden es 600 bis 700 Kolleginnen und Kollegen sein, die so arbeiten werden. Und das wird gar nicht so schwierig sein, denn es ist wesentlich befriedigender so zu arbeiten als in dem alten Setting.

Würden Sie den heutigen Zustand als Two-Speed-IT bezeichnen?

Andreas Nolte: Sicher, von der Technologie her gibt es natürlich Unterschiede. Die Frontend-Entwicklung läuft auf der Cloud Foundry, im Backend-Bereich haben wir eine andere Build-Pipeline und ein anderes Tooling. Aber man kann diverse Teilaspekte übertragen. Wir arbeiten gerade an einem Piloten, wo wir Frontend und Backend zusammenbringen.

"Veränderungsbereitschaft ist nicht auf eine Altersgruppe begrenzt"

Es ist immer so, dass das agile Team eine End-to-End-Verantwortung hat. Es nutzt in der Service-Architektur Backend-Services, bindet sie in die Frontend-Applikationen ein und hat dabei die volle Verantwortung. Wenn das agile Team Kollegen braucht, die sich mit Anpassungen in den Backend-Services auskennen, werden die mit ins Team kommen und die entsprechenden APIs entwickeln.

Sind die Philosophien und Mentalitäten nicht viel zu unterschiedlich, als dass man einfach Mitarbeiter aus dem Backend auf Abruf in das agile Frontend-Team berufen könnte?

Andreas Nolte: Das ist ein Change-Prozess, der sich über eine gewisse Zeit hinziehen wird. Ich bin aber sehr zuversichtlich. Wir beobachten übrigens, dass die Veränderungsbereitschaft überhaupt nicht auf eine bestimmte Altersgruppe begrenzt ist. Es gibt sowohl von erfahrenen als auch von jungen Entwicklern positives Feedback. Insofern bin ich sicher, dass wir das durch die komplette IT durchziehen können.

Die Agilisierung der Softwareentwicklung funktioniert nur, wenn die Fachbereiche viel stärker als bislang in Entwicklungsprozesse involviert werden. Sie haben ja eben auch beschrieben, dass die Product Owner oft von der Fachseite stammen. Damit reicht ein kultureller Change in der IT kaum aus, Sie brauchen ihn im gesamten Unternehmen!

Andreas Nolte: Das ist definitiv so. Wenn man solche Initiativen rein aus der IT treibt und niemand mitmacht, wird man keinen Erfolg haben. Da kommt dann so ein "Water-Scrum-Fall" raus: Man ist innerhalb der IT vielleicht agil aufgestellt und arbeitet in Sprints, doch Test- und Demand-Prozesse folgen dem Wasserfall-Prinzip.

Wie haben wir das adressiert? Als wir die Idee hatten, haben wir eine Reise ins Silicon Valley gemacht und uns das angeschaut. Dabei waren neben den IT-Verantwortlichen auch unser CEO, unser COO sowie die Leiter Marktmanagement und Betriebsorganisation dabei. Im Grunde genommen haben wir den Prozess, wie programmiert wird, stark an Pivotal angelehnt. Wir haben verschiedene Ansätze verglichen und den Eindruck gewonnen, dass das die beste Art und Weise ist, Software zu entwickeln.

"Das Team verspricht etwas und hat dann 100 Tage Ruhe zum Arbeiten"

Von Anfang an war unser Management im Boot, allen voran unser CEO der Allianz Deutschland, Manfred Knof. Er hat den Change aktiv begleitet. Das war sicher einer der Erfolgsfaktoren bei der gesamten Geschichte. In einem nachfolgenden Meeting mit allen Top-120-Führungskräften der Allianz Deutschland war Agilität dann auch der Schwerpunkt des ersten Tages. Wir hatten externe Sprecher, den Strategiechef von Pivotal etwa, und wir haben viele Vorträge edukativer Art gemacht, wie man ideal in dieser agilen Methodik zusammenarbeitet.

Danach ist auch noch ein unternehmensweites Transformationsprojekt aufgesetzt worden, das uns nach wie vor begleitet. Die Organisation muss ja lernen, dass sich der Erfolg nur dann einstellen wird, wenn sie eine gewisse Autonomie an die Teams abgibt. Das Team verspricht etwas und hat dann 100 Tage Ruhe zum Arbeiten. Was Sie auf keinen Fall machen dürfen, ist, alle zwei Wochen einen Lenkungsausschuss einzuberufen oder sonst wie zu versuchen, von außen Einfluss zu nehmen.

Bei der Geschichte zählt am Ende nur das Feedback der Kunden, nicht die Meinung einzelner - auch wenn die eine wichtige Rolle im Unternehmen spielen. Eine Organisation muss lernen, dass die typischen Lenkungskreise mit den verschiedenen Hierarchieebenen nicht mehr in diese Art zu entwickeln hineinpassen. Wir haben also sukzessive die Steuerungsgremien abgeschafft und durch Reviews in den Training Centers ersetzt. Jeder der will, ist dort eingeladen und darf seine Meinung äußern, aber die Verantwortung wird im Team belassen.

Wie gehen Sie bei solch selbständigen Teams mit Governance-Themen um? Jemand muss entscheiden, welche Daten in die Cloud gehen, welche APIs offengelegt werden, mit welchen Partnern man zusammenarbeiten darf und vieles mehr.

Andreas Nolte: Wir öffnen uns an der Stelle ganz bewusst. Wir sind in Kontakt mit vielen Startups aus der Fintech- und Insurtech-Szene, mit denen wir manchmal eng zusammenarbeiten. Allianz Deutschland ist mit seiner über 125-jährigen Firmengeschichte historisch eher ein Unternehmen, das nach innen gerichtet war. Doch jetzt sind wir im Zeitalter der Digitalisierung angekommen, es geht ums Lernen und um Partnerschaften. Deshalb müssen wir uns öffnen und unser Wissen durch Partnerschaften komplettieren.

Zur Backend-IT: Ein Unternehmen wie die Allianz hat jede Menge Legacy-Altlasten mitzuschleppen, Mainframe-Anwendungen, vielleicht schlecht dokumentiert - wie werden Sie damit umgehen? Planen Sie einen Befreiungsschlag?

Andreas Nolte: Wir sind schon seit 2007 dabei, unsere Legacy-Systeme zu erneuern. Das Zielsystem ist eine Eigenentwicklung, das Allianz Business System (ABS). Wir implementieren es in mehreren Wellen. Als erstes haben wir mal eine einheitliche Kundensicht geschaffen. Einen Kunden finden Sie in diesem System nur noch genau einmal, eindeutig identifiziert.

"Es geht um die Migration von 42 Millionen Verträgen"

Vorher hatten wir Spartensysteme für die Silos Lebens-, Sach- und Krankenversicherungen im Einsatz. Wir sind jetzt in mehreren Wellen dabei, die Verträge, die wir noch in den Legacy-Systemen haben, nach ABS zu migrieren. Dann werden wir die Legacy-Systeme abschalten. Wir sind jetzt bei rund 19 Millionen Verträgen, die wir im Zielsystem haben. In Summe geht es um die Migration von 42 Millionen Verträgen.

Hätte für diese Anforderungen keine Standardsoftware zur Verfügung gestanden?

Andreas Nolte: Wir haben uns ganz bewusst für eine eigene Lösung entschieden. Etwas Vergleichbares gibt es auf dem Markt nicht. Damit sind wir bisher auch sehr gut gefahren. Wir können die Funktionen, die wir brauchen, selber beisteuern und sind technisch in der Lage, alle 14 Tage Updates zu machen. Wir haben Tarifierungs-Services, die wir extern dazukaufen und dann damit verbinden, so dass wir sehr flexibel sind, was Änderungen angeht.

Als ich 2007 auf Veranstaltungen vorgestellt habe, was wir mit ABS vorhaben, ist das oft mit einem Stirnrunzeln aufgenommen worden. Inzwischen beschäftigen sich auch andere mit dem Aufräumen ihrer Backend-Systeme aus den 70er, 80er und vielleicht Anfang der 90er Jahre. Die Kollegen, die sich damit noch auskennen, gehen langsam in Rente. Es wird immer schwieriger, solche Altsysteme am Laufen zu halten oder gesetzlich notwendige Anpassungen vorzunehmen.