www.itil.de - Der ITIL Blog
In letzter Zeit höre ich oft: „Wir haben die IT-Mitarbeiter in ITIL geschult, jeder hat die Foundation gemacht. Wir haben die ITIL Prozesse Incident, Problem und Change Management eingeführt. Aber es läuft nach wie vor chaotisch. ITIL bringt uns nichts!“
Hier wird sehr deutlich, dass ITIL alleine die Probleme nicht lösen kann. Hinterfragt man, warum die ITIL-zertifizierten Mitarbeiter die definierten ITIL-Prozesse nicht einhalten, stellt man fest, es fehlt die praxisnahe Ausgestaltung und die dedizierte Ausrichtung der Prozesse an den Unternehmenszielen.
Praxisnahe Ausgestaltung heißt, die Prozesse müssen sich in das Tagesgeschäft der Mitarbeiter einpassen. Hier ist kulturelles Veränderungsmanagement gefragt. Das Organizational Change Management in der ITIL Practitioner Guidance greift dieses Dilemma mit den Vorgaben „Widerstände identifizieren“ und den „Wandel managen“ auf. Ausrichtung an den Unternehmenszielen hat sich COBIT auf die Fahne geschrieben mit den Zielkaskaden „Unternehmensziele zu IT-Zielen zu Enabler Zielen“. So gut so schön. Beides löst aber nicht eine Grundproblematik: Das Silodenken der Abteilungen, auch innerhalb der IT. Hier braucht es neue Ansätze, z..B. DevOps.
Der DevOps-Gedanke kann als eine bereichsübergreifende, unternehmensweite Kollaboration der Manager, Entwickler, Tester und Administratoren unter Einbeziehung der Kunden verstanden werden. Alle Beteiligten arbeiten zusammen an der Erreichung des gemeinsamen Ziels. Dies ist ein neuer unternehmensphilosophischer Ansatz jenseits des Silodenkens in hierarchischen Strukturen (vgl. Brian Fitzgerald, Klaas-Jan Stol). Es bedarf des Aufbaus einer ganzheitlichen Kultur der Zusammenarbeit, Umsetzung von Maßnahmen zur Nutzung von Automatisierung, Gemeinsame Metriken zur Messung des Erfolgs oder Harmonisierung mit (bestehenden) IT-Frameworks wie ITIL. Das hat die DASA (Devops Agile Skills Association) in 6 DevOps Prinzipien zusammengefasst:
· Kundenorientiertes Handeln
· Erstellen mit dem Ziel vor Augen
· End-to-End-Verantwortung
· Cross-funktionale autonome Teams
· Ständige Verbesserung
· Automatisieren Sie alles, was Sie können
Damit stellt DevOps einen gemeinsamen Bezugsrahmen für das gesamte Unternehmen bereit, um das Silodenken aufzuheben.
Um auf die Ausgangsfrage zurückzukommen: Das Problem ist nicht das ITIL Framework, sondern die Umsetzung in der bestehenden Unternehmenskultur. Damit Frameworks wie ITIL oder COBIT funktionieren, bedarf es oft einer Änderung in der Unternehmenskultur. Meist ist das ein Vorteil für das Unternehmen, bedeutet dies doch neue Denkansätze, neue Ausrichtung, Fortschritt.
Es wird aber auch deutlich, dass Frameworks alleine nicht funktionieren, sondern immer nur in Kombination. Insellösungen führen zu Frustration. Wenn z.B. der Change Prozess nur für die IT eingeführt wird, wird die IT weiterhin chaotisch agieren. Änderungen müssen sich immer an den Unternehmenszielen ausrichten und der Prozess muss unternehmensweit verstanden werden, mit Antrag, Bewertung, Priorisierung. Allerdings muss der Prozess einfach sein und kein Bürokratiemonster werden. Das ist die Kunst eines „ServiceARTisten“.
Autor: Dr. Guido Hoffmann
Mai 2017
Literatur:
Brian Fitzgerald, Klaas-Jan Stol: Continuous Software Engineering - A Roadmap and Agenda. In: Journal of Systems and Software, 4. Juli 2015
DASA, Devops Agile Skills Association, http://www.devopsagileskills.org/
ITIL Practitioner Guidance, 2015
Abonnieren Sie
unseren Blog itil.de
Unsere Mission
Wir leisten einen Beitrag zu besserem IT Service Management durch die pragmatische Auseinander-setzung mit ITIL und verwandten Themen.
Werbung
Wollen Sie ITIL-Experte werden? Dann lassen Sie sich zertifizieren bei
Kommentar schreiben
ITILDisciple (Mittwoch, 17 Mai 2017 13:35)
Ein gemeinsamer Referenzrahmen klingt ja erstmal toll, dürfte aber erstmal als nette, bunte Darstellung von nichts konkretem von den meisten abgenickt werden. Mit stellt sich die Frage, wie es zu einem solchen kulturellen Wandel kommen soll, wenn die Mitarbeiter vorger ein ganz anderes Bild von ihren Aufgaben hatten. Der eine hat entwickelt, der andere hat die Server und Infrastruktur administriert, ein dritter verkauft und der vierte übersetzt das, was verkauft wurde in technische Anforderungen und Architektur.
Wie komme ich da zu einem Kulturwandel? Wie bringe ich ITIL zum fliegen?
Guido Hoffmann (Mittwoch, 17 Mai 2017 13:58)
Kulturwandel kann ich nur durch Kommunikation und "es vorleben" erreichen. Der Kulturwandel muss von der Führung ausgehen. Es bedarf eines gemeinsamen Verständnisses der Ziele.
ITIL bringe ich zum fliegen, wenn die einzelnen Prozesse auf diese Ziele abgestimmt werden. Ein Beispiel: Change Management ist oft ein gelebter Prozess. Die Einführung von Antragsformularen (als Word- oder online Dokument ist egal) und einem einzigen Eingangskanal ist der Anfang eines formalisierten Prozesses. Dann legt ein Change Manager (die Rolle muss eingeführt werden) fest, welche Informationen vom wem gebraucht werden, um darüber zu entscheiden. Das alles natürlich an das Unternehmen und seine Umgebung angepasst.
Das ist aufwendig und mühsam. Keine Frage. Vor allem wenn das für alle Prozesse gilt, die ich benötigte (das sind aber weniger als gedacht :)).
Dass das so funktioniert, können wir durch viele Projekte belegen.
ITILDisciple (Dienstag, 13 Juni 2017 01:43)
Es klingt sehr einleuchtend, dass die Einführung eines Change Managers und eines Change Request-Formulars ein guter Einstiegspunkt für eine zunehmende Formalisierung des Change Managements ist.
Aber kann man das denn bei allen Prozessen zur Einführung einfach so handhaben? Einfach einen Manager für den Prozess festlegen, und einen formalen Einstiegspunkt definieren, den dann kein Mitarbeiter mehr umschiffen darf?
Ihr vorletzter Satz klingt so, als würde man die meisten ITIL Prozesse gar nicht brauchen?!
Guido Hoffmann (Dienstag, 13 Juni 2017 10:21)
Ja, die meisten ITIL Prozesse müssen nicht explizit angegangen werden, da sie i.d.R. schon gelebte Prozesse sind.
Wir haben in Projekten bewiesen, dass in der Service Strategie nur "Service Portfolio" nötig ist, im Service Design "Design Koordination", in der Service Transition "Change Management" und der Operation "Incident und Problem Management".
Damit lässt sich eine Service Organisation bzw. die IT schon sehr gut strukturieren und formalisieren.