In dieser Folge setze ich die Darstellung der Verbindung von DevOps und ITIL4 fort. Seit Anfang 2019 ist das erprobte Framework ITIL in einer agilen, neuen Version verfügbar. Genauso wie DevOps seit langem ITSM-Ansätze integriert, referenziert ITIL4 nun auch auf agile und DevOps-Ansätze.
Aus einem Kundenprojekt heraus habe ich einen Workshop zur Verbindung der beiden Ansätze konzipiert, den ich als Inhouse-Veranstaltung und als offenes Seminar anbiete. Zusätzlich habe ich einige Fachartikel zu diesem Thema veröffentlicht. Diese Folge geht konkreter auf die Zusammenführung beider Ansätze ein.
In der Podcast-Episode wird das synergetische Verhältnis zwischen ITIL 4 und DevOps erörtert, wobei ihre Kompatibilität und gegenseitige Verstärkung für moderne IT-Organisationen betont wird. Der Sprecher erläutert sieben Schlüsselschritte zur Integration dieser Rahmenwerke, die Aspekte wie Zusammenarbeit zwischen Entwicklung und Betrieb, Ausrichtung auf Geschäftsbedürfnisse, Orientierung an Wertströmen und teambasierte Organisationsstrukturen umfassen. Die Episode hebt die Bedeutung von Automatisierung und pragmatischem Handeln hervor und betont die Notwendigkeit eines ausgewogenen Ansatzes, der sowohl die systematische Struktur von ITIL 4 als auch die agile, teamorientierte Natur von DevOps nutzt.
Inhalt
- Einführung in die Kompatibilität von ITIL 4 und DevOps
- Sieben Schritte zur Integration von ITIL 4 und DevOps
- Zusammenarbeit zwischen Entwicklung und Betrieb
- Integration in Geschäftsprozesse
- Orientierung an Wertströmen
- Mehrwert auf Unternehmensebene schaffen
- Operative Teams als Grundbausteine bilden
- Herausforderungen in der Automatisierung ansprechen
- Die Notwendigkeit pragmatischer Anwendung
- Die Bedeutung der Teamorientierung in DevOps und Prozessorientierung in ITIL 4
- Einblicke in ITIL 4s Wertstromaktivitäten und -praktiken
- Diskussionen über organisatorische Veränderungen von Projektfokus zu Produktfokus
- Die sich wandelnde Rolle der IT in Unternehmen
Shownotes
Artikel für Teil 1: Hybride IT-Organisationen mit ITIL4 und DevOps
Artikel für Teil 2: ITIL und DevOps im Zusammenspiel
Beschreibung ITIL4 und DevOps Workshop
Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)
Hallo und herzlich willkommen zum DevOps-Podcast auf die Ohren und ins Hirn.
Heute haben wir Teil 2 zum Thema ITIL 4 und DevOps, zwei starke Partner für moderne IT-Organisationen.
Beim letzten Mal hatte ich ja in einem kleinen Selbstgespräch ein bisschen was erzählt aus meinen Erfahrungen aus Schulungen, aus Workshops
und hatte in dem Teil 1 hergeleitet, dass ITIL 4 und DevOps für mich aus meiner Sicht zusammenpassen, sehr gut zusammenpassen
und hatte das über die Prinzipien getan. Ich hatte also dargelegt, dass die Werteorientierung als ein Prinzip von ITIL 4
sehr schön mit dem Customer-Centric-Action-Prinzip der DASA zum Thema DevOps oder für DevOps zusammenpasst.
Ich hatte das quasi durchgezogen für alle Prinzipien und war stehen geblieben bzw. hatte geendet mit der Aussage,
dass alle ITIL-Prinzipien, alle sieben ITIL 4-Prinzipien sehr schön zu fünf,
der sechs DASA-DevOps-Prinzipien passen. Ja, und übrig geblieben war, dass cross-funktionale, autonome Teams gebildet werden.
Das ist ein DASA-DevOps-Prinzip, was aus meiner Sicht eben in ITIL nicht so vorhanden ist.
Heute, Teil 2, geht es darum, wenn die beiden Frameworks oder Ansätze nun gut zusammenpassen, wie passen sie denn zusammen?
Also, wo kann man das denn sehr schön zusammenbringen? Und das will ich tun und basieren,
das wieder auch auf einem meiner beiden Artikel, die in den Shownotes wieder beide eben drin sein werden.
Das heißt, der zweite Artikel heißt oder hat das Thema, wie passen denn ITIL 4 und DevOps zusammen?
Ich habe da sieben Punkte oder sieben Schritte dargelegt, die ich jetzt auch hier durchgehen werde
und die, wie gesagt, auch immer ein Inhalt der Schulung sind oder meiner Workshop sind.
Ich gehe die mal ganz kurz durch.
Basis ist immer eine Zusammenarbeit zwischen Dev und Ops als Schlüssel zum Erfolg.
Das heißt, Development und Betrieb, Development and Operations müssen sich zusammenraufen
und danach können sie erst auf das Business zugehen, meine Ansicht an der Stelle.
Das heißt, der erste Schritt ist, dass Dev und Ops sich zusammentun.
Dev meine ich hier übrigens immer auch im Sinne von Projekten.
Es muss nicht eine klassische Development- oder Entwicklungsabteilung sein.
Es kann auch gut sein, dass sich über Projekte Dinge entwickeln.
Auch da ist es eben sinnvoll oder für mich zwingend notwendig eigentlich,
wenn ich moderne IT-Organisationen aufbauen möchte, dass Dev und Ops einfach zusammenarbeiten,
um mit einer Stimme zum Kunden hin zu sprechen.
Interessant ist, dass das an vielen Stellen, wenn ich es im Unternehmen anspreche,
zwei unterschiedliche Reaktionen hervorruft.
Einmal gibt es die Reaktion, machen wir schon, tun wir schon, wir arbeiten schon zusammen.
Das ist okay, das glaube ich dann auch erst mal.
Da kann ich natürlich in weiteren Gesprächen herausfinden, ob es wirklich so ist und wie der Kunde dazu steht.
Aber das ist wie gesagt eine mögliche Reaktion in den Workshops und in den Beratungsmandaten.
Zweite Reaktion ist, stimmt, aber die anderen reden ja nicht mit uns.
Und die anderen sind dann immer Dev oder Ops, je nachdem, über welchen Kanal ich im Unternehmen dann dazu gerufen werde.
Also erster Schritt, erster wichtiger Punkt ist, Dev und Ops müssen zusammenarbeiten, müssen ihre Sprache finden.
Und wie das passieren kann, darauf gehe ich auch noch ein bisschen drauf ein später.
Wenn die beiden Seiten sich gefunden haben, dann kommt das Thema Business muss eingebunden werden.
Das heißt, dann komme ich dahin, dass ich hochperformante IT-Organisationen habe,
die gemeinsam mit dem Kunden etwas bewegen, die mit dem Kunden sprechen.
Und dazu müssen sie, wie gesagt, erst mal eine Sprache gefunden haben.
Dann muss das Business eingebunden werden.
Da gibt es den wunderschönen, die wunderschöne Abkürzung.
Wir kennen ja alle die ITs da sehr, sehr erfinderisch.
Bis Dev, Ops, also bis Dev und Ops arbeiten zusammen.
Punkt 2, Schritt 2.
Diese beiden Schritte sind noch so ein bisschen logisch, wie ich finde, hängen voneinander ab.
Also ich finde eben erst, dass die IT sich finden muss, zusammenfinden muss.
Und dann kann man aufs Business zugehen.
Wenn das passiert ist, dann ist ja die Frage, wie arbeiten bis Dev und Ops zusammen?
Wie arbeiten Business und IT zusammen?
Dann kommt für mich dann der.
Dritte Punkt, der dritte Schritt, die Orientierung an Wertschöpfungsketten.
Ich wollte eben schon so abschweifen in den englischen Begriff Value Streams.
Das ist für mich ein sehr wichtiger Punkt.
Und dort kommt man dann auch fachlich zueinander.
ITIL 4 hat sich ja sehr stark an Wertschöpfungsketten, an Value Streams orientiert.
Das ist dann der Kern eigentlich von ITIL 4 geworden, zumindest was so grafische Darstellungen angeht.
Und deswegen ist das bei mir der Punkt 3.
Das heißt, wenn sich Business.
Und ITIL gefunden haben und gemeinsam eine Vorgehensweise gefunden haben, Vertrauen aufgebaut haben oder neues Vertrauen aufgebaut haben und Anleger geregelt haben, dann geht es darum, wie arbeiten wir fachlich zusammen?
Dann kommt der Punkt 3.
Schritt 3 Orientierung an Wertschöpfungsketten, an Value Streams und danach kommt der Punkt 4, der heißt bei mir, wer mehr Wert auf Unternehmensniveau schaffen, was ich damit meine, würde ich später im Detail erläutern.
An der Stelle hier.
Ziele ich so ein bisschen darauf ab, wo ich denke, dass DevOps und ITIL 4 sich eben sehr schön ergänzen.
Ich habe ja eingangs dieser Folge und auch zum Ende der letzten Folge gesagt, ich sehe einen großen Unterschied darin, dass DevOps mehr oder sehr stark in eine Teamorientierung geht.
Das heißt Dezentralisierung von Entscheidungsbefugnissen, Dezentralisierung von Macht, wenn man so will, aber vor allen Dingen dahin, wo die Entscheidungskompetenz liegt.
Also Dezentralisierung.
Und das birgt natürlich die Gefahr, dass diese Dezentralisierung dafür sorgt, dass ich gar nicht mehr Governance-Regeln einhalte, dass ich vielleicht gar nicht mehr mit einer Denke quasi dieses Unternehmen sehe, mit einer Denke gemeinsam agiere.
Das heißt für mich ist dann der Punkt 4 Mehrwert auf Unternehmensniveau der wichtige Punkt, meinen Kunden auch auf einem Enterprise-Level zu bedienen und nicht nur punktuell mit irgendwelchen Teams in irgendeiner Form zusammenzuarbeiten.
Also Punkt 4.
Mehrwert auf Unternehmensniveau schaffen.
Ja und dann kommt aber der wichtige Punkt, den ich eben schon angedeutet habe.
Teams bilden die operative Grundlage.
Das heißt für mich Punkt 5, Schritt 5 ist es hinzubekommen, ITIL 4 und DevOps zusammenzubringen, indem ich schon realisiere, dass aktuell Teamorientierung, eine teamorientierte Organisation aktuell im Gespräch ist und viele Unternehmen ja auch in diese Richtung auch schon gehen.
Das heißt Teams, wie bilde ich Teams, da würde ich dann, oder gehe ich in Punkt 5, in Schritt 5 drauf ein.
Dann habe ich noch den Punkt Automation ist eine Herausforderung.
Das bedeutet, man denkt erst mal Automation ist doch kein Thema, machen wir doch alles.
Ja, machen wir alles, aber aus meiner Sicht auch da oder aus meiner Erfahrung heraus ist es auch so, dass an vielen Stellen Automation im Dev-Bereich stattfindet und Automation im Ops-Bereich.
Aber eben nicht im DevOps.
Das heißt, ich habe vielleicht, wenn es gut läuft, nur noch eine manuelle Übergabe mit all der Verschwendung, die wir so schön kennen, wenn Dev an Ops übergibt.
Aber wenn man sich das 3-Wege-Modell von Gene Kim zum Beispiel mal anguckt, ist es ja eigentlich auch genau da schon sehr wunderschön beschrieben.
Es geht eben darum, wirklich zusammenzuarbeiten und Automation kann ja nur dann wirklich die Mehrwerte bringen, wenn ich das über die gesamte Kette bringe.
Also man merkt schon an der Begrifflichkeit.
Es geht hier auch so ein bisschen um das Thema Wertschöpfungsketten.
Das heißt, Automation bezieht eigentlich ganz für mich automatisch mit ein, dass ich mir Gedanken gemacht haben muss über die Wertschöpfungsketten.
Das mache ich in ITIL, indem ich die Value Streams anschaue.
Das ist im DevOps-Umfeld häufig schon geschehen, wenn ich über die CDCI-Pipeline spreche.
Wenn ich die also entsprechend aufbaue, muss ich ja zumindest mal gedanklich eine Wertschöpfungskette beschrieben haben.
Ob die übergreifend ist?
Das lasse ich mal offen, aber das ist, wie gesagt, der nächste Schritt.
Automation ist eine Herausforderung.
So, und der letzte Schritt meiner sieben Punkte, meiner sieben Schritte ist, Pragmatismus ist angesagt.
Und das ist eben, wie ich finde, dann quasi der Absprungpunkt, weil dieser Workshop, dieser Tagesworkshop soll ja nicht nur Wissen vermitteln,
sondern auch die Leute voranbringen und zu Aktionen kommen.
Und da geht es dann in der Regel darum, wie kriege ich denn das?
Was ich in dem Workshop mit den beiden Seiten erarbeitet habe, auch dann auf die Kette, in die praktische Umsetzung.
Und da finde ich, heißt es dann, machen ist wie wollen nur krasser.
Der ein oder andere, der in meinen Workshops war, weiß, dass ich diesen Spruch sehr gerne mag.
Gibt es auf T-Shirts, gibt es auf Kaffeetassen.
Also nochmal zum Mitschreiben, machen ist wie wollen nur krasser.
Und das steckt eigentlich hinter Pragmatismus ist angesagt.
Also das als kurze Einleitung zu den sieben Punkten.
Zu den sieben Schritten, die aus meiner Sicht dann genutzt werden können, um überhaupt zu klären, wie kommen denn ITIL 4 und DevOps zusammen.
Dann gehen wir mal ins Detail.
Das heißt, ich versuche jetzt ein bisschen zu erläutern, wie aus meiner Sicht jeweils die einzelnen dieser sieben Schritte aus beiden Sichten,
also ITIL 4 und DevOps quasi gesehen werden, was beide Seiten dazu beitragen können.
Und wenn ich mir den ersten Punkt anschaue, Zusammenarbeit ist die Basis für den Erfolg.
Das heißt, Dev und Ops müssen zusammenarbeiten.
Dann hat sich da aus meiner Sicht mit ITIL 4 sehr grundlegend etwas getan, nämlich die Orientierung am Wertstrom.
Das heißt, das, was wir früher kannten von ITIL, dieses mächtige Service-Lebenszyklus-Modell mit den fünf Büchern und den fünf Lebenszyklus-Phasen,
hat sich gewandelt, hat sich gewandelt in Richtung der Orientierung am Wertstrom.
Und die Prozesse, das ist früher als Prozesse.
Das, was früher gesehen wurde, hat sich verändert in Richtung Praktiken.
Das wird jetzt Praktiken genannt.
Und die Idee ist einfach das, was wir an Prozesswissen haben in ITIL, dass das als Praktik entsprechend genutzt wird im Wertstrom.
Das heißt, die Sichtweise auf einen Service-Lebenszyklus ist komplett gestrichen worden.
Wir gehen über den Wertstrom und die Verantwortung für das Ergebnis, die Verantwortung für die Gestaltung,
die Verantwortung für die Organisation.
Das ist alles etwas, was im Wertstrom passiert.
Das heißt, ich müsste oder ich muss als Organisation schauen, wo ist mein Wertstrom oder wo sind die Wertströme.
Und dann baue ich da drum oder packe da rein die entsprechenden Praktiken.
Und da wiederum kommt dann das Wissen zum Tragen, was wir aus ITIL V2, V3 kannten und kennen
und was wir in vielen Unternehmen auch schon genauso lange im Einsatz.
Ich habe dann die verschiedenen Praktiken und die regeln dann die Zusammenarbeit.
Das heißt, ITIL V4 hat aus meiner Sicht die ganzen Themen wie Prozesse, was wir früher auch kannten,
als Praktiken beschrieben, ein bisschen entschlackt und eben in den Wertstrom gepackt.
Das heißt, ich habe genauso weiterhin einen Service-Level-Management, nicht mehr als Prozess über alles,
sondern als Praktik und ich muss dann im jeweiligen Wertstrom prüfen,
wie gut kann dieses Service-Level-Management funktionieren.
Wie gut kann dieses Service-Level-Management funktionieren?
Und wie kann ich das Service-Level-Management in meinem Wertstrom entsprechend als Praktik unterstützen?
Das heißt, jetzt einfach nur mal ein paar Beispiele.
Wie kann ich aus ITIL V4 die Zusammenarbeit gestalten?
Wie gesagt, über Service-Level-Management.
Dort wird geregelt, wie dann die einzelnen Teams beispielsweise in einem, also DevOps-Teams,
in einem Wertstrom zusammenarbeiten.
Es wird im Prozess Change Control, der heißt jetzt Change Control, wird geregelt.
Wie kriege ich kontrolliert meine Ergebnisse der Entwicklung in den Betrieb?
Wenn das Ganze natürlich in der Verantwortung eines Teams ist und wir dort wenig Abhängigkeiten zum Beispiel in der Architektur haben,
dann hat dieser Prozess gar nicht mehr so viel Bedeutung,
beziehungsweise diese Praktik wird dann gar nicht mehr so stark genutzt.
Das kann man jetzt fortführen, Incident Management, Request Fulfillment Management,
das sind alles Themen, wo ITIL quasi Praktiken vorgibt.
Wie kann in der ITIL-Management-Management, Request Fulfillment-Management,
wie kann in der ITIL-Management-Management zusammengearbeitet werden?
Wenn ich jetzt mal schaue, wie sieht das im DevOps-Umfeld aus,
dann würde ich oder dann ziehe ich gerne das Modell von Gene Kim heran, das Drei-Wege-Modell,
das ja sehr schön in seinen beiden Büchern beschrieben ist, etwas griffiger und lesbarer im Phoenix Project,
aber auch im DevOps-Handbuch.
Das DevOps-Handbuch ist ja genauso aufgebaut, aber es gibt übrigens auch frühere Veröffentlichungen von Gene Kim,
die das ganze Thema auch schon etwas früher beleuchten.
Was meint das Drei-Wege-Modell von Gene Kim?
Das Drei-Wege-Modell sagt, dass ich in einem ersten Schritt den ersten Weg beschritten habe,
wenn ich einen durchgängigen Flow etabliert habe.
Das heißt, von Dev fließen Informationen an Ops, man denkt also schon aneinander,
Dev liefert Informationen an Ops.
Das heißt aber auch, dass ich eben noch keinen Rückfluss habe.
Das Ziel dieses Durchgängigen.
Flows ist eigentlich einen schnellen und widerstandslosen Arbeitsfluss von Entwicklung zu Betrieb haben.
Also das fließt in die eine Richtung, nämlich in den Ops-Bereich.
Das heißt, da habe ich Themen, dass ich eben versuche, die Arbeit sichtbar zu machen,
den Work-in-Progress zu beschränken, Batch-Größen zu reduzieren und die Anzahl der Übergabepunkte zu reduzieren.
Das sind also alles Themen, wo DevOps sagt, so soll zusammengearbeitet werden und zusammenarbeiten heißt eben in diesem First Way,
in dem ersten Weg Dev liefert an Ops Informationen.
Wenn ich den zweiten Weg mir anschaue, dann schaffe ich es, aus Sicht von Jean Kim ein kontinuierliches Feedback sicherzustellen.
Das heißt, kontinuierlich fließen Informationen von Dev an Ops, aber auch zurück.
Das heißt auch dieser Kreislauf, das ist ja der erste Kreislauf,
die erste Gestaltung von Feedbackschleifen hat noch keine konkrete direkte Auswirkung auf die Organisation,
aber es muss eben sicher sein.
off die Organisation. Aber es muss eben sicher sein.
sichergestellt sein, dass wir im Prinzip wirklich kontinuierliches Feedback bekommen und das
für beide Seiten. Das heißt, das führt dazu, dass ich mit komplexen Systemen sicherer
arbeiten kann, weil ich eben immer entsprechenden Austausch habe. Das führt auch dazu, dass
ich die Probleme schon erkenne, wenn sie auftreten. Das wissen wir alle, wie teuer und aufwendig
es ist, Probleme zu beheben, wenn ich schon in der Produktion mit diesen Problemen bin.
Das heißt also, ein Vorteil, ein Ansatz ist ja auch wirklich, Probleme sichtbar zu
machen, dort wo sie auftreten, nämlich bei der Entwicklung. Shift-Left, das Thema hatten
wir ja auch in dem Podcast, testen in dem Umfeld. Das heißt, das Ziel dieses zweiten
Weges von Gene Kim ist es auch, Qualität zur Quelle zu bringen, also nach vorne zu
verlagern, also Qualität nach links zu verlagern. Dritter Weg von Gene Kim ist der
Weg, kontinuierliches Lernen und Experimentieren zu etablieren. Und dann habe ich nicht nur
die Feedback-Schleife zwischen Dev und Ops, die quasi einmal in jede Richtung fließt,
sondern ich habe das eigentlich täglich. Ich habe solche Themen wie Dailies, ich habe
Retrospektiven, also ich habe eigentlich systemimmanent einen permanenten und auch kurzfristigen Austausch,
eine permanente kurzfristige Rückmeldung von Dev an Ops und umgekehrt. Und wieder,
Daily ist eine Möglichkeit.
Wenn man das aber noch ein bisschen weiter treibt, heißt es aber eigentlich auch, wir
reden auch über Automation. Und das bedeutet auch, dass ich letzten Endes dafür sorge,
dass die Informationen, die ich aus einer Automatisierung von Abläufen bekomme, auch
an Dev und an Ops jeweils entsprechend zurückmelde quasi. Das heißt, wenn ich diesen dritten
Weg von Gene Kim nehme, der aus meiner Sicht ein Vorschlag aus der DevOps-Welt ist, dann
schaffe ich es.
Wenn ich die Informationen, die ich in meinen Lernen etablieren kann, in meine Lernen zu
etablieren, eine Sicherheitskultur, eine Austauschkultur hinzubekommen, dann schaffe ich es, Verbesserungen
bei der täglichen Arbeit zu institutionalisieren. Das heißt, ich schaffe es, wenn ich lokal
Dinge entdecke, sei es im Dev, sei es im Ops-Bereich, dass ich die dann global umsetze, dass ich
global daraus Erkenntnisse gewinne.
Und letzten Endes ist das dann auch schon der Hinweis an die Art der Führung, an die
Möglichkeiten, die Führungskräfte haben müssen, nämlich eine Kultur des Lernens
und des permanenten Austausches hinzubekommen.
Also, wie gesagt, Zusammenarbeit aus Sicht von Eitel, da geht es über den Wertstrom,
da liefert Eitel sehr viele Informationen über den Wertstrom. Zusammenarbeit aus Sicht
von DevOps mit dem Drei-Wege-Modell, eigentlich letzten Endes Zusammenarbeit über die schrittweise
Etablierung von Feedback, von gemeinsamen Lernen, von permanentem Austausch zwischen
Dev und Ops.
Also zwischen Projekten.
Also zwischen Projekten.
Also zwischen Projekten und einem Betrieb.
So, was kann man da noch darüber hinaus darstellen, was ist noch aus meiner Sicht denkbar?
Und wir alle kennen, denke ich, mittlerweile das Thema Minimum Viable Product, also das
MVP.
Und das ist ja auch in Eitel 4 mit als Begriff aufgenommen worden, als, wie ich finde, eben
wichtiger Begriff.
Und wenn ich darüber spreche, wie Dev und Ops zusammenarbeiten sollen, dann habe ich
das Gefühl, dass das ein sehr interessantes Thema ist.
Und wenn ich darüber spreche, wie Dev und Ops zusammenarbeiten sollen, dann heißt das für
mich auch mal darüber nachzudenken, ob das, was wir bisher in den Unternehmen an Prozessen
haben, nicht auch mal überdenkenswert ist, hinterfragenswert ist.
Und es gibt da einen sehr schönen Artikel, den ich auch in den Shownotes verlinken werde,
eine sehr schöne Quelle.
Und ich spreche mal oder schlage mal vor, über den Minimum Viable Process sich Gedanken zu
machen.
Der Minimum Viable Process erreicht sein definiertes Ziel.
Der Minimum Viable Process erreicht sein definiertes Ziel.
Der Minimum Viable Process erreicht sein definiertes Ziel.
Der Minimum Viable Process erreicht sein definiertes Ziel.
Der Minimum Viable Process erreicht sein definiertes Ziel.
Der Minimum Viable Process erreicht sein definiertes Ziel.
Mit dem Mindestmaß an Beschreibung und konkreter Ausformulierung erst dann, wenn er quasi
am Laufen ist.
Was heißt das?
Was meine ich damit konkret?
Es gibt eine ganze Reihe von Prozessbestandteilen, wenn ich an klassisches Prozessmanagement
denke.
Und da gehört natürlich das Ziel des Prozesses hinzu.
Und da sage ich, klar, passt.
Also das heißt, ein Minimum Viable Process beinhaltet immer auch ein Ziel.
Das Ziel muss beschrieben sein.
Dann gibt es immer den wichtigen Punkt im Prozessmanagement,
so ein Prozess muss angestoßen werden.
Es muss irgendeinen Trigger geben, der den Prozess anstößt.
Auch das muss natürlich in einem Minimum Viable Process Bestandteil sein.
Dann gibt es aus dem Prozessmanagement den Punkt,
ich muss den Eingang geregelt haben
und die Ergebnisse des Prozesses und seiner Aktivitäten müssen festgeschrieben sein.
Und ich muss mir überlegen, welche Lieferanten brauche ich quasi für den Eingang
und was sind die Empfänger der Ergebnisse.
Und das ist etwas, wo ich sage,
das muss ich nicht in einer statischen Prozessbeschreibung niederlegen,
sondern das kann ich schon ein bisschen enger fassen.
Und da reicht es, wenn ich bei den Ergebnissen des Prozesses sage,
wer kriegt die finalen Ergebnisse des Prozesses.
Das heißt, wer ist der Abnehmer.
Ich muss also nicht unbedingt aus meiner Sicht als Diskussionsvorschlag regeln,
was einzeln in den Prozess übergeben wird.
Es ist einfach nur wichtig, dass ich mir die finalen Ergebnisse vor Augen führe
und dass die Empfänger der Ergebnisse klar sind.
Und das sind eben aus meiner Sicht die einzigen Punkte,
die, wenn man über eine Entschlackung von Prozessen nachdenkt,
die dann geregelt sein müssen.
Das heißt, ich muss nicht unbedingt mir Gedanken machen
über notwendige Ressourcen für die Prozessaktivitäten.
Erst dann, wenn der Prozess ans Laufen kommt,
wenn er vielleicht ein bisschen weiter ausgedehnt wird,
wenn er weiter ausgerollt wird, dann muss ich mir darüber Gedanken machen.
Brauche ich Prozesskennzahlen? Brauche ich erwartete Ergebnisse?
Auch darüber kann man streiten.
Das tun wir auch trefflich in den Workshops immer,
weil natürlich mein Vorschlag hier mit einem Minimum-Process
vielen Ansichten von Prozessmanagement entgegensteht.
Also die erwarteten Ergebnisse, die Performance.
Natürlich will ein Kunde Zahlen haben, will er Faktnamen,
auf die er sich erinnert.
Auf die er sich beziehen kann, auf die er sich berufen kann.
Aber das ist natürlich etwas, wo wir vielleicht sogar auch aus dem agilen Umfeld lernen können,
zu überlegen, ob das vielleicht ein bisschen offener gestaltet werden kann.
Also kurz gefasst, Minimum-Process ist für mich ein Punkt,
über den man mal diskutieren sollte und der genutzt werden kann.
Jetzt kommen wir auf das, was quasi auch Inhalt des Podcasts und des Workshops ist.
Wie kriege ich Dev und OBS zusammen?
Und über diesen Weg können vielleicht beide Seiten mal diskutieren,
was sie wirklich für Prozesse brauchen.
Also Vorschlag von mir, Minimum-Process als Ansatz zu nutzen,
um Dev und OBS zusammenzubringen und vielleicht ein bisschen zu entbürokratisieren.
Wie führe ich diese beiden Ansätze jetzt nun zusammen?
Also abschließend zu dem Thema.
Aus meiner Sicht kann das Service-Management, kann ITIL 4 die Wertschirmorientierung mitliefern.
Das Thema zentrales Prozessmanagement.
Das heißt, was lasse ich zentral laufen, was wird zentral geregelt,
damit ich unter anderem auch zentral sicherstellen kann,
dass die notwendige Governance eingehalten wird.
Und insofern ist also eigentlich ITIL 4 oder könnte genutzt werden als Skalierungsidee.
Und ITIL 4 stellt quasi so Shared Services bereit, um Dinge wie zum Beispiel ein Ticketsystem,
um Dinge wie die Abdeckung von gemeinsamen Vorgehen zu dokumentieren.
Also ITIL 4, mehr Governance, mehr die Gesamtorganisation, mehr das Thema Skalierung und Überblick.
Und im Gegensatz dazu, Dev OBS liefert die dezentrale Kompetenz, also die Erfahrung damit,
die Erfahrungen, die man macht, das Vorgehen für dezentrale Kompetenz und dezentrale Verantwortung.
Sprich eben nicht mehr zentral alles zu entscheiden, das in die Teams zu verlagern
und damit auch schnell zu entscheiden.
Und dann schließt sich der Kreis für mich wieder.
Natürlich muss ich schnell entscheiden können, aber ich muss die notwendigen Rahmenbedingungen einhalten.
Und das wäre das, was ich aus ITIL 4 bekomme.
Das heißt aus meiner Sicht hier passen die beiden zusammen.
Jeder Ansatz liefert etwas, was der andere nutzen kann, was ich dann entsprechend zusammenbringen kann.
So, Business einbinden.
Ich habe eben dargestellt, IT hat sich gefunden, Dev und OBS arbeiten zusammen.
Wie kann ich es nun hinbekommen?
IT, Dev und OBS nachhaltig mit dem Business zusammenarbeiten.
Und da habe ich ja vorhin schon gesagt, so ein Buzzword reingeworfen.
Es gibt natürlich schon bis Dev OBS, genauso wie es DevSecOps gibt.
Da merkt man schon, an Dev OBS ist vielleicht nicht alles so ganz komplett, zumindest aus mancherlei Sicht.
Also bis Dev OBS.
Das heißt, wenn ich als Organisation, als IT-Organisation hoch performant werden will,
muss ich eigentlich auch Business einbeziehen.
Und das vielleicht anders einbeziehen als bisher.
Und wenn ich an meine Projekte denke im agilen Umfeld, dann ist das mittlerweile häufig auch meine Aufgabe,
dass ich quasi aus dem IT-Bereich heraus abgesendet werde, dem Business zu erklären,
wie sie sich anders einbringen können oder sollten oder müssten, wenn wir über agile Vorgehensweisen reden.
Wenn wir das auf Dev OBS übertragen, heißt das, das Business muss mitarbeiten, muss anders arbeiten,
und ich denke, ich habe vorhin schon klargemacht, diese sogenannte Wall of Confusion,
die wir, denke ich, alle kennen zwischen Dev und OBS, gibt es eigentlich auch zwischen allen drei Parteien.
Wenn ich also Business mit dazu nehme in das Bildchen, dann habe ich letzten Endes auch eine Wall of Confusion
zwischen BIS und Dev und BIS und OBS.
Also, zusammengefasst, bis Dev OBS ist für mich der nächste Schritt, die nächste Aktivität,
Business muss ich mit einbeziehen, und ich habe schon ein bisschen vorgegriffen,
und das werde ich auch später noch mal ein bisschen intensiver ausbreiten und erläutern,
wie kriege ich es hin, und die Antwort aus meiner Sicht lautet Wertstrombetrachtung.
Der Wertstrom ist die Klammer letzten Endes um alle Aktivitäten.
Wertstrom kenne ich aus dem ITIL 4 Umfeld und Wertstrom kenne ich aus dem Dev OBS Umfeld.
Und wenn ich dann auch mal die Erfahrung aus der Praxis,
deswegen halte ich sehe immer mehr Unternehmen, die zum Beispiel das Budget für IT-Projekte,
vielleicht sind es ja gar nicht mehr nur IT-Projekte, ins Business verlagern.
Es gibt immer mehr Unternehmen, die Produktteams aufstellen und die Produktteams,
die Verantwortung dafür, viel stärker auch ins Business verlagern.
Teilweise geht es ja sogar so weit, dass Business im Produktteam vertreten ist, also aktiv mitarbeitet.
Also all das sind aktuelle Entwicklungen,
wo man eben sieht, die Unternehmen machen ihre Erfahrungen damit und man rückt immer enger zusammen.
Und ich glaube auch, dass viele meiner Meinung sind, dass eine klassische IT-Abteilung nicht mehr
vielleicht mal den Stellenwert hat, wenn ich an mittlere Unternehmen denke wie früher.
Ich habe neulich auch so eine schöne Übersicht gesehen, welche IT-Jobs vielleicht keine Zukunft mehr haben.
Und da war genau das Thema IT-Leiter im mittelständischen Unternehmen hat zumindest eine unsichere Zukunft.
Aber gut.
Das war kleiner Ausflug ins Philosophieren.
Bis DevOps ist hier das Thema, also bis DevOps müssen zusammenarbeiten.
Und wie sieht das ITIL 4 aus der Sicht?
Ich habe das im Prinzip ja eben schon gesagt.
Die Wertschöpfungssicht, die Wertschöpfungsaktivitäten aus Sicht von ITIL 4,
die Service Value Chain liefert dort die Antwort.
Das heißt, ich habe den Eingang in diese Service Value Chain mit den Opportunities,
mit dem Demand und hinten raus kommt irgendwie,
also irgendwie kommt ein Wert raus.
Und dazu gibt es eben verschiedene Practices, wie eben auch schon,
und verschiedene Prozesse, die die Zusammenarbeit gestalten.
Und auch da habe ich beispielsweise das Service Level Management.
Das heißt, die Verhandlung der SLRs ist die Aktivität.
ITIL klärt dort, wie ich SLRs verhandle, wie ich also Business und IT zusammenbringe.
Ja, da wird der Demand konkretisiert und der Value wird in Zahlen überführt.
Da wird also konkret beschrieben, was der Value ist.
Wenn ich das Incident Management mir anschaue, dann ist die Störungsbeseitigung,
startet eben da, der Demand ist Störungsbeseitigung
und der Value ist dann die beseitigte Störung.
Request Fulfillment, die konkrete Kundenanfrage ist das Demand
und der Value ist dann die Umsetzung, die Befriedigung des Requests,
den das Business gestellt hat.
Also ITIL 4 hat da sehr viele schöne Vorschläge, die eigentlich nichts Neues sind,
die aber eben entsprechend in ITIL 4 schön neu verpackt sind.
Und was ich sehr interessant finde, ist das Thema Co-Creation.
Das heißt, ein neu beschriebener oder ausführlicher beschriebener Punkt ist,
dass das Business und die IT gemeinsam für die Wertschöpfung verantwortlich sind.
Co-Creation, also ITIL 4 sagt ganz klar auch, es muss eine Zusammenarbeit zwischen Business und IT geben.
Wenn ich mir DevOps anschaue, wie geht DevOps auf das Thema ein?
Wie bindet DevOps das Business ein?
Das ist natürlich aus der agilen Sichtweise, aus den agilen Frameworks klar und sehr schön geregelt.
Das heißt, ich habe bestimmte Rollen, die ganz klar für die Zusammenarbeit zuständig sind.
Ich habe eine geregelte Kommunikation, weil ich entsprechende Artefakte habe,
weil ich entsprechende Meetings habe.
Und so ist Co-Creation.
So ist quasi aus dem Thema entsprechende Meetings, entsprechende Artefakte, entsprechende Rollen
eine ziemlich starke Fokussierung darauf, operativ zusammenzuarbeiten.
Das heißt also auch hier wieder, ich hoffe, dass man es gerade so ein bisschen raushört,
ITIL hat mehr die übergreifende Sichtweise, dadurch, dass die Prozesse eben etabliert sind,
dass das jetzt mittlerweile Praktiken sind, die ich nutzen kann und in der operativen Arbeit
kann ich in DevOps arbeiten.
Und das heißt, ich kann jetzt auch noch mal ein paar Sachen aus dem agilen Umfeld kennen.
Und das ist ja nicht nur ein Product Backlog und Sprint Backlog.
Das geht ja noch ein bisschen weiter.
Eine Produktvision und eine Story Map, all das sind Dinge, die wir aus dem agilen Umfeld kennen und nutzen können.
Das heißt, wenn ich jetzt mal das zusammenfasse, dann macht es eben Sinn, BIS, DEV und OBS zusammenzubringen.
Was liefert ITIL da an der Stelle?
ITIL liefert quasi das Rollenverständnis.
Für alle vier beteiligten Seiten liefert die übergreifende Wertstrombetrachtung und gestaltet die Zusammenarbeit.
Also ITIL kennt eben genau die Regelungen, wie ich zusammenarbeiten kann.
Was liefert DevOps dafür?
DevOps liefert die teamorientierte Organisation, produktorientierte Organisation, schafft Transparenz durch die Artefakte
und schafft es auch zu einer Kommunikationsstrategie.
Das heißt, es gibt eine gemeinsame Kommunikation zwischen allen drei beteiligten Personen, unter anderem durch regelmäßige Meetings.
Worauf ich jetzt hier nicht konkret darauf eingehen kann, ist eine wunderschöne Übung, die ich in den Projekten und auch in der Schulung immer wieder mache.
Letzten Endes diese drei Parteien mal an einen Tisch zu bringen.
Und das kann man sehr schön mit einer kleinen Übung machen, wobei so klein ist die gar nicht.
Das kann auch schon ein, zwei oder auch drei Stunden dauern.
Da vielleicht ein kleiner Spoiler, mal zu schauen.
Ob man nicht bis der DevOps zusammenbringen kann, indem man sagt Hey, was liefern wir denn an die anderen zwei Parteien?
Und was erwarten wir von den anderen zwei Parteien?
Also kleine Übung.
Wer Interesse daran hat, kleiner Werbeblock, kann die Schulung buchen.
Ende des Werbeblocks.
Und kommen wir zum dritten Punkt.
Orientierung an Wertschöpfungsketten.
Ich habe ja mit den ersten beiden Punkten ausgeführt.
Dev und Ops arbeiten zusammen.
Wunderschön.
Bis arbeitet auch zusammen.
Hat sich bereit erklärt, ein Product Owner zu stellen.
Hat sich bereit erklärt, das Budget anders zu betrachten und und und.
Also wir haben jetzt mal wünscht dir was und bis der von Ops arbeiten schön zusammen.
Aber wie gestalte ich das denn?
Wie gestalte ich das denn, die Organisation hoch performant hinbekomme, dass ich sie quasi wertorientiert gestalten kann?
Und auch da wieder.
Wie kriege ich das geregelt?
Die Orientierung an Wertschöpfungsketten.
ITIL hat da sehr schön die alten Prozesse im Practices überführt.
Das hatte ich jetzt schon ein paar Mal gesagt.
Und hat sechs Wertschöpfungsaktivitäten benannt und die sehr schön in das Modell gepackt.
Das heißt, wenn die Nachfrage des Kunden reinkommt, geht die erste Wertschöpfungsaktivität los.
Das ist das Engagement.
Oder sich engagieren.
Dann gibt es die folgenden Wertschöpfungsaktivitäten.
Beschaffen, erstellen, designen und transitionen und bereiten und unterstützen.
Und letzten Endes, wer sich ein bisschen in der ITIL 3 Welt auskennt, der hat schon ein paar Analogien, ein paar ähnliche Begriffe gehört.
Das heißt, letzten Endes kann man so sein.
Die Wertschöpfungsaktivitäten greifen auf die ITIL Practices zurück, die nicht mehr auch einer festen Lebenszyklus sind.
Die sind nicht mehr in einer festen Lebenszyklusphase zugeordnet.
Also, sechs Wertschöpfungsaktivitäten in ITIL.
Ich habe es ja eben gesagt.
Wir haben das Thema planen.
Wir haben das Thema verbessern.
Wir haben das Thema engagieren oder Engagement.
Wir haben das Thema designen und transitionen.
Wir haben beschaffen und erstellen.
Und wir haben bereitstellen und unterstützen.
Und dann kommen Produkte und Services heraus.
Und die liefern dann den Wert an den entsprechenden Kunden.
Die ITIL Practices, da würde ich jetzt nicht näher drauf eingehen.
Ich würde jetzt darauf eingehen, was liefert DevOps oder was kommt aus der DevOps-Welt dazu.
Und DevOps hat sich sehr früh schon dem Thema Value Stream Mapping oder dem Thema Value Stream Analyse gewidmet.
Und letzten Endes ist das dann eine Möglichkeit, den oder die Wertströme gemeinsam zu gestalten, zu analysieren.
Und kann daraus auch eine entsprechende Prozessoptimierung ableiten.
Das heißt, hier kann die IT gemeinsam mit dem Business Methoden nutzen, die wir aus dem Lean Management kennen.
Value Stream Mapping wird in der Schulung auch detaillierter erklärt.
Vielleicht nur ganz, ganz kurz im Überblick.
Ich mache mir Gedanken über die Stimme des Kunden.
Was will der Kunde überhaupt?
Banale Frage, ist aber der Start in so einem Value Stream Workshop.
Dann mache ich mir Gedanken darüber.
Was sind die Anforderungen des Kunden?
Was soll umgesetzt werden?
Ich überlege mir, das war der Punkt eins, überlege mir, wer ist am Prozess beteiligt oder wer ist an diesem Value Stream beteiligt?
Und das ist dann immer schon mal sehr interessant, wenn man solche Workshops durchführt, wo man dann feststellt, wer alles an solchen Aktivitäten beteiligt ist.
Wenn man dann nämlich nachfragt, ja, wer macht denn diese Aktivität, die vielleicht nur mal so nebenbei erwähnt wurde.
Dann muss man wieder einen neuen Teilnehmer in den Workshop mit reinholen.
Also Kundenzielen und Anforderungen formulieren, Prozessbeteiligte analysieren.
Dann die ganzen Aktivitäten erfassen.
Also was passiert in diesem Wertstrom?
Das kann schon mal eine ziemlich große Posted-Wand auf Brown Paper werden.
Dann analysiere ich den Work in Progress.
Also wo ist Arbeit im Value Stream in Progress, die noch nicht abgeschlossen ist, die noch nicht übergeben ist.
Dann, das deutet im Prinzip vor.
Das deutet im Prinzip schon auf Engpässe hin.
Ich mache mir ja Gedanken über die Gründe für Engpässe.
Also warum hängt es an bestimmten Stellen, warum geht es dort nicht weiter.
Ich mache mir Gedanken darüber, wo muss vielleicht auch nachgearbeitet werden.
Also wo geht, wenn ich jetzt im Eitel-Sprech komme, wo geht ein Ticket zurück, um nochmal nachzuarbeiten, um nochmal Dinge nachzuschärfen.
Fünfter Schritt ist, dass ich nochmal ergänzend Informationen dazu packe zu den einzelnen Schritten.
Dann mache ich einen ganz wichtigen Schritt.
Ich bewerte die zeitlichen Aspekte des Prozesses.
Das heißt, was sind Durchlaufzeiten, was sind Prozesszeiten und was sind Wartezeiten.
Und über diesen Weg versuche ich die Effizienz des gesamten Prozesses zu ermitteln, indem ich eigentlich oder ganz einfach die Prozesszeit durch die Durchlaufzeit teile.
Ganz interessant ist, dass dort Werte rauskommen.
Ja, wo?
Wo der eine oder andere ziemlich überrascht ist.
Also wie gering die sind.
Die Effizienz ist teilweise bei 10 bis 20 Prozent bei Business-Prozessen.
Denn wenn ich mir überlege, ich habe 40 Stunden vielleicht Bearbeitungszeit, aber bei 120 Stunden Durchlaufzeit, wenn ich 40 durch 120 teile, komme ich auf 33 Prozent.
Gut, das so als kurzer Überblick bis hierher.
Ach, ich habe vergessen, Nutzen und Verschwendung muss ich dann noch mir anschauen.
Wenn ich über Value-Stream, Bewertung und Effizienz rede.
Das heißt, wenn ich die Aktivitäten erfasst habe in diesem Value-Stream, schaue ich noch, wo ist Customer-Value-Add.
Also wo sind wirklich Aktivitäten, die einen Nutzen für den Kunden erbringen.
Das ist ganz klar.
Die brauche ich auf jeden Fall.
Die sind nicht diskutabel, weil sie eben einen Nutzen erbringen.
Dann gibt es noch Punkte, die vielleicht, die auf jeden Fall erstmal Verschwendung sind, weil sie keinen direkten Nutzen erbringen.
Aber die kann ich ja unterteilen.
Ich kann in Non-Value-Added Aktivitäten unterteilen.
Das heißt, das ist wirklich Verschwendung.
Das sind überflüssige Aktivitäten.
Und vielleicht gibt es Aktivitäten, die erforderlich sind, die dann eben über diesen Weg auch einen Geschäftswert erbringen, einen Nutzen erbringen.
Die aber im Prinzip nicht ursprünglich oder ursächlich Wert erzeugen.
Das sind dann die Business-Value-Add-Tätigkeiten.
Also gerade die letzten beiden Schritte.
Einen Prozess oder einen Wertstrom zeitlich zu bewerten, die Durchlaufzeit mit der Prozesszeit in Beziehung zu setzen und dann Nutzen und Verschwendung mehr anzuschauen.
Also Customer-Value-Add anzuschauen, Business-Value-Add und Non-Value-Add-Tätigkeiten zu ermitteln.
Ja, das war der kurze Ausblick auf Value Stream Mapping als Beitrag von DevOps, von Lean Management, um bis Dev und Ops zusammenzubringen.
Und wenn ich das dann zu Ende denke und das auf das Thema Team-Orientierung mappe, dann heißt es eigentlich, dass ich in einem DevOps-Team die Tätigkeiten durchführe, die als Praktiken in einem Wertstrom dann zu sehen sind, wenn ich das auf die Organisation mal übertrage.
Und jetzt auch hier wieder vielleicht ein kleiner, es ist vielleicht kein Werbeblock, aber ein kleiner Hinweis.
Es gibt eine sehr schöne Initiative.
Wo auch interessante Leute mitarbeiten.
Wir haben Leute aus der Praxis.
Wir haben erfahrene Berater.
Und was wir versuchen, ist, dass wir ein Praxisleitfaden ermitteln für Value Stream.
Also wer Interesse daran hat, wie das aussieht, der kann sich entweder für meinen DevOps-Newsletter registrieren.
Der kriegt Informationen oder sich einfach bei mir melden.
Es gibt eine wunderschöne, kleine, feine, hochkarätig besetzte Arbeitsgruppe, wo wir eben Value Stream mit einem Praxisleitfaden ermitteln.
Und auch vielleicht mit einem Workshop-Angebot versehen wollen.
So, nächster Punkt.
Ich hatte gesagt, der vierte Schritt, der vierte Aspekt ist, Mehrwert auf Unternehmensniveau zu schaffen.
Das heißt, was ich vorhin versucht habe, ist klar zu machen, dass ich eben nicht nur operativ irgendwie von der IT heraus mit Business zusammenarbeite,
sondern dass ich wirklich auf Unternehmensniveau, auf Enterprise-Niveau Mehrwert biete.
Und da ist eben der Ansatz von mir, was steckt dahinter?
Governance.
Für mich steckt an erster Stelle dort Governance dahinter.
Und ich finde das deswegen interessant, weil beide Seiten, also ITIL 4 und DevOps, unterschiedliche Sichten auf Governance haben.
Und der eine oder andere mag über die andere Sicht von Governance schmunzeln, Kopf schütteln.
Aber ich denke, auch da ist es ihm wichtig, zusammenzukommen.
Wie sieht ITIL 4 Governance aus?
Ganz einfach, die Definition von Governance ist das Mittel, mit dem eine Organisation geführt und gesteuert wird.
Das heißt, es gibt verschiedene Aktivitäten, die ausgehend von einem Leitungsorgan dafür sorgen, dass ich bewertende Aktivitäten habe,
dass ich lenkende Aktivitäten habe, dass ich überwachende Aktivitäten habe.
Aber das ist eben sehr stark in Richtung vorgeben, steuern und überwachen, um Governance einzuhalten.
Wie sieht DevOps das Ding aus?
Wie sieht DevOps das Ding aus?
Wie sieht verständlich sein System aus?
Wichtig ist das Thema Governance.
Aus DevOps Sicht ist Governance die Sicherstellung, dass das Business Innovation und Servicebereitschaft wie vereinbart,
also Zeit, Qualität und Preis erhält.
Und das eben unter anderem durch die passende Zusammenarbeit zwischen den internen und externen Partnern.
Also da ist die Definition von Governance ein bisschen anders, wie ich finde.
Und warum?
Weil ich durch die verschiedenen Aktivitäten,
die verschiedenen Inhalte von DevOps einfach dafür sorge, dass durch die tägliche Arbeit Governance eingehalten wird.
Also ich brauche keine so weitgehende Vorgabe und Kontrolle, sondern das wird im täglichen Doing geregelt.
Das heißt, die agilen Werte und Prinzipien, die Definition of Done, die Akzeptanzkriterien bei den User Stories
und alles Punkte, die auf die Governance einzahlen.
Es gibt vielleicht ein Scrum of Scrums, wo sich Entwickler austauschen.
Es gibt vielleicht ein Enterprise Backlog, wo übergreifende Themen drinstehen.
Es gibt einzelne Rollen mit dedizierter Verantwortung für eine Governance-Sichtweise eben aus Sicht von DevOps.
Das heißt, aus meiner Sicht, die beiden Ansätze liefern gegenseitige oder liefern nicht gegenteilige,
aber doch abweichende Sichten auf Governance.
Und auch da finde ich es eben sehr interessant, das mal zusammenzubringen
und das gemeinsam zu einer Sicht zusammenzubringen.
Das heißt, da, was liefert ITIL?
ITIL liefert langjährige Erfahrung in Planung und Steuerung und in der Optimierung von Services.
Also dort Governance aus Sicht von oder in Sicht für Vertragstreue.
Und DevOps liefert den Fokus auf die Menschen, auf die Teams, also auf die Akzeptanz
und auf die operative Umsetzung von Governance.
Also wie kriege ich es hin, dass mein Kunde genau das bekommt, was er braucht?
Und das ist das, was man bestellt oder erwartet hat.
Gut.
Jetzt habe ich behandelt.
Dev und Ops zusammenarbeiten, Schritt 1.
Bis Dev und Ops zusammenarbeiten, Schritt 2.
Mehrwert auf Unternehmensniveau.
Quatsch, Value Stream Sichtweisen, also Wertschöpfungskette.
Value Stream, Mehrwert auf Unternehmensniveau, Schritt 4.
Und jetzt Schritt 5.
Teams bilden die operative Grundlage.
Und da hatte ich vorhin schon gesagt, dass das ein sehr guter Punkt ist.
Und das ist ein sehr guter Punkt.
Und das ist ein sehr guter Punkt.
Und das ist ein sehr guter Punkt.
Wie schon gesagt, da ist es aus meiner Sicht ein großer Unterschied zwischen ITIL 4 und Dev Ops.
ITIL 4 hat, das habe ich auch im ersten Teil des Podcasts schon mal ausgeführt,
ITIL 4 sagt schon, die müssen zusammenarbeiten.
Aber Dev Ops geht aus meiner Sicht einen Schritt weiter oder auch vielleicht mehrere Schritte weiter
und sagt ganz klar, wir brauchen selbstorganisierte, autonome Teams,
die dezentral das Wissen haben und die dezentral entscheiden.
Und das ist eben ein Punkt, den ich mir immer wieder vorgestellt habe.
Und das ist eben ein wichtiger Punkt, den ich in dem Workshop ein bisschen weiter ausführe,
insbesondere mit einer Folie, die ich auch in meinen Vorträgen nutze, die Veränderung.
Was bedeutet das für die Unternehmen?
Und es bedeutet für die Unternehmen, dass ich mich weg von einer Aktivitätenorientierung
hin zu einer Produktorientierung entwickle.
Das heißt, das, was Sie jetzt alle kennen, die Spezialisten, die Brands aus dem Phoenix Project,
die sind nicht mehr so wichtig.
Es wird immer mehr Leuten bewusst, dass diese Brands,
nicht die Lösung des Problems, sondern die Ursache des Problems sind.
Das heißt, ich orientiere mich weg von Spezialisten, die ich immer in Projekten zusammensetze,
wo ich vielleicht wochenlang auf einen Spezialisten warten muss, wo ich von Spezialisten abhängig bin.
Ich entwickle mich hin zu einer teamorientierten Ausrichtung, einer produktorientierten Ausrichtung.
Das heißt, ich orientiere mich an der notwendigen Arbeit.
Ich entwickle mich von einer Funktionsorientierung, nämlich die Silos,
die klassischen Silos.
Hin zu einer Team- und zu einem Service-basierten Aufbau.
Also auch da organisatorische Veränderungen.
Und ich komme dahin, dass ich meinen Fokus im Unternehmen von Projekten wegschiebe hin zu Produkten.
Ich lasse das mal ein bisschen wirken und ich hoffe auch, dass ich demnächst einen Gesprächspartner dann endlich hier dazu bekomme,
der dazu auch aus der Praxis seine Erfahrungen dann teilen wird.
Das heißt, weg von Projekten hin zu Produkten.
Ich habe Produktteams,
die für ein Produkt, wie auch immer ich das Produkt schneide und definiere, komplett verantwortlich sind.
Von der Wiege bis zur Ware, von Anfang bis Ende.
Und das ist eben eine starke organisatorische Veränderung, weil ich das eben entsprechend auch umsetzen muss.
Die Ausrichtung der Organisation verschiebt sich dann von einer optimalen Ressourcennutzung.
Das ist ja des Aktivitäten orientiert.
Ich versuche, meine Brands, meine Spezialisten,
optimal einzusetzen, hin zu einer Optimierung für die Schnelligkeit.
Das heißt Produktorientierung heißt auch, dass ich schnell reagieren kann.
Und das bedeutet natürlich schon, dass ich eine gewisse Qualität liefern muss.
Das bedeutet aber auch, dass eventuell bei einer schnellen Lösung vielleicht nicht immer sofort der Spezialist gefragt ist,
sondern dass man das sich im Team erarbeitet und vielleicht auch die Lösung nicht sofort hundertprozentig ist.
Das akzeptieren wir, weil wir einfach schnell reagieren wollen.
Bzw.
müssen. Und das Team, das Produktorientierte Team, hat die volle Verantwortung bis in die
Produktion. Das heißt, ich übergebe nicht ein Projektergebnis an den Betrieb, sondern
das Team, was entwickelt, was am besten permanent zusammenarbeitet, hat die volle Verantwortung,
also die Ergebnis- und die Durchführungsverantwortung. Und was bedeutet das? Das bedeutet, dass
ich eben autonome Teams habe. Ich habe dann Produkt-Teams und Plattform-Teams. Die Plattform-Teams
stellen die notwendige, die beschriebene und vereinbarte Basis bereit, worauf sich
die Produkt-Teams entsprechend draufklicken. Ich nenne das immer Knopfdruckgeschäft. Wenn
also die Produkt-Teams ihre Anforderungen sauber beschrieben haben, dann klicken sie
nur auf den Knopf und kriegen dann eben das, was sie brauchen, sei es ein Server, sei es
auch vielleicht eine komplette Infrastruktur, auf Knopfdruck, weil es von der Produktion
dem Plattform-Team oder den Plattform-Teams entsprechend auch automatisiert bereitgestellt
wird. Also Hinweis da nochmal ganz klar, autonome Teams brauche ich. Worauf ich jetzt hier auch
aus Gründen der Zeit nicht stärker darauf eingehe, ist das Thema, dass ich solche Teams
natürlich nicht nur fachlich passend zusammensetzen muss, sondern auch darauf achten muss, wie
sie sich organisieren. Das muss nicht immer Scrum sein, das kann sehr wohl auch Kanban
sein, wenn ich überhaupt auf konkrete Methoden, wie ich das jetzt hier vorgestellt habe,
den Boden abziele. Und dass ich im Idealfall auch darauf achte, dass die Menschen zueinander
passen. Und dann komme ich schon in den Bereich Teamentwicklung, Teambuilding, Bell bin als
ein Stichwort, um Teamrollen mir überlegen muss. Und das sind aber nur kleine Hinweise,
will ich nicht näher darauf eingehen. Wenn ich das jetzt zusammenfasse bis hierher, dann
ist es aus meiner Sicht, das was ich bis hierher rübergebracht habe, ein hybrider Ansatz,
zu skalieren. Also DevOps liefert die Sicht, mit Teams zu arbeiten. Und das fällt ja nicht
vom Himmel. Ich kann ja nicht einfach eine Organisation mit der bestehenden Architektur
und den bestehenden Abhängigkeiten in eine DevOps-Organisation umwandeln. Ich muss ja
auch dafür sorgen, dass das Ganze skaliert. Es gibt das Skate Agile Framework, SAFE Framework,
gerade sehr beliebt, aber unter Agilisten auch sehr verhasst, weil das vielleicht gar
nicht so agil ist oder sein soll. Will ich gar nicht diskutieren. Das ist ein Thema,
über das wir hier diskutieren. Es ist aber eine Möglichkeit zu skalieren. Es gibt die
Flight Levels von Klaus Leopold, Kanban Flight Levels. Da hatte ich ja genau vor drei Podcasts
mich mit einem Experten dazu unterhalten. Das sind zwei mögliche Skalierungsansätze.
Und um das nochmal klar zu machen, für mich ist ITIL 4 auch eine Möglichkeit, DevOps
zu skalieren. Ein paar Beispiele habe ich hier heute auch gegeben. Gut, Automation ist
eine Herausforderung. Nähern wir uns so ein bisschen dem Ende. Wenn ich Automation als eine
Herausforderung bezeichne, meine ich, dass ich die IT hier in der neuen Herausforderung stellen muss.
Das, wovon sie jahrelang gelebt hat, nämlich Geschäftsprozesse beim Kunden zu automatisieren,
das muss sie nun selber tun. Und meine Wahrnehmung ist, dass das Ganze sehr wunderschön läuft,
wenn ich kleine Bereiche rausnehme, wenn ich überschaubare Wertschöpfungsketten habe,
dann habe ich eben schon sieben, acht, neun, neun, neun, neun, neun, neun, neun, neun, neun, neun, neun, neun,
schon CI, als continuous integration, was ganz gut funktioniert. Dann gehen die Unternehmen
weit hin in continuous delivery und sind irgendwann beim continuous deployment, also haben wirklich
eine CD oder CD-CI Pipeline vielleicht sogar auch wirklich für eine vernünftige Wertschöpfungsaktivität.
Aber wie gesagt, meine Wahrnehmung ist häufig, dass das genauso wieder eine Sub Betrachtung
ist, also ein Teilbereich und ich nicht alles automatisiere. Also, was ich hier in diesem
Teil sagen möchte, ist, dass eigentlich auch hier beide Seiten aufeinander zugehen müssen
oder sollen. Und wer sich an Teil 1 erinnert, da habe ich ja gesagt, ITIL-Prinzip optimieren
und automatisieren. Das ist das, glaube ich, was ITIL mitbringen kann in die Zusammenarbeit.
Eine übergreifende Sichtweise, die Top-Down-Vorgehensweise und den Blick dazu, vielleicht Dinge mal
zu optimieren, bevor ich sie automatisiere. Auch das zahlt wieder ein auf das Thema Wertstrombetrachtung.
DevOps liefert die teamorientierte Organisation. Das heißt, ich optimiere lokal von Bottom-Up.
Je nachdem, wie umfassend meine Sichtweise ist, kann das schon ziemlich weit gehen. Aber durch die Teamorganisation
und durch die Tools, die ich verwende in den Teams, komme ich dort zu einer Automation Bottom-Up gesehen.
Und auch da wieder mein Hinweis, mein Vorschlag, sprecht miteinander, geht aufeinander zu, nutzt die Vorteile
der jeweils anderen Seite, nutzt die Erfahrung der jeweils anderen Seite. Also Automation ist eine Herausforderung,
weil Devs und Ops auch dort zusammenarbeiten müssen. Und dort treffen dann ja die erfahrenen Entwickler
zusammen. Da treffen die Administratoren aufeinander, da treffen die Techniker aufeinander. Und das denke
ich, das ist eine Moderation wert. Letzter Punkt meiner sieben Schritte ist das Thema Pragmatismus ist angesagt.
Und ich habe schon gesagt, mein Lieblingsspruch an der Stelle ist, machen ist wie wollen nur krasser.
Wie gesagt, kann man als T-Shirt bestellen, kann man als Kaffeetasse bestellen. Ist schon, finde ich, ein sehr
wahrheitsgemäßer Spruch. Und das soll auch vielleicht der Abschluss sein, dieses Podcast. Der Abschluss dahingehend,
dass ich sage, ITIL 4 und DevOps passen gut zueinander. Sie ergänzen sich sehr schön. Jede Seite bringt Überschneidungen mit.
Also es gibt relativ große Schnittmengen.
Und es gibt quasi die zwei Sichtweisen auf ein Problem. Und diese Sichtweisen ergänzen sich sehr, sehr schön.
Pragmatismus ist angesagt. Sprecht miteinander, geht aufeinander zu und seid offen für die andere Seite.
Denn das ist das, ich habe das, glaube ich, auch im ersten Teil schon mal angedeutet. Teilweise wundere ich mich,
wie aus meiner persönlichen Sicht, wie unagil manche agile Vorgehensweisen sind, weil sie nämlich,
genau sagen, wir organisieren alles so, wie wir es gelernt haben, wo es auf das Erfahrungswissen vom IT-Service-Management,
von bestehenden Strukturen nicht zugegangen wird, was nicht einbezogen wird. Und das finde ich einfach schade.
Und das versuche ich mit diesem Podcast, das versuche ich mit dem Workshop zu regeln und diese Leute zusammenzubringen.
Und wenn ich jetzt ganz an den Anfang zurückspringe, das Teil 1 dieser beiden Podcasts, da habe ich erläutert, wie es entstanden ist.
Einer meiner Kunden hat die Erfahrung gemacht, die DevOps-Teams haben gemerkt, wir müssen auf den Betrieb zugehen.
Der Betrieb hat mit Hinweis auf ITIL sich gesperrt und wir haben es dann geschafft, eben mit ITIL 4, mit der Öffnung von ITIL,
mit ITIL als einem agilen Service-Management-Framework, haben wir es geschafft, die eben an den Tisch zu bringen.
Und die internen Workshops, die ich gehalten habe bisher in 2019 und auch in 2020 und die offenen, die zeigen,
dass da Gesprächsbedarf ist.
Also, ich beende den Podcast mit dem Aufruf, Pragmatismus ist angesagt, sprechen miteinander.
Ich verlinke, wie gesagt, die beiden Artikel nochmal.
Ich verlinke die Workshop-Beschreibung und den einen oder anderen Link aus den Schulungsunterlagen würde ich auch noch in die Shownotes packen,
damit jeder, der bis hierher zugehört hat, auch belohnt wird.
Ich sage danke fürs Zuhören, freue mich auf den nächsten Podcast und bis dahin, tschüss.
Tschüss.