CIO 061 – IT-Architektur Plattformen: Modelle der großen Tech Firmen – Interview mit Dr. Oliver Bossert

Ja, das ist eine gute Frage. Weil eigentlich sind ja diese Tech-Firmen teilweise in Bereichen erfolgreich oder eine Bedrohung für die etablierten Firmen, in denen sie gar keine Erfahrung haben. Also wenn man sich überlegt, momentan wird viel über Facebook und Amazon und Google im Bankenbereich diskutiert, dass sie anfangen jetzt Angebote für Financial Services anzubieten.

Da würde man ja eigentlich traditionell sagen, naja, dann muss ich mir als Bank keine Sorgen machen, weil die haben ja keine Ahnung von meinem Geschäft. Aber jetzt hat sich ja in den letzten Jahren doch einiges geändert im Rahmen von Flexibilität, im Rahmen von der Volatilität der Geschäftsmodelle. Es kann heute eigentlich kaum noch jemand sagen, was sich nächstes Jahr im Bankenbereich abspielen wird, ob jetzt das nächste Bitcoin kommt oder ob Fintechs das Ganze unterbrechen.

Und da ist es wichtig flexibel zu sein. Und genau das ist eigentlich das, was Tech-Firmen gut können. Auf die Kundenbedürfnisse eingehen, auf neue Trends eingehen und eben neue Angebote zu offerieren.

00:04:25.2

Naja, also ich würde sagen, der Startpunkt ist immer der Kunde, und das sagt sich so leicht. Ich glaube, das hat wahrscheinlich auch jedes Unternehmen irgendwo bei sich in der Strategie stehen, dass wir kundenzentriert arbeiten wollen, dass der Kunde im Mittelpunkt steht. Aber wenn man das in der Praxis durchdenkt, kommt man häufig zu sehr erstaunlichen Erkenntnissen.

Wenn ich zum Beispiel von einer Bank ausgehe, dann habe ich als Bank häufig den Ansatz, dass ich sage: Meine Customer Journey oder die Kundenreise ist, wie der Kunde einen Autokredit mit mir abstimmt oder abschließt. Das heißt, der informiert sich darüber, dann kommt er zu mir in die Bank, dann führen wir ein Gespräch, dann bekommt er den Kredit, bekommt den zugeteilt, und damit ist die Reise zu Ende. Und irgendwann zahlt er ihn zurück.

Das ist aber von Kundensicht überhaupt nicht die Customer Journey, die für mich relevant ist. Die Customer Journey, die für mich relevant ist, ist das Auto.

00:05:36.9

Genau, ich möchte das Auto kaufen und ich möchte nicht irgendwie einen Autokredit abschließen oder eine Versicherung abschließen.

00:05:43.8

Genau. Ja. Das heißt also, aus der Sicht des Versicherungsunternehmens oder der Bank ist das natürlich der wichtige Event, weil das irgendwie mein Produkt an den Mann bringt, weil ich damit Geld verdiene. Aber aus einer Kundensicht ist das eigentlich komplett irrelevant.

00:06:04.1

Nicht nur die Tech-Firmen, sondern auch, wenn man sich erfolgreiche Firmen, wie zum Beispiel eine USAA, das ist eine kleine army-, veteranenspezialisierte Bank in Amerika, anguckt, was die anders machen, ist: Die bauen ihre Plattform rund um die Ereignisse, die für den Kunden wichtig sind auf.

Und das Ereignis ist nun mal das Kaufen von dem Auto. Und wenn man sich jetzt eine USAA anguckt, die hat ein Angebot, wo ich mir das richtige Auto aussuchen kann, wo ich das Auto kaufen kann, wo ich das Auto dann versichern kann, wo ich das Auto finanzieren kann, ich kann darüber meine Wartung abwickeln, und ich kann am Ende des Tages darüber dann auch mein Auto wieder verkaufen.

Das heißt also, wirklich meinen Lebenszyklus und nicht den Produktlebenszyklus der Bank abgedeckt.

00:06:51.3

Genau. Und dann sieht man auch, wenn man sich zum Beispiel die Kundenzufriedenheit, also den Net Promotor Score von der USAA anguckt, ist der deutlich, deutlich über dem Industrie-Average und sogar oberhalb von dem von Amazon.

Das heißt also, ein sehr erfolgreiches Konzept, wenn man auf die Kundenbedürfnisse eingeht, was dann aber natürlich auch wieder Implikationen für meine Architektur hat, weil ich ein solches Angebot nur dann realisieren kann, wenn meine Architektur entsprechend flexibel ist und eben tatsächlich auch so eine Ende-zu-Ende-Customer Journey abbilden kann.

00:07:32.9

Also wir haben dazu auch Untersuchungen gemacht, wo wir zusammen mit der Henley Business School einen größeren Survey gemacht haben, um herauszufinden, wie strukturieren denn erfolgreiche Player ihre Transformation. Und da findet man, dass tatsächlich insgesamt 50 Prozent der Unternehmen ihre Transformation nach Capabilities oder nach Fähigkeiten strukturieren.

Bei denjenigen, die in ihrer Industrie Digital Leader sind, also die wirklich sehr weit vorne mit dabei sind, wenn es um die Entwicklung digitaler Funktionalitäten geht, sind es sogar 80 Prozent.

Warum ist das so wichtig? Früher hat man IT entlang von Prozessen entwickelt. Das heißt, ich hatte in meiner Bank, um bei dem Beispiel zu bleiben, einen Kontoeröffnungsprozess und hatte dann eine Applikation für die Kontoeröffnung. Ganz klar. Und ich hatte einen anderen Prozess oder eine andere Applikation für die Ausgabe von Kreditkarten. Dummerweise gibt es natürlich Redundanzen zwischen diesen Prozessen.

Zum Beispiel taucht der Kunde in beiden Prozessen auf, sodass sich dann am Ende mehrere Applikationen habe, die alle mit dem Management eines Kunden beschäftigt sind. Davon ist man jetzt in den letzten Jahren natürlich weggekommen, aber man findet immer noch viele solcher Redundanzen oder aber auch von, ich würde das mal sagen, so Mikro-Monolithen. Also, dass ich nicht mehr quasi meine komplette Funktionalität in einer Applikation abbilde, aber dann doch sehr viel Funktionalität, was mir in dem Moment als sinnvoll erscheint.

Also Beispiel: Fast alle Händler werden die Zahlungsfunktionalität als integralen Bestandteil von ihrer Online-Plattform oder von ihrem E-Commerce-System umgesetzt haben. Jetzt guckt man sich Amazon an. Amazon hat das Ganze so aufgesetzt, dass sie das Payment als isolierten eigenen Service auch Dritten anbieten können. Das heißt also, ich muss eigentlich von Anfang an immer darüber nachdenken, meine Services so zu schneiden, dass sie prinzipiell auch für ein externes Offering oder ein eigenständiges Angebot geeignet werden.

Und das machen, glaube ich, solche Tech-Player sehr gut, und da können die etablierten Unternehmen sicherlich noch einiges von lernen.

00:10:08.9

Genau.

00:10:23.6

Naja, ich brauche natürlich immer eine Verantwortung, die aus einer Geschäftsstrategie Sinn macht, um es mal so zu definieren. Also ich glaube, was wir häufig auch sehen, was nicht gut funktioniert, ist, wenn ich zu granulare Services schneide, also wenn ich dann Services habe, die eigentlich nur, ein Tabellenfeld aktualisieren oder neue Daten anlegen, wenn ich das jemandem von der Fachseite nicht mehr erklären kann, dann ist der Service meistens zu granular.

Aber ich brauche am Ende ein Team, einen verantwortlichen Product Owner, der so ein Team leitet, was dann auch tatsächlich die Verantwortung für einen Bereich hat. Und das Spannende ist ja, dass ich genau da dann auch die Strategie, die Geschäftsstrategie in meiner Applikationslandschaft reflektieren muss.

Um das mal an einem Beispiel, bleiben wir wieder bei der Bank, zu verdeutlichen. Ich habe jetzt unterschiedliche Kundengruppen in der Bank, also Geschäftskunden auf der einen Seite und die Privatkunden auf der anderen Seite. Wenn ich jetzt so rein nach Lehrbuch vorgehen würde, würde ich sagen: Naja, also Vereinheitlichung bringt immer niedrigere Kosten, das heißt, ich sollte möglichst viel standardisieren.

Wenn man jetzt aber nochmal mit einer Geschäftsbrille draufguckt, dann gibt es Bereiche, in denen macht das auf jeden Fall Sinn. Also zum Beispiel die Kontoführung ist für einen Großkonzern genauso die gleiche wie für mich. Ist die gleiche Logik, ist der gleiche Prozess, sind die gleichen Fähigkeiten. Das kann man auf jeden Fall vereinheitlichen. Wenn ich jetzt aber mein Auto finanzieren möchte, ist das ein anderer Prozess als wenn ein Flughafenbetreiber ein neues Terminal finanzieren möchte.

00:12:12.7

Genau. Das heißt, den Kreditprozess da jetzt zu vereinheitlichen macht wahrscheinlich keinen Sinn. Und dann gibt es einen dritten Bereich, wie zum Beispiel, wenn ich über das ganze Kundenmanagement nachdenke, wo es dann tatsächlich von der Strategie abhängt, ob ich das vereinheitlichen möchte oder nicht, weil es hat ja Implikationen.

Also, wenn ich das alles zusammenfahre, dann ist es für mich zum Beispiel einfacher, den Geschäftsführer von einem großen Geschäftskunden auch im Privatumfeld zu erkennen. Dann kann ich dem einen extra Kaffee anbieten oder so. Das kann ich nicht machen, wenn ich das komplett getrennt habe.

Und genau da ist dann, glaube ich, auch das Spannungsfeld, wo es dann tatsächlich darauf ankommt, die Strategie bewusst zu formulieren, wo wir aber auch als Architekten und als IT umgekehrt die Verantwortung haben unsere Kollegen auf der Fachseite zu challengen, zu hinterfragen und denen Optionen zurückzuspielen und ihnen zu sagen: Guck mal, das wären jetzt die zwei Möglichkeiten wie wir das Ganze umsetzen könnten. Das wären die folgenden Implikationen.

Was passt denn besser zu der Strategie? Was häufig realistischer ist, als einfach zum dritten und zum vierten Mal wieder nachzufragen, was denn jetzt eigentlich die Strategie ist.

00:13:28.1

Ja und nein. Ich glaube, hier muss man unterscheiden über welche Services reden wir denn? Auf der einen Seite gibt es Services, die tatsächlich in diesen Applikationen, die da reingehören, weil sie tatsächlich eine originäre Funktionalität von der entsprechenden Applikation sind, also beim ERP-System zum Beispiel die Rechnungsstellung.

00:14:13.6

Genau. Was man aber in vielen Unternehmen als Herausforderung hat heute, ist, dass man die gleichen Systeme auch als Entwicklungsplattform oder als IT-Plattform genutzt hat. Ein gutes Beispiel dafür sind immer die E-Commerce-Systeme im Handel. Dass ich angefangen habe mal irgendwann ein E-Commerce-System zu nutzen, zu einer Zeit, als E-Commerce eigentlich ein Me Too Thema war.

Wo man gesagt hat: Das ist nicht differenzierend, das machen jetzt alle, ich muss das auch mal ausprobieren, aber es war weit weg von der strategischen Bedeutung, die E-Commerce heute hat.

Das hat sich über die Jahre entwickelt und man hat immer mehr Funktionalitäten in das E-Commerce-System reingebaut, sodass man da heute eigentlich wieder einen großen Monolithen hat.

00:15:00.7

Genau. Nur halt, dass ich bei dem ERP vielleicht noch damit leben kann, wenn ich nur alle zwei Monate Anpassungen vornehmen kann, bei einem E-Commerce-System ist das nicht adäquat und funktioniert nicht. Und deshalb sehen wir es als wichtig an, sozusagen eine digitale IT-Plattform zu schaffen, die das Zuhause darstellt für alle Funktionalitäten, die nicht originär in eines der Kernsysteme reingehören.

00:15:29.4

Genau. Sodass ich sagen kann: Ich nutze meine Industriestandardsoftware wie jetzt ein ERP-System oder ein E-Commerce-System, die nutze ich tatsächlich für meine Standard-Funktionalitäten, für alle Funktionalitäten, die ich genauso machen möchte wie der Rest der Industrie.

Für das, was differenzierend ist, fange ich jetzt aber nicht an mein ERP-System zu customizen oder zusätzliche Funktionalitäten in mein E-Commerce-System einzubauen, sondern die baue ich auf meiner eigenen Plattform an der Seite wie das die Tech-Player auch machen.

Und habe dadurch dann einerseits geringere Kosten, wenn ich das nächste Mal mein ERP-System aktualisieren muss und zum anderen kann ich damit dann auch tatsächlich kleine, unabhängige Teams schaffen, die in so einer Micro-Service-Architektur dann auch tatsächlich die Funktionalitäten umsetzen, ohne dass es eine enge Kopplung mit den Release-Fenstern von den großen Applikationen gibt.

00:16:29.4

Das hängt ganz davon ab, was die Anforderungen von meinen Kunden sind. Weil auch hier ist es ganz spannend, dass die Technologie eine immer größere Rolle spielt. Wenn ich so vor fünf oder zehn Jahren eine langsame Applikation gebaut habe, dann haben sich meine Mitarbeiter geärgert. Das war aber was, das habe ich vielleicht in der Mitarbeiterumfrage gesehen, aber ich habe das nicht auf meiner P & L am Ende oder meiner Gewinn- und Verlustrechnung gesehen.

Wenn ich heute eine langsame Applikation habe, dann kann man statistisch zeigen, dass Kunden das nicht akzeptieren, sondern die gehen bei Google einfach wieder zurück und klicken auf meinen Konkurrenten. Das heißt also, ich habe tatsächlich heute einen direkten Zusammenhang zwischen den Latenzzeiten in der IT und meinem Umsatz.

Wenn das zu langsam ist, verliere ich Umsatz. Und da kann es natürlich schon sein, dass ich Daten über einen Service von meinen Backendsystemen brauche, die zu langsam sind oder wo ich über einen Enterprise Service Bus gehen muss, der zu langsam ist.

Und da ist es dann wichtig, eben mir das auch tatsächlich detailliert anzuschauen und sich mir dann zu überlegen: Entweder muss ich vielleicht mit einer anderen Integrationsweise arbeiten, vielleicht muss ich den ESB durch eine leichtgewichtigere Integrationsart ersetzen oder ich muss eine Caching-Funktionalität einbauen, dass sozusagen gar nicht mehr die Daten, jetzt wieder beim Banken-Beispiel, von meinem Mainframe abgefragt werden, sondern dass die von einem dazwischen gelagerten Cache kommen, sodass sie schneller sind und ich nebenbei wahrscheinlich auch noch beim transaktionsbasierten Mainframe-Vertrag ein paar Euro sparen kann.

00:18:23.7

Also wir unterscheiden ganz gerne diese 3 unterschiedlichen Plattformen. Dass wir oben einmal eine kundenorientierte Plattform haben, wo wir dann auch auf jeden Fall die ganzen Funktionalitäten bündeln müssen, die für den Kunden wichtig sind. In dem Beispiel, das könnte jetzt zum Beispiel die Autoplattform sein so.

Dann darf ich jetzt natürlich nicht den Fehler machen, dass ich in der Plattform alles entwickle, was ich an Funktionalitäten brauche, weil dann würde ich diese Funktionalitäten ja nicht wiederverwenden können.

Das heißt, wir nennen das dann Business Capability Plattforms, oder man könnte auch von funktionalen Plattforms oder von Feature Teams sprechen, die sich dann um eine einzelne Funktionalität kümmern. Wieder in unserem Beispiel könnte das jetzt zum Beispiel die Bewertung von einem Auto sein oder es könnte die Finanzierung von dem Auto sein. Oder zum Beispiel auch ganz einfach, dass der Kunde sich anmelden kann.

Auch das ist ja eine Funktionalität, die in allen meinen Customer Journeys irgendwo notwendig ist. Das heißt, ich brauche ein Team, was sich darum kümmert. Und dann kommt noch die dritte Art von Plattform mit dazu, wo wir von einer Core IT-Plattform sprechen oder einer digitalen Technologie-Plattform. Und was ich eben gesagt habe, eben das Zuhause für diese Funktionalitäten.

Weil wenn ich das nicht hätte, was würde dann jedes Feature-Team machen? Die würden sich wahrscheinlich die ersten zwei, drei Monate von ihrer Entwicklung immer damit beschäftigen: Welche Version von Kubernetes nutzen wir denn jetzt? Und wie integrieren wir? Und wie speichern wir die Daten? Und wie bauen wir eigentlich unsere Frontends auf? Und das möchte ich ja nicht.

Ich möchte ja, dass die quasi, wenn die am Montag die Budgets bewilligt bekommen haben, dass sie am Dienstag die erste produktive Software schreiben können. Und dafür muss ich eben dann diese dritte Form der Plattform haben, das heißt also eine Technologie Plattform, die dann von diesen Feature-Teams genutzt wird, sodass ich da quasi maximal Re-Use betreibe und die von Tag 1 an produktiv arbeiten können.

00:20:29.6

Business Capability Plattform.

00:20:34.3

Genau.

00:20:37.7

Da kommen sehr viele spannende Punkte raus. Also zum einen sieht man zum Beispiel, dass es ganz wichtig ist, mit wem die Architektur redet. Also klingt erstmal nicht so intuitiv, aber wir sehen, dass die Unternehmen, die erfolgreich sind, viel mehr Zeit darin investieren, tatsächlich mit den fachlichen Ansprechpartnern, mit dem Management, mit dem Vorstand zu sprechen und dafür weniger Zeit mit ihren Suppliern verbringen.

Was, glaube ich, auch so die zwei Arten sind, die wir insgesamt bei der Architektur sehen. Auf der einen Seite sehen wir Architekten, die immer noch sehr technisch denken, für die sozusagen ein guter Job darin besteht, wenn ich technisch das Problem gelöst habe.

Und auf der anderen Seite haben wir Architekten, die sagen, ich habe dann einen guten Job gemacht, wenn ich was verändert habe. Und die Veränderungen geht eben meistens über die reine Technik hinaus. Sondern ich muss das dem Vorstand erklären, ich muss die Budgets dafür bekommen. Ich muss hinterher meine Mitarbeiter trainieren, dass sie die neuen Lösungen auch nutzen.

00:22:00.2

Genau. Also es ist ein viel breiteres Spektrum, was ich heute eigentlich abdecken muss gegenüber früher, wo ich gesagt habe: Naja gut, jetzt schreibe ich den neuen Code in meinem COBOL-System und dann geht der live und dann ist mein Job eigentlich erledigt.

Und da sehen wir tatsächlich einen sehr großen Unterschied darin, wie IT-Architektur gemanagt wird. Und daraus erklärt sich auch so ein Stück weit die große Popularität von so einem capability-basierten Ansatz, weil das eben genau die Schnittstelle zwischen Fachseite und IT ist.

00:22:36.0

Genau. Während ich jetzt irgendwie über die Software, System XY Release 35, mit meinem Marketing-Vorstand nicht sprechen kann.

00:22:48.4

Genau. Und umgekehrt, wenn jetzt irgendwie der fachseitige Ansprechpartner über seinen Risikomanagement-Prozess spricht, dann kann ich wahrscheinlich als ITler damit nichts anfangen. Und deshalb, wir brauchen eine gemeinsame Sprache, ein gemeinsames Kommunikationswerkzeug, was dann aber auch sich zu einem Management-Werkzeug entwickeln sollte.

Also ich mache immer gern den Vergleich, es sollte kein Stadtplan sein, weil in einen Stadtplan kann ich ein neues Haus einzeichnen, dadurch ändert sich in der Realität nichts.

Sondern es sollte ein Stadtentwicklungsplan sein, der gemeinsamen von Fachseite und IT genutzt wird, sodass, wenn ich da ein neues Kraftwerk oder ein neues Haus einzeichne, dass in den nächsten Jahren da draus noch irgendwann gebaut wird. Und dann denkt man anders über so ein Instrument nach, als wenn es nur eine Visualisierungs- und Kommunikationshilfe ist.

00:23:41.8

Genau. Und genauso wie ich bei einer Stadtplanung auch sagen kann, das ist jetzt ein Wohngebiet und das ist ein Gebiet, in dem ich Kernkraftwerke bauen darf, was typischerweise nicht direkt nebeneinander liegt und nicht das gleiche Gebiet ist, kann ich eben mit so einem capability-basierten Ansatz auch eine differenzierte Sicht auf meine Landschaft entwickeln. Dass ich sagen kann, es gibt eben bestimmte Bereiche, da bin ich zum Beispiel reguliert.

Wenn ich jetzt in der Pharmaindustrie oder in der Bank unterwegs bin, dann gibt es ja immer Bereiche, wo ich einfach ein Vier-Augen-Prinzip anwenden muss, wo ich …

00:24:30.7

Genau. Also wo ich vielleicht auch mehr Wert auf eine stabile Abwicklung und mehr Wert auf hohe Qualitätsstandards setze als zum Beispiel bei meinem internen Reporting oder bei dem Kunden-Frontend. Das heißt also, da kann ich dann tatsächlich differenziert darüber nachdenken, was sind denn Bereiche, wo ich vielleicht mehr experimentieren möchte, wo ich auch mal schneller was zum Kunden bringe, dass der sich das angucken und darauf reagieren kann?

Und was sind Bereiche, wo ich sage, nee, da möchte ich wirklich, dass sehr viele Leute draufgeguckt haben, weil da können wir uns eigentlich keinen Fehler erlauben.

00:25:10.3

Ja, jede Menge. Also …

00:25:16.1

Genau.

00:25:22.4

Ja, also, ich glaube, man sieht da einen ganz deutlichen Zusammenhang zwischen, vielleicht nicht so sehr zwischen dem Geschäftsmodell an sich, aber zwischen der Fragestellung, wie sehr ist denn mein Geschäftsmodell schon am Wackeln oder inwieweit beschäftigen sich digitale Attacker schon mit meinem Geschäftsmodell?

00:26:08.7

Genau. Weil ich natürlich irgendwie, wenn ich jetzt in einem Bereich bin, der relativ gut abgeschottet ist, ein Nischenmarkt ist, wo ich vielleicht nur B2B-Kunden habe, wo ich in einem Duopol unterwegs bin mit zwei, drei anderen Wettbewerbern weltweit, wo ich vielleicht auch, keine Ahnung, jetzt Maschinenhersteller oder sowas, dann habe ich natürlich nicht den gleichen Druck wie jetzt eine kundenorientierte Plattform-Strategie zu entwickeln, wie wenn ich im Buchmarkt unterwegs bin, wo Amazon natürlich einen immensen Druck aufbaut und die Player wesentlich mehr zum Handeln zwingt als das jetzt in manchen etablierten Bereichen der Fall ist.

00:26:55.6

Genau. Also, dass der Taximarkt eine Disruption erfährt, hätte man vor Uber wahrscheinlich nicht erwartet so.

00:27:19.0

Auf jeden Fall, zumal es ja auch die Frage ist: Möchte ich nur reagieren oder möchte ich selber vielleicht auch der Disruptor sein? Also ich glaube, es ist in jedem Fall auch in den etablierten Branchen, auch in den B2B-Branchen, sehr sinnvoll darüber nachzudenken, wie kann ich plattformorientierter sein?

Wie kann ich ein modulareres Offering für meine Kunden aufbauen? Weil am Ende des Tages, A) es kann jederzeit sein, dass einer der großen Tech-Player sich vielleicht doch für meine Branche anfängt zu interessieren, und zum anderen kann ich mir auf die Art und Weise ja auch selber einen Wettbewerbsvorteil aufbauen und mir eben überlegen: Was ist es denn, was für meine Kunden wichtig ist? Und da vielleicht auch eine wichtige Veränderung.

Wenn die Kunden heute über ihre Erfahrungen mit einem Unternehmen nachdenken, dann ist es seltenst der Fall, dass nur der direkte Wettbewerber den Vergleichspunkt darstellt. Weil die Kunden bestellen ja über Amazon, die interagieren ja mit Facebook, die suchen über Google.

Und darüber haben sie natürlich ein Nutzenerlebnis, was sie eigentlich dann auch von ihren Geschäftspartnern erwarten. Das heißt also, wenn Amazon heute den Bestellvorgang prägt und ich am nächsten Tag meine Ware erhalte, dann ist das nicht unbedingt vielleicht was, was ich jetzt irgendwie erwarte, wenn ich eine Maschine für ein, zwei Millionen Euro bestelle. Aber dass diese Maschine dann vier Wochen braucht, bevor ich überhaupt ein Angebot bekomme oder bevor ich einen Liefertermin zugesagt bekomme, das sind Leute immer weniger bereit zu akzeptieren.

00:29:01.7

Genau.

00:29:09.8

Vielleicht fange ich mal damit an, wie man es nicht machen sollte.

00:29:25.8

Also traditionell hat man ja in der IT häufig den Anspruch, Dinge richtig zu machen und nacheinander abzuarbeiten.

00:29:34.9

So. Und das gilt ja häufig auch für eine Transformation, dass ich sage: So. Ich muss jetzt erstmal alle meine Mitarbeiter schulen, dann muss ich mir eine Cloud-Plattform überlegen, dann muss ich meine Entscheidungsprozesse ändern, dann muss ich noch viele, viele andere Dinge tun. Und wahrscheinlich kam in der Zwischenzeit die nächste Rezession und ich habe gar nicht mehr das Geld, um alle diese Dinge umzusetzen, um dann irgendwann in ferner Zukunft mal ein erfolgreiches Modell umzusetzen.

Das heißt, was wir als erfolgreiches Modell für diese Plattform-Transformationen sehen, ist eher sehr tief und sehr intensiv in einem Bereich zu transformieren und dort dann alles umzusetzen.

Weil am Ende des Tages funktionieren diese Transformationen nach einem Minimum-Prinzip. Das heißt, das schwächste Glied in der Kette wird immer bestimmen, wie schnell ich bin und wie gut ich bin.

Wenn ich eine Technologie habe, wenn ich meine CI/CD-Pipeline aufgebaut habe, wenn ich stündlich oder minütlich neue Funktionalitäten in die Produktion geben kann, das mir aber nur erlaubt ist, wenn ich 6 Wochen vorher in meinem Lenkungsausschuss das Okay dafür bekommen habe, …

00:30:48.3

… dann brauche ich nicht so viel in die Technik zu investieren. Und wenn ich das sogar nur dann tun kann, wenn ich letztes Jahr im Oktober dafür schon Budget eingestellt habe, dann ist meine reale Cycle-Time viel, viel länger als diese eine Minute oder die eine Stunde, die ich jetzt vielleicht technisch umsetzen könnte.

00:31:08.5

Genau. Und das eben konsistent in einem Bereich erstmal umzusetzen. Das heißt also, dass ich jetzt nicht versuche, meine komplette Bank in die Cloud zu bringen und dann die kompletten Prozesse zu ändern, sondern wenn ich sage, ich nehme mir jetzt ein relevantes Problem.

Zum Beispiel: Wie können meine Kunden ein neues Konto eröffnen? Und dann versuche ich aber auch, alle Elemente von diesem Problem zu lösen. Das heißt, die technischen, die organisatorischen, die Entscheidungsprozesse, wie ich neue Mitarbeiter einstelle. Und wenn ich das dann mal gelöst habe, dann kann ich anfangen, das Ganze zu skalieren. Und das sehen wir viel häufiger als ein erfolgreiches Rezept, als wenn ich versuche, das sozusagen sequenziell und funktional umzusetzen.

00:32:15.4

Genau. Und es ist am Ende auch, auch das sehen wir, es ist sehr von den richtigen Talenten abhängig, und meistens habe ich die nicht in ausreichender Zahl im Unternehmen zur Verfügung, sondern ich muss Mitarbeiter schulen, ich muss die trainieren, ich muss vielleicht einzelne Externe damit einbeziehen, oder ich muss mir so einen „Anchor Hire“ suchen, der dann weitere Talente mit anzieht.

Und das kann ich halt nicht für 1.000 Leute in der IT gleichzeitig machen, sondern das funktioniert nur dann, wenn ich tatsächlich sehr viel Top-Management-Attention auf einen Bereich gebe und diesen Bereich dann Ende zu Ende transformiere. Dann sieht auch der Rest des Unternehmens, dass das gut ist, dass es funktioniert, dass dabei was rauskommt, bekommt dann Interesse, und wenn das gut läuft, habe ich dann für die zweite und die dritte Welle eigentlich mehr Nachfrage als ich liefern kann.

00:33:19.8

Nein, also ich glaube, gerade da auch für den Mittelstand bewegt sich ja sehr viel. Weil die großen Cloud-Provider ja immer integriertere und immer leistungsstärkere Lösungen anbieten. Das heißt also, ich kann heute ja sehr viel mehr auch als Plattform schon von einem Amazon, einem Google oder einem Microsoft beziehen, als das vor ein paar Jahren noch der Fall war.

Das heißt, ich glaube, da ist schon die Möglichkeit da einen Teil dieser IT-Plattform sozusagen auch schon vorkonfiguriert von einem dieser Provider zu beziehen. Und dann sind ja die Teams in der Regel sowieso nicht groß. Auch in einem Großunternehmen würde ich keinesfalls mehr als 10 Leute in ein Team packen. Und das ist eine großartige Chance auch für den Mittelständler, sich auf solche Punkte zu fokussieren.

Aber ich glaube, gerade in dem Thema Fokussierung ist ein großer Hebel, wo auch der Mittelstand noch viel Potenzial hat. Weil häufig ist man auch dort eben IT-seitig sehr darauf bedacht, das nächste ERP-Upgrade vorzubereiten und irgendwie die Lichter anzulassen. Und man hat darüber vielleicht dann nicht wirklich die Kapazität oder man hat nicht den notwendigen Fokus, um sich eben auch auf innovativere oder kundenzentriertere Themen vorzubereiten.

00:35:01.6

Also ich glaube, der wichtigste Punkt ist überhaupt erstmal, dass ich mit einer Strategie und einem Geschäftsmodell starte, dass tatsächlich auch an Plattformen ausgerichtet ist.

Weil, wenn ich jetzt sage, ich habe nur ein Produkt und ich bin nur Produktzulieferer und ich erzeuge hier quasi eine Commodity, ich weiß nicht, ob sich das heute noch jemand leisten kann, aber wenn das sozusagen meine Geschäftsstrategie ist, dann brauche ich keine kundenzentrierte Plattform.

Sondern ich muss mir tatsächlich einmal strategisch Gedanken darüber machen: Was sind meine Bereiche, in denen ich differenzieren möchte? Was ist das, was ich dem Kunden anbieten möchte? Und was sind vielleicht auch Partner oder Joint Ventures, die mir helfen diese Kundenerwartung zu erfüllen?

Also um wieder auf das Autobeispiel zurückzukommen. Autos zu bewerten und zu verkaufen ist beileibe nicht eine Kernkompetenz einer Bank. Das heißt also, wenn ich jetzt in so einem Geschäftsmodell reingehen möchte, dann sollte ich nicht versuchen jetzt selber ein Autohändler zu werden, sondern ich muss mir halt einen guten Partner dafür suchen, vielleicht ein Online-Portal, was bereits mehr Erfahrung hat als ich, wie man Autos verkauft.

Das heißt, allein sozusagen diese Offenheit in der Kultur, in der Geschäftsstrategie und in dem Ansatz des Unternehmens ist aus meiner Sicht eine ganz wesentliche Aufgabe.

00:36:45.2

Genau.

00:36:49.4

Genau. Mich da sozusagen nach außen zu öffnen, auch vom Mindset und von der Kultur her zu öffnen, und zu erkennen, dass IT mehr ist als eine Kostenstelle, ist, glaube ich, der nächste wichtige Punkt für das Management.

Man hat eigentlich, wenn man sich jetzt irgendwie große Unternehmen anschaut, es gibt nur sehr wenige Kostenpositionen, die über so einen strikten Deckel gemanagt werden wie das bei der IT der Fall ist.

Also ich würde jetzt ja als Autobauer nicht sagen, wir haben einen Stahlbudget, und wenn das Stahlbudget zu Ende ist, dann bauen wir Autos aus Holz.

00:37:32.6

Sondern Stahl wird als Investition gesehen, wo ich halt schauen muss, dass wenn ich irgendwie Stahl einkaufe und da ein Auto draus mache, dass ich am Ende damit durch diese Investition in den Stahl einen entsprechenden Return erwirtschafte und dadurch einen positiven Shareholder Value erzeuge.

Bei IT hat man, glaube ich, aus einer Gesamtmanagement-Perspektive ein so geringes Verständnis oder eine so geringe Transparenz, dass man sagt: Wir sollten nicht mehr als 2 Prozent vom Umsatz in IT investieren. Und das ist natürlich ein Ansatz, der heutzutage nur noch bedingt trägt.

Und da ist der erste Schritt, nicht das IT-Budget komplett aufzugeben und beliebig viel für IT auszugeben, sondern der erste Schritt ist tatsächlich, Transparenz zu schaffen, Vertrauen aufzubauen und auch von der Fachlichkeit her ein Interesse für IT zu entwickeln. Ich glaube, das ist ganz wichtig.

00:38:31.1

Ja, und auch, wenn wir jetzt bei dem Autobeispiel bleiben, wahrscheinlich könnte es sich niemand in einem Autokonzern erlauben, dass er sagt: Ach, diese ganzen Motoren und die Technik, das interessiert mich nicht so, da will ich nichts mit zu tun haben. Das wäre kulturell nicht akzeptiert.

Auf der anderen Seite ist es aber in den gleichen Unternehmen durchaus akzeptiert, dass man sagt: Ach, diese IT, das interessiert mich nicht, ich möchte eigentlich mit diesen Details dort nichts zu tun haben. Je mehr aber IT sozusagen im übertragenden Sinne der Motor des Geschäftsmodells wird, umso weniger können es sich CIOs, CEOs, COOs, das gesamte Management eigentlich, erlauben, sich davon zu distanzieren, sondern sie müssen sich eben auch damit auseinandersetzen.

Und wie in dem vorhin genannten Beispiel von den Latenzzeiten, die direkt einen Einfluss auf meinen Umsatz haben, müssen sie sich teilweise auch mit unangenehmen Details auseinandersetzen, weil das nun heute mal Bestandteil von meinem Geschäftsmodell ist.

00:39:59.3

Genau.

00:40:06.9

Ich glaube, es ist ganz wichtig, dass man in so einer Transformation erstmal mit einem sehr breiten Blick reingeht, dass man sich mit anderen austauscht, dass man schaut, was andere Unternehmen gemacht haben. Und das muss nicht immer unbedingt die Silicon Valley Tour sein, wo man sich ein Facebook und ein Amazon anschauen, sondern auch einfach mal in dem lokalen Markt mit anderen sich austauscht, verstehen, was die gut gemacht haben und davon zu lernen.

Ich glaube, sehr viele Unternehmen sind da noch zu sehr in ihrem eigenen historischen Mindset gefangen und definieren gut als, 2 Prozent besser als letztes Jahr. Wenn ich aber nicht weiß, was andere machen, dann habe ich vielleicht das falsche Maß für was ich als gut definiere.

00:41:04.0

Genau. Und ich glaube, das ist ein ganz, ganz wichtiger, ganz wichtiger Startpunkt. Und dann eben auf der Basis dann auch den Dialog mit der Fachseite suchen, die Fachseite durchaus auch zu challengen und herauszufordern und sozusagen nicht darauf zu warten, dass die Fachseite zur IT kommt und sagt, ich möchte jetzt gerne mit dir Partner auf Augenhöhe werden, was man ja so gerne immer sagt, sondern dass man als IT vielleicht auch den Mut hat, einfach mal als Partner aufzutreten und tatsächlich relevante fachliche Fragen mit den Kollegen auf der Fachseite zu diskutieren.

00:41:50.2

Ja, vielen herzlichen Dank!

00:41:56.6