Wo ITIL und DevOps sich tatsächlich reiben
Beide beantworten verschiedene Fragen, und die Reibung entsteht fast immer an der eigenen Freigabestufe, nicht an einem Widerspruch zwischen den Denkweisen.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Konflikt ist meistens hausgemacht
Die Erzählung ist bekannt: hier das Team, das mehrmals täglich ausliefern könnte, dort der Ablauf, der eine Woche Vorlauf verlangt. Beide Seiten haben recht und streiten trotzdem über die falsche Sache. Der Vorlauf steht in keinem Rahmenwerk, er steht in einer internen Regel, die nach einem Ausfall beschlossen und seitdem nicht mehr angefasst wurde.
Solange der Streit auf dieser Ebene läuft, kostet er auf beiden Seiten. Die schnellen Teams bauen Umgehungen und dokumentieren nachträglich, die Steuerung verliert genau die Übersicht, für die sie eingerichtet wurde, und bei der nächsten Ursachenanalyse fehlen die Änderungen, die offiziell nie stattgefunden haben.
Der teuerste Teil ist die Personalfrage. Wer aus Entwicklung oder Betrieb kommt und den Eindruck gewinnt, dass Sorgfalt und Tempo sich ausschließen, entscheidet sich für eine Seite. Beide Entscheidungen kosten die Organisation Fähigkeiten, die sie in der jeweils anderen Rolle gebraucht hätte.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der direkte Vergleich
ITIL 4
ein Rahmenwerk für Wertschöpfung, Steuerung und Nachweis über den gesamten Service
DevOps
eine Arbeitsweise aus Entwicklung und Betrieb, die Durchlaufzeit und Rückmeldung in den Mittelpunkt stellt
| Entscheidungsfrage | ITIL 4 | DevOps |
|---|---|---|
| Wer verkürzt die Zeit von der Idee bis in den Betrieb? | Kommt darauf an Bietet mit Change-Modellen und Wertstromarbeit die Werkzeuge dafür, macht aber keine Vorgabe zur Automatisierung selbst. | Stärke Ist genau darauf ausgerichtet, von automatisiertem Testen über Auslieferung bis zur schnellen Rückmeldung aus dem Betrieb. |
| Wer beantwortet die Frage, wer eine Änderung freigegeben hat? | Stärke Change Record, Change Authority und Kalender sind für genau diesen Nachweis gebaut und über alle Teams hinweg gleich. | Kommt darauf an Der Nachweis entsteht nur, wenn die Pipeline ihn bewusst erzeugt. Wo das fehlt, bleibt am Ende ein Verlauf in einem Chatkanal. |
| Wer kümmert sich um Bestandssysteme, an denen niemand mehr entwickelt? | Stärke Betrieb, Support und Lieferantensteuerung sind unabhängig davon beschrieben, ob überhaupt noch entwickelt wird. | Schwäche Setzt ein Team voraus, das baut und betreibt. Fehlt die Entwicklungsseite, greifen die meisten Vorgehensweisen ins Leere. |
| Woher kommt die Sprache für die Zusammenarbeit mit Lieferanten? | Stärke Service Level Management, Lieferantensteuerung und Beziehungsmanagement liefern die Begriffe, die auch in Verträgen tragen. | Kommt darauf an Funktioniert stark innerhalb der eigenen Organisation, hat aber wenig anzubieten, sobald eine Vertragspartei außen sitzt. |
| Wer sorgt dafür, dass eine Verbesserung über Teamgrenzen hinaus wirkt? | Stärke Continual Improvement führt ein Register über alle Bereiche, damit auch die Themen aufgegriffen werden, die kein Team allein lösen kann. | Kommt darauf an Die Retrospektive wirkt zuverlässig im Team, endet aber meistens an dessen Grenze, weil ihr die Adresse für alles Weitere fehlt. |
Wer verkürzt die Zeit von der Idee bis in den Betrieb?
Bietet mit Change-Modellen und Wertstromarbeit die Werkzeuge dafür, macht aber keine Vorgabe zur Automatisierung selbst.
Ist genau darauf ausgerichtet, von automatisiertem Testen über Auslieferung bis zur schnellen Rückmeldung aus dem Betrieb.
Wer beantwortet die Frage, wer eine Änderung freigegeben hat?
Change Record, Change Authority und Kalender sind für genau diesen Nachweis gebaut und über alle Teams hinweg gleich.
Der Nachweis entsteht nur, wenn die Pipeline ihn bewusst erzeugt. Wo das fehlt, bleibt am Ende ein Verlauf in einem Chatkanal.
Wer kümmert sich um Bestandssysteme, an denen niemand mehr entwickelt?
Betrieb, Support und Lieferantensteuerung sind unabhängig davon beschrieben, ob überhaupt noch entwickelt wird.
Setzt ein Team voraus, das baut und betreibt. Fehlt die Entwicklungsseite, greifen die meisten Vorgehensweisen ins Leere.
Woher kommt die Sprache für die Zusammenarbeit mit Lieferanten?
Service Level Management, Lieferantensteuerung und Beziehungsmanagement liefern die Begriffe, die auch in Verträgen tragen.
Funktioniert stark innerhalb der eigenen Organisation, hat aber wenig anzubieten, sobald eine Vertragspartei außen sitzt.
Wer sorgt dafür, dass eine Verbesserung über Teamgrenzen hinaus wirkt?
Continual Improvement führt ein Register über alle Bereiche, damit auch die Themen aufgegriffen werden, die kein Team allein lösen kann.
Die Retrospektive wirkt zuverlässig im Team, endet aber meistens an dessen Grenze, weil ihr die Adresse für alles Weitere fehlt.
Was passt wann
- Wenn die Durchlaufzeit von der Idee bis in den Betrieb dein Engpass ist
- fang bei Wertströmen und Automatisierung an und hol dir aus ITIL nur das, was den Nachweis erzeugt.
- Wenn Prüfungen, Lieferanten oder regulierte Services im Spiel sind
- brauchst du die ITIL-Practices als gemeinsame Sprache, sonst entsteht der Nachweis am Ende von Hand und zu spät.
- Wenn dein Freigabeweg der Grund ist, warum Teams still ausliefern
- ändere die Change-Modelle und die Freigabestufen, nicht das Rahmenwerk.
Fünf Stellen, an denen beide Denkweisen ineinandergreifen
- 01 Wertströme zeigen beiden Seiten dieselben Wartezeiten.
- 02 Change-Modelle machen wiederholbare Auslieferungen freigabefrei.
- 03 Die Pipeline erzeugt den Nachweis, den die Prüfung später braucht.
- 04 Shift-Left holt Prüfung und Betriebswissen näher an die Entstehung.
- 05 Continual Improvement greift auf, was über Teamgrenzen hinausreicht.
Was du mitnimmst
Du kannst benennen, welche Frage in einer konkreten Auseinandersetzung eigentlich offen ist, und du weißt, an welchen Stellschrauben sich Tempo gewinnen lässt, ohne den Nachweis aufzugeben.
Den Engpass richtig verorten
Du unterscheidest, ob die Wartezeit aus einer Regel, aus einer Abhängigkeit oder aus fehlender Automatisierung kommt.
Modelle statt Ausnahmen
Du überführst wiederholbare Auslieferungen in vorab bewertete Change-Modelle, statt für jeden Durchlauf eine Einzelfreigabe zu erzeugen.
Nachweis automatisieren
Du lässt die Pipeline die Belege für Freigabe, Prüfung und Rückfalloption erzeugen, statt sie hinterher von Hand nachzutragen.
Wertströme gemeinsam lesen
Du misst Wartezeiten zwischen den Schritten statt der Auslastung einzelner Stationen und bekommst damit eine Sprache, die beide Seiten teilen.
Zwei Geschwindigkeiten zulassen
Du gibst Bestandssystemen und schnell gelieferten Produkten unterschiedliche Modelle, statt beide unter dieselbe Regel zu zwingen.
Die fünf Ziele abgleichen
Du prüfst, welches der fünf Ziele digitaler Produkte in deiner Organisation regelmäßig zugunsten eines anderen geopfert wird.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Bremsklotz sitzt selten im Rahmenwerk
ITIL 4 verlangt kein wöchentliches Gremium und keine Papierform. Der Standard Change ist ausdrücklich für wiederholbare Änderungen mit bekanntem Risiko gedacht und braucht keine Einzelfreigabe. Wer eine automatisierte Auslieferung hat, kann genau diese als Change-Modell hinterlegen und den Nachweis aus der Pipeline erzeugen lassen.
Was tatsächlich bremst, ist eine Umsetzung, die jede Änderung gleich behandelt. Das ist eine hausgemachte Entscheidung und lässt sich im Haus zurücknehmen. Der beste Hinweis darauf, dass genau das passiert ist, sind Teams, die Änderungen nachträglich eintragen, weil der reguläre Weg nicht in ihren Rhythmus passt.
Wo beide dasselbe meinen
Der Wertstrom ist der offensichtlichste Berührungspunkt. ITIL 4 baut die Service Value Chain darauf auf, DevOps kommt über Lean zum gleichen Bild, und beide fragen nach den Wartezeiten zwischen den Schritten statt nach der Auslastung der einzelnen Station.
Der zweite Punkt ist Verbesserung als Dauerbetrieb. Continual Improvement mit einem geführten Register und die Retrospektive im Team verfolgen dasselbe Ziel, arbeiten aber auf verschiedenen Flughöhen. Die Retrospektive wirkt im Team, das Register hält fest, was mehrere Teams betrifft und deshalb sonst niemand aufgreift.
Der dritte ist Shift-Left. Prüfungen, Wissen und Entscheidungen wandern nach vorn, näher an die Entstehung. In ITIL 4 taucht das in Create, Deliver and Support auf, in der DevOps-Welt als automatisiertes Testen und als Betriebswissen im Entwicklungsteam.
Was High Velocity IT hinzufügt
Das HVIT-Modul beschreibt fünf Ziele digitaler Produkte: wertvolle Investitionen, schnelle Entwicklung, widerstandsfähiger Betrieb, gemeinsam erzeugter Wert und gesicherte Konformität. Der Punkt daran ist die Gleichzeitigkeit. Geschwindigkeit ohne Widerstandsfähigkeit erzeugt Nacharbeit, Konformität ohne Geschwindigkeit erzeugt Umgehung.
Nützlich ist das Modul vor allem als Prüfraster für die eigene Organisation. Wer die fünf Ziele nebeneinanderlegt und ehrlich bewertet, findet meistens eines, das systematisch zugunsten eines anderen geopfert wird, und weiß danach, wo die eigentliche Diskussion zu führen ist.
Die Kulturfrage, die keiner von beiden löst
Wenn ein Team seinen Service selbst betreibt, wandert die Rufbereitschaft mit. Das trägt nur, wenn das Team groß genug ist und die Belastung anerkannt wird. In kleineren Organisationen entsteht daraus schnell eine Handvoll Personen, die dauerhaft erreichbar sind, und das hält niemand lange durch.
Die zweite Frage ist der Umgang mit Fehlern. Eine Nachbetrachtung ohne Schuldzuweisung und Problem Management verfolgen denselben Zweck, aber beide leben von einer Haltung, die kein Rahmenwerk verordnen kann. Wo aus einer Ursachenanalyse regelmäßig eine Personalfrage wird, hört die Ursachensuche auf, ganz gleich welches Vokabular verwendet wird.
Dazu passende Kurse
Die fünf Ziele digitaler Produkte und die Spannungen zwischen ihnen werden im Modul High Velocity IT durchgearbeitet, und wer dort einsteigen will, kann sich zuerst die Kurse zu High Velocity IT ansehen .
Wenn dich interessiert, wie die aktuelle ITIL-Generation Agilität einordnet , lohnt der Blick auf die neuere Modulreihe.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Katharina war eine super Dozentin mit sehr viel Wissen. Sie ist auf alle Fragen eingegangen und konnte alle klären.
Ein sehr anspruchsvolles Training welches von einer sehr kompetente Trainerin geleitet wurde.
Alles in allem bin ich sehr zufrieden, da der Trainer sich viel Mühe gegeben hat und alles sehr gut erklären konnte.
Häufige Fragen
Muss ein Team mit schnellen Lieferzyklen ITIL-Zertifizierungen haben?
Wie kommen automatisierte Deployments in den Change Record?
Was, wenn nur ein Teil der Landschaft schnell liefern kann?
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem ITIL & PRINCE2-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Tempo und Nachweis schließen sich nicht aus
Wie sich schnelle Lieferzyklen mit Steuerung und Nachweisführung verbinden lassen, spielt das Modul High Velocity IT an konkreten Fällen aus Organisationen durch.