+++ Neuer Blogeintrag: Was ist der (Mehr) Wert von ITIL? +++ weitere Artikel: IT Abteilungen – siechende Patienten? +++ Release- und Projektmanagement – eine Seite einer Medaille? +++ Der Ruf nach dem "ITIL Doktor" +++ Was haben ITIL und Fußball gemeinsam? - ITIL einführen - aber wie? +++ ITIL in Unternehmen simulieren und spielerisch an den De-Facto Standard heranführen +++

Was ist ITIL.de?

www.itil.de ist die Informationsquelle für alle Fragen rund um das IT Service Management nach ITIL® in Form eines Blogs.

Der Blog

Di

16

Sep

2014

Was ist der (Mehr) Wert von ITIL?

Diese Frage stellen immer wieder die Entscheider in einem Unternehmen. Sie sehen, dass ihre Mitarbeiter zwar eine ITIL Schulung nach der anderen besuchen, aber was hat das Unternehmen davon? Lassen sie sich dann ITIL erklären bzw. fragen nach Umsetzungsmöglichkeiten, schalten sie schnell ab. Zu komplex! Zu theoretisch! Eine unzureichende methodische Struktur! Für die Praxis nicht geeignet! (vgl. Kallus).

Schulungen und Zertifizierungen allein reichen nicht. Man muss das Ganze auch in die Praxis transferieren (vgl. Jindra). Wie sagte schon Goethe: „Es ist nicht genug, zu wissen, man muss es auch anwenden; es ist nicht genug es zu wollen, man muss es auch tun!“

 

Es gibt viele Ansätze, ITIL in einem Unternehmen einzuführen:

  • ·        Man beginnt mit dem, was für die Kunden am sichtbarsten ist, dem Service Desk und dem Incident Management.
  • ·        Man beginnt mit dem Service Katalog, weil Services die Grundlage der Umsetzung sind.
  • ·        Man beginnt mit dem Configuration Management, weil das die Wissensbasis ist.
  • ·        Man beginnt mit …

Aber es gibt kein Kochbuch, keinen Königsweg. ITIL einzuführen ist immer sehr individuell.

 

Man muss verstehen, dass die ITIL Theorie nur eine konzeptionelle Hilfe für eigene Ansätze ist (vgl. denkfabrik).  Werden die Best Practice Ansätze von ITIL an die sehr speziellen Anforderungen des einzelnen Unternehmens angepasst, dann ergibt sich auf jeden Fall ein Mehrwert für das Unternehmen.

 

Das ITSMF Deutschland hat bereits im August 2007 in seinem Artikel über „Total Value of IT (TVIT)“ beschrieben, wie ITIL dabei helfen kann, Kostentreiber in der IT zu identifizieren. Die Einführung von IT Service Management läuft in der Regel nach dem Muster: Planung, Inbetriebnahme, Überwachen, Verbessern.

 

Das Problem: Man muss dabei nicht nur die direkten IT Kosten berücksichtigen, sondern vor allem die indirekten Kosten die durch die Einführung und die Leistungserbringung von Services entstehen. Erst dann lassen sichGesamtkosten und der Nutzen der IT analysieren. Das setzt aber Kostentransparenz der IT voraus, die dann Business Cases für die einzelnen Services ermöglichen (vgl. ITSMF).

 

Und genau hier liegt für Unternehmen der Mehrwert von ITIL. ITIL bietet Ansätze Kostentransparenz in einem Unternehmen zu schaffen. Die fünf Kernbücher und ihre Prozesse liefern die Basis, wie Unternehmen ihre IT effizienter und effektiver organisieren können. Dabei wird sich schnell herausstellen, dass der Vorteil weniger in einer besseren IT Ausstattung liegt, sondern vielmehr in einer optimierten Organisation.

 

In allen meinen Projekten lagen die Probleme nie in oder an der IT, sondern in einer unzureichenden (Unternehmens) Organisation, fehlendem Wissen der Mitarbeiter bzw. wie sie dieses Wissen praktisch anwenden können und einer klaren Zielvorgabe.

 

ITIL liefert durchaus einen Mehrwert – wenn man es denn richtig tut.

 

Autor: Dr. Guido Hoffmann

 

Literatur:

Andrea Jindra, „Wissen allein reicht nicht“, Weiterbildungsmarkt.at, 4.10.2013

ITSMF Deutschland, „Total Value of IT“, 1.8.2007

Denkfabrik, „Mittelstand zeigt sich nicht als Freund von ITIL“, denkfabrik.com, 6.11.2012

Michael Kallus, „Mittelstand bei ITIL verunsichert“, cio.de, 27.5.2004

 

0 Kommentare

Mo

07

Apr

2014

IT Abteilungen – siechende Patienten?

Sparen an allen Ecken und Enden. Viele Leute haben das Unternehmen verlassen. Die übrigen sind damit beschäftigt, die Systeme am Laufen zu halten, neue Projekte kommen unaufhaltsam. An Verbesserungen ist gar nicht zu denken. Keine Zeit, kein Geld, kein Managementinteresse (vgl. Fischbach).

 

In einem früheren Blogeintrag „Der Ruf nach dem ITIL Doktor“ wurde bereits eine Möglichkeit der Hilfe aufgezeigt: „Nach einer Anamnese wählt der ITIL Doktor die richtigen Werkzeuge zur Untersuchung aus: Priorisierung der ITIL Prozesse, Reifegrad der Prozesse, Implementierungstiefe der Prozesse, Organisationsgrad des Unternehmens, Governance und Compliance Regeln usw…“ (vgl. Hoffmann).

Soweit ok. Aber, kommt oft der Einwand, das dauert lange. Gefolgt von der Frage: Wie komme ich denn schneller zu einer Entlastung?

Gene Kim und das „Visible Ops“-Team haben auf Basis von ITIL ein agiles Rahmenwerk entwickelt, das effiziente Umsetzungsmöglichkeiten für ITIL aufzeigt (vgl. Lee). Damit lassen sich die Quick Wins erreichen. Hier wird ITIL nicht in der „reinen Lehre“ angewendet und es wird auch nicht nach Schema F vorgegangen (zuerst die Prozesse Incident, Problem, Change…, Einführung eines ITSM Tools…).

 

     Die erste von vier Phasen befasst sich ganz im Sinne des ITIL Doktor mit der „Stabilisierung des Patienten“ (vgl. Behr, Kim, Spafford). Dahinter verbirgt sich die Frage, was bringt den Patienten, hier die IT, immer wieder aus dem Tritt. Die Antwort: Veränderungen, frei nach dem Motto „never change a running system“. Die Konsequenz, Änderungen vermeiden oder stark einschränken. In der Praxis kann das so aussehen:

      - Nur ein kleiner Personenkreis darf Änderungen beantragen.

      - Es gibt eine ganz klare Change Policy mit einem verpflichtenden Change Antrag, angelehnt an die 7 R’s aus ITIL Service Transition.

     - Es gibt klar definierte „Change Fenster“.

          -  Die Einhaltung der Change Policy strikt durchsetzen.

Dahinter verbirgt sich die Erkenntnis, dass Änderungen die größte Fehlerquelle in der IT sind. Durch die Verringerung von Fehlern werden Ressourcen frei, die dann proaktiv die IT verbessern können (vgl. Schlesinger).

 

In der zweiten Phase können dann die IT Systeme und Service ermittelt werden, die besonders wichtig und vorsichtig zu behandeln sind. Diese können dann langsam verbessert werden.

Diese Vorgehensweise weicht zwar eindeutig von der „normalen“ Vorgabe ab, andererseits ist ITIL Best Practise. So mit der Implementierung von ITIL anzufangen scheint ein probates Mittel zu sein. ITIL ist kein Standard, gibt keine Vorgehensweise vor oder fordert bestimmte Prozesse. ITIL zeigt Möglichkeiten auf, die IT besser zu betreiben. Jedes Unternehmen muss seinen eigenen Weg finden. Quick wins stehen dabei meist ganz oben.

 

In diesem Sinne: Anamnese auf jeden Fall, aber dann die richtige, die schnellwirkende Medizin finden. Aber dabei bitte nicht in blinden Aktionismus verfallen.

 

Autor: Dr. Guido Hoffmann

 

Literatur:

 

Jan Fischbach, Wo kann IT noch sparen?, Das Teamwork-Blog, 20.02.2014

Guido Hoffmann, Der Ruf nach dem ITIL Doc, ITIL.de, 03.12.2013

James Lee, Lean ITIL – Agile ITIL, ITIL.de, 27.08.2013

Kevin Behr, Gene Kim, George Spafford, Information Technology Process Institute, The Visible Ops Handbook: Implementing ITIL in 4 Practical and Auditable Steps, 2005

Thomas Schlesinger, The Visible Ops Handbook, Schlesis Blog, 24.11.2011

 

0 Kommentare

Do

19

Dez

2013

Release- und Projektmanagement – eine Seite einer Medaille?

Immer wieder werden wir vor allem von Mittelständlern gefragt, wie kann man erfolgreich Releases implementieren, ohne die Betriebsumgebung zu stören bzw. ohne in den ersten Tagen auf massive Schwierigkeiten zu stoßen. Dies ist nicht neu, ist doch die Schnittstelle zwischen den Entwicklungs- und Betriebsabteilungen in einer IT-Organisation immer wieder problematisch und bietet Anlass für handfeste Streitigkeiten (vgl. Disterer).

Warum ist das so? Sind die Menschen zu dumm? Lernen sie nichts aus Erfahrungen?

Ich glaube, das sind die falschen Fragen. Vielmehr sollte man sich die Art und den Umfang der Releases anschauen. ITIL bietet an der Stelle schon eine große Hilfe: Gibt es eine Release Policy? Gibt es Release Pläne? Wie sieht das Release Design aus?

Nähert man sich dem Thema von dieser Seite, kommt man unweigerlich zu dem Ergebnis, dass jedes Release ein Projekt ist. Zur Umsetzung braucht man also Projektmanagement. Am besten eine Methode, die unternehmensweit eingesetzt wird.

Aber hier taucht das nächste Problem auf. Das Gesamtunternehmen verwendet i.d.R. gerne die klassischen Methoden wie PRINCE2, PMI u.ä., die IT setzt bevorzugt auf die agilen Methoden wie Scrum. Diese beiden Ansätze müssen vernünftig auf einander abgestimmt werden. Sie ergänzen sich und schließen sich nicht aus, wie in vielen Unternehmen geglaubt wird. Auf der Unternehmensebene sind die klassischen Projektmanagementmethoden unerlässlich. Nur so lassen sich Governance und Compliance einhalten. Bei der Durchführung und Entwicklung können die agilen Methoden sehr nützlich sein.

Schauen wir uns mal an, was das für unsere Ausgangsfrage bedeutet:

Die Planung eines Releases fängt bereits im Design an. D.h., die grundlegenden Voraussetzungen wie die Release Policy und das generelle Release Design müssen vor der Realisierung schon da sein. In der PRINCE2 Terminologie hieße das, die Managementstrategien (Risiko, Qualität, Konfiguration, Kommunikation), die in der Initialisierung gebraucht werden, sind bereits vorhanden. Das Fehlen dieser Grundlagen führt bei der Produktivsetzung eines Releases bzw. bei der Übergabe einer Änderung an den Betrieb zu hohem Kommunikations- und Koordinierungsaufwand (vgl. Elsässer, S. 72ff)

Voraussetzung für das Release Management ist ein genehmigter Änderungsantrag aus dem Change Management. Er wurde untersucht und bewertet. Es wurde quasi das Release „initiiert“ mit einem Business Case, einem grobem Plan mit Messpunkten und abgestimmten Managementstrategien.

Die Aktivitäten des Service Designs und des Change Managements in diesem Zusammenhang spiegeln die Initialisierung einer Projektmanagementmethode wie PRINCE2 wieder.

Die Realisierung der Arbeitspakete des Releases, Planen, Bauen, Testen, Implementieren, Early Life Support kann dann „agil“ laufen. Gerade für Bauen und Testen bietet sich „agil“ an, wenn die Vorgaben aus dem Change Management und dem Service Design ausreichend sind.

Zusammenfassend lässt sich also sagen, erst die Verknüpfung von ITIL und einer Projektmanagementmethode wie PRINCE2 erlaubt es, Releases ohne Probleme zu implementieren. Beides zusammengenommen berücksichtigt die häufigsten Fehler (fehlendes Anforderungs- und Stakeholder Management) und erzeugt einen Mehrwert, generiert Nutzen. Wichtig ist aber, dass sowohl ITIL als auch die Projektmanagementmethode abgestimmt ist auf das jeweilige Unternehmen. Darin liegt unserer Ansicht nach das Grundproblem: die Anpassung der Best-Practises ITIL und PRINCE2 geht nicht weit genug oder ist nicht aufeinander abgestimmt oder existiert gar nicht.

 

Autor:

Guido Hoffmann

 

Quellen:

Georg Disterer

Itil: Zwischen Entwicklung und Betrieb hakt es

26.05.2007

http://www.computerwoche.de/592968

 

 

Wolfgang Elsässer

ITIL einführen und umsetzen, München, 2006

3 Kommentare

Di

03

Dez

2013

Der Ruf nach dem „ITIL Doktor"

Wann ruft man nach einem Arzt? Wenn man krank ist.

Wann ist man krank? Wenn der Körper nicht mehr so funktioniert, wie er soll.

Wann stellt man eine Dysfunktion fest? Wenn man Schmerzen hat.

Dieser logischen Kette folgen die Menschen schon seit Jahrhunderten. Bei Schmerzen, vor allem bei langanhaltenden Schmerzen, geht man zum Arzt. Der weiß, welches Medikament oder welche Behandlung Linderung verschafft.

Von daher wäre es nur logisch, wenn ein Unternehmen Schmerzen in der IT hat, wenn die IT das Unternehmen nicht mehr ganz unterstützt, den „ITIL Doktor“ zu rufen. Tut man das? Selten oder nie.

Viel lieber schickt man Mitarbeiter auf Schulungen, kauft sogenannte ITIL.konforme Tools und hofft so, die Schmerzen zu lindern.

Genügt bei einer Krankheit eine „Schulung“, das Nachschlagen im Internet und eine Selbstmedikation zur Heilung, wenn man die Ursache nicht kennt? Wohl kaum. Man doktert an Symptomen herum. Ein Arzt hat ein langjähriges Studium hinter sich. Er untersucht, stellt eine Anamnese und erst dann verschreibt er eine Behandlung.

Dies lässt sich eins zu eins auf die IT-Probleme übertragen.  Es bedarf zunächst einer eingehenden Untersuchung der Probleme und einer Anamnese.

Ein „ITIL Doktor“ hat eine langjährige Erfahrung. Nach einer Anamnese wählt er die richtigen Werkzeuge zur Untersuchung aus: Priorisierung der ITIL Prozesse, Reifegrad der Prozesse, Implementierungstiefe der Prozesse, Organisationsgrad des Unternehmens, Governance und Compliance Regeln usw..

In der Praxis sieht es so aus, dass nach einer Business Impact Analyse (BIA) die kritischen Geschäftsprozesse (vgl. BSI) und Organisationseinheiten auf ihre IT-Unterstützung hin untersucht werden (vgl. BCM-News). Danach werden die für die Unterstützung wichtigsten ITIL Prozesse identifiziert und mit einem Service-Health-Check (vgl. expertplace) deren Reifegrad ermittelt sowie die Einhaltung von Governacne und Compliance Regeln. Erst nach dieser ausführlichen Untersuchung kann dann die entsprechende Behandlung empfohlen werden. Wichtig ist aber das Übel an der Wurzel zu packen, die Ursachen anzugehen. Ein „ITIL Doktor“ weiß, wie er eine Pain-Value-Analyse durchführt und zu einem Ursache-Wirkungs-Diagramm kommt (vgl. Kern). So kann der „ITIL Doktor“ die richtige Medizin auswählen.

Dabei muss die verordnete Medizin nicht immer teuer oder aufwendig sein. Oft hilft auch „Krankengymnastik“. Das Einüben bestimmter Verhaltens- und Handlungsmuster. Im Neudeutschen unter „Coaching“ bekannt.

 

Autor: Dr. Guido Hoffmann

 

Literatur:

Webkurs Notfallmanagement des BSI nach BSI Standard 100-4, Kapitel 3

Kochbuch für eine Business Impact Analyse, www.bcm-news.de,12.09.2010

ITIL® Health Check, www.expertplace.de/CMS/DE/Services/IT_Servicemanagement.htm

Johannes Kern: Ishikawa Diagramme - Ursache-Wirkungs-Diagramme. Grin Verlag, München 2009

 

 

 

0 Kommentare

Do

17

Okt

2013

Was haben ITIL und Fußball gemeinsam? - ITIL einführen - aber wie?

Auf den ersten Blick scheint es ziemlich verwegen, die beiden in einen Zusammenhang zu stellen. Das eine ist eine komplexe Best-Practices-Methode, deren Einführung und Beherrschung vielen sehr schwer fällt. Auf der anderen Seite haben wir eine Sportart, die Millionen mit Begeisterung spielen.

Schaut man aber genauer hin, ergeben sich sehr wohl Parallelen. Hier wie dort braucht man Spezialisten: hier z.B. Hard- und Softwareexperten, dort z.B. Torwart und Stürmer. Und ganz wesentlich, die müssen zusammen passen und zusammen spielen. Beim Fußball reicht es auch nicht, sich Wissen aus Büchern anzueignen, um z.B. ein guter Trainer zu werden und eine Mannschaft in die Champions League zu führen. Warum aber glauben viele, so könnte man ITIL einführen?

 

Allerdings wird auch ein sehr guter Trainer wie Pep Guardiola es nicht schaffen, einem Kreisligisten den „Hochgeschwindigkeitsfußball“ mit Kurzpassspiel beizubringen. Die Qualität einer Mannschaft definiert sich aus den individuellen Fähigkeiten der einzelnen Spieler und dem darauf aufbauenden Spielsystem. So hat jeder Spieler und jede Mannschaft eigene Stärken und Schwächen. Aber auch im Falle eines sehr guten Trainers und hervorragenden Fußballspielern reicht es nicht, dass der Trainer eine neue Taktik erklärt und bestimmt, wer welche Position einzunehmen hat, damit am nächsten Spieltag das neue System schon reibungslos funktioniert. Es bedarf der dazu passenden Spieler und eines intensiven Trainings, um das neue System zu beherrschen.

 

Genauso ist es mit ITIL. ITIL lebt vom Teamwork und den individuellen Fähigkeiten der einzelnen Mitarbeiter und deren „Lernfähigkeit“ – sprich Einsatz und Willen. Um z.B. einen Prozess wie Incident Management einzuführen, reicht es nicht, sich den Prozess aus der ITIL-Literatur zu nehmen, den in irgendein Tool zu packen und dann zu meinen, das war es schon und alles läuft. Wie ein Prozess designt, ausgestaltet, eingeführt und gelebt wird, ist immer abhängig von den Mitarbeitern, die zur Verfügung stehen.

 

Ein Fußballtrainer kann von Kreisligaspielern keine Dribblings à la Ribery verlangen mit einem Torabschluss in den Winkel. Hier ist wahrscheinlich die einfache Taktik von Sepp Herberger gefragt: „Das Runde muss ins Eckige“ – egal wie (vgl. Volker).

 

Will ich einen ITIL-Prozess einführen, muss ich zunächst einmal fragen: Welche Mitarbeiter habe ich? Welche Fähigkeiten haben sie? Wo gibt es Defizite? Wie steht es um die Lernfähigkeit? Danach müssen die Prozesse daraufhin angepasst und das Training der Mitarbeiter intensiviert werden. Nur so kann sichergestellt werden, dass nach einer gewissen Zeit ein gutes Spiel mit herausgespielten Toren herauskommt und das Spiel nicht nur auf Grund von Glückstreffern gewonnen wird. Sprich: ein Incident sollte schnell und kompetent gelöst werden und nicht durch Try-and-Error.

 

 

Wissen, auch ITIL Wissen, gibt es heute auch kostenlos im Internet. Dieses Wissen ist aber meist auch umsonst. Denn entscheidend ist das „Gewusst wie“. Schon Johann Wolfgang von Goethe sagte: „Es ist nicht genug zu wissen, man muss es auch anwenden.“ Ich ergänze: „…richtig anwenden können.“

 

Autor: Dr. Guido Hoffmann

 

Quellen:

Volker, Das Runde muss ins Eckige, 27.6.2013, http://log-os.info/wordpress/die-quadratur-des-kreises-oder-das-runde-muss-ins-eckige/

Johann Wolfgang von Goethe, Wilhelm Meisters Wanderjahre, 1829

0 Kommentare

Fr

11

Okt

2013

ITIL in Unternehmen simulieren und spielerisch an den De-Facto Standard heranführen

Oft werden wir Berater und Trainer mit der Aussage konfrontiert „ITIL ist viel zu komplex(1)“, „das verstehen die Mitarbeiter nicht“. Ja, ITIL ist ein sehr komplexes Thema, aber ITIL kann auch spielerisch vermittelt werden. 

ITIL als Simulation. Sie werden sich jetzt denken „Was simulieren die?“ In einer Simulation wird versucht den Mitarbeitern, weit ab von der IT, das Thema ITIL näher zu bringen. Jede größere ATO (akkreditierte Trainings Organisation) hat solch eine Simulation im Portfolio. Sei es, dass sie auf den Mond fliegen, sie einen netten Abend mit ihrer Frau bei ihrem Lieblingsitaliener verbringen oder ein Schiff inklusive der Passagiere und der Ladung sicher von Hafen zu Hafen navigieren.

 

Letzteres versuche ich mit meinen Teilnehmern. Die Aufgabe am Anfang klingt kinderleicht. Wir besetzten das Schiff mit den üblichen Rollen (Kapitän, 1. und 2. Offizier, Maschinisten, Steuerleute, Bootsleute, der Reeder ...) und dann beginnt eigentlich auch schon das Spiel.

 

Die Aufgabe für die Crew ist es, Waren und Passagiere in den nächsten Hafen zu bringen. „Kann ja so schwer nicht sein“, denken Sie und sicherlich auch die Teilnehmer zu Beginn der Simulation. Aber hier werden die Teilnehmer sehr schnell merken, ohne ordentliche Organisation und die fehlenden Prozesse wird es zu einem Dilemma. Sie arbeiten dabei unter Zeitdruck und  der Moderator versucht, das Spiel zusätzlich zu erschweren.

 

In der ersten Runde gibt  es oft ein heilloses Durcheinander auf dem Schiff. Das ist auch gut so. Denn nun kommt ITIL ins Spiel. Oftmals erkennen die Teilnehmer schon, dass die zweite Runde besser werden muss als die erste. Aber wie genau, dass wissen sie nicht. „OK, wir müssen mehr kommunizieren und Informationswege einhalten“. Schon mal ein sehr guter Ansatz. Auch dass man Informationen wie Route und Ladelisten zu Beginn einer Reise erhält. Aber was machen wir mit den auftretenden Schwierigkeiten während der Reise?

 

Genau das ist der Einstieg in die Simulation. Es werden  Prozesse und die dazugehörigen Verantwortlichkeiten auf dem Schiff eingeführt. Für auftretende Störungen hätte ITIL den Prozess Incident Management; um genau zu wissen was und wen wir an Bord haben, dafür käme Service Asset and Configuration Management (2) ins Spiel; die Antriebswelle wird getauscht nach einem Defekt, dafür bedient man sich  am De-Facto Standard und implementiert  Change Management.

 

Natürlich wird nicht Alles gleich besser bei der nächsten Reise, aber  alle Reisen werden dokumentiert und es wird sehr schnell ersichtlich, dass eine Verbesserung eintritt. Über die komplette Simulation werden noch weitere Prozesse eingeführt und die Verantwortlichkeiten mit der Crew an Bord koordiniert.

 

Nach der letzten Runde  der Simulation werden die Abläufe auf dem Schiff  in der Regel ein Selbstläufer. Jetzt ist klar wer was macht, was passiert wann und wie wird mit  Störungen oder Problemen umgegangen?

 

Nun wird den Teilnehmern auch klar, hinter ITIL steckt viel mehr als nur vier Buchstaben und viel Dokumentation. Zum Ende der Simulation wird das ganze auf die IT des Unternehmens projiziert und da wird deutlich, wo es hakt und wo tatsächlicher Handlungsbedarf besteht.

 

Fazit:

Sollten Sie Bedenken gegenüber ITIL haben und nicht genau wissen was sich hinter dieser Abkürzung tatsächlich versteckt oder wünschen Sie sich ein spielerisches Heranführen an das Thema, dann ist eine Simulation genau das Richtige. Somit lernen Sie ITIL besser kennen und erkennen sicherlich Optimierungspotenzial in Ihren Prozessen.

 

Autor: Patrick Schiavone

 

Quellen

1 - http://www.computerwoche.de/a/wo-itil-zu-komplex-ist,1235865

2 - http://www.docusnap.com/it-dokumentation/praxis/warum-eine-itil-cmdb-fur-die-it-dokumentation-benotigt-wird    

0 Kommentare

Mi

02

Okt

2013

Request Fulfilment - Wirklich immer zusammen mit Incident Management einführen?

Viele ITIL Berater sagen, wenn wir schon Incident Management einführen, können wir auch direkt Request Fulfilment einführen. Service Anfragen gehen sowieso immer über den Service Desk.

Wenn es um IT Fragen, Hilfen oder Zurücksetzen eines Passworts geht, gilt die Antwort – „ja“. Aber der Prozess ist doch etwas mehr. Warum sollte es im Prozessmodell sonst die Frage nach „finanzieller Freigabe“ geben. Für mich verbirgt sich hinter dem Prozess eher der „Materialentnahmeschein“ für das Lager. Ein Prozess, der eigentlich in jedem Unternehmen schon immer läuft. Oft sogar mit eigenen Formularen, ob in  Papierform oder  elektronisch, z.B. als Workflow in Lotus Notes.

 

Daher die Frage: Macht es Sinn, einen bereits bestehenden und funktionierenden Prozess in die ITIL-Schablone und in ein Service Management Tool zu stecken? Kommt darauf an, sagt schon „Radio Eriwan“. Es gibt Beispiele, wo es durchaus Sinn macht. Dann liegt allerdings hinter dem Prozess ein Service- bzw. Produktkatalog.

 

Ein Beispiel: Ein Pharmaunternehmen will die Bestellung von Verbrauchs- und Ausrüstungsmaterial seiner Forschungslabore über Request Fulfilment abwickeln. Das Unternehmen hat mehrere Standorte und will das Bestell- und Lagerwesen zentralisieren, sowie seine Lieferanten einbeziehen. Jetzt sagen bestimmt viele: Das gibt es doch schon von SAP. Warum also etwas Neues erfinden? (vgl. Compliance Magazin 2008).

 

Der Charme liegt zum einen in der normalerweise einfacheren Einrichtung in einem ITSM Tool (Webinterface, Webformular, Integration in andere Prozesse wie Change und Configuration Management) (vgl. Simons, S. 76; vgl. Majer, s. 108) und zum anderen in den  geringeren Kosten (Customizing, Lizenzen).

 

Damit dies funktioniert, muss aber ein Service- oder Produktkatalog verfügbar sein, aus dem die Anwender auswählen können. Hier ist der Zugang entscheidend. Web-Publishing wird in diesem Zusammenhang immer wichtiger (vgl. Lauer). Viele ITSM Tools haben eine Web-Schnittstelle zu Online Katalogen oder verwenden Webtechnologie zur Darstellung von Produktkatalogen. Ein ganz wesentlicher Aspekt: Anwender müssen nicht nur das Produkt auswählen können, sondern sie müssen auch die Kosten dafür kennen (vgl. Schmidt/ Dohle, S. 67).

 

Unter diesem  Gesichtspunkt wird Request Fulfilment zu einem recht komplexen Prozess: Definition der Services bzw. Produkte, deren Unterstützung in  den jeweiligen Geschäftsprozessen, der finanzielle Freigabe-Workflow, Definition der Kosten und Abrechnung und der Serviceerbringung, unter Umständen mit Hilfe externer Dienstleister… alles in allem ein sehr komplexer Prozess.

 

Ein weiteres Anwendungsbeispiel ist die Baustellenausrüstung der Firma Strabag. Die gesamte IT-technische Ausrüstung einer Baustelle wird über Request Fulfilment abgewickelt. Es gibt einen Produkt- und Servicekatalog, der den Bauleitern über ein Webformular zur Verfügung steht. Hintergrund ist eine bessere und planbarere IT-Ausstattung der Baustellen (vgl. Omninet Anwendertreffen 2010).

 

Kommen wir zurück zur Ausgangsfrage: Sollte man Request Fulfilment zusammen mit Incident Management einführen? Vor dem Hintergrund, dass Request Fulfilment i.d.R. ein bestehender und funktionierender Prozess ist, ein klares Nein. Incident Management alleine ist bereits komplex genug. Darüber hinaus gibt es Prozesse, die wesentlich wichtiger für den Unternehmenserfolg sind und viel weniger ausgeprägt als Request Fulfilment, z.B. Change und Configuration Management.

 

Autor: Dr. Guido Hoffmann

 

Quellen:

Rainer Schmidt, Helge Dohle, „ITIL® V3 umsetzen“, Symposion Publishing GmbH, 2009

Christion Simons, „IT Service Management mit ITIL® V3“, 2010

Frederic Majer, „Semantisches Informationsmodel für die Betriebsunterstützung“, 2010

Compliance Magazin, www.compliancemagazine.de, 05.09.2008

Johann Lauer, www.web-publishing.biz

Omninet, Anwendertreffen 2010, www.omninet.de

0 Kommentare

Do

05

Sep

2013

BRM – Business Relationship Management, den Kunden verstehen lernen

In der überarbeiten Fassung ITIL 2011 wird in der Phase Service Strategie der neue Prozess Business Relationship Management eingeführt. Neu? Nein! Bereits in der ITIL V3 wurde über diesen Prozess geschrieben. Nur nicht in dieser Detailtiefe und nur am Rande erwähnt. Aber warum wird dieser Prozess so wichtig? 

Zunächst einmal schauen wir uns das Ziel an, welches der BRM-Prozess verfolgt: „Das Ziel von ITIL Business Relationship Management besteht im Identifizieren der Bedürfnisse bestehender und potentieller Kunden und Sicherstellen, dass diese Bedürfnisse mit geeigneten Services erfüllt werden.“

 

Machen wir das aber nicht schon?“ werden Sie sich jetzt fragen. Vielleicht trifft das zu oder Sie erfüllen diese Anforderungen nur  teilweise. Um die Wünsche und Bedürfnisse dem Kunden entsprechend erfüllen zu können, wird jemand aus den eigenen Reihen benötigt, der die Sprache der Kunden spricht.

 

Ihr Kunde kann ihnen vielleicht gar nicht genau mitteilen was er eigentlich benötigt, da er weder das  Know-how noch das  technische Verständnis hat, um seine Anforderungen in IT-Sprache klar zu formulieren. Somit ist es wichtig, dass wir genau diesen „Dolmetscher“  haben. Der Business Relationship Manager kann  das Ganze  in die Sprache der IT übersetzen.  „Übersetzungsfehler“ sollten dabei vermieden werden, um dem Kunden das zu liefern, was er gerne haben möchte. Nur so kann die resultierende Wertschöpfung gewährleistet werden. In der ITIL Version 3 sprach man von „Kunden verstehen“.

 

Dieses „Kunden verstehen“ hat man nun in diesen Prozess umgewandelt und ergänzt. Business Relationship Management ist eigentlich schon bekannt. Schauen sie sich mal diesen Cartoon dazu an (http://www.projectcartoon.com/cartoon/27). Eigentlich wird hier der ITIL Prozess BRM beschrieben.

 

Nun steckt in diesem Prozess aber weit mehr, als nur zu  Dolmetschen. Wenn man noch mal  den Cartoon zum Vergleich nimmt, lässt sich vielleicht erkennen, dass der Kunde mit dem Service unzufrieden ist. Es ist einfach nicht das, was er wollte und erwartet hat. Auch hier benötigen wir das Business Relationship Management.

 

Denn zu den weiteren Aktivitäten des Business Relationship Manager zählen:

  • Messen und Steigern der Kundenzufriedenheit
  • Bearbeiten und Überwachen von Kundenbeschwerden
  • Pflege der Kundenbeziehung und darüber die Bedürfnisse der Kunden verstehen

 

BRM ist eng mit dem Service Level Management aus der Service Design Phase verknüpft. Daher ist es nicht selten, dass der SLM auch die Rolle des BRM besetzt.

 

Fazit:

Diese intensive Kommunikation mit dem Kunden versetzt uns als Service Provider in die Lage, eng  am Kunden dran zu sein, so das Geschäft des Kunden zu kennen, die Wertschätzung der IT-Services nachzuvollziehen und die Ziele so besser unterstützen zu können und damit die Kundenzufriedenheit zu erhöhen. Wo Sie ihre Informationen herbekommen zum Thema „Was der Kunde will“ (Key Account, Vertrieb, SLM ...) und wie Sie den Prozess nennen ist egal. Wichtig für Ihren Erfolg ist, dass Sie die Sprache ihrer Kunden verstehen und somit sicherstellen können, dass die Bedürfnisse ihrer Kunden mit dem „richtigen“ Service bedient werden.

 

Autor

Patrick Schiavone

0 Kommentare

Di

27

Aug

2013

Lean ITIL – Agile ITIL: ein Widerspruch?

Ist der Begriff „Lean und Agile ITIL“ ein Widerspruch? Nach manchen Vorstellungen ist ITIL ein Synonym für Bürokratie, also alles andere als schlank und definitiv nicht agil. Aber lasst uns diese Idee jetzt ein wenig unter die Lupe nehmen.

Zunächst eine Klarstellung der Begriffe.


Lean stammt ursprünglich aus der japanischen Fertigungsindustrie und zielt auf die Effizienz im Betrieb: Pull, Kanban, kaizen, Just-in-Time sind nur ein paar Schlüsselbegriffe.

 

Agile deutet eher auf sich verändernde Situationen hin, wie Projekte oder stetig wechselnde Umgebungen. Hierfür gibt es Methoden wie Agile Project Management, Xtreme Programming, Scrum usw., die auf eine hohe Team-Produktivität durch Ansätze wie Timeboxing, Team-Entscheidungen oder Daily-Standups zielt./1/


Lean Prozesse schaffen wir durch stetige Verbesserungen, am liebsten proaktiv.


Agile Ansätze dagegen bereiten bestens darauf vor, auf neue Anforderungen zu reagieren. Beide Aspekte sind heute für den Erfolg  notwendig. Was auch gilt: Die Agilität, meine Fähigkeiten, meine Prozesse anzupassen, ist genauso wichtig wie Lean Prozesse, die durch ihre Schlankheit leichter anzupassen sind.

 


Welche ITIL-Prozesse können von lean Ansätzen profitieren? Alles aus Service Operations, wie Incident Management, Problem Management und insb. Request Fulfillment. Die höchste Effizienzsteigerung (im Sinne von Kosten-/Aufwandsersparnissen) erfolgt jedoch im Request Fulfillment, da durch die „standard operating procedures“ (SOP) für wiederkehrende Anfragen die Anzahl von Entscheidungen und die Wartezeit reduziert werden kann.


Es geht allerdings nicht nur darum, die SOPs gut zu beschreiben, sondern auch darum, wie die Arbeit erledigt wird. Pull-Prozesse (anstelle von Push) und Kanban sorgen für Arbeitseffizienz; just-in-time für die Reduktion von Überfluss. Insbesondere sorgt das Kanban-Prinzip mit der Eingrenzung der „Work in Progress“ für eine kapazitätsgerechte Arbeitsweise, d.h. die Anzahl laufender Tasks wird reduziert, damit der Gesamtdurchsatz steigt. /2/ Denn „Durchpeitschen“ verursacht langfristig nur Stress.

Das Change Management braucht m.E. eine Mischung aus Lean und  Agile Vorgehen. Der Durchlauf des Change Requests erfolgt nach lean Prinzipien. Allerdings deutet das Umsetzen des spezifischen Change selbst auf eine projektartige Situation. Hier liegt der Fokus auf dem Team und dessen Fähigkeit, gemeinsam und schnell hochwertige Anpassungen bzw. Neuentwicklungen zu erstellen.


Spielen wir den Prozessablauf doch mal durch:

  1. RFC wird eingereicht.Change Manager priorisiert und klassifiziert.
  2. Change Authority genehmigt. Damit landet der Change (je nach Priorisierung etc.) im Backlog.
  3. Das Entwicklungsteam (SW oder HW) kümmert sich um den Change erst dann, wenn es Luft in seinem Kanban-System hat.
  4. Bei der Entwicklung wenden die Teams agile Elemente wie Timeboxing, Team-Entscheidungen, Daily-Standups an und ein Product Owner ist für die zeitgerechte aber auch anforderungsgerechte Entwicklung verantwortlich.
  5. Der Release-Termin wird eingehalten. Punkt. (Wobei nach Agile Prinzipien der Scope möglicherweise kleiner ist.)


Hier haben wir eine Mischung aus Lean und Agile, welche die Effektivität jeder IT Service Management Organisation steigert. Drei Anmerkungen dazu:

  • In den Schritten 1-3 empfindet man die Bürokratie hauptsächlich in schlecht aufgebauten RFC-Formularen und im Warten auf eine Entscheidung.
  • Die Schwierigkeit einer Entscheidung liegt vor allem in der Ungewissheit (oder Unwissenheit). Fehlt  die notwendige Vorbereitung (Analyse, Business Case etc.), tut sich die Change Authority schwer.
  • Eine Person muss den Hut für die Gesamtpriorisierung auf haben, und diese Prioritäten müssen kommuniziert werden. Sonst entwickelt sich Frustration bei denen, deren Change Request ganz unten im Stapel liegt.


Ein „Lean und Agile ITIL“ ist doch machbar. Haben Sie es schon versucht? Dann bitte Ihre Erfahrungen melden. Das Redaktionsteam von ITIL.de und sicherlich andere Leser sind an den Erfahrungsaustausch interessiert.

 

-- James Lee

 


/1/ Es gibt sicherlich tausende Bücher zu diesen Themen. Im IT-Kontext habe ich von folgenden profitiert: Henrik Kniberg and Mattias Skarin, “Kanban and Scrum - Making the Most of Both,” 2010, http://www.infoq.com/minibooks/kanban-scrum-minibook; Andrew Craddock, Agile Project Management (DSDM Consortium, 2010);  David J Anderson and Arne Roock, Kanban: evolutionäres Change Management für IT-Organisationen (Heidelberg: dpunkt-Verl., 2011); Mary Poppendieck, Lean Software Development an Agile Toolkit, 12. print. (Boston [u.a.]: Addison Wesley, 2007); Ken Schwaber and Jeff Sutherland, The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game, Version 2013, http://www.scrum.org/storage/scrumguides/Scrum_Guide.pdf.


/2/ Kanban bedeutet auf Japanisch „Karte“. Die Kanban wir verwendet, um zu zeigen, dass Teile neu aufgestockt werden müssen. Sie ist dadurch Synonym für Pull-orientierte Arbeit geworden. Siehe https://de.wikipedia.org/wiki/Kanban.


Kanban Boards werden häufig in Agile-Entwicklungsumgebungen angewendet.   Die simpelste Variante sieht drei Spalten vor: Backlog, in Arbeit, fertig. Nach Kanban-Prinzipen  dürfen nur eine begrenzte Anzahl von Aufgaben  „in Arbeit“ an einem gewissen Zeitpunkt stehen. Die Begrenzung zeigt die optimale Kapazität des Teams.  Kanban Boards können auch von Einzelpersonen für Arbeitsstrukturierung angewendet werden.  Hierzu siehe Jim Benson and Tonianne De Maria Barry, Personal Kanban: Visualisierung und Planung von Aufgaben, Projekten und Terminen mit dem Kanban-Board (Heidelberg: dPunkt, 2013).


Die Eingrenzung des Work in Progress ist häufig schwer zu realisieren, da stets etwas Neues auf unserem Schreibtisch landet. Allerdings, genau wie eine Maschine unter zu hoher Last kaputt geht, gehen Menschen unter zu hohem Druck langfristig auch kaputt. Obwohl jeder Mensch eine andere Arbeitsgeschwindigkeit hat, pendelt sich auch  der Schnellste langfristig auf den persönlichen Durchschnitt ein.

1 Kommentare

Mo

19

Aug

2013

ISO 20.000 Zertifizierung - Notwendiges Ziel einer ITIL-Einführung?

Eine gute Frage, die sich aber nicht einfach mit Ja oder Nein beantworten lässt. Zunächst muss das Wesen von ITIL und ISO 20.000 klar sein und die Motivation, die hinter einer ITIL-Einführung steht.

ITIL ist ein Prozessrahmenwerk für IT Organisationen, basierend auf Best Practices. Jede IT Organisation kann das für sich Beste herausnehmen und anpassen. Aus diesem Grund sind die Prozesse in jedem Unternehmen unterschiedlich (vgl. Kittel, Koerting, Schott, S. 3f). ITIL zertifiziert aber nur Einzelpersonen und keine Unternehmen. Mit ITIL alleine können IT-Organisationen nicht nachweisen, dass sie „ITIL-konform“ arbeiten.

 

ISO 20.000 dagegen definiert Anforderungen an Service Management Prozesse in einem Unternehmen und zertifiziert sie. Dies ist somit der einzig   mögliche  objektive Nachweis, dass   ein Unternehmen IT Service Management wirklich lebt (vgl. Wallner, Dettmer).

 

Aus der Grundfrage, welche Motiviation hinter einer ITIL-Einführung steckt, ergibt sich automatisch die Antwort, ob eine ISO 20.000 Zertifizierung ein sinnvolles Ziel ist oder nicht.

 

Von Hause aus sind „IT-Organisationen oftmals träge und zäh wie Teig“ (Andermatten). Sie agieren nach dem Motto: „Never change a running system“, denn es hat in der Regel lange gedauert, bis etwas reibungslos läuft. Der Druck, dass IT-Organisationen sich ändern, kommt meist von außen: alte Betriebssysteme werden abgekündigt, Applikationen laufen aus der Wartung, neue Geschäftsanforderungen kommen hinzu, das Kundenverhalten ändert sich usw..  Genau jetzt tauchen die Probleme auf: Welche Prozesse müssen wie angepasst werden? Welche Kosten ergeben sich daraus? Welche Governance und Compliance Richtlinien müssen eingehalten werden? Doch das ist Management nach dem Ausnahmeprinzip!

 

Spätestens hier müsste klar werden, dass Service Management eine Management Aufgabe ist und die Verantwortung nicht bei den Betriebsmitarbeitern und Lieferanten liegt. Wie kann man denn etwas kontrollieren, wenn man nicht weiß, wie die Leistung erbracht und überwacht wird? Welche Ressourcen wie gebraucht werden?

 

ITIL Prozesse einzuführen mit einer Ablauf- und Aufbauorganisation, mit KPI’s, hilft nur zum Teil. Fehlt die regelmäßige externe Kontrolle und das Bewusstsein für ständige Qualitätsverbesserung, ist die Gefahr groß, in alte Strukturen zurückzufallen. Eine ISO 20.000 Zertifizierung hingegen bringt die nötige Kontrolle und fordert von einer IT-Organisation ständig steigende Qualität.

 

ISO 20.000 ein ambitioniertes Ziel? Kommt darauf an, denn die Norm stellt lediglich Mindestanforderungen an eine professionelle IT-Organisation, die ohnehin gebraucht werden. Sie verlangt keine Perfektion (vgl. ISO/IEC 20.000-1:2005 Part 1: Specification).

 

Schaut man sich einige der Mindestanforderungen an, so sagt einem schon der gesunde Menschenverstand, dass diese benötigt werden, z.B.:

  • Durch die Veränderung erforderliche neue oder veränderte Verträge und Vereinbarungen zur Berücksichtigung der Geschäftsanforderungen sind in den Umsetzungsplänen aufgenommen.
  • Die existierenden Service Management Prozesse, Verfahren und Dokumentationen werden auf notwendige Anpassungen für die geänderten Services überprüft und ggfs. in die Planung aufgenommen.
  • Das erwartete Endergebnis durch die Änderung / Neuerung ist messbar in den Umsetzungsplänen definiert.
  • Klare Richtlinien und Vorgaben für die Budgetierung, Buchführung und Rechnungsstellung sind vorhanden und enthalten alle IT Assets, Ressourcen, externe Dienstleistungen, Mitarbeiter, Versicherungen und Lizenzen.
  • Direkte und indirekte Kosten können getrennt voneinander betrachtet werden.
  • Änderungen an Services werden bepreist und durch den Change Management Prozess genehmigt.

(vgl. ISO/IEC 20.000-1:2005 Part 2: Code of Practise)

 

Ohne den Druck der Zertifizierung werden solche Aufgaben nur halbherzig wahrgenommen oder auf einen späteren Zeitpunkt verschoben, „denn es eilt nicht“. Schon ist man wieder beim Management nach dem Ausnahmeprinzip.

 

Deutlich wird, dass die größte Hürde nicht das Einhalten der Mindestanforderungen ist, sondern die Integration der Norm in das Führungssystem der IT-Organisation (vgl. Andermatten). Der Ball liegt beim Management.

 

Zurück zu unserer Ausgangsfrage: ISO 20.000 Zertifizierung als Ziel einer ITIL-Einführung? Ein ganz klares JA. Wie sonst kann man langfristig in einer IT-Organisation Transparenz schaffen, Kosten optimieren und die Qualität ständig steigern.

 

Autor: Dr. Guido Hoffmann

 

Literatur:

Georg Wallner, Klaus Dettmer, „ISO-20.000 ist schon die halbe ITIL-V3 Miete“, Computerwoche 2.6.2008

Martin Andermatten, „Der Weg zum Erfolg durch die ISO 20.000 Zertifizierung“, ITIL-Blog.ch, 25.12.2011

Martin Kittel, Torsten J. Koerting, Dirk Schött, Kompendium für ITIL Projekte, Books on Demand, Norderstett, 2010

ISO/IEC 20.000-1:2005 Part 1: Specification

ISO/IEC 20.000-1:2005 Part 2: Code of Practise

0 Kommentare

Abonnieren Sie

http://www.itil.de/rss/blog

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

ITIL Seminaranbieter expertplace academy