In einem aktuellen All Things ITSM-Podcast auf der Knowledge 16 wurde ich nach meinen Gedanken zu Agile und DevOps gefragt.
Es ist in der IT kein Geheimnis, dass DevOps derzeit das heißeste Thema im ITSM-Umfeld ist, da Unternehmen versuchen, die Barrieren zwischen „Dev“ und „Ops“ abzubauen, um Innovationen zu beschleunigen und eine kontinuierliche Entwicklung sowie die Veröffentlichung neuer Funktionen und Services zu ermöglichen.
Während Unternehmen wie Spotify gezeigt haben, wie sie auf Basis dieses neuen Paradigmas von Grund auf eine neue Engineering-Kultur aufgebaut haben, stehen viele etablierte IT-Organisationen vor einer ganz anderen Herausforderung: Sie versuchen, vom alten „IT-Fabrikmodell“ zu einem neuen, stärker horizontal ausgerichteten, agilen Kollaborationsmodell zu wechseln.
Das Problem liegt weniger auf der Entwicklungsseite als auf der Betriebsseite, wo vielen Organisationen noch immer die grundlegende Integration zentraler IT-Prozesse wie Incident Management (IM), Problem Management (PM) und Change Management (CM) fehlt.
Das sehen wir täglich in unserer Arbeit mit Kunden: IM, PM und CM sind unter unterschiedlichen Verantwortlichkeiten angesiedelt, haben unterschiedliche Prioritäten und nur wenige Schnittstellen, um eine gute Datenübergabe sicherzustellen. Was häufig fehlt, ist die End-to-End-(Kunden-)Prozessperspektive dieser drei Disziplinen, die es in diesem Fall letztlich alle darum geht, Kunden- und technische Probleme schneller und dauerhaft zu lösen und gleichzeitig die IT-Verfügbarkeit zu maximieren.
Ich persönlich glaube, dass dies viel damit zu tun hat, wie Frameworks wie ITIL® – sagen wir – „fehlinterpretiert“ wurden. Während eines ihrer Hauptziele darin bestand, eine stärker prozessorientierte Kultur aufzubauen, haben viele Organisationen sie als Begründung genutzt, ganze Funktionen um die einzelnen Prozesse herum aufzubauen – was in vielen Unternehmen zu Silos geführt hat, die nur selten miteinander interagieren.
Mit oder ohne DevOps müssen wir uns fragen, welchen Mehrwert wir für den Kunden schaffen, wenn wir diese Disziplinen aufbrechen, statt sie auf einen gemeinsamen Zweck auszurichten und übergreifend zu integrieren – mit dem übergeordneten Geschäftsziel, die Verfügbarkeit zu erhöhen und das Kundenerlebnis zu verbessern. Dann sind wir möglicherweise bereit für DevOps, bei dem es um „horizontales Business Management“ und die Ausrichtung multidisziplinärer Teams mit unterschiedlichen Kompetenzen auf einen gemeinsamen Zweck (statt auf eine Struktur) geht.
Die Re-Integration der Ops-Seite des Geschäfts ist jedoch mehr als nur das Ausrichten von Organisationen und Teams auf einem Blatt Papier. Eine Änderung des Organigramms allein hat keinerlei Einfluss auf die Geschäftsergebnisse. Diese Neuausrichtung muss Hand in Hand gehen mit einer Entrümpelung unserer Prozesse, dem Entfernen nicht wertschöpfender Arbeit und der Befähigung unserer Mitarbeitenden durch Kompetenzen, um über ein breiteres Spektrum an Disziplinen hinweg arbeiten zu können. Wir müssen sie für das richtige Verhalten belohnen (statt ihr Denken zu begrenzen, indem wir sie in eine bestimmte Schublade stecken) und unsere Tool-Landschaft bereinigen, um sicherzustellen, dass wir aussagekräftiges Wissen schaffen und einfache, wiederkehrende Aufgaben automatisieren können.
Erst dann werden wir den wahren Wert von DevOps ausschöpfen können.
