Neuroleadership im Einsatz: Innovationen in IT-Projekten

Sind Innovationen in IT-Projekten bei Großkonzernen möglich? Viele IT-Mitarbeiter schütteln bei dieser Frage den Kopf. In Konzernen, deren Kerngeschäft nicht IT ist, findet sich kein innovatives Umfeld, sondern zumeist Legacy-Systeme, eine starre IT-Governance und etliche Vorgaben, wie die neue Software in die Gesamtarchitektur eingebettet werden soll. Ideen für Neuerungen werden im Keim erstickt oder nach langen Meeting-Runden aufgegeben. Das muss nicht sein! In diesem Artikel wird eine Methodik vorgestellt, wie unter anderem mit Hilfe von Neuroleadership Veränderungen im konservativen Umfeld platziert und umgesetzt werden können.

Innovationen in der IT – damit verbindet man Firmen wie Netflix, Amazon und Facebook. Diese Firmen haben sich nicht mit den vorherrschenden Frameworks und Techniken zufrieden gegeben, sondern haben eigene Standards gesetzt und somit nebenbei die IT revolutioniert. Ganz anders bei den klassischen Großkonzernen, die weder neue Frameworks und Techniken erfinden, noch den neusten Standards des Marktes folgen. Zumeist herrscht in solchen Firmen eine veraltete IT-Architektur mit einem hohen Standardisierungsgrad vor. Das hat seine Vorteile, zum Beispiel bei der Wartung und bei der Schulung des Personals. Die Nachteile sind allerdings gravierend für die heutige Zeit: Innovationen und Neuerungen haben es schwer und müssen zumeist von vielen Abteilungen bis hin zum Chef-Architekten geprüft werden, bevor sie nur ansatzweise eine Chance haben, umgesetzt zu werden. IT-Mitarbeiter treffen tagtäglich in Projekten bei Großkonzernen auf die Fragestellung: Wie können Innovationen im konservativen Umfeld umgesetzt werden?

In diesem Artikel wird eine Methodik vorgestellt, wie Neuerungen in einem innovationsfeindlichen Umfeld platziert und implementiert werden können. Die Methodik umfasst drei Phasen: am Anfang steht die Idee, die ein Problem mit einer neuen Vorgehensweise lösen kann. Danach folgt das Sichern der Unterstützung bei den Entscheidungsträgern und die letzte Phase umfasst den Kompetenzaufbau beim Team, das die Neuerung umsetzen sollen.

Phase 1: Probleme analysieren und passende Ideen finden

Eine Bank möchte ihre Kunden per App auf dem Smartphone oder Wearable über Bargeldabhebungen von ihren Konten informieren. Das Herz der historisch gewachsenen IT-Architektur ist ein Mainframe mit einer DB2-Datenbank. Die Lese- und Schreibtransaktionen sind teuer und unperformant. Wie können die innovativen Anforderungen mit einem Legacy-System umgesetzt werden?

Konzerne lösen umfassenden Änderungen in der IT mithilfe von IT-Projekten. IT-Berater werden eingestellt und analysieren zusammen mit der IT-Abteilung die bestehende Architektur und gleichen die Erkenntnisse mit der Problemstellung ab. Die Frage, die hierbei beantwortet werden muss, ist: Welche Technologien passen zu den Gegebenheiten und lösen die identifizierte Problematik?

Inspirationen bieten Blogs, Podcasts und Konferenzen. Große Beratungshäuser veröffentlichen jedes Jahr ihre Technologie-Visionen und Trends. Hieraus können Innovationen abgeleitet werden, die auf die aktuelle Projektsituation passen.

Eine innovative Lösung für die Bank ist ein Hadoop-Cluster, das die Daten des Mainframes spiegelt. Alle Lesezugriffe greifen auf das Cluster zu, das bei jedem Schreibzugriff automatisch aktualisiert wird. Dies spart Kosten, da weniger Aufrufe auf dem Mainframe abgesetzt werden müssen. Die Performanz steigt, da das Cluster hochverfügbar und skalierbar ist. Der Kunde wird schnell und günstig über Bargeldabhebungen informiert und kann bei einem Missbrauchsverdacht sofort eingreifen.

Phase 2: Unterstützung sichern

Eine veraltete Serverlandschaft eines Konzerns soll vereinheitlicht werden. Die abzulösende Architektur besteht aus 50 dezentralen Servern, die regional eingesetzt werden. Die Software auf jedem Server ist gleich, nur regionale Konfigurationsparameter und Daten werden für jeden der 50 Server in regelmäßigen Abständen (mehrmals im Jahr) manuell eingearbeitet. Dieser Aufwand, der zudem fehleranfällig ist, soll minimiert werden. Das System soll zentralisiert werden und über das Netzwerk die regionalen Abnehmer beliefern. Die Vorgaben der IT-Betriebsführung des Konzerns geben vor, wie dieser zentralisierte Server realisiert werden soll: Ein Applicationserver mit einer relationalen Datenbank – gegebenenfalls noch gespiegelt und über einen Lastverteiler angesprochen, um eine gewisse Skalierbarkeit zu erreichen. Dies ist wenig innovativ und das Bauen eines Monolithen ist mehr als überholt. Ein neuer Ansatz ist die Verwendung von Microservices, die für sich skalierbar und austauschbar sind. Wie kann der IT-Architekt von dieser Idee überzeugt werden, sodass er diesem neuen Ansatz zustimmt und damit ggf. eine Neuerung der Konzern-Vorgaben initiiert?

Können wir beeinflussen, wie Ideen aufgenommen werden?

Die Idee ist gefunden, allerdings stellen sich die IT-Standards des Konzerns in den Weg. Zumeist ist in der IT-Governance kein Platz für Technologien, die erst wenige Jahre auf dem Markt sind. IT-Projekte müssen sich häufig eine Genehmigung bei einem IT-Architekten einholen und gegebenenfalls Einschränkungen hinnehmen, damit die Software auch betriebsgeführt wird. Häufig scheitern gute Ideen genau hier, bei der Überzeugung einer dritten Person. Können wir beeinflussen, wie Ideen aufgenommen werden?

Die Analyse des Gehirns findet im Bereich der Neurowissenschaften statt. Es wird beobachtet, wie Informationen verarbeitet werden und wann diese einen positiven und wann einen negativen Effekt auf unser Verhalten verursachen. Hieraus kann abgeleitet werden, wann Menschen eine Idee oder Information akzeptieren und wann sie diese ablehnen. Dr. David Rock hat die Erkenntnisse der Neurowissenschaft auf Managementtheorien übertragen und damit zusammen mit Jeffrey Schwartz ein neues Konzept namens Neuroleadership gegründet [1]. Er hat fünf Faktoren – abgekürzt SCARF – identifiziert, die laut Rock maßgeblich beeinflussen, ob eine Information positiv oder negativ aufgenommen wird [2]:

• Status
  Wie beeinflusst diese Idee meine Stellung in der Firma oder im Team?
• Certainty (Sicherheit)
  Weiß ich alles über diese Idee und über die Innovation, um Entscheidungen für die Zukunft treffen zu können. Habe ich die Sicherheit, diese Entscheidungen auch treffen zu können?
• Autonomy (Selbstbestimmung)
  Habe ich die Kontrolle über die Ereignisse oder kommt diese Innovation so schnell und unerwartet über mich herein, dass ich Angst habe, die Kontrolle über meine Handlungen zu verlieren?
• Relatedness (Verbundenheit)
  Kann ich mich mit der Idee identifizieren? Oder ist das soweit weg von mir, dass ich keinen Bezug dazu aufbauen kann?
• Fairness
  Wie gerecht fühle ich mich behandelt? Kommt die Idee vielleicht unvorbereitet zu mir? Habe ich das Gefühl, dass mir Informationen vorenthalten werden? Wurde schon etwas hinter meinem Rücken entschieden?

SCARF bildet wichtige Faktoren ab, die bei der Kommunikation beachtet werden sollten. Hierbei ist noch zu beachten, dass nicht alle Faktoren bei jedem Menschen gleichermaßen wichtig sind. Ob ein Mensch stark status- oder sicherheitsorientiert ist, lässt sich zumeist nach kurzer Beobachtung herausstellen.

Eine Kombination aus technischer Expertise und Neuroleadership legt eine solide Grundlage, um Innovationen im konservativen Umfeld zu platzieren.

Microservices statt starrer Monolith [3] – diese Idee musste beim IT-Architekten passend platziert werden, sodass er die Information nicht gleich ablehnt, sondern diese akzeptiert. Es konnten zwei wichtige Faktoren laut SCARF identifiziert werden, die die Reaktion auf die innovative Idee maßgeblich beeinflussen würden: Sicherheit und Verbundenheit. Der IT-Architekt kannte sich mit der Architektur von Microservices nicht aus und war entsprechend unsicher, ob das funktionieren würde. Zudem konnte er sich mit diesem Architekturansatz nicht identifizieren. Lösung war ein transparenter Wissenstransfer. Hierbei wurden nicht nur die Vorteile, sondern besonders auch die Nachteile aufgezeigt. Dies übermittelt Sicherheit und gibt dem IT-Architekten die Möglichkeit, auf Basis der Daten selbst zu entscheiden. Die Verbundenheit wurde durch das Bauen von Prototypen erzeugt. Der IT-Architekt konnte selbst sehen, wie Microservices aufgebaut werden, miteinander interagieren und live zum Einsatz kommen.

Phase 3: Kompetenzen aufbauen

Eine hohe Standardisierung in der IT hat einen gravierenden Vorteil: Es werden nicht die besten Mitarbeiter des Marktes benötigt und die Umgebungen ändern sich nicht so schnell. Die Prozesse liegen gut dokumentiert vor und sind schon seit mehreren Jahren etabliert. Sobald sich der Konzern für eine neue Technologie entscheidet, wird diese umfassend geschult bevor sie in den Prozess aufgenommen wird. Dies versetzt die Mitarbeiter in eine sehr bequeme Komfortzone, die allerdings Innovationen und Neuerungen stark behindert. Nachdem eine gute Idee gefunden und die Unterstützung eingeholt wurde, ist eine zentrale Frage zu beantworten: Ist das Team für die Innovation bereit?

Das Ziel ist nicht, das Team für genau eine neue Technologie oder Methodik zu schulen. Das Ziel sollte sein, ein kontinuierliches Lernen zu etablieren, sodass das Team seine Komfortzone erweitert und weniger kritisch gegenüber Neuheiten ist. Kontinuierliches Lernen muss Schritt für Schritt in den Arbeitsalltag integriert werden. Es gibt eine Vielzahl an Ideen und Methoden, die sich etabliert haben:

• Brownbag-Sessions
  Dies sind kleine Vorträge, in denen Mitarbeiter etwas vorstellen, mit dem sie sich gerade beschäftigt haben und somit den Horizont von allen erweitern. Hierbei sollten die Themen nicht zu eingeschränkt sein, die Mitarbeiter sollten vielmehr die Freiheit haben, auch fachfremde Interessen vorzustellen [4].
• Besuch von Konferenzen
  Oftmals werden die jungen Teammitglieder auf Konferenzen geschickt und die alteingesessenen machen so etwas nicht mehr gerne. Falls es nicht genug Karten gibt, sollte die Vergabe der Karten rotieren. In Kombination mit einer Brownbag-Session hat das ganze Team etwas davon.
• Code-Katas & Code-Dojos
  Dies sind für alle Entwickler wichtige Übungen, um das Programmieren zu verbessern. Selbst wenn ein Team an Legacy-Code arbeitet, darf das keine Ausrede sein, Clean-Code-Paradigmen oder Code-Patterns zu missachten.
• Hackathon
  Auf diesen Veranstaltungen arbeitet man mit begrenzter Zeit im Team an einem Problem oder einer Aufgabestellung und stellt die Ergebnisse am Ende vor. Das Problem hat meistens nichts mit den Fachproblemen des Arbeitslebens zu tun und hilft somit, den Horizont zu erweitern. Der Austausch mit anderen Programmierern aus anderen Branchen unterstützt auch das Lernen von Best Practices.
• FedEx-Days
  Was Google und Zalando können, kann überall etabliert werden: Ein Tag im Jahr steht den Mitarbeitern frei an einer Idee 24 Stunden zu arbeiten und die Ergebnisse dem Team vorzustellen [5].
• Prototypen
  Ein Bild sagt mehr als tausend Worte – ein Prototyp gibt mehr Informationen darüber, ob etwas funktioniert, als stundenlange Recherche im Internet. Das Bauen eines Prototypen hilft nicht nur für die eigenen Erkenntnisse, diese können auch den IT-Architekten vorgestellt werden, wenn diese noch überzeugt werden müssen.

Fazit

Kontinuierliches Lernen zu etablieren ist meistens am Anfang schwer. Regelmäßige Veranstaltungen, Brownbag-Sessions, Code-Dojos usw. können helfen, dies zu einer Gewohnheit werden zu lassen, die aus den Arbeitsalltag nicht mehr wegzudenken ist. Neben dem kontinuierlichen Lernen sollte auch das agile Prinzip von "inspect & adapt" [6] genutzt werden, um für das Team die passenden Werkzeuge zu finden.

Sind Innovationen im konservativen Umfeld möglich?

Ein konservatives Umfeld legt einem IT-Projekt viele Steine in den Weg zu mehr Innovation und mehr Neuheiten. Durch die Methodik mit den Stufen "Idee – Unterstützung – Kompetenz" kann ein Großteil der Steine aus den Weg geräumt werden. Die Idee muss zu dem Konzern passen und gegebene Probleme lösen können. Um Unterstützung zu sichern, sollten mithilfe des Neuroleaderships die wichtigen Faktoren analysiert werden, die den Unterschied der Informationsverarbeitung machen. Zum Schluss muss das Team, das die Innovation umsetzen soll, in seiner Kompetenz gestärkt werden. Dies kann durch das Einführen vom kontinuierlichen Lernen erreicht werden.