single.php
< Beitrag von Jens Zange

Anforderungsprofil Framework-Philosoph

ITIL ist als Framework etabliert. ITIL ist der Platzhirsch, auch wenn es schon seit einigen Jahren keine wesentlichen Änderungen mehr gibt. Dies ist Fluch und Segen zugleich: Zwar „weiß man, was man hat“, aber häufig wirken andere Frameworks, Methoden und Ansätze neuer, frischer und „hipper“. Was tun?

Ein super Framework – doch nicht die Antwort auf alle Fragen

Vor gut 10 Jahren galt für die meisten IT-Führungskräfte: Ein Tool ist die Antwort auf alle Fragen. Inzwischen hat sich die weise Erkenntnis „a fool with a tool is still a fool“ bis zum letzten Mitarbeiter herumgesprochen. Wenn aber Tools nicht die Antwort liefern, dann ja sicher die wohl durchdachten Frameworks.

Dieser Irrglaube ist einerseits ein Segen für die Beraterbranche, denn der Irrtum erzeugt Unterstützungsbedarf durch externe Fachleute. Auf der anderen Seite sorgt dieser Irrtum aber für Verwirrung und Ernüchterung. Selbst der Platzhirsch ITIL leidet unter der hohen Erwartung, dass alles besser wird, sobald man ITIL einführt. Mal abgesehen davon, dass man ITIL nicht einführen, sondern sich nur daran anlehnen kann, führt diese Erwartung zum vorzeitigen Tod eines jeden ITSM-Projektes. Denn: ITIL bietet mehr als nur Prozessdokumentation und die Benennung diverser Rollen in der Organisation. SCRUM ist mehr als nur ein Denken in kürzeren Zeitabständen und das Umbenennen vom Projektstatus in „Daily“. DevOps ist mehr als der regelmäßige Austausch zweier Abteilungen – und diese Liste ließe sich lange weiterführen.

Framework und Firmenkultur – wenn das nicht passt, läuft nichts

Auch auf die Gefahr hin, dass es esoterisch klingt: Ein Framework funktioniert nur dann gut, wenn man die Grundidee, die Philosophie, wirklich verstanden hat. Erst dann kann man von sich behaupten, „auf dem Weg zu sein“ und etwas „zu leben“. Und erst danach sollte man darüber nachdenken, verschiedene Ansätze miteinander zu vermischen.

Nehmen wir ein Beispiel aus dem ITIL-Projektalltag: Da ist eine Organisation, die streng hierarchisch aufgestellt ist und in Hierarchien denkt. Die IT will vorangehen, zeigt Service-Orientierung und setzt sich das Ziel, zur ITSM-Organisation zu werden. Brav werden Prozesse skizziert, Rollen besetzt und – natürlich – Tools evaluiert. Bei näherer Betrachtung zeigt sich: Die Prozesse sind zu generisch, die Rolleninhaber verstehen die eigene Aufgabe bzw. Rollenbeschreibung nicht und die Tools funktionieren nur dann gut, wenn Mitarbeiter ihre Rollen verantwortungsvoll wahrnehmen. Wie aber soll ich in einer hierarchischen Organisation, die zum Teil noch mit „Management of fear“-Ansatz agiert, einen Mitarbeiter motivieren, zum Beispiel die Rolle des Change Managers wahrzunehmen? Zu groß wird die Angst sein, einen RfC des eigenen Abteilungsleiters wegen Formfehler zur Überarbeitung zurückzugeben. Zu groß wird die Angst eines Change Advisory Board (CAB) sein, Changes abzulehnen.

Die wichtigsten Säulen hinter ITIL sind Servicebewusstsein und das Rollendenken. Das funktioniert nur, wenn ich Verantwortung delegiere. Die Mitarbeiter müssen die Chance haben, sichtbar zu sein und Entscheidungen selbstständig zu treffen – auf der Basis ständiger Kommunikation untereinander. Sichtbarkeit in einer Organisation mit einer schlechten Fehlerkultur ist keine Belohnung, sondern eine Bestrafung. Genau deshalb tun sich viele Unternehmen und IT-Abteilungen so unglaublich schwer, ITSM zu leben.

Klären Sie Grundideen und Prioritäten – dann ergänzen sich auch Gegensätze

Frameworks miteinander zu kombinieren, bedeutet Philosophien miteinander zu verbinden. Stellen Sie sich vor, Sie hätten in den 90er Jahren versucht, den Mauerfußball der italienischen Nationalmannschaft mit der Offensivtaktik Brasiliens zu vermischen. Mit viel Glück wäre dies unglaublich erfolgreich gewesen, mit hoher Wahrscheinlichkeit aber ein Rohrkrepierer: Die Spieler hätten einfach nicht gewusst, was denn nun die oberste Priorität hat.

Das soll nicht bedeuten, dass sich zum Beispiel DevOps und ITIL automatisch widersprechen. Im Gegenteil, es gibt Gemeinsamkeiten und sinnvolle Überschneidungspunkte. Allerdings sind diese Überschneidungen nicht auf dem Papier und schon gar nicht in Prozessbeschreibungen zu finden, sondern in der Philosophie. Eine Kombination kann sinnvoll sein, aber nur, wenn Sie aus der richtigen Motivation heraus angewendet wird. Statt voreilig Methoden zu adaptieren bloß, weil so oft über sie geschrieben wird, sollte man die Grundideen dieser Methoden, die Philosophie dahinter, analysieren – und danach das Prinzip von Stephen Convey walten lassen: „Erst verstehen, dann verstanden werden.“

Folgen
X

Folgen

E-mail : *
Kategorie: ITSM | Schlagwörter: , , | Kommentare: 0

Beitrag kommentieren

CAPTCHA * Time limit is exhausted. Please reload CAPTCHA.