Durch die Digitalisierung sind vormals IT-ferne Geschäftsmodelle zunehmend IT-getrieben. Digitale Lösungen entwickeln sich mehr und mehr zum Kerngeschäft. Neue, teils branchenfremde Wettbewerber treten in die eigenen Märkte ein, teilweise mit ganz neuen Geschäftsmodellen. Daten gewinnen eine immer größere Bedeutung - gleichzeitig muss die entstehende Informationsflut auch bewältigt werden.
Den Komfort, den Konsumenten von der Nutzung privater Endgeräte und öffentlicher Web-Angebote her kennen, erwarten sie auch von der Corporate-IT. Die Anforderungen an Produkte verändern sich. Und je größer die Nähe zum Endkunden, desto höher ist auch der Anspruch an Schnelligkeit. Branchenvorreiter und Newcomer rollen im Stundentakt neue Features aus, steuern laufend mit Erkenntnissen aus dem Nutzer-Monitoring nach und richten sich mit agilen Methoden in einer völlig neuen IT-Welt ein.
Diese Beschleunigung beflügelt viele IT-Verantwortliche. Andere hinterlässt sie ratlos. Sollen sie nachziehen und ihre IT-Organisation "agilisieren"? Oder doch anderen den Vortritt lassen? Die hohe Geschwindigkeit soll ihre IT-Organisation handlungsfähig machen. Doch was bedeutet das für die Steuerbarkeit der Organisation? Was heißt es für die Stabilität und Sicherheit der Systemlandschaft?
Wie so oft, ist auch hier Augenmaß angebracht. Trotz aller genannten Veränderungen ist Geschwindigkeit nicht die neue Norm für eine moderne IT-Organisation. Entscheidend ist, angesichts vielfältiger unterschiedlicher Anforderungen, das richtige Tempo gehen zu können: eine IT der zwei Geschwindigkeiten. Gartner hat hierfür unterschiedliche Vergleiche angestrengt. Wir verwenden gerne das einprägsame Bild von Marathonläufern und Sprintern.
Die Marathon-IT steht für Ausdauer und Zuverlässigkeit. Sie bleibt verantwortlich für klassische Kernsysteme mit hohen Anforderungen an Stabilität, Datenintegrität und Datensicherheit wie zum Beispiel Produktionssysteme, die Finanzbuchhaltung oder auch sicherheitsrelevante Anwendungen, beispielweise in der Flugsicherung. Ein beruhigender Gedanke.
Für Produkte und Services mit kurzen Innovationszyklen und kurzer Time-to-Market entsteht eine neue Sprint-IT, die von Schnelligkeit und Agilität geprägt ist. Sie agiert unter höherer Unsicherheit und mit unklaren Anforderungen. Sie baut leichtgewichtige Prototypen für Produkte und Services, validiert sie schnell mit den Endanwendern und setzt deren Feedback in kurzen Zyklen in Produktänderungen um.
Die Transformation einer IT-Organisation mit gleich getakteten Projekten in eine IT der zwei Geschwindigkeiten ist weit mehr als nur eine technische Umbaumaßnahme der IT-Landschaft. Sie wird flankiert von einer veränderten Geisteshaltung, einem kulturellen Umdenken. Sie erfordert neue, teilweise sehr spezifische Fähigkeiten von den Beteiligten. Und sie verlangt nach geeigneten organisatorischen Prinzipien.
Im Wesentlichen geht es in der Transformation der IT um vier Handlungsfelder: Kultur, Fähigkeiten, Organisation und IT-Landschaft.
Kultur - die Basis von allem
Herr Schicht atmet hörbar aus. Er ist erleichtert. Eben hat er einen ungewöhnlichen Workshop hinter sich gebracht. Über eineinhalb Tage hat er die Anforderungen seiner Kunden analysiert und daraus neue Ideen für sein Produkt entwickelt. Unterstützt von Beratern hat er die Ideen nach ihrem Innovationsgrad und ihrer Machbarkeit bewertet. Er hat sie priorisiert und einige davon prototypisch umgesetzt, um sie seinen Kunden zu zeigen. Was daran ungewöhnlich ist? Seine Kunden waren die ganze Zeit über dabei.
In den sieben Jahren, die Herr Schicht sein Produkt verantwortet, war er mit seinem Fachteam der zentrale Wissensträger und Vordenker. Gemeinsam überlegten sie, was ihren Kunden noch helfen könnte, wie bestehende Features weiterentwickelt werden sollten und welche neuen Erkenntnisse aus den verfügbaren Daten herauszuholen seien. Sie dachten konsequent von den eigenen Fähigkeiten, vorhandenen Daten oder technologischen Möglichkeiten aus. Doch oft gingen die Neuerungen an den Anforderungen der Kunden vorbei.
Dieses Mal bezog Herr Schicht seine Kunden von Beginn an ein. Eigene Annahmen des Produktteams blieben ebenso außen vor wie vorhandene Lösungsideen. Die Kunden formulierten frei ihre Bedürfnisse in der täglichen Arbeit und im Umgang mit dem Produkt. Herr Schicht und sein Team hörten zu, fragten interessiert und wertfrei nach und halfen so den Kunden, ihre Anforderungen zu schärfen. Die Ideen, die aus diesem Vorgehen entstanden, waren überraschend - und oft verblüffend einfach. Und sie lagen teilweise neben dem, was das Produktteam für Kernanforderungen der Anwender gehalten hatte.
Outside-in als Konzept der Innovationsentwicklung
Echtes, vorurteilsfreies Zuhören bringt wertvolle Erkenntnisse. Diese Haltung stellt den Kunden in den Mittelpunkt, fragt nach seinen Bedürfnissen und leitet daraus neue Produkte, Services oder Funktionen ab. Outside-in ist ein wesentliches Konzept derInnovationsentwicklung geworden. Im Unterschied dazu entwickelt Inside-out ein Produkt aus den vorhandenen Fähigkeiten, Daten oder technologischen Möglichkeiten.
Zum ersten Mal befragt Herr Schicht seine Kunden direkt. Er bekommt ungefiltertes Feedback zu der Lösung, die er seit sieben Jahre entwickelt. Er fragt nach den Wünschen der Kunden - völlig ergebnisoffen, ohne eine eigene beste Idee oder eine fertige Lösung vorzulegen. Und das alles im Beisein seines Chefs, der das neue Workshop-Format miterleben will. Was, wenn die Teilnehmer nicht mitziehen? Was, wenn die Kunden sein Produkt zerreißen? Wenn ihre Ideen und Anforderungen nicht umsetzbar sind?
Kultur des schnellen Feedbacks
Herr Schicht hat Angst, Fehler zu machen. Und er steht mit dieser Sorge nicht alleine da. Seit Jahrzehnten sind wir so sozialisiert: Erwünschtes Verhalten wird belohnt, unerwünschtes sanktioniert. Insbesondere auch in der Arbeitswelt führt das zu einer Kultur der Fehlervermeidung.
Das Wasserfall-Modell in der Anwendungsentwicklung ist Beleg dafür: Wir tun schon früh im Prozess alles, um am Ende eines langen Prozesses möglichst keine Fehler zu finden. Der Preis sind hunderte Seiten und tausende ausgegebene Euro für ausführliche Konzepte, eine Time-to-Market, die in Jahren statt Monaten gerechnet wird, und eine Organisation, die Verantwortung auf alle verteilt, so dass am Ende niemand mehr verantwortlich ist. Dennoch passieren Fehler. Sie ziehen dann oft ein Blame-Game nach sich, das Gräben zwischen Abteilungen vertieft, statt sie für neue Modelle wie Digital Labs zusammen zu schweißen.
Haltung der Fehlervermeidung kostet zu viel Zeit
Letztendlich sorgt die Haltung der Fehlervermeidung für lange Prozessketten, mit denen ein neues Feature zwar maximal abgesichert ist, aber deutlich später als die Wettbewerbsprodukte auf den Markt kommt. Die Absicherung kostet letztlich Marktanteile.
Sprint-IT tritt an, um Produkte und Services mit kurzen Entwicklungs- und Deployment-Zyklen auf den Markt zu bringen. Dabei passieren Fehler. Sie sind nicht schwerwiegend - ein Fehler im Prototyp wird mit dem nächsten Deployment des Sprint-Projekts nach wenigen Minuten behoben, automatisiert getestet und ausgespielt. Vor allem aber provozieren Fehler wertvolle Reaktionen der Kunden. Daher muss auch inhaltlich nicht alles hundertprozentig abgestimmt und fertig sein. Funktionen können nur rudimentär implementiert sein, um den Kunden eine erste Idee zu vermitteln und ihre Meinung einzuholen.
Sprint-IT braucht deswegen eine Kultur der Fehlerakzeptanz. Besser noch: eine Kultur des schnellen Feedbacks. Sie kennt keine Fehler, nur Rückmeldung. "Fail often and early" beschreibt eine Geisteshaltung, die in der Ideenfindung ebenso gültig und bedeutsam ist wie in der Umsetzung: Dinge einfach mal ausprobieren, mit den Betroffenen validieren und auf Basis ihres Feedbacks anpassen oder verwerfen. "Fail" bedeutet also weniger "Scheitern", als vielmehr feststellen, dass die aktuelle Idee die eigentlichen Bedürfnisse der Kunden noch nicht trifft. Dazu zu lernen und zu ergänzen. Und am Ende das Produkt zu liefern, das den Kunden wirklich nützt.
Herr Schicht war überwältigt, zu sehen, mit welch spielerischer Freude seine Kunden, das Produktteam und auch sein Chef ausgewählte Lösungen ausarbeiteten. Mit Papier und Schere, Stiften und Kleber, mit Lego und Alltagsgegenständen. Sie formten rudimentäre, anfassbare Prototypen, die sie den anderen Teams vorstellten. Der Spaß am Experimentieren war dabei ebenso groß wie der Erkenntnisgewinn zu den Lösungsideen. Richtig verstandenes "Scheitern" kann so schön sein. Und so erfolgreich.
Der Perspektivwechsel muss vorgelebt werden
Ein solcher Kulturwandel lässt sich nicht von oben verordnen. Es geht um einen Perspektivwechsel, das aktive Einnehmen einer veränderten Geisteshaltung. Dieser Wandel will gelebt und vor allem vorgelebt werden. Er stellt hohe Anforderungen an die Führungskräfte, und er benötigt bewusstes Change Management. Outside-in-Denken bedeutet letztlich auch die Einsicht, dass die Kreativität der Gruppe dem Wissen des Einzelnen überlegen ist.
Dass es einen gewissen Verlust an Planbarkeit und Kontrolle geben muss, ist besonders für Führungskräfte schwer zu verstehen. Sie sind es gewohnt zu moderieren, zu steuern und am Ende zu entscheiden. Je mehr sie es schaffen, ihr lange geübtes Rollenverständnis loszulassen, desto leichter gelingt der Wandel hin zu einer offenen, an den Bedürfnissen der Kunden ausgerichteten Kultur.
Fehler zu akzeptieren und als Rückmeldung wertzuschätzen ist eine Haltung, die wir alle erst lernen. Erfahrungsgemäß braucht eine solche Feedback-Kultur starke Vorbilder -idealerweise mit Führungsverantwortung. Um von der modischen Worthülse zur erlebten Haltung zu werden, muss sie konsequent vorgelebt werden. Wenn das gelingt, profitiert die gesamte IT-Organisation von Ideenreichtum, Spaß und Eigeninitiative - ganz gleich, ob in der Marathon-IT oder Sprint-IT.
Mit Outside-In-Perspektive und Feedback-Kultur schaffen Unternehmen ein gutes Stück des Weges bei der kulturellen Veränderung, die für eine IT der zwei Geschwindigkeiten nötig ist. Natürlich werden auch neue Fähigkeiten bei Mitarbeitern, andere Organisationsformen und eine veränderte IT-Landschaft benötigt, doch der Kulturwandel ist die Grundlage dafür, dass der Aufbruch nachhaltig ist. Nur mit großer Unterstützung des Top Managements gelingt dieser Wandel.
Fähigkeiten für eine IT der zwei Geschwindigkeiten
Eine IT der zwei Geschwindigkeiten versetzt Unternehmen in die Lage, für jedes Vorhaben das angemessene Tempo zu finden. Das Ziel der Sprint-IT ist dabei, die Wünsche ihrer Kunden treffsicher und schnell zu adressieren. Die Mitarbeiter benötigen neue technische und methodische Fähigkeiten, um
zu entdecken, was Kunden wirklich brauchen,
Ideen auszuprobieren,
Stakeholder mitzunehmen und
schneller Lösungen zu entwickeln und an den Markt zu bringen.
Wir wollen hier auf einige Ansätze eingehen, die wir dafür als besonders wertvoll erachten: Design Thinking, Prototypen, agile Methoden,DevOps und Cloud-Technologien.
Vorhaben, die auf den Geist von Design Thinking setzen, bleiben nah am Menschen. Beispielsweise, indem sie aus dem Wissen über Kundengruppen konkrete Personas bilden und so den abstrakten Kunden zu einer erlebbaren Person machen. Prototypen machen eine Idee anfassbar; Teams begeistern so schnell und mit wenig Aufwand Kunden und Vorgesetzte für ihre Ideen. Die Software-Entwicklung realisiert mit agilen Methoden eine kürzere Time-to-Market, DevOps ist die Grundlage dafür, dass Lösungen schnell live gehen. Cloud-Technologien schaffen schnell skalierbare Umgebungen für Entwicklung, Test und Produktion.
Design Thinking stellt den Mensch in den Mittelpunkt
"Das ist ja meine Tante!", sagt Herr Geldorf aus dem Fachbereich über "Hildegard": eine weibliche Silver-Agerin kurz vor der Rente. Viel unterwegs mit großer Begeisterung und ohne Smartphone. Diese Persona ersetzt - zusammen mit "Holger", "Gudrun" oder "Melek" - anonyme Kundengruppen durch konkrete Menschen. Personas verdichten Daten aus der Nutzerforschung zu fiktiven Personen mit Namen und Gesicht, Familienstand und Wohnort, Hobbys und Charaktereigenschaften. Details zu ihrem Lebenslauf und ihrem Verhalten reichern diese Archetypen zu fast realen Personen an.
Personas sind von Design Thinking inspiriert, ähnlich wie Customer Journeys oder Empathie-Karten. Die Methoden folgen einer gemeinsame Logik: Sie stellen den Menschen in den Mittelpunkt. Die Persona Hildegard ist Herrn Geldorf und jedem Marketing- oder Vertriebsmitarbeiter im Unternehmen viel näher als eine Sammlung statistischer Daten.
Durch die Vermenschlichung der Daten finden wir zielgenau heraus, was Kunden brauchen. Wir erkennen in Hildegard jemanden wieder - sei es Oma, Tante oder Nachbarin. Wir können uns leicht in sie hineinversetzen und wir entwickeln Empathie. Wir können aus der Perspektive dieser Person nachempfinden, welche Bedürfnisse sie hat und welche Produktneuerung für den Nutzerkreis, für den sie steht, hilfreich ist.
Design Thinking gibt Menschen Raum, um eigene Lösungen zu finden. Teilnehmer erarbeiten in Workshops selbst die Fragen, an denen sie konkret arbeiten. Sie finden Lösungen spielend - und manchmal spielerisch. Weil sie die Probleme selbst identifiziert haben, machen sie sich die gefundenen Lösungen stärker zu eigen als mit einer vorgegebenen Aufgabe.
Mit Produktideen auf Kundenfeedback reagieren
So macht Design Thinking Dinge sichtbar und greifbar: Statt langer Konzeptphasen lernt man direkt am Produkt und aus dem Kunden-Feedback. Der Endbenutzer entscheidet so zumindest indirekt, wie das User-Interface einer Software aussieht oder welche Funktionen entwickelt werden. Die Outside-in-Perspektive - Unternehmen antworten mit Produktideen auf Impulse von außen - ergänzt das. Was sich so banal und selbstverständlich anhört, dreht die Perspektive in vielen Unternehmen um.
Design Thinking ist nicht nur eine Methode, sondern vielmehr eine Haltung, die verschiedenen Leitsätzen folgt: Das bereits beschriebene "Fail often and early" gehört dazu, ebenso die Aufforderung "Have fun!" und "Dare to be wild!". Und ja, das erfordert ein wenig Mut in unserer erwachsenen Arbeitswelt. Ob spielerische Ansätze in der Anforderungsanalyse oder die Reduktion von umfassenden Datensätzen in überschaubare Personas: Business-Analysten, Produktmanager oder IT-Berater wagen etwas Ungewöhnliches, wenn sie in einem Unternehmen, dessen Mitarbeiter Präsentationen gewohnt sind, neue, spielerische Methoden auszuprobieren.
Sie trauen sich, Herrn Geldorf mit neuen Formaten zu überraschen - auf die Gefahr hin, dass er nicht mitzieht. (Randnotiz aus der Praxis: Das ist uns noch nie passiert.) Design Thinking braucht Menschen, die ein bisschen verrückt sind, die lieber experimentieren als sich in ihrer Komfortzone zu langweilen. Und eine Haltung im Unternehmen, die dafür Raum lässt. Da sind wir wieder bei der kulturellen Dimension als Grundlage für eine IT der zwei Geschwindigkeiten: Ohne eine Kulturtransformation verändern neue Methoden wenig.
Prototypen: Ideen zum Anfassen
Als Frau Brühl nach einem längeren Telefonat in den Anforderungsworkshop zurückkehrt, betritt sie eine veritable Baustelle: Die Kollegen basteln eifrig mit Schere, Kleber und Papier an Prototypen für die Benutzeroberfläche einer neuen Software. Der Spaßfaktor ist hoch, Frau Brühl steigt schnell in die Arbeit mit ihrem Team ein. Gemeinsam erleben sie den ganzen Tag mit Leichtigkeit, Schwung und Lust an spielerischem Herangehen. Als der Schlussgong ertönt, sind alle überrascht, mehrere Teilnehmer protestieren und wollen ihren Papier-Prototypen unbedingt zu Ende bauen. Die Ergebnisse machen die abstrakte Benutzeroberfläche der neuen Software greifbar und sichtbar. Es entstehen einleuchtende Lösungen für Probleme, an die die Verantwortlichen noch nicht gedacht hatten.
In der nächsten Runde werden die Lösungen, die die Workshop-Teilnehmer mit Papier-Prototypen für Klickstrecken und Menüführungen gefunden haben, digital nachgebildet: Mockups oder andere Prototypen machen die User Experience des fertigen Produkts sichtbar - zum Beispiel für Nutzertests im frühen Produktstadium oder um Projektsponsoren auf Vorstandsebene von der Idee zu begeistern.
Konkretes Zeigen spricht Menschen besser an als abstraktes Beschreiben. Statt theoretischer Empfehlungen am Ende einer Machbarkeitsstudie zeigt ein erfolgreicher Prototyp das Grundgerüst für den fachlichen Ausbau. Dazu gehört ein wenig Mut zu Lücke: Ein Prototyp zeigt die Leistungsfähigkeit einer Idee, dekliniert aber nicht systematisch jede potenzielle Problemkonstellation durch. Prototypen erfüllen andere Bedürfnisse, die in frühen Phasen von Projekten eine wichtige Rolle spielen: Sie begeistern Menschen und geben Sicherheit. Im Ausprobieren eines Prototyps wird jeder zum Kunden, der begeistert Funktionen entdeckt und aus seiner eigenen Perspektive und Erfahrungswelt neue Anwendungsfälle beisteuert. Wie bei einem Nutzertest bekommen Produktverantwortliche Feedback, was funktioniert, welche Funktion nicht intuitiv erfasst wird und was fehlt.
Frau Brühls Vorgesetzte entwickelt durch einen lauffähigen Prototypen ein besseres Verständnis für das Projekt als durch eine Präsentation. Ihr fällt die Budgetentscheidung dank Prototyp leichter, weil sie nicht die sprichwörtliche Katze im Sack kauft. Der Prototyp zum Anfassen sichert die Investition in die Produktidee ab.
Prototypen-Bauer spielen auf einer umfangreichen Klaviatur. Sie nutzen Balsamiq, Pop oder Axure für Mockups, D3.js für Visualisierungen oder Node-RED für IoT-Anwendungen, um nur einige Beispiele zu nennen.
Mehr Speed durch agile Methoden, DevOps, Cloud
Neue Workshop-Formate machen uns agiler darin, Probleme zu verstehen und Lösungen zu finden. Agiler bedeutet auch, dass wir Kunden-Feedback und Marktentwicklungen schneller berücksichtigen. Das verkürzt die Zeit bis zur Marktreife von Funktionen. Bei den technischen Fertigkeiten braucht die Sprint-IT Pendants, um die Ideen schnell umzusetzen: Wir schlagen agile Methoden, DevOps und Cloud-Technologien vor.
Agile Methoden liefern schnell kleine Inkremente. Stakeholder sehen so nach jedem Sprint fertige Zwischenergebnisse. "Alle zwei Wochen ist Weihnachten", beschreibt einer unserer Kunden nach der Scrum-Einführung seinen Aha-Moment. So übertragen agile Methoden die flexible und schnell anpassbare Produktstrategie in die Produktentwicklung. Der Product Owner eines Scrum-Teams teilt die Produktvision in kleine, einzeln in Sprints umsetzbare Anforderungen und priorisiert sie nach Kriterien wie Geschäftsnutzen und Risiko. Das Kunden-Feedback auf die Sprint-Ergebnisse fließt unmittelbar in die Produktstrategie zurück - wenn sie schnell live geschaltet werden.
Das leistet DevOps. Die enge Zusammenarbeit von Software-Entwicklung und Betrieb während des kompletten Software-Lebenszyklus' automatisiert wiederkehrende Arbeiten: Features werden automatisiert getestet und ausgerollt, sobald der Software-Ingenieur sie in die Versionsverwaltung comittet. Mit "Infrastructure as Code" zieht der Applikationsbetrieb auf Knopfdruck Server mit vorkonfigurierten Einstellungen hoch. Konfigurations-Management-Tools wie Chef und Puppet helfen, komplexe Server-Landschaften schnell, nachvollziehbar und automatisiert zu managen. Monitoring-Tools sammeln und aggregieren Daten aus dem Produktionsbetrieb - weiteres Feedback für die Entwicklungsabteilung und die Produktentwicklung.
Cloud-Technologien liefern auf Knopfdruck skalierbare und schnell verfügbare Umgebungen für Test, Entwicklung und Produktion. Liefer- und Einrichtungszeiten für Hardware gehören der Vergangenheit an. Applikationen lassen sich zügig in eine Cloud-Infrastruktur auslagern, wenn die Architektur sauber definiert wurde. Zur Architekturdefinition gehört ein Cloud-fähiges Konzept für die Datensicherheit.
Agile Methoden, DevOps und Cloud-Technologien bauen auf einer gemeinsamen Grundhaltung auf: Die Kluft zwischen Software-Entwicklung und Applikationsbetrieb wird kleiner. Software-Ingenieure beschäftigen sich mit Betriebsfragen, um ihre Entwicklungsumgebung in der Cloud hochzuziehen. Sie arbeiten mit DevOps-Tools wie Puppet oder Ansible und kennen technische Rahmenbedingungen und Abrechnungsmodelle der Betreiber. Dabei muss nicht jeder alles machen: Scrum-Teams sind meistens multifunktional besetzt. Der Experte für ein Thema sitzt oft direkt am Nachbartisch.
In jeder Phase sprinten können
Mit Design-Thinking-Elementen wie Personas oder Customer Journeys finden wir heraus, was die Nutzer von einem Produkt erwarten. Diese Features werden als Prototyp getestet: schnell gebaut, schnell ausgerollt und schnell bestätigt - oder verworfen. Sie bescheinigen einem Vorhaben die Umsetzbarkeit und inspirieren als Ideen zum Anfassen.
Technische Fähigkeiten übertragen diese Geschwindigkeit und Flexibilität auf die Software-Entwicklung: Agile Methoden wie Scrum verkürzen die Time-to-Market von Features durch schnelle Entwicklungszyklen; DevOps rollt die Features zügig in den Live-Betrieb aus; mit Cloud-Technologien werden IT-Infrastrukturen ausreichend skalierbar. Zusammen genommen verkürzen diese Fähigkeiten die Zeitspanne, bis eine neue Funktion online ist, und sie lassen Raum für eine iterative Weiterentwicklung von Softwareprodukten.
Eine Randnotiz: agiles Vorgehen bedeutet nicht zwingend, Arbeiten schneller oder billiger zu erledigen. Es geht darum, die Kundenbedürfnisse besser zu treffen. Und das zählt.
Organisatorische Überlegungen für eine Two-Speed-IT
Unternehmen müssen heute neue Produkte und Services in schnellen Iterationen zum Kunden bringen. Andererseits wollen sie datenschutz- oder sicherheitsrelevante Vorgänge nachvollziehbar und risikoarm abwickeln. Um beide Anforderungen zu erfüllen, bauen Firmen Sprint-Teams innerhalb der Regel-Organisation auf. Häufig entsteht so eine kulturelle Kluft zwischen Menschen in Marathonprojekten und Sprint-Vorhaben: hier die vermeintliche schnelle, hippe Sprint-IT, dort die beständige Marathon-IT. Wie verhindert man das?
Die Kunst besteht darin, Organisationsformen zu finden, in der beide IT-Modi gleichwertig ihren Beitrag leisten. Die Sprint-IT braucht genügend Unabhängigkeit von der Bestandsorganisation, ohne ihr dabei fremd zu werden. Die Sprinter müssen schnell neue Lösungen für Kundenanforderungen entwickeln können und gleichzeitig das Bewusstsein und Verständnis für den Wert von Stabilität erhalten. Gleichzeitig sollten sie den Marathonläufern die Möglichkeit eröffnen, sich mit neuen Vorgehensweisen vertraut zu machen. Idealerweise sind die Grenzen zwischen beiden Welten daher durchlässig. Sprint-IT-Labs und Rotation der Menschen zwischen Marathon- und Sprint-Projekten spannen dieses Arbeitsumfeld auf.
Laborbedingungen für Produkte
Jürgen Stefan wippt ungeduldig mit dem Fuß: "Das neue Projekt läuft nicht richtig an. Unsere Kollegen sind schon ausgelastet mit den Aufgaben, die sie haben. Und sie denken für das neue Produkt in den Bahnen, die wir schon kennen. Wie soll da was Neues herauskommen?" Stefan ist Projektleiter für eine neue Produktidee. Wie viele andere in seiner Rolle stellt er einige Wochen nach Projektbeginn fest: Mitarbeiter, die für einige Stunden in einem Innovationsprojekt mitarbeiten, und parallel dazu ihre Aufgaben in der Regelorganisation weiterführen, tun sich schwer damit, etwas Neues zu schaffen. Sie bringen bekannte Denkweisen aus ihrem bisherigen Arbeitsumfeld mit. Sich davon zu lösen, fällt schwer, weil sie mit einem Fuß oder mehr im alten Job bleiben. Viele Unternehmen importieren so auf dem Weg in eine IT der zwei Geschwindigkeiten ungewollt Abläufe und Logiken aus der Bestands-IT in die Sprint-Projekte.
Mit seinem Chef arbeitet Jürgen Stefan an Projektbedingungen, durch die seine Kollegen mehr Zeit haben und außerhalb der eingefahrenen Wege denken. Die beiden etablieren einen neuen Projekttyp: Mitarbeiter arbeiten in einem Innovationszentrum am neuen Geschäftsmodell. Die "Digital Labs" sind aus der Regelorganisation herausgelöst. Jedes Projekt arbeitet autonom.
So arbeiten Digital Labs
Weg vom Organigramm: Statt etablierter Linienverantwortung organisieren sich die Mitarbeiter in einem unabhängigen Team, das ausschließlich am Sprint-Projekt arbeitet. Statt der etablierten Funktionen gibt es neue - zum Beispiel angelehnt an ein Scrum-Team.
Weg vom alten Job: Menschen brauchen Zeit und Gelegenheit, um Neues zu entwickeln. Ihr altes Aufgabefeld kann sie davon ablenken. Wenn sie ihre Aufmerksamkeit ausschließlich auf das neue Projekt legen, investieren sie Zeit und Elan ohne Reibungsverluste mit den Aufgaben in der Bestandsorganisation.
Weg von etablierten Regelungen: Sprint-Projekte arbeiten explorativ, Prototyp-getrieben und nach Kunden-Feedback. Das geht einfacher, wenn sie einen höheren Freiheitsgrad haben, als Projekte in der Regelorganisation.
Weg vom alten Büro: Agiles Arbeiten mit kurzen Feedback-Zyklen braucht direkte Interaktion. Beim gemeinsamen Kaffeetrinken entstehen Ideen. Kollegen tauschen sich in einem Projektbüro oder auf einem gemeinsamen Stockwerk ungezwungener aus. Und entwickeln schneller ein Wir-Gefühl fürs Projekt.
Weg vom Abteilungsdenken: Agile Teams sind multifunktional aufgestellt - und damit quer zu den Abteilungen für Fachleute gleicher Art. Die enge Zusammenarbeit von Produktverantwortlichen, Wissensträgern aus Fachbereich oder Vertrieb, Softwareingenieuren und Designern in einem Team schafft ein übergreifendes Verständnis von Produkt oder Service. Sie löst einen Perspektivwechsel bei den Menschen im Projekt aus: Sie sind Beteiligte statt Betroffene, Stakeholder statt Zuschauer. Sie identifizieren sich mit dem Projektziel und machen es zu ihrem Anliegen.
Rotation ist das Zauberwort
Stefans Kollegen arbeiten in multifunktionalen Sprinter-Teams. Sie sind außerhalb des Organigramms unterwegs, in anderen Räumen und mit mehr Freiraum. Kurz: Sie arbeiten in der neuen Projektart "Sprint". Das schafft Freiraum, in dem Menschen Methoden abseits der ausgetretenen Pfade entdecken. Diese Unabhängigkeit verkehrt sich jedoch schnell in eine Undurchlässigkeit zwischen Sprint- IT und Marathon-IT: Parallel zur Regelorganisation wird ein neue, vermeintlich hippere Projektorganisation aufgebaut. Sie liegt quer zum bestehenden, und die beiden Stränge sind kaum noch kompatibel. Spätestens, wenn ein Sprint-Projekt in die Bestands-Organisation überführt wird, fallen die fehlenden Schnittstellen zwischen beiden Welten auf.
Rotation ist das Zauberwort: Kollegen wechseln für eine begrenzten Zeitraum in ein Sprint-Projekt. Sie haben in dieser Zeit keine Nebenprojekte oder Linienaufgaben. Nach dem Projekt oder einer bestimmten Projektphase kehren sie in ihre alte Rolle zurück. Das bringt mehrere Vorteile: Es entsteht nicht der Eindruck eines "Brain Drain" aus der Bestandsorganisation, wichtige Wissensträger werden eher für einen begrenzten Zeitraum ausgeliehen. Die Fachleute wiederum verlieren nicht ihre Expertise, die sie so wertvoll für das Sprint-Projekt macht. Und sie nehmen vielleicht aus dem Sprint-Projekt einen frischen Blick mit in ihren regulären Job.
Change-Management: Unterschiedlich schnell, gleich wertig
Rotation sorgt für Austausch zwischen beiden Organisationstypen: Die Marathon-IT findet in den neuen, flüchtigeren Methoden Impulse für ihre Arbeit. Die Sprint-IT lernen den Wert von Stabilität kennen und schätzen. Hier wird ein Risiko in der Transformation deutlich: die neue, agile Welt droht die bestehende IT zu überstrahlen, die leicht auf "zu langsam, zu schwerfällig" verkürzt wird. Eine Zweiklassen-Gesellschaft aus einer selbsternannten Startup-Elite und einer stabilen, aber vermeintlich langweiligen Marathon-IT kann die Folge sein.
Um dem gegenzusteuern, kommt dem Change Management eine wichtige Bedeutung zu. Es gilt, beide Welten wertzuschätzen, die Wertschöpfung beider Projektarten hervorzuheben und sie nicht gegeneinander auszuspielen. Kurz: Beide müssen als gleich wichtig und gleichwertig in den Köpfen verankert werden.
Die bewusst langsamere, auf Zuverlässigkeit und Sicherheit ausgerichtete Marathon-IT hat weiter große Bedeutung für Systeme mit hohen Anforderungen an Stabilität, Datenintegrität und Sicherheit. Und der Einbau einer neuen gesetzlichen Vorgabe in eine komplexe, gewachsene Systemlandschaft verlangt ebenso nach Menschen mit der richtigen Mischung aus Kreativität und technischer Expertise wie agile und innovative Vorhaben. Schlussendlich bedienen unterschiedliche Menschen mit ihren individuellen Fähigkeiten die verschiedenen Anforderungen.
Diese Akzeptanz braucht Unterstützung aus dem Management, aktives Vorleben und Moderation sind die Schlüssel. Der Change-Management-Prozess umfasst alle behandelten Bereiche: Grundlegend ist die kulturelle Transformation zur Outside-In- und Feedback-Kultur, die wir zu Beginn beschrieben haben. Die veränderte Haltung versteht Chancen wie Grenzen neuer Fertigkeiten und Methoden - etwa dass ein Prototyp zwar einen ersten Eindruck gut vermittelt, dafür aber wenig Detailgrad zeigt. Und sie braucht Fürsprecher in der Bestandsorganisation, die die Regeln des neuen Projekttyps tragen.
Die Organisation kann Unternehmen helfen, ihre Ziele zu erreichen. Sie kann diesen Zielen aber auch im Wege stehen. Sprint-IT-Labs und Rotation sind Anregungen, um den Anforderungen aus beiden Organisationstypen gerecht zu werden, ohne einen Kulturgraben zu schaffen zwischen Stabilität und Sicherheit einerseits, Innovation und Freiraum andererseits. Wie bei jeder organisatorischen Frage gilt: Die richtige Mischung aus Freiraum und Kompatibilität ist für jedes Unternehmen individuell. Wir raten, verschiedene Ideen auszuprobieren. Die Menschen im Projekt wissen oft genau, welche Rahmenbedingungen sie brauchen, um das übergeordnete Ziel zu erreichen.
IT-Bebauung für Sprint- und Marathon-IT
Sprint-Systeme erfordern in der Regel ein agiles Projektvorgehen, DevOps als Liefermodell und andere Organisationsprinzipien als die Bestandsorganisation. Auch bei den technischen Rahmenbedingungen muss es Freiheiten geben. Ein Sprint-Team sollte etwa die Entwicklungsumgebung für einen Prototypen bei einem Cloud-Provider aufsetzen oder einen Crowd-Testing-Anbieter für authentisches Zielgruppen-Feedback beauftragen dürfen. Damit das schnell geht, muss dieses Team nicht alle Vorgaben des unternehmensweiten Einkaufs einhalten.
Komplementär zum Sprint-Projekt entsteht auf der Ebene der IT-Landschaft ein neuer Systemtyp, das "Sprint-System": Solche Systeme werden quasi auf der Überholspur gebaut und ausgerollt - in jedem Fall schneller als Systeme in der Bestandsorganisation. Sie setzen verstärkt auf Vorhandenes, etwa Open-Source-Technologien oder Inhalte von Partnern. Die Sprint-Systeme müssen Vorgaben aus der IT-Bebauung nur bedingt berücksichtigen, sie brauchen keine umfangreichen Schnittstellenverträge, und dürfen mehr stand-alone bauen. Die Integration in die bestehende Systemlandschaft steht hinter der schnellen Umsetzung zurück. Der Preis für diese Freiheit ist, dass die einheitliche IT-Landschaft in Teilen verloren geht. Was heißt das für die IT-Strategie?
Speed-Bebauung: schnell und anders bebauen
"Eine komplette Bebauung an einem Tag?" Die Verwunderung des CIO im eintägigen Workshop ist nachvollziehbar. Wir versprechen ihm Antworten auf seine beiden wichtigsten Fragen: Wie vermeiden wir technischen Wildwuchs, wenn wir Prototypen für 50 neue Funktionen bauen? Und wie bauen wir Systeme so, dass wir sie bei Erfolg in die bestehende Landschaft übernehmen können? Tatsächlich: Am Ende des Tages hat jede der zirka 50 neuen Funktionen ihren Platz im Domänenmodell gefunden, und die Leitplanken für jedes geplante Sprint-System sind definiert. Das ist Speed-Bebauung.
Speed-Bebauung zieht das Tempo nach, das schnelle Feedback-Methoden auf der Anforderungsebene und agile Software-Entwicklung und DevOps auf der technischen Ebene vorgeben. Die Bebauung der IT-Landschaft oder Domäne im Ganzen hat dabei nicht ausgedient, sie geht der Speed-Bebauung voraus und setzt Leitplanken, die einen Wildwuchs bei den geplanten Sprint-Systemen verhindern.
Im Workshop haben wir die neuen Funktionen auf das fachliche Domänenmodell "gemappt", die Zuordnung diskutiert und noch zu entstehende Domänen festgelegt. Anschließend haben wir die bestehenden IT-Systeme wie CRM, Finance oder Vertrieb über die fachliche Sicht gelegt und so das Geschäft des Kunden inklusive der neuen Funktionen mit der IT-Landschaft abgeglichen. Mit diesem klaren Tableau haben wir anschließend die individuellen Leitplanken für jedes Sprint-System festgelegt.
Definition der Leitplanken entscheidet über Flexibilität
Die Sprint-Systeme sind Prototypen, um neue Funktionen auf Kunden-Feedback oder Machbarkeit zu testen. Die Leitplanken definieren, ob ein Prototyp später im Lebenszyklus in ein Bestandssystem integriert wird oder eine eigene Anwendung bleibt. Je nach Geschäftsmodell kann beispielsweise eine Mobile-Payment-Lösung als Erweiterung des bestehenden Finance-Systems konzipiert werden oder als eigenständige Bezahllösung. Das beeinflusst, wie der Technologie-Stack für den Prototyp aussieht; auch diese Entscheidung ist Teil der Leitplanken.
Ein weiterer wesentlicher Punkt ist die Definition der Schnittstellen für den Datenaustausch mit den Um-Systemen. Eventuelle Besonderheiten - zum Beispiel ein Fokus auf Datensicherheit und -integrität für Mobile Payment oder auf Performance für einen Webshop - runden die Leitplanken-Definition ab. In diesem Rahmen dürfen Systeme so gebaut werden, wie es der Prämisse "schnell zum Kunden" dient.
Die klassische Bebauung auf der bestehenden IT-Landschaft ist Voraussetzung für die Entscheidung, welche Systeme ein Sprint- brauchen und welche ein Marathon-Vorgehen brauchen. Dabei gilt die Faustregel: Ein Sprint-System ist nahe am Endkunden, deckt innovative Funktionen ab und die Anforderungen sind (zumindest teilweise) unklar. Ein Marathon-System ist der Stabilität, Datenintegrität und Datensicherheit verpflichtet. Es deckt in der Regel Standardfunktionen ab, die Anforderungen für Erweiterungen sind gut detailliert - zum Beispiel weil sie Compliance-Vorgaben entsprechen müssen oder bestehende Funktionen ergänzen.
In Sprint-Systemen können erste Erfahrungen mit Technologien, Frameworks, Sprachen oder Betriebsmodellen gesammelt werden, die bei Erfolg in den etablierten Stack für Marathon-Systeme übernommen werden. Und es gilt auch umgekehrt: Nicht alles, was in Sprint-Systemen gemacht wird, muss für die nächste Version beibehalten oder in einem anderen System wiederverwendet werden - die Lernkurve darf steil sein.
Damit die Sprint-Systeme in die Marathon-IT überführt werden können, oder Prototypen an die Kernsysteme andocken, braucht es dort sauber definierte Schnittstellen - eine Selbstverständlichkeit, die in einer IT-Landschaft mit zwei Systemtypen noch einmal wichtiger wird.
Produkte und Services nahe am Kunden entwickeln, Features früh ausprobieren, neue Technologien einsetzen: Die IT der zwei Geschwindigkeiten ist in vielen Unternehmen schon Realität. Allerdings ist die Entwicklung nicht immer sichtbar, und ganz sicher ist sie nicht überall willkommen. Dennoch krempelt Technologie etablierte Geschäftsmodelle in vielen Branchen gründlich um. Die Transformation in den vier skizzierten Handlungsfeldern Kultur, Fähigkeiten, Organisation und IT-Landschaft anzustoßen, macht die Transformation zu einer IT der zwei Geschwindigkeiten explizit.
Das Ziel ist eine lebendige IT-Organisation. Sie probiert neue Technologien aus und reagiert schnell auf Kunden-Feedback und Marktentwicklungen, ohne Stabilität und Sicherheit aufzugeben. Für das Gelingen dieser Transformation braucht es Wertschätzung für die Stärken beider Stränge in der IT-Organisation, eine IT-Landschaft, die für unterschiedliche Arbeitsprämisse verschiedene Bebauungsmodi entwickelt und eine Moderation, die die Verschiedenartigkeit und das organisatorische Nebeneinander erklärt. Darüber hinaus ist ein Management wichtig, das den Austausch kommunikativ, personell und insbesondere persönlich fördert.