<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1621132604871265&amp;ev=PageView&amp;noscript=1">

Wir sprachen mit Manuel Reil, dem Gründer und CTO von Alyne, über die Voraussetzungen für Innovation in Unternehmen.

(Read a shortened version of this interview in English here >>)

 

Sie sind CTO von Alyne, einem Start-up für ‘RegTech’. Was verbirgt sich hinter diesem neuen Begriff?

Eigentlich ein schon sehr alter Themenbereich. Unser Gründerteam stammt von Accenture, wo wir uns in unseren Karrieren immer mit den Themen IT-Security- und Cyber-IT-Themen beschäftigt haben. Was uns dann zur Gründung bewegt hat, war die Motivation, IT-Sicherheit- und IT-Risikomanagement-Services nun als digitales Produkt anzubieten.

Sie helfen also bei der Digitalisierung einer Branche?

Ja, weg vom Berater als Dienstleister – wie wir es auch für Kunden immer waren – hin zu einer Lösung, die Teams selbst inhouse nutzen können. Wir wollen Unternehmen richtiggehend dahin motivieren, weniger an „analoge“ Berater outzusourcen und stattdessen als Software as a Service zu nutzen.

Durch Ihre Arbeit haben Sie einen Einblick in unterschiedlichste Unternehmen. Und man könnte durchaus sagen, Sie vertreiben und implementieren einen noch relativ neuen Service. Sie schauen gewissermaßen Unternehmen live beim Digitalisieren zu. Welche Gemeinsamkeiten erkennen Sie bei jenen, in denen Innovation gefördert wird?

Generell gibt es keinen bestimmten Unternehmenstyp, aber es braucht die richtige Innovationsbereitschaft innerhalb der Abteilungen und der Führungsebene. Unser Kundenstamm fängt bei der Start-up-Bank an und geht bis zu Banken und Konzernen mit Tausenden Mitarbeitern, die ihr internationales IT-Risikomanagement über Alyne betreiben. Da gab es für uns Überraschungen in beide Richtungen: Unternehmen, die wir als innovativer eingeschätzt haben, stellen sich quer und erzkonservative Versicherungen oder Banken überraschen mit Digitalisierungsfreude. Es kommt tatsächlich auf Persönlichkeiten, aber auch auf Teamkonstellationen und Unternehmensstrukturen an.

Manuel Reil Q1

Wer ist hier Motor, wer Bremse der Innovation?

Beide können sich auf allen Ebenen im Prozess befinden. Im Wesentlichen gibt es drei beteiligte Gruppen: die Führungsebene, also im Konzern tatsächlich die C-Suite, dann das mittlere Management und schließlich die IT-Fachabteilung selbst. Alle haben ihre Ängste und Bedenken. Besonders traurig ist es, wenn ein Bereich schon für den anderen eine Hürde antizipiert, wenn eben gar kein Optimismus herrscht. Der Abteilungsleiter möchte nichts vorschlagen, weil er denkt, das kriege ich sowieso nicht durch. Von Managern hingegen höre ich Sätze wie „Ja, ABER unsere IT stellt sich quer“. Das ist geradezu verrückt, weil wir für alle Positionen die Gegenbeispiele kennen – Teams, in denen es einfach funktioniert.

Wie geht man hier vor als Unternehmensführung wenn Innovation ins Stocken gerät?

Es ist schwierig, keine Frage. Es gibt hier auch vielerorts Bemühungen, etwa mit einem Chief Innovation Officer und einem Innovation Lab die Innovation von oben aufzupfropfen. Davon halte ich selber gar nichts. Aus mehreren Gründen: Zum einen gibt man diesen Positionen nicht das nötige Personal und Standing. Man hat eine Innovationsabteilung, die bei den wirklichen Investitionsentscheidungen wenig mitzureden hat. Oder aber es fehlt das Fachwissen. Man stellt hoch motivierte neue Führungskräfte ein, die mit der Materie der Fachabteilung nicht vertraut sind.

Für den gefährlichsten Effekt solcher Inseln der Innovation halte ich aber die Signalwirkung für den Rest der Belegschaft. Was könnte denn demotivierender sein, als eine Handvoll Mitarbeiter auszusortieren und ab jetzt in einer Innovationsabteilung abzuschotten. Was soll denn der Rest der Mitarbeiter dazu denken, außer: „Wir gehören also zum alten Eisen“?

Was ich eher und anstatt dieser Innovation Labs wichtiger fände, wäre, dass bestehende Teams Innovationsprojekte bekommen, um ihre eigenen Aufgaben und Abläufe zu verbessern. Statt es auszulagern und dann hinterher einen reformierten Prozess wieder zu implementieren. Das ist zum Scheitern verurteilt. Und nicht fair gegenüber den bestehenden Mitarbeitern in den Abteilungen. Ich halte das für ein maximales Anti-Pattern.

Erreicht man so die Kunst des Demotivierens?

Ja. Ist ja auch verständlich. Ein Mitarbeiter arbeitet fünf, zehn oder zwanzig Jahre in einem Prozess, hat Erfahrung, kennt sich aus, dann kommt die Innovationsabteilung und reißt ihm den Prozess aus den Händen und gibt ihn danach verbessert zurück – mit der Aufforderung, ihn dann weiterhin stillschweigend zu bedienen.


Manuel Reil Q3


Viel cooler wäre es gewesen, die Innovationskraft über das ganze Unternehmen hinweg freizusetzen. Die breite Fläche der Mitarbeiter insgesamt ein bisschen innovativer zu machen. Vielleicht haben diese Mitarbeiter nicht die Kapazitäten, um die neuesten Werkzeuge zu recherchieren, aber sie haben doch Wissen in der Fachdomäne, die eine Innovationsabteilung nie haben wird. Man verwechselt oft die Digitalmachung alleine mit der wirklichen Innovation. Viel wichtiger ist es aber, die Knackpunkte in einer Sache zu identifizieren, um den Einsatz der richtigen Tools zu bewerten.

Wir sprachen über die verschiedenen Rollen der C-Suite, des mittleren Managements und der Experten in den Abteilungen. Wie kann jeder von ihnen zur Innovation beitragen?


Meist ist es so: Wenn die Problemstellung erst mal auf dem C-Level bekannt ist, gibt es hier oft eine relativ hohe Bereitschaft für Innovation. Schwierig ist es, eine Lösung überhaupt erst so weit zu bringen. Umgekehrt steht man beim „Buy-in“ der Geschäftsführung vor den Problemen der Implementierung. Hier gilt es, die Mitarbeiter aus der Technik und das mittlere Management mitzunehmen. Was bei Automatisierung und Digitalisierung immer mitschwingt, ist die Angst vor dem Abbau von Personal. Hier muss man Managern  verständlich machen, dass das umgekehrte Risiko viel größer ist: Mitarbeiter, die gar nicht dazu kommen, ihre fachliche Expertise einzusetzen, weil sie den halben Tag mit Excel-Orgien beschäftigt sind.

Was die Techies selbst betrifft, so muss man die Balance finden. Die Position, in der sich die beratenden Mitarbeiter oder auch Abteilungsleiter in der Technik in einem Konzern befinden, ist oft eine schwierige. Der Fortschritt kommt hier so schnell, dass man aufpassen muss, dass man einem Mitarbeiter nicht suggeriert: „Hey, das, was du sieben Jahre gemacht hast, war Blödsinn“, nur weil es jetzt viel einfacher und schneller geht. Hier gilt: Man muss Lösungen ganz offen mit Mitarbeitern diskutieren, sonst landet man in einem Outsourcing-Teufelskreis.

Was meinen Sie mit Outsourcing-Teufelskreis?

Wenn interne Mitarbeiter nie an Cloud-Lösungen beispielsweise experimentieren können, weil sie immer eingekauft werden, dann werden sie auch weiterhin eingekauft. Und dann entsteht jedes Mal dieser Graben zwischen dem externen Mitarbeiter und der Skepsis Fachabteilung. Man erhält die verrückte Situation, dass Entwickler manchmal die alte, schlechtere Lösung verteidigen.

Haben Sie also Fälle gesehen, in denen Entwickler selbst zu Innovationsbremse werden können?

Leider ja, aber nicht aus Persönlichkeitsgründen, sondern weil im Unternehmen Entscheidungen über Jahre auf eine bestimmte Weise getroffen wurden. Der innovationsscheue Entwickler hat gelernt, dass er oft lange kämpfen muss, um beispielsweise ein millionenschweres Rechenzentrum auszubauen. Wenn er dann nur zwei Jahre später eine Lösung vorschlägt, die das überflüssig macht, gerät er in Erklärungsnot. Die Kunst ist es, hier diesen Kommunikationsknoten wieder zu lösen. Wir als Externe erleben manchmal die aberwitzige Situation, dass wir bei unseren Kunden über E-Mails oder Meetings Informationen zwischen beispielsweise Management und Fachabteilung vermitteln, die sie selbst nicht untereinander austauschen.

Beobachten Sie hier, dass Führungskräfte Mitarbeiter in dem Prozess nicht genug motivieren? Was ist Ihr Tipp als CTO – wie fördert man die eigenen Mitarbeiter und schafft ein gutes Arbeitsklima?

Ich hab oft das Gefühl, dass man langjährige Mitarbeiter in der IT (aber auch darüber hinaus) gerne in dem festhält, was sie sowieso schon machen. Da weiß das Management: Mitarbeiter X hat den eigenen Themenbereich, der wird abgearbeitet und das passt. In einem Start-up beispielsweise hat man ja automatisch immer mal einen anderen Hut auf. Kann sich an etwas ausprobieren. Ich denke, da sind sicher viele Ideen, die in den Abteilungen schlummern, weil es für die Mitarbeiter einfach kein Gewinn ist, sich für diese Vorschläge selber stark zu machen.

Wie kann man Mitarbeiter hier unterstützen?

Es gibt hier schon in gewisser Weise eine Kluft zwischen den Kulturen – dem typischen Entwickler und der Business-Seite. Das besteht darin, dass Entwickler gegenseitig Anerkennung dafür bekommen, dass sie ein besonders kniffliges Problem gelöst haben. Die Business-Seite denkt aber in Kategorien wie Value. Also welchen Mehrwert oder welche Einsparung bringt ein Vorschlag. Da müssen sich Entwickler etwas anpassen. Die Welt funktioniert nun mal in Marken, Wordings und Phrasen. Während ein Techie vielleicht sehr sachlich beschreibt: „Wir haben jetzt die Zugriffszeit unserer App auf zehn Millisekunden runtergebracht“, hat die Business-Seite nur müde Fragezeichen im Gesicht: „Ja und?“

Braucht es einen Übersetzer zwischen Techie und Unternehmen?

Wer überzeugen will, muss vereinfachen und den Nutzen klar veranschaulichen. Die Aufmerksamkeitsspanne ist heutzutage für uns alle ja kürzer denn je. Überspitzt gesagt gilt da der alte Beraterspruch: Ein guter Business Case sollte in der Kernaussage auch für Kinder verständlich sein. Auch denke ich, man sollte jeden Vorschlag oder jeden Zwischenstand immer visuell gestützt präsentieren. Also eine Kennzahl beispielsweise herausgreifen. Mit einem Szenario durchgerechnet oder dem Vergleich zu den Vorjahreszahlen. Auch schon mal ein Mock-up eines Interfaces präsentieren.

Die Kunst liegt darin, die eigene Leistung besser zu verkaufen. Auch mal Lob einzusammeln. „Tue Gutes und rede darüber“ – damit tun sich Entwicklerinnen und Entwickler noch zu schwer. Für Projektleiter und Manager gilt: Lob auch für die Techies einsammeln. Gerade auch konstruktive Kritik, beispielsweise zu einem ersten Designvorschlag, ist goldwert, weil dann die Abteilung weiß: Hier hat sich jemand wirklich mit meiner Arbeit befasst. Wir machen das sogar oft, dass wir gutes Feedback für die Mitarbeiter beim Kunden an das Management weitergeben. „Mitarbeiter X und Y haben hier wirklich hervorragende Arbeit geleistet.“ Entwickler kriegen oft zu wenig Lob – leider.

Ist in Deutschland die Kultur für Innovation eine andere als international?

Ja. Und das finde ich auch gar nicht schlecht. Ich selber bin gar nicht immer ein Fan von „Fail Fast“, also dieser Kultur des einfach Machens und Ausprobierens. Ich halte es auch in der IT für sinnvoll, ein paar sprichwörtlich deutsche Tugenden durchaus hoch zu halten. Dass man es nicht aufs Scheitern anlegt. Zwar kann etwas schon zunächst explorativ sein, aber mit der Vorarbeit, um das Risiko zu minimieren und sagen zu können: Es wird wahrscheinlich kein Fail.

Was nicht heißt, dass sich deutsche Firmen nicht ruhig mehr agile Arbeitsweisen zutrauen sollten. Mit einer Handvoll Daten pilotieren statt einer kompletten Big Bank-Migration. Und dann eben schnell direkt wieder Resultate auch visuell aufbereiten und präsentieren.

Ich erlebe es oft, dass Mitarbeiter, die das am konkreten Fall einmal durchexerziert haben, natürlich begeistert sind von einer Neuerung und die auch umsetzen wollen. Man muss dafür aber vielleicht erst die Abteilungsleitung, die verantwortlich ist für die Implementierung in der IT, beiseitenehmen und ihr Platz für alle Bedenken geben. Denn schließlich ist diese Skepsis Teil ihres Jobs. Aber niemand will sich vor versammelter Mannschaft die Blöße geben müssen und zugeben: „Das wusste ich gar nicht, dass es diese einfache Lösung gibt.“ Doch genau diese Mitarbeiter gilt es, zu überzeugen. Sie müssen gut dastehen dank einer Erneuerung. Innovationen – egal wie technologisch fortschrittlich – sind immer nur dann gut, wenn sie von Mitarbeitern angenommen werden.

New call-to-action

Topics

IT-Recruiting Tipps, IT-Recruiting bei...

Kommentare

Lernen Sie uns kennen - in einem persönlichen Telefongespräch

Bei Fragen stehen wir Ihnen gern unter 0800 400 42 43 oder unter arbeitgeber@stackoverflow.com zur Verfügung.