Das führende ITSM-Framework ITIL® ist in einer neuen Version verfügbar und fokussiert nun stark auf Agilität. In diesem Podcast habe ich Martin Andenmatten zu Gast, der als ausgewiesener Experte für IT Service Management gilt und viele gute Veröffentlichungen für die Coomunity liefert. Wir sprechen unter anderem über die Neuerungen in ITIL4®, über die Beziehung von DevOps und ITIL® und wie diese beiden Ansätze IT-Organisationen in Zukunft gemeinsam unterstützen können.
In dieser Podcast-Episode diskutieren die Teilnehmer die Entwicklung und Integration von DevOps und ITIL 4, zwei zentrale Frameworks in der IT-Serviceverwaltung. Martin Andenmatten, ein Experte auf diesem Gebiet, beleuchtet die historische Trennung zwischen DevOps und ITIL und erklärt, wie ITIL 4 mit neuen Konzepten wie Service Value Chain und Guiding Principles reagiert hat. Der Fokus liegt auf der Verschmelzung agiler Prinzipien in ITIL und der Förderung einer effektiveren Zusammenarbeit zwischen Entwicklung, Betrieb und Geschäftsprozessen. Die Episode endet mit einem optimistischen Ausblick auf die zukünftige Koexistenz und Synergie von DevOps und ITIL 4.
Inhalt
- Einleitung und Vorstellung der Gäste
- Martin Andenmatten, Managing Director von Glenfis
- DevOps und ITIL: Historische Perspektiven und Trennung
- Diskussion der ursprünglichen Konflikte zwischen DevOps und ITIL
- ITIL 4 und seine neuen Konzepte
- Erklärung des Übergangs zu ITIL 4
- Vorstellung der Service Value Chain und Guiding Principles
- Integration agiler Prinzipien in ITIL 4
- Wie ITIL 4 agile Methoden aufnimmt
- Die Rolle von DevOps in der heutigen IT-Landschaft
- Diskussion über die anhaltende Relevanz und Entwicklung von DevOps
- Synergie und Koexistenz von DevOps und ITIL 4
- Diskussion über die zukünftige Zusammenarbeit von DevOps und ITIL
- Schlussfolgerungen und Ausblick
- Abschließende Gedanken zur zukünftigen Richtung von ITIL und DevOps
Shownotes
Hybride IT-Organisationen mit ITIL4 und DevOps
ITIL und DevOps im Zusammenspiel
Transkript (automatisiert erstellt, daher keine Gewähr 🙂 )
Herzlich willkommen zum Podcast DevOps auf die Ohren und ins Hirn.
Wir haben heute das Thema DevOps und ITIL, wieder Freunde.
Und zu diesem, denke ich, ziemlich interessanten Thema freue ich mich, einen sehr kompetenten Gesprächspartner an Bord zu haben, Martin Andenmatten.
Martin Andenmatten ist Managing Director der Firma Glenfis aus der Schweiz.
Und ich glaube, bevor ich jetzt Martin weiter vorstelle, denn da ist sehr viel zu erzählen, ist ein sehr kompetenter Gesprächspartner, würde ich sagen, Martin, stell du dich doch mal vor.
Ja, vielen Dank, Dirk, dass du mir hier die Gelegenheit gibst.
Ja, ich bin ja schon eine Weile unterwegs mit verschiedensten Themen im Bereich Organisationsentwicklung.
Wie du gesagt hast, bin ich Geschäftsführer der Firma Glenfis.
Das ist ein Unternehmen, das ich vor 20 Jahren gegründet habe.
Ja, tatsächlich vor 20 Jahren.
Das ist auch so der Anfang gewesen, als das Thema ITIL großgekommen ist.
Und ja, ich habe hier ein Unternehmen mit 15 Mitarbeitern.
Wir haben spannende Beispiele.
Wir haben spannende Projekte.
Wir arbeiten mit Menschen und wir teilen die Erfahrungen und sind trotz all diesen 20 Jahren immer wieder überrascht, was wir für tolle neue Herausforderungen anpacken können.
Ja, und heute ist ja ein spannendes Thema auf dem Tablett und da bin ich gerne bereit, da mal meine Einschätzung zu geben.
Ja, was ich so interessant finde, ist, dass du eben natürlich die ITIL-Kennzüge hast oder das ITIL-Know-how aus.
Ja, 20 Jahre an der Stelle, aber dass du ja auch in vielen anderen Themen unterwegs bist.
Also du bist in dem Thema Agilität unterwegs.
Du kennst dich auch sehr gut aus dem Thema COVID.
Also wie kann ich IT mit Governance verbinden?
Also ich glaube, dass du da, wenn du da sagst, du bist eine Weile unterwegs.
Diese Weile ist ja schon relativ lang, was du ja selber gesagt hast.
Und dadurch bringst du auch natürlich sehr viel Kompetenz, sehr viel Erfahrung mit.
Und ja, da freue ich mich auf unser Thema.
DevOption ITIL, wieder Freunde.
Die Hörer meines Podcasts werden ja wissen, ich stelle immer den Gästen die Frage, was ist DevOps für dich?
Kannst du DevOps definieren?
Kannst du DevOps beschreiben?
Also Martin, wie würdest du denn DevOps definieren oder beschreiben?
Ja, das ist immer die spannende Frage.
Ich höre ja deine Podcasts immer wieder gerne und es ist auch spannend, wie da auch immer unterschiedliche Definitionen herauskommen.
Für mich ist es klar, es ist eine Bewegung.
Es ist vor allem eben auch eine kulturelle Bewegung, die auf eine bessere Zusammenarbeit ausgerichtet ist.
Insbesondere eben auch angestoßen aus der Softwareentwicklung.
Dort ist die ganze agile Mindset, denke ich, schon eine Weile länger präsent gewesen.
Und man hat damit eigentlich mal diese Bastion Operation, diese Mauer da durchbrochen.
Und ich sehe vor allem eben darin diese Bewegung.
Dieser Mindset der agilen Zusammenarbeit, der besseren Zusammenarbeit im Vordergrund.
Ich sehe weniger im Fokus jetzt die Technologie, dieses Automatisieren, das natürlich auch irgendwo ein Bestandteil ist.
Aber die große Bewegung, die man dann ausgelöst hat, eben, dass man da endlich mal über den Graben schaut,
das ist für mich eigentlich die große Errungenschaft von DevOps.
Okay, das finde ich interessant, weil ich hatte über das Thema Bewegung, über den Begriff Bewegung, noch nie drüber nachgedacht.
Der tauchte noch nie so in meiner Sichtweise auf.
Aber natürlich, es ist eine Bewegung.
Es ist eine Bewegung von Leuten, die einfach sagen, wir möchten zusammenarbeiten oder wir sollten zusammenarbeiten.
Und wir heißt dann eben die verschiedenen Bereiche, Dev und Ops oder auch vielleicht noch ein paar mehr Bereiche.
Ja, ich glaube eben, es ist ja auch ein bisschen eine Befreiung gewesen.
Ich denke, Operation hat sich da ein bisschen eingelegt.
Die Mauern hochgezogen und irgendwie ist man angestanden, mit dem Druck hier noch mehr Tempo hineinzubekommen, Veränderungen anzustoßen.
Und mit dieser Bewegung, sage ich jetzt trotzdem nochmal, DevOps hat man eigentlich da einen Stein ins Rollen gebracht, hat die Türen geöffnet.
Und das hat auch eine gewisse Befreiung vielleicht gebracht in Organisationen.
Ja, das finde ich, das klingt gut.
Das ist ja auch für mich interessant.
Wenn ich jetzt auf den Titel vom Podcast gehe, Dev, Ops und ITIL wieder Freunde?
Fragezeichen.
Das suggeriert ja, dass sie mal nicht Freunde waren oder überhaupt noch nie Freunde waren.
Würdest du das auch so sehen?
Ja, eben. Ich personifiziere jetzt so Methoden und Frameworks nicht wirklich.
Das ist letztendlich projiziert man vielleicht gewisse,
Verhaltensweisen oder sucht dann irgendwo Feindbilder oder Gründe, wieso gewisse Sachen nicht laufen.
Aber es stimmt natürlich schon ein bisschen, dass das ganze ITIL Framework, so wie es auch in vielen Organisationen eben umgesetzt worden ist,
eben als der Grund für diese eher starren, eher bürokratischen Prozesse angeschaut worden sind und damit eigentlich auch die Ursache,
wieso das insbesondere natürlich Operation vielleicht sich da nicht so bewegt hat.
Und was man natürlich dann hauptsächlich als Begründungen gehört hat, wieso das jetzt endlich Dev Ops da zum Zuge kommt,
war dann, weil alles, was man vorher gehabt hat und da ist natürlich ITIL als, sage ich mal, zentrales Framework,
das praktisch in jeden Organisationen vorhanden gewesen ist, ist dann die,
ja, ideale Zielscheibe wahrscheinlich gewesen, für dort alles mal abzuladen, was nicht gut läuft.
Und was man ja so gehört hat, ITIL ist ein Loch, das ist viel zu prozesslastig,
dass mit diesen vielen Prozessen, die da sind, das kann ja unmöglich funktionieren,
sind viel zu theoretisch und natürlich jetzt mit diesen Phasen, die ja da das Lifecycle dargestellt hat,
mit Strategie, Design, Transition, Operation, das ist das Tönt nach Wasserfall
und das ist überhaupt nicht mehr geeignet für diese eher eben auf agilen Methoden ausgerichteten Arbeitsweisen.
Und daher hat ITIL, und das muss man ja auch sagen, ITIL hat dort auch keine entsprechende Antwort gehabt bis jetzt
und hat das einfach so mal schlucken müssen.
Und ich meine, ich habe ja am Anfang auch gesagt,
ich kenne das Framework schon seit dem Anfang an, seit der Version 1
und es war ja nie die Absicht von diesem Best-Practice-Framework,
irgendwie eine Bürokratie aufzubauen oder starre Verhaltensweisen in Organisationen zu etablieren.
Man hat eigentlich ein Framework bereitgestellt mit der Idee,
schau,
das sind so diese Best-Practices als Guidelines, adoptiert die und passt die an für eure Organisationen.
Und was die Organisationen gemacht haben, die haben das dann zwar übernommen,
aber haben es nicht angepasst an die Organisation und praktisch dann eins zu eins diese Themen da versucht umzusetzen.
Das war sicher ein großes Problem.
Auf der anderen Seite, das muss ITIL aus heutiger Sicht sicher auch sagen,
die Prozesse, die sind dann so detailliert.
Die sind dann so beschrieben worden, dass man sich überhaupt nicht mehr Gedanken gemacht hat,
dass das Ganze eben irgendwie zusammen funktionieren muss.
Man hat dann eben wirklich aus diesen Funktions-Silos, die man vielleicht gekommen ist,
hat man dann Prozess-Silos aufgebaut und jeder hat sich hinter die Prozesse versteckt.
Das ist sicher das, was ITIL, ich denke, nicht in der ursprünglichen Idee gehabt hat,
aber was natürlich draus geworden ist.
Ja, na gut, ich meine, es ist ja so, wenn ich mir das anschaue,
ITIL oder ITIL sind ja erstmal nur Bücher.
Also insofern, man kann ja den Büchern nicht vorwerfen,
dass sie das Ziel hatten, etwas zu bürokratisieren.
Es sind immer noch die Menschen, die irgendetwas daraus gemacht haben an der Stelle.
Und was ich auch immer sehe, ist,
ich war ja eine Zeit lang auch ziemlich kritisch gegenüber ITIL,
muss aber jetzt sagen, man muss auch mal ein bisschen Abstand gewinnen
und man darf nicht außer Acht lassen.
Es gab mal Zeiten oder Phasen, ITIL ist ja schon ein bisschen älter,
wo es absolut Sinn gemacht hat, mit dieser Art Denkweise
ein bisschen mehr Professionalität und Standardisierung
in die Unternehmen reinzubringen.
Ja, ich denke, das hat ja gefehlt.
Man hat irgendwie zu wenig Struktur gehabt,
insbesondere wo man das ganze Thema immer wieder projiziert,
ist der IT-Operation-Bereich.
ITIL hat ja von der Idee her natürlich auch vielen grösseren Scope,
aber dort insbesondere im Betrieb,
dort hat man eigentlich nicht wirklich gesehen,
was man da wirklich an Mehrwert leistet,
ausser dass man schaut, dass die Infrastruktur schön warm läuft
und dass die Systeme immer hochgefahren sind.
Und dass da ein Mehrwert fürs Unternehmen daraus entsteht,
nur damit man schaut,
die Lampen leuchten, das ist zum Teil in vielen Organisationen
auch heute noch nicht wirklich sichtbar.
Und mit ITIL hat man zumindest den Tätigkeiten
und diesen Aufgaben einen Namen gegeben.
Man konnte es auch strukturieren und man konnte den Leuten,
die dort auch wirklich einen tollen Job machen wollten
und auch gemacht haben, konnte man auch eine Perspektive geben,
wie sie sich entdecken.
Ich denke, das ist sicher auch ein großes Vermächtnis,
dass man ITIL und den Leuten, die dahinter stecken,
immer noch stecken, zugutehalten muss.
Ja, klar.
Jetzt hast du eben schon angedeutet,
dass sich bei ITIL ein bisschen was verändert hat.
Wir reden ja heute auch über die Version ITIL 4,
wobei ich gehört habe, das soll nicht Version 4 heißen,
sondern nur ITIL 4.
Also egal, wie das heißt, es gibt eine neue Version,
eine Veränderung bei ITIL.
Und das geht auch in Richtung Agilität.
Kannst du da mal vielleicht ganz kurz oder auch ein bisschen länger
was zu erklären?
Ja, vielleicht das mit dem Klären mit dem V4.
Es ist in der Tat so, das V kommt nicht in Erscheinung.
Man sagt ITIL 4.
Die 4 hat verschiedene Bedeutungen.
Einerseits ist es klar, die neue Version.
Auf der anderen Seite soll es auch die vierte Revolution
oder die in der Art, die wir jetzt haben,
von der Digitalisierung, wo wir jetzt gerade drinstecken,
dass das auch ein Basisrahmenwerk ist.
Und ja, es hat sich ja einiges aufgestaut.
Wir haben es ja gesehen.
Der ITIL hat keine Antworten gehabt auf die neuen Herausforderungen,
auf die neuen Arbeitsweisen und insbesondere auch auf die Agilität hin
hat sich dort einiges aufgestaut, dass man jetzt den angepackt hat.
Und ja, es ist natürlich,
sehr viel hat sich da geändert.
Also, was man vielleicht von ITIL V3 oder der Edition 2011 her kennt,
das war ja schon, wo man das dazu mal eingeführt hat,
auch ein großer Schritt.
Man hat ja diesen Service Lifecycle ins Leben geworfen,
weil man ja dann auch wirklich den Service in den ganzen Lebensphasen
da kennen und steuern und auch entwickeln wollte.
Dieser Lifecycle ist in der Form eigentlich nicht mehr vorhanden.
Man hat jetzt eigentlich angedockt an die anderen Frameworks,
insbesondere auch aus dem Lean Umfeld hat man diesen Value Chain oder
dieses Service Value System hochgezogen, weil ja, man hat,
ich sage das immer gerne so, man hat von der Version 3 mit dem Fokus
auf den Service teilweise ein bisschen,
die Schwierigkeiten gehabt, den Mehrwert für das Business hervorzuheben.
Und in der neuen Version ITIL 4 ist der Fokus jetzt nicht mehr der Service alleine,
sondern insbesondere der Fokus liegt auf dem Mehrwert,
auf dem Value für das Business.
Und die Leute, die sollen immer wieder vor Augen haben,
was ist letztendlich der Mehrwert?
Wieso machen wir überhaupt gewisse Dinge?
Und dieses Ausrichten auf diesen Value,
äh,
hat dann eigentlich den Rahmen gegeben für dieses Service Value System.
Und insbesondere spannend hier drin ist,
dass man ähnlich wie vielleicht in diesem agilen Manifest,
hat man auch hier jetzt sogenannte Guiding Principles definiert,
so Leitprinzipien, nach denen man eigentlich die grundsätzliche Denkhaltung
ausrichten sollte oder auch die Wertvorstellungen ausrichten sollte.
Und weiß nicht, vielleicht kennt man noch den ITIL Practitioner.
Das war ja so ein Zwischending,
der mal auch mit sehr viel Aufwand erstellt wurde,
aber im Markt nicht wirklich großen Anklang gefunden hat.
Aber dort drin waren wirklich sehr, sehr gute Ansätze schon enthalten,
wie man eben auch auf die heutigen Anforderungen rausgeht.
Und diese Guiding Principles, das sind eigentlich Kern,
Prinzipien, die man da auch aus diesem Practitioner jetzt herausgenommen hat
und hier eigentlich zur Grundlage gelegt hat.
Lass mich mal ganz kurz einhaken.
Ich habe ja gesagt, es wird auch vielleicht ein bisschen mehr,
was du zu erzählen hast, weil es ja eine relativ große Veränderung ist.
Was ich aber nochmal nachfragen wollte, was für mich der Eindruck ist,
es gibt ja ITIL jetzt nicht mehr in den vier Bänden mit einem kompletten Werk
und darauf entwickle ich, und das ist einmal durchdekliniert,
darauf setze ich die Schulungen auf, sondern man hat quasi jetzt pro Schulungszyklus
oder pro Schulungsinhalt entwickelt man Bücher.
Also man geht, wenn man so will, auch agil vor.
In kleineren Schritten entwickelt man das große Ganze.
Ist das ein richtiger Eindruck?
Ja, das ist eigentlich ein richtiger Eindruck.
Ich bin auch ein bisschen skeptisch gewesen oder kritisch,
dass man jetzt die Detaillierung eigentlich anhand von der Ausbildung ausrichtet
und nicht umgekehrt.
Aber die Idee ist schon, dass mit diesem Foundation,
das ist ja das erste Buch, das da ist,
also es wird dann über das ganze Jahr werden,
da mindestens noch vier oder fünf Bücher kommen,
hat man jetzt eigentlich die Grundlage gebaut
oder eigentlich auch die Übersicht geschaffen,
um das ganze System mal von einer Vogelperspektive anzuschauen.
Ich denke, das ist ein großer Vorteil gegenüber vielleicht den anderen Büchern,
die da nach diesen Lifecycle-Phasen orientiert sind.
Man hat eigentlich immer nur eine bestimmte Optik eingenommen
und es war dann sehr viel Sekundärliteratur auf dem Markt,
die mehr oder weniger gut geschrieben sind,
die dann das ganze Bild eigentlich gebaut haben.
Und hier mit dem Foundation hat man jetzt so eine Grundlage erarbeitet
und man sieht schon relativ gut, wie das Ganze letztendlich dann auch aufgebaut ist.
Also insbesondere dieses Value System mit diesem Value Stream,
das Konzept, das kommt hier sehr gut herüber.
Also für mich würde es auch heißen, wenn ich mir das vorstelle,
wenn ich jetzt in ITIL einsteigen möchte,
dann hätte ich ja früher eigentlich, wenn ich keine Schulung besuchen will,
mir diese fünf Bücher durchlesen müssen,
weil es ja gut, es gab zwar ein paar Originalzusammenfassungen,
aber es gab eben quasi von der Originärliteratur nur diese fünf Bücher
und das kann ich jetzt anders machen.
Jetzt lese ich mir dieses Buch Foundation durch
und habe dann einen Überblick, was hinter ITIL 4 steckt
und kann dann tiefer einsteigen in die weiteren Bücher, die noch kommen werden.
Ja, so in der Art.
Aber es ist vielleicht auch noch ein ganz anderer Ansatz, den man hier fährt,
was genau in den neuen Büchern, in den noch zu erwartenden Büchern drinsteckt.
Das ist schwierig jetzt hier schon abzuzeichnen,
aber man hat den Vorwurf, dass die Bücher zu umfangreich gewesen sind,
dass die Beschreibungen so detailliert gewesen sind,
also diese praktisch vorschreibende Darstellung, wie man Prozesse dann zu bauen hat,
von dem ist man grundsätzlich weggekommen.
Man hat diesen Vorwurf dann auch ernst genommen
und hat jetzt die Prozesse gar nicht mehr als Prozesse beschrieben,
sondern man hat alle bekannten Prozesse und Funktionen, die in ITIL 3 dagewesen sind,
die hat man jetzt eigentlich als Prozesse beschrieben.
die hat man jetzt eigentlich als Prozesse beschrieben,
die hat man jetzt eigentlich als Praktiken dargestellt.
Und Praktiken sind ein bisschen allgemeiner gehalten hinsichtlich,
was jetzt Prozessinhalte sind,
sondern es ist dann auch vor allem eben auch noch der Link
zu den anderen Ressourcen, die notwendig sind, sind da abgebildet.
Man hat eben dann als Organisation, die sowas dann eben adaptieren will,
viel mehr Spielraum.
Es ist gar nicht so viel Material vorhanden, um zu definieren,
wie was gebaut ist, Priorisierung heisst einfach,
Heißt einfach, es muss priorisiert werden, aber wie man das jetzt macht, das ist dann der Organisation überlassen.
Daher ist dann meine Empfehlung, es gibt dann immer noch Leute, die dann plötzlich anstehen und nicht genau wissen, wie man sowas machen könnte,
dass man jetzt die alten Bücher, die V3-Bücher nicht gleich wegschmeißt.
Vielleicht kann es dann helfen, dass man zwischendurch wieder mal zurückgreift auf das V3-Buch und geht dort mal reinschauen und sich eine Vorstellung holt.
Wie das dann nun konkret aussehen könnte.
Aber das Aktuelle, das ist wirklich sehr schlank gehalten.
Man hat eine ganz einfachere Übersicht, wie so Dinge zusammenhängen.
Okay, das heißt, wenn ich jetzt kurz zusammenfasse von den Änderungen von ITIL 4.
Die erste große Änderung ist, es gibt keine Service-Lebenszyklen mehr oder Lebenszyklusphasen.
Es gibt dafür jetzt eine Value Chain, eine Service-Value Chain.
Wir haben ähnlich wie beim ITIL 4.
In einem agilen Manifest, in einer agilen Umgebung haben wir eben Guiding Principles.
Also etwas so eine Art, wie der Name schon sagt, leitende Prinzipien.
Und wir haben, wenn man so will, keine Prozesse mehr, keine Funktionen, sondern nur noch Praktiken, die beschrieben werden.
Richtig?
Das ist richtig, was aus dem Inhalt vom ITIL her kommt.
Das heißt ja nicht, dass es dann keine Prozesse mehr braucht.
Die Prozesse, die muss man natürlich dann in Organisationen bei der Umsetzung schon bauen.
Aber die Idee ist jetzt wirklich, dass man nicht jetzt einfach silomäßig die Prozesse oder eben die Praktiken umsetzt als wieder eigenständige Entitäten,
sondern man baut jetzt, und da ist vielleicht auch ein bisschen diese Anlehnung an die DevOps-Gedanke,
man baut jetzt eben Value Streams, die sich dann eben zusammensetzen aus den verschiedenen Praktiken, die man dann braucht.
Also es ist nicht die Idee, dass man jetzt einen Value Streams,
einen Value Stream hat aus einer Praktik heraus, sondern ein Value Stream besteht dann vielleicht aus verschiedensten Praktiken,
die dann angezogen werden, wenn sie entsprechend dann auch zum Zuge kommen.
Und das gibt eine grössere Flexibilität, es gibt auch mehr Modularität und vor allem hilft es eben den Organisationen,
hier auch ein bisschen zurückzugreifen an Inhalten, was man dann allenfalls berücksichtigen sollte.
Das ist vielleicht sicher einer der grossen Vorteile.
Ja, okay. Was gibt es noch an grossartigen oder nennenswerten Veränderungen?
Ja, eben, es ist natürlich sehr viel im Detail drin.
Also wichtig eben sind schon diese Guiding-Prinzips, also diesen Fokus auf den Mehrwert zu legen,
dort anfangen, wo man auch heute steht, iterativ vorwärts gehen, Feedback geben, Sichtbarkeit erhöhen,
all diese Themen, die lehnen sich stark eigentlich auch an diesem agilen Mindset an.
Ja, was gibt es?
Was gibt es sonst noch? Also ein Thema ist eben auch diese ganze Wertschöpfungsthematik.
Man hat, das ist immer einer der grossen Vorwürfe, die man an die IT-Organisationen hat.
Die IT hat immer das Gefühl, sie wisse dann, was jetzt der Service und was der Mehrwert für das Business darstellt.
Aber letztlich kann man den Mehrwert nicht ohne das Business bestimmen.
Und so ist ein Grundkonzept vom neuen ITIL 4 dieses Value Co-Creation.
Also man kann den Mehrwert nicht ohne das Business bestimmen.
Also man kann den Mehrwert nicht ohne das Business bestimmen.
Man erarbeitet den Mehrwert eben gemeinsam zusammen mit den Stakeholdern,
mit dem Business, mit den irgendwelchen, weiß nicht, auch Partnern, mit Legal.
Also es ist nie eigentlich ein Ergebnis, das man aus der IT-Organisation herausgibt
und so, hier hast du jetzt und hoffentlich kriegst du Value,
sondern es ist eigentlich, der Mehrwert wird eigentlich geshared.
Also es ist eine…
Eine Co-Ownership of the Value.
Und das heißt, man hat viel mehr Skin, letztlich viel mehr Haut eigentlich auch auf der Business-Seite drin,
um sicherzustellen, dass es tatsächlich das ist, was das Business braucht.
Wenn ich das richtig verstehe, das Business wird quasi mit in die Verantwortung genommen,
in Mitwirkungspflicht, den Business zu beschreiben und zu bestimmen.
Auf jeden Fall.
Also beschreiben, ich denke, wichtig ist, dass man wirklich,
dass man wirklich genau herausspürt, wie das Business diesen Service braucht.
Und das ist auch noch der zweite Grundgedanke, den man jetzt hier damit eingebaut hat,
neben dem Co-Creation, ist auch dieses ganze Service-Relationship,
dass die Unternehmen, also die IT-Organisation, sei das interne oder externe,
erhöht letztendlich die Capabilities vom Kunden, der natürlich diesen Service aufnimmt.
Also mit dem…
Mit dem kann der Kunde sein Business dann wiederum optimaler gestalten.
Und letztendlich wird er natürlich dann vom Business aus gesehen den Service, den er seinen Kunden gibt,
auch wiederum ihm gegenüber helfen, dem Endkunden seinen Service, seine Capabilities zu erhöhen.
Also es ist eigentlich so eine Art, eine Kettenreaktion, dass man dann eigentlich damit erreicht,
wenn die Mehrwerte…
optimal austariert sind, dass eben auch die Endkunden und vielleicht auch die Kunden der Endkunden
entsprechend dann auch einen Mehrwert haben.
Dieses über den Tellerrand schauen, nicht nur, was gefällt jetzt meinem Kunden,
sondern auch verstehen, wie das Produkt oder der Service, den man gegenüber dem Endkunden liefert,
wie das dann dem Endkunden auch wirklich was verbessert.
Ja, okay. Wenn ich mir diese Veränderungen mal anschaue, dann stellt sich mir,
die Frage, ist denn ITIL 4 überhaupt noch ITIL?
Also hat sich da nicht ITIL so komplett verändert, dass man von einem neuen ITIL sprechen kann?
Man kann sicher von einem neuen ITIL sprechen, das kann man auf jeden Fall.
Also wenn man das natürlich so liest, hat man komplett neue Konzepte, neue Ideen dabei.
Aber der Grundgedanke vom Service Management, der ist nach wie vor da.
Man will natürlich…
Services so produzieren oder so bereitstellen, dass es dem Kunden einen maximalen Mehrwert gibt.
Das war schon immer die Ursprungsidee.
Und die Methodiken, wie man das erreicht mit den Veränderungen, die…
Und das ist ja nicht der Anspruch, den ITIL hat, den auch eigentlich kein Framework hat,
für sich zu definieren, alles zu wissen oder alles zu definieren, wie man gute Services baut,
sondern dass man das auch einfließen lässt, wie jetzt gerade die ganzen agilen Bewegungen,
dass man das eben nutzt, diese Gedanken dann auch weiterzuentwickeln.
Und von daher ist es bestimmt neu, aber es hat natürlich sehr viel Wiedererkennungswert.
Eben schon allein von den Praktiken, die im ersten Moment vielleicht genau gleich heissen,
wie sie früher mit den Prozessen geheissen haben.
Aber das sind Sachen, die immer wieder auf die bestehende oder auf die alte ITIL-Version zurückblicken.
Jetzt hast du ja ganz viel berichtet davon, was sich an ITIL verändert hat oder mit ITIL 4 verändert hat.
Was hat sich denn nicht verändert, außer dass die Prozesse und Funktionen jetzt quasi nur anders heißen?
Also wo ist sich ITIL quasi treu geblieben und wo können auch die, die sich mit dem alten ITIL auskannten oder auskennen
und die es auch gut finden, die es genutzt haben, wo finden die sich denn am ehesten wieder?
Also wo hat ITIL auch wichtige Dinge beibehalten?
Also eben, was ja sicher…
Wenn man mal bleibt, ist der Name. Das ist mal das Einfachste.
Das ITIL ist sicher noch das Gleiche.
Ich denke auch, wie es auch alles jetzt so beschrieben ist.
Ich denke, dieses Streben nach eben besserer Zusammenarbeit mit dem Business,
diese Einstellung, die es da braucht, diese Serviceorientierung,
diese Fokussierung eben auch auf das Wesentliche, das ist gleich, ist eigentlich immer noch…
Genau gleich da.
Es hat natürlich sehr viele neue Definitionen dabei.
Die Definition von, was ist ein Service, was ist Value, hat man leicht adaptiert,
aber das ist auch noch ziemlich ähnlich, wie es früher gestanden hat.
So, jetzt haben wir ja den Titel DevOption ITIL wieder Freunde.
Und wir hatten ja zu Anfang gesagt, dass es schon so ist,
dass sich durch ITIL in einer vielleicht auch falschen Anwendung Bürokratie herausgebracht,
gebaut hat, Silo-Denken herausgebaut hat.
Das hat dazu geführt, dass sich Firmen und Unternehmen zu anderen Konzepten hingewendet haben,
eben unter anderem DevOps, aber auch nicht alleine.
Wie würdest du das einschätzen?
Würde man heutzutage, wenn man quasi bei Null anfängt, wenn man einsteigt,
würde man dann sagen, okay, ITIL 4 reicht als Framework aus oder auch als Einstieg aus,
um sich den aktuellen Problemen zu widmen?
Also braucht man dann DevOps überhaupt noch, diese Bewegung, von der du vorhin gesprochen hast?
Ja, ich glaube, DevOps ist sicher ein mustergültiger Value-Stream,
den man jetzt eigentlich im Vorfeld, eben jetzt schon ein paar Jahre,
bevor es die neue Version da ist, eigentlich aktiv auch gelebt hat
und auch gesehen hat, was das für Effekte hat.
Eben, man hat natürlich im Zusammenhang mit DevOps sehr viele Mythen hochgezogen,
dass jetzt DevOps ist dann gleich NoOps, das heißt, man braucht eigentlich gar keine Operation mehr,
weil alles automatisiert ist, es läuft alles und in der Entwicklung wird dann auch alles wieder gefixt
und gelöst, damit es läuft.
Das ist wirklich ein Mythos.
Es gibt sehr viele Aktivitäten, die in welcher Konstellation auch immer,
ob das jetzt eine DevOps-Konstellation ist oder noch eine klassische,
die werden nach wie vor auch in Zukunft gebraucht werden.
Ich glaube sehr daran, dass diese DevOps-Bewegung wirklich was verändert hat,
dass diese Graben zwischen Entwicklung und Betrieb da zu einem großen Teil zugeschüttet hat werden können.
Aber wegen dem werden diese Aktivitäten und diese Praktiken, die man dann auch braucht,
rundherum um diesen, sage ich mal, Entwicklung, Test, Release, Deployment-Stream,
werden nach wie vor gebraucht.
Das wird notwendig sein.
Und man kann das im Prinzip eigentlich in diesem gleichen Mindset,
kann man so Value-Streams dann auch ausweiten auf andere Themen.
Und da kann E-Till, kann dazu ein guter Fundus sein.
Ich denke, dass sich das dort wirklich ergänzt.
Weil eine große Errungenschaft, die DevOps wirklich hat,
ist diesen Graben zwischen Entwicklung und Operation zuzukippen.
Es gibt aber noch andere Gräben, auch noch in der Organisation.
Und der größte ist ja immer noch zwischen Business und IT.
Den hinzubekommen.
Ja, okay.
Aber ich habe dich so verstanden.
Also erst mal den Graben zwischen Business und IT.
Da ist E-Till, denke ich, oder deiner Aussage nach,
das würde ich unterschreiben, in der neuen Version,
ein guter Einstieg oder bietet gute Hinweise.
Gerade auch mit der Idee Co-Creation oder Value Co-Creation.
Richtig?
Ja, das war ja immer schon die Absicht.
Ich bin auch nicht naiv zu glauben, dass jetzt dann alle Probleme in Zukunft gelöst sind.
Diese Absicht.
Solche Sachen in den Griff zu bekommen und besseres Verständnis zu bekommen,
das wird auch mit der Version 4 noch die eine oder andere Hürde nehmen.
Genau gleich, wie ich überzeugt bin und jetzt mittlerweile auch in verschiedenen Orten feststelle,
dass mit dem Grundgedanken von DevOps alleine diese Zusammenarbeit auch nicht überall
wirklich so harmoniert, wie man sich das eben gerne vorstellt.
Also die Probleme liegen nicht in der…
Denn Frameworks, die liegen nach wie vor eigentlich in der Kultur,
insbesondere auch im Leadership, im Vorleben, in den Verhaltensweisen, in der Organisation.
Und daran müsste man eigentlich arbeiten.
Und dann sind die Frameworks dann Unterstützungshilfen.
Also das Framework alleine wird es nicht schaffen.
Das bin ich überzeugt.
Wenn ich jetzt mal aus meiner DevOps-Sicht heraus die Idee hätte zu sagen,
okay, jetzt gibt es eine neue ITIL-Version, die scheint agiler zu sein,
oder ist agiler, hat auch das als Überschrift für sich ja auch gewählt.
Könnte man also im Prinzip ITIL 4 nutzen, um auch den Betrieb einfach mal in die Richtung zu bringen
und sagen so, Mensch, ITIL 4 ist jetzt agil, ganz plattformuliert, jetzt müsst ihr es auch werden.
Also bietet der ITIL 4 eine gute Möglichkeit, auch agile Gedanken,
agiles Gedankengut in den Betrieb reinzubringen, quasi über den Umweg-Framework?
Ja, also das Wichtigste…
Das Wichtigste ist wirklich, sage ich mal, diese Leitprinzipien.
Diese sieben Leitprinzipien, die gehören groß geplottet, ausgedruckt in jedes Betriebsbüro rein,
in jede Entscheidungsfindung herangezogen, bei jedem Design mit überlegt,
wenn es darum geht, was zu bauen.
Also es ist diese Grundhaltung, die muss man irgendwie den Leuten vermitteln können.
Okay.
Und mit dem Lesen vom Buch alleine ist es ja wahrscheinlich nicht getan.
Die Ausbildung wird hoffentlich in Zukunft mehr darauf Wert legen, solche Werte in den Fokus zu bringen,
also dass man die Leute natürlich schult, aber die Schulung alleine macht die kulturelle Veränderung nicht statt.
Letztlich muss es ein klarer Wille sein von jeder Organisation, von einer IT-Organisation,
wie positionieren wir uns in der Organisation, welche Werte vertreten wir?
Und dann gibt es nicht Werte für die Entwicklung oder Werte für den Betrieb,
sondern es sind allgemeine Werte, die hoffentlich abgestimmt sind mit den Werten des Gesamtunternehmens.
Und hier, das neue ITIL hat hier konkrete Inhalte jetzt mal so formuliert,
die kann man übernehmen und die kann man auch an die eigene Wortwahl dann noch anpassen.
Aber von daher ist sicher dort mal der Samen gesät,
dass es so etwas geschehen kann.
Also ich finde das interessant, ich musste eben ein bisschen schmunzeln.
Erst du sagtest, die Guiding Principles ausdrucken und an die Wand hängen,
dann könnte man sie wahrscheinlich neben das Agile Manifest hängen,
was ja auch an vielen Wänden hängt in den Büros.
Und wenn da noch Platz ist, kann man die so nebeneinander hinhängen
und dann wird man feststellen, dass das eben allein nicht ausreicht.
Das hast du ja auch gesagt.
Das heißt, auch bei agilen Teams, wo ich unterwegs bin, da hängt es auch an der Wand.
Vielleicht nicht mal das Agile Manifest.
Aber doch zumindestens auch mal so gewisse Prinzipien von Scrum,
die Scrum-Werte zum Beispiel.
Und trotzdem wird es noch nicht gelebt.
Und das reicht ja auch nicht, die Schulung zu besuchen.
Es reicht auch nicht, das Poster aufzuhängen.
Aber es ist ja vielleicht mal ein erster Schritt, auch zu sagen,
so, das sind jetzt unsere Leitlinien, weil das ist das,
was ich versuche in meinen Scrum-Schulungen immer rüberzubringen.
Ich lege Wert drauf, das Agile Manifest zu erklären,
die agilen Prinzipien zu erklären, die Scrum-Werte zu erklären,
weil das natürlich auch…
Das ist das, was ich mache.
Die Unklarheit nachher über Prozesse oder Aktivitäten immer hilft.
Also man kann immer wieder gucken,
aha, wir haben jetzt die und die Frage, linksrum oder rechtsrum,
dann lass uns doch mal das Agile Manifest anschauen
oder die agilen Prinzipien.
Was würden wir denn mit seiner übergeordneten Sicht
auf diese Frage antworten?
Okay, da gehen wir eben mal den Weg linksrum.
Also diese Guiding Principles, glaube ich, ist dann auch was Neues.
Gab es so etwas vorher noch nie in ITIL?
Eben.
Diese Guiding Principles,
die sind ja vor allem eben jetzt ein bisschen abgeleitet
und ein bisschen gestrafft worden aus dem ITIL Practitioner.
Das ist ja das Buch, das so zwischen, sage ich mal,
ITIL 4 und ITIL 3 herausgekommen ist.
Und dort haben sehr viele, sehr viele Bekannte
und auch hochgeschätzte Autoren haben dort wirklich jetzt auch versucht,
all diese Sachen, die man eben vermisst hat
oder die zu wenig klar zum Ausdruck gekommen sind,
hier dort zu vereinen.
Und in der Form,
in der Form gab es das.
Es ist zwar immer sehr viel im Prosa-Text beschrieben gewesen,
aber so richtig herausgelistet, was kulturelle Werte sind,
wie wichtig eben diese Einstellung, dieses Verhalten,
diese Zusammenarbeit ist.
Und das mit Grundsätzen untermauert,
das hat es vorher nicht gegeben.
Und ich denke da auch, was man mit dem Practitioner,
das war ja auch ein bisschen abgekupfert,
vielleicht aus diesem agilen Manifest,
ja, dass man so gemeinsam,
dass man so gemeinsame Werte irgendwie mal auflistet.
Und das hat jetzt hier auch Niederschlag gefunden.
Und ich finde das gut.
Das hilft letztendlich eben auch so ein bisschen Orientierungshilfe.
Weil diese Leiblinien, Leibprinzipien,
die sollten unabhängig sein,
ob wie jetzt die Organisationsstruktur aufgestellt ist,
was für neue Ziele, wie die Strategie sich ändert.
Sondern die sollten wirklich eine Grundhaltung zum Ausdruck bringen.
Ja, und vor allen Dingen, wenn man das wirklich schafft,
dass man die eben nicht nur an die Wand hängt,
sondern dass man sie auch,
auch diskutiert, erarbeitet
und für sich daraus konkrete Dinge ableitet,
also für das eigene Team, für das eigene Unternehmen,
dann wird es ja auch greifbar.
Weil sonst ist es ja genauso wie Unternehmensvisionen,
die eben in einem Elfenbeinturm
von der Strategieabteilung entwickelt werden,
die kriegst du auch nicht transportiert an die Mitarbeiter,
weil sie einfach da überhaupt gar keinen Bezug zu haben an der Stelle.
Und man muss sie auch immer wieder zurate ziehen
und das eigene Tun ein bisschen hinterfragen.
Bringt das jetzt noch einen Mehrwert?
Ist es transparent?
Ist es transparent für alle?
Und dass man wirklich diesen Fokus nicht aus dem Auge verliert.
Das ist sicher.
Wir waren ja noch bei der Diskussion
DevOps und ITIL wieder Freunde.
Und wenn ich das mal so ein bisschen zusammenfasse,
die letzten 35 Minuten so,
dann waren es zwar keine Freunde,
weil ITIL keine Antworten hatte auf das,
was DevOps adressiert hat,
wo DevOps ja auch ein bisschen Pionierarbeit geleistet hat.
Aber du würdest heute sagen,
ITIL hat quasi diese Lücke geschlossen
und jetzt können beide in friedlicher Koexistenz,
helfen, Dinge zu verbessern.
Also sprich, man sollte schon schauen,
dass man das, was die DevOps-Bewegung
deiner Ansicht nach bewegt hat
und welche Wege sie beschritten hat,
dass man das einfach jetzt mit ITIL gemeinsam weiter voranbringt.
Ja, auf jeden Fall.
Also ich glaube, die Grundlage dazu ist jetzt eigentlich geschaffen.
Und ich würde auch sagen,
das wäre jetzt komplett falsch,
dass man sagt, okay, jetzt hat DevOps diese Lücke geschlossen,
und jetzt gehen wir wieder zurück zu ITIL.
Ich denke, diese Bewegung, die muss man aufrechterhalten.
Und es ist nicht die Frage,
ob jetzt DevOps oder ITIL oder Scrum oder sonst was.
Letztlich muss der Spirit,
der muss in der Organisation rüberkommen.
Und die Frameworks und die Methoden,
die existieren für sich ja nicht alleine.
Und ich glaube jetzt,
es sind viele Leute,
die vielleicht dem ITIL den Rücken gekehrt haben
und das irgendwie als abgeschlossen betrachtet haben.
Die müssen vielleicht ein bisschen über den eigenen Schatten springen
und vielleicht doch mal schauen,
ob es dort vielleicht Antworten gibt,
die sie mit der Methode DevOps alleine nicht lösen können.
Und umgekehrt muss auch jetzt diese
vielleicht noch eingeschorene ITIL-Gemeinde
auch nicht das Gefühl haben,
wir brauchen jetzt kein DevOps mehr,
wir können das Ganze wieder stoppen,
weil wir jetzt wieder eine Antwort haben.
Für die ganze agile Fragestellungen,
die wir haben aus dem Markt oder aus der Organisation.
Ich denke gerade die DevOps-Bewegung hat eben gezeigt,
dass es machbar ist.
Und es ist ein sehr guter Case,
der mit diesem Value Stream jetzt eigentlich dort gebaut wurde.
Jetzt muss man eben auch den Mut haben,
weitere Value Streams nach dem gleichen Muster so zu bauen,
dass es eben auch die Zusammenarbeit
der beteiligten Organisationen,
die sich da auch noch weiter vereinfachen,
die sich da auch noch weiter vereinfachen,
die sich da auch noch weiter vereinfachen,
und nicht diese Silo-Mentalität weiterhin fördert.
Ich weiß auf jeden Fall für mich,
dass ich das, was du eben gesagt hast,
vollkommen unterschreiben würde.
Ich habe in meinen DevOps-Schulungen
eigentlich keine Antwort geben können.
Also zumindest nicht auf der Basis der Unterlagen,
die ich verwende.
Und das sind ja hoch angesehene Unterlagen,
wo wir wirklich konkret auf die Frage eine Antwort geben konnten,
wie organisiere ich jetzt den Betrieb in DevOps.
Das war eine relativ allgemeingültige,
bequeme,
bequeme Bilder und Übersichten.
Aber konkret die Frage,
wie lasse ich jetzt Inzidenz laufen?
Also wie kriege ich denn selbst organisierte Teams,
die quasi nicht nur Entwicklung,
auch Betrieb machen sollen,
wie kriege ich das hin,
dass die eben in einem Inzidenz-Prozess mitspielen?
Weil die Erwartung kann ja nicht sein,
dass alle Teams jetzt 24-7 erreichbar sind.
Also ich brauche ja schon noch ein paar Dinge,
die genau in ITIL ja beschrieben sind.
Und da habe ich keine Antworten in den Unterlagen gehabt.
Natürlich habe ich praktische Erfahrungen
ausprobiert oder getan.
Aber wie gesagt,
DevOps hat auf solche Fragen keine Antworten gehabt
und die gab es immer im IT Service Management,
gab es immer im ITIL.
Und das ist für mich schon ein wichtiger Punkt.
Also es hat jetzt in dem Buch,
dem ITIL Foundation,
so anschauliche und auch Beispiele im Appendix,
wie so Value Streams jetzt eben aussehen könnte.
Aus beispielsweise für so einen
Incident Resolution Stream.
Und das Gute eben daran ist,
dass es eben nicht ein Prozess alleine ist,
sondern da gibt es jetzt eben Praktiken
aus dem Service Desk Umfeld.
Es gibt Praktiken aus dem Configuration Management,
aus dem IT Asset, aus dem Continual Improvement.
Also man kann so anschaulich dann auch,
wie es da beschrieben ist,
so einen Value Stream dann bauen.
Das sind natürlich auch wieder Beispiele
und dürfen nicht so eins zu eins übernommen werden.
Aber einfach nur zur Illustration,
dass dieses Konzept,
das man eigentlich mit DevOps da gebaut hat,
dass man das jetzt mit den verschiedenen Praktiken,
die sind ja übrigens jetzt von den 26 Prozessen
auf 34 Praktiken angewachsen,
dass man die eben so verwenden kann.
Aber es hat eben auch jetzt Themen drin wie
Architektur Management,
es hat Themen drin wie Business Analyse,
es hat Themen drin wie,
wie Service Design inklusive Design Thinking,
wie User Experience, wie Customer Experience.
Das sind so Themen,
die jetzt viel, viel mehr eigentlich auch
in die Welt der Entwickler hineingreifen.
Und von daher ist es eine Quelle mehr,
die man nutzen kann,
ohne dass man jetzt für sich alleine den Weg suchen muss.
Und es hilft ungemein,
den eigenen Kopf anzuschalten,
selber nachzudenken
und diese Beispiele aus dem Appendix zu nehmen
und sie eben sich selber weiterzuentwickeln.
Am besten Business, Entwicklung und Betrieb zusammen.
Richtig?
Genau.
Genau.
Genau.
Also dort,
ja eben auf der Seite vom Business,
das habe ich ja gesagt mit diesen Co-Creation,
da ist einiges jetzt neu drin.
Dort könnte man auch in Zukunft noch mehr machen.
Also ich sage das jetzt gerade bewusst,
weil ich weiß,
ich bin jetzt ja auch vor allem
mit dem Business Relationship Management Institute
in Zusammenarbeit,
wo man wirklich diese strategische Partnerschaft
noch viel, viel präziser
und noch viel, viel direkter einfordern muss
oder auch sicher arbeiten muss.
Und das ist dann sicher auch noch eine Entwicklungsmöglichkeit,
die ITIL vielleicht mal in der Version 5 noch hinkriegt.
Na ja,
das ist doch gut.
Ob wir die noch erleben?
Fragezeichen.
Aber gut.
Ja,
in unserem Berufsleben.
Wir werden sie vielleicht nochmal erleben.
Also alle sieben Jahre kommen neue Versionen.
Also das heißt,
Ja,
okay.
Wenn du jetzt dann mit 26 noch dabei bist,
dann,
ja,
dann wirst du vielleicht die Fünf erleben.
Also ich will in 2026,
könnte ich mir schon vorstellen,
noch zu arbeiten.
Ich weiß nicht,
wie das bei dir ist.
Ja,
ich,
ja,
ich,
ja,
ja,
ja,
ja,
ja.
Ja,
ich glaube,
da,
wenn man mal mit diesem Virus investiert wird,
dann kann man sich nie lösen.
Ja,
das wird man über alle Phasen,
die noch kommen,
da mittragen.
Ja,
und ich werde mich sicher auch immer wieder ein bisschen äußern zu den Themen.
Das ist doch gut.
Also dann vereinbaren wir jetzt schon einen Termin,
Podcast in 2026 im Sommer.
Du sitzt auf irgendeiner Alm und ich sitze irgendwie,
weiß ich nicht,
am Flüsschen und dann reden wir über ITIL 5.
Sehr gerne.
Gut.
Ja,
Also ich fand, das war eben schon mal
eine gute Überleitung zu einem
Schlusswort. Hast du
noch irgendwas, was du zu dem Thema
DevOps und ITIL wieder Freunde
noch sagen wolltest?
Ja, nein. Ich denke jetzt,
die Hände ausstrecken,
sie einander geben
und dann
anfangen, sich wieder zu umarmen. Das ist
vielleicht das
Schlusswort, das ich sage. Ich denke,
die Grundlagen sind dazu da. Jetzt müssen
es die Menschen nur noch tun.
Jawohl, das ist doch perfekt.
Das heißt, wir nehmen den Schlusssatz
DevOps und ITIL wieder Freunde
Ausrufezeichen und
reicht euch die Hände, vertragt
euch und dann würde ich
sagen, ich bedanke mich, Martin, für den
tollen Podcast, für die
wirklich tollen Aussagen und auch für das
friedvolle Ergebnis.
Vielen Dank dir.
Vielen Dank.