6 Tipps für Two Speed IT

Lösungen für eine Two-Speed-Infrastruktur

Christoph Lixenfeld, seit 25 Jahren Journalist und Autor, vorher hat er Publizistik, Romanistik, Politikwissenschaft und Geschichte studiert.

1994 gründete er mit drei Kollegen das Journalistenbüro druckreif in Hamburg, schrieb seitdem für die Süddeutsche Zeitung, den Spiegel, Focus, den Tagesspiegel, das Handelsblatt, die Wirtschaftswoche und viele andere.

Außerdem macht er Hörfunk, vor allem für DeutschlandRadio, und produziert TV-Beiträge, zum Beispiel für die ARD-Magazine Panorama und PlusMinus.

Inhaltlich geht es in seiner Arbeit häufig um die Themen Wirtschaft und IT, aber nicht nur. So beschäftigt er sich seit mehr als 15 Jahren auch mit unseren Sozialsystemen. 2008 erschien im Econ-Verlag sein Buch "Niemand muss ins Heim".

Seit 2014 betreibt er die Informationsplattform www.wohinmitmutter.de.

Christoph Lixenfeld schreibt aber nicht nur, sondern er setzt auch journalistische Produkte ganzheitlich um. Im Rahmen einer Kooperation zwischen Süddeutscher Zeitung und Computerwoche produzierte er so komplette Zeitungsbeilagen zu den Themen Internet und Web Economy inklusive Konzept, Themenplan, Autorenbriefing und Redaktion.
Alle reden von der 2-Speed-IT. McKinsey hat jetzt en Detail beschrieben, wie sich eine passende Infrastruktur am besten aufbauen lässt.

Im Grunde ist ja die ganze Idee von der IT der zwei Geschwindigkeiten die zweitbeste Lösung, eine, auf die nur CIOs angewiesen sind, die ihren gewachsenen Legacy-Ballast weder verschrotten noch per Knopfdruck auf Speed trimmen können.

Kein Startup käme auf die Idee, seine IT in einen schnellen und einen langsamen Teil aufzuspalten. Stattdessen baut es vom ersten Tag an eine Organisation auf, die dem Tempo der Digitalisierung gewachsen ist.

"Born Digital"-Unternehmen als Vorbild nehmen

Solche "Born Digital"-Unternehmen sollten sich die CIOs von Traditionsfirmen zum Vorbild nehmen, wenn es um den Aufbau einer 2-Speed-IT geht. Das ist die Kernbotschaft einer umfassenden Analyse zum Thema aus dem Hause McKinsey. Titel (sinngemäß übersetzt): "Fit für die digitale Beschleunigung: Wie das Modell einer 2-Speed-IT aussehen sollte."

Die Autoren Oliver Bossert, Martin Harrysson und Roger Roberts erläutern darin anschaulich und leicht verständlich, warum und wie sich zunächst der Blickwinkel der Verantwortlichen ändern muss, bevor sie sich an den Umbau beziehungsweise die Ergänzung ihrer Organisation machen können.

Amazon, Facebook und Google als Vorbild

Die Geschwindigkeit, den Takt unserer digitalen Welt, gibt nicht irgendeine Technik vor, sondern der Kunde. Seine Wünsche konsequent IT-seitig abzubilden und sein Feedback in den eigenen Entwicklungsprozess einzubauen, muss deshalb zentrales Anliegen jeder Beschleunigung und Erneuerung der eigenen IT-Organisation sein.

Die McKinsey-Autoren nennen Amazon, Facebook und Google beispielhaft für einen IT-Ansatz, der digitale Erlebnisse plant, statt sich Gedanken über Anwendungen und Komponenten zu machen. Zitat: "Sie sammeln ständig Input ihrer Konsumenten ein, und sie lernen daraus. Und sie haben keine Angst vor dem Scheitern."

ERP-Strukturen stehen im Weg

Wie aber können Unternehmen, die mit traditionellen ERP-Strukturen arbeiten, eine IT-Organisation der zwei Geschwindigkeiten aufbauen? Laut McKinsey geht es darum, das Management und die Steuerung der kundenzentrierten Frontend-Systeme von der Steuerung des vorhandenen Backends zu entkoppeln.

In einem nächsten Schritt wird das Feedback von Kunden systematisch in die Produktentwicklung integriert und die Ergebnisse evaluiert. Internetunternehmen - Online-Händler zum Beispiel - können hier als Vorbild dienen.

Nicht alles über den Haufen werfen

Das gilt natürlich nur für den einen Teil einer 2-Speed-IT-Struktur. Denn zwei Geschwindigkeiten zu etablieren bedeutet ja, dass die eine Hälfte bei ihrem bisherigen Tempo bleiben kann. Oder anders gesagt dass Unternehmen in der Lage sind, ihre - für viele Teile des Business´ - bewährten Strukturen zu bewahren und trotzdem für Neues gewappnet zu sein.

Im Idealfall stellt der 2-Speed-Ansatz das Beste aus beiden Welten bereit. Voraussetzung ist allerdings, dass alle Beteiligten konsequent an einem Strang ziehen. Nach Ansicht der McKinsey-Autoren liegt die größte Herausforderung darin, sich darüber einig zu werden, wo genau die Grenzen innerhalb der 2-Speed-Organisation zu ziehen sind.

Backendsysteme sind zu langsam für Kundenwünsche

Wie entwickelt man Neues in neuem Tempo, ohne dass den Machern das Vorhandene im Weg ist? Welche Schnittstellen sind erforderlich, um das Neue anschließend in das vorhandene Geschäftsmodell einpassen zu können.

Ein Großhändler zum Beispiel, der einen Onlineshop aufsetzen will, würde traditioneller Weise mit dem einen Team jene Schnittstellen entwickeln, die für die Anbindung ans Backend gebraucht werden, und ein zweites kümmert sich für die Bedienbarkeit und um das Look-and-Feel, also um die Nutzerseite.

Diese Konstruktion funktioniert aber nicht mehr in Zeiten, in denen auf sich ändernde Kundenwünsche innerhalb von Tagen oder Wochen regiert werden und auch die Backendsysteme in diesem Tempo angepasst werden müssen.

Keine Trennung von Frontend und Backend

Die "Born Natives" der Digitalisierung, Amazon zum Beispiel, haben deshalb so großen Erfolg, weil sie Frontend und Backend eben nicht voneinander trennen.

Wie aber kreieren CIOs mit Erfolg eine 2-Speed-Organisation, deren Arbeitgeber nicht zu diesen Born Natives gehören?

Mehr oder weniger erfolgversprechende Methoden

Die McKinsey-Autoren beschäftigen sich hier zunächst mit Methoden, die häufig angewandt werden, ihrer Meinung nach aber nur mehr oder weniger erfolgversprechend sind.

Erstens: Lösungen für die digitale Welt von einem externen Dienstleister entwickeln lassen. Das habe den Nachteil, dass solche Lösungen hinterher nie wirklich perfekt in die bestehende Landschaft integriert seien.

Bei vielen Projekten kommt es nicht darauf an, wer der schnellste ist, sondern dass man gemeinsam, quasi synchronisiert, am Ziel ankommt.
Bei vielen Projekten kommt es nicht darauf an, wer der schnellste ist, sondern dass man gemeinsam, quasi synchronisiert, am Ziel ankommt.
Foto: Volt Collection - Shutterstock.com

Zweitens: Einen eigenen kleinen Inkubator für solche Aufgaben Gründen. Nachteil: Meistens kommen dabei Halbheiten in Serie heraus, die nicht auf Dauer nutzbar sind, weil die Entwickler immer schon beim nächsten Projekt sind, bevor eine Lösung wirklich läuft.

Drittens: Eine eigene komplett neue digitale Organisation schaffen. Das kann eine gute Idee sein, sagt McKinsey, allerdings nur, wenn diese Organisation gut angebunden ist an das übrige Business.

Inhalt dieses Artikels

 

GSTZ

Die bimodale IT ist sicher der richtige Weg um neue Anforderungen besser erfüllen zu können - diese dann aber als "Two Speed IT" zu kennzeichnen ist weniger hilfreich. Allzu leicht wird dann "schnell" mit "neu" und "gut" und damit vorrangig zu fördern gleichgesetzt, während das bisher Übliche als "langsam", "alt" und daher "schlecht" abqualifiziert wird - also als ein Übel, welches möglichst bald abgeschafft werden sollte.
Üblich war es bisher auch, dass es eine ordentliche Buchhaltung gab, die eigenen Mitarbeiter regelmäßig ihr Gehalt erhielten und dergleichen langweiliger Routinekram mehr. Spätestens wenn das eigene Gehalt ausbleibt weil ein hyperaktiver Marketier oder gestresster DevOp beim ultraflexiblen Realisieren irgendwelcher neuen Geschäftsmodelle irgendwas verbaselt hat wird sich wohl eine etwas differenziertere Sichtweise einstellen.
Besser wäre es, die bimodale IT in einen "agilen" und einen "stabilen" Teil zu sortieren, und diese auch sinnvoll miteinander zu synchronisieren, so wie dies auch in einer Abbildung zum Artikel mit zwei nebeneinander her laufenden Personen sehr anschaulich dargestellt ist. Keiner von ihnen ist schneller, sondern einer ist tänzerisch begabt und damit flexibler, und kann somit den eher geradlinig agierenden zuverlässigen Lastenträger optimal unterstützen.
Stabile IT ist keineswegs langsam, sondern beispielsweise sogar besser geeignet sehr leistungsfähige Online-Transaktionsverarbeitung mit kurzen und stabilen Responsezeiten zu realisieren - und dabei auch die Datenintegrität zuverlässig zu gewährleisten. Unterschiedlich ist nur die Geschwindigkeit mit der Änderungen eingeführt werden können (und sollten). Bei kritischen Geschäftsfunktionen (z.B. bei der Steuerung von Produktionsprozessen, und überall dort wo es um richtiges Geld geht) empfiehlt sich nach wie vor sehr gründliches Testen und sorgfältige Dokumentation.

comments powered by Disqus