counter

ITIL handfest - was nützts - Teil 1 - Incidentmanagement

16.04.2019 19:49:41 | Steigele | 0 Kommentare
Es ist nicht mehr zu leugnen. Seit man erkannt hat, dass strukturiertes Arbeiten innerhalb der Informatik seine Vorteile haben kann, und seit dies auch noch mit einem Label namens ITIL belegt ist, brummt das Getriebe.

Da wird von Prozessen, neuen Begriffen und allen möglichen revolutionären neuen Erkenntnissen philosophiert, doziert und akklamiert, dass einem die Ohren wackeln. Das Problem, die gesamte Literatur und alle zugehörigen Wikis, Werbe- und Kursbroschüren strotzen nur so von Bulletpoints, dass es nur so kracht. Zwar bin ich selbst als Prozessberater mit dieser Domäne mehr als nur betroffen, aber hin und wieder wunderts mich schon, warum die Autoren und Abschreiber die diese Sammlung an Erfahrungen im IT-Servicemanagement immer alles so kompliziert machen müssen.

Hier ein kurzes Beispiel, wie einem IT- oder Businessmanager das "Incidentmanagement" verkauft wird. Ich habe dazu mal gegoogelt und mir sprichwörtlich ein "Bild" darüber gemacht, was denn da die Suchmaschinen so rausspucken. Sieh da ich bin fündig geworden. Da steht doch auf prominenter Stelle unter
http://wiki.de.it-processmaps.com/index.php/ITIL_V3_Service_Operation_-_Servicebetrieb folgendes:

Incidentmanagement:

Prozessziel: Die Verwaltung aller Incidents über ihren gesamten Lebenszyklus. Das primäre Ziel des Incident Managements besteht darin, einen IT-Service für den Anwender so schnell wie möglich wieder herzustellen.

Nach meiner persönlichen Interpretation ist diese Definition generalstabsmässig und beratungstechnisch korrekt formuliert (wlll heissen, präzise, nur für Experten verständlich, aber kaum brauchbar).

Da ich dafür bekannt bin überall anzuecken hier ein Beispiel, wie ich es dem Finanzchef eines Mittelstandsunternehmens erklärt habe.

Zuerst habe ich ihn gefragt, ob er Lust hat in Zukunft bei steigendem Arbeitsaufwand der Informatik weitere Stellen für den Support zu bewilligen. Die Antwort kam mit einem unverbindlichen Lächeln, als klares Nein. Versehen wurde die Antwort mit einer kleinen Replik: "Die sollen zuerst mal lernen strukturiert zu arbeiten, bevor ich dort noch weitere Stellen genehmige".

Meine Antwort: Wenn sie es ihren existierenden Mitarbeitern verwehren, zu lernen wie man strukturiert arbeitet, werden Sie auch nicht weiterkommen. Irgendwann springen Ihnen die guten Supporter ab, die mittelmässigen werden unter der höheren Arbeitslast ausbrennen und die neuen brauchen so lang zur Störfallbehebung, dass sie selbst auch auf der Strecke bleiben. Übrigens, Informatiker wachsen nicht auf den Bäumen.

Da dieser Finanzchef zur Ausnahmekategorie derer gehörte, die auch mal Unflätiges vertragen, gings dann auf einer seriöseren Gesprächsebene weiter. Wir haben dann nur über die Auswirkungen von bestimmten Arbeitsumständen und Systemlücken in der Störfallbehebung und Beispielen aus der Praxis gesprochen. Ich habe dabei kein einziges mal auf die üblichen Floskeln aus irgendeiner ITIL-Annabelle geschweige denn auf offiziellen Kurs-Pamphlete zurückgegriffen. Verstanden hats der Finanzchef trotzdem.

Also werde ich diesen Blog - Beitrag um Beitrag um ein paar griffige Beispiele aus jedem ITIL-Prozess fortsetzen, vielleichts hilfts dem einen oder anderen.

PS: Es gibt auch ein paar Websites, die ganz brauchbar sind.
www.4servicemanagers.com ist eine davon.

Kommentar hinzufügen

Sicherheitscode

Keine Kommentare vorhanden.