Bewertung: 5 / 5

Stern aktivStern aktivStern aktivStern aktivStern aktiv
 

Überblick ITIL

Viele Unternehmen setzen für den IT Betrieb, bzw. die Steuerung des IT Betriebs durch die externen Provider, die IT Service Management (ITSM) Methode „Information Technology Infrastructure Library“ (ITIL) ein.
ITSM hat insgesamt den störungsfreien Betrieb der IT Anlagen im Fokus.

Hierzu definieren die Unternehmen (IT-)Services, welche sowohl messbar, als auch klar abgrenzbar sind.

ITIL nimmt für sich in Anspruch, „Best Practices“ für den IT Betrieb zusammenzutragen. Hieraus ergibt sich, dass man durch die Umsetzung der ITIL Vorgaben einen durchschnittlichen IT Betrieb implementieren kann.

ITIL definiert Anforderungen an IT Dienstleistungen, an IT-.Prozesse und letztlich auch an die IT Organisation.

Der IT Betrieb soll möglichst einheitlich und berechenbar ablaufen.

 

Während ITIL v2 noch stark an Prozessgruppen (ITIL-Sprech: Prozessdomänen) orientiert war, kommt ITIL v3 zu einer starken Ausrichtung am Lebenszyklus der Dienstleistungen, d.h. die Planung und Implementierung der Services wird gleichermaßen beachtet.

 

ITIL bietet folgende Vorteile [ITIL2007]

  • strukturierter Ansatz, was es erlaubt, ITIL schrittweise einzuführen und dabei keine wesentlichen Punkte zu übersehen.
  • gute Basis für den IT Betrieb. Es sind in ITIL kaum Dinge definiert, die man als „unnötig“ bezeichnen könnte. Daher bietet ITIL einen guten Ausgangspunkt zum Aufbau eines geordneten ITSM.
  • „in-Faktor“, kein CIO wird für die Einführung kritisiert werden, da ITIL insgesamt eine gute Presse hat.
  • Wissensverlust verhindern: Durch die umfassende Dokumentation der Prozesse kann einem plötzlichen Wissensverlust bei Kündigungen oder Wechsel von externen Mitarbeitern verhindert werden.
  • Günstige Preise: Viele Vorschriften definieren die Arbeitsprozesses, daher werden weniger „kreative Admins“ benötigt, sondern eher „folgsame Admins“, welche normalerweise einen günstigeren Tagessatz haben.
  • Karrierepfad: Durch die definierten Rollen kann der IT Betriebsmannschaft ein karrierepfad gebaut werden. Dadurch können die Mitarbeiter evtl. stärker an das Unternehmen gebunden werden.
  • Review durch Führungskräfte: Das IT Management sollte die Prozesse (eigentlich) formal Abnehmen und gewinnt dadurch (erneut) einen tiefen Einblick in die Technik. Das technische Verständnis durch das Management ist positiv zu bewerten.
  • Visualisierung von Prozessen: Die visuelle Prozessdokumentation (flow charts) helfen beim Verstehen der Vorgänge und auch bei der Fehlersuche.
  • Wortschatz: ITIL definiert einen einheitlichen Wortschatz, was Personal insgesamt leichter verfügbar macht.
  • Nachverfolgbarkeit: Durch die Dokumentation der Vorgänge können Probleme leichter analysiert werden.
  • Flexibilität: Durch einen hohen Freiheitsgrad ist es möglich, die Prozesse auf die Bedürfnisse der jeweiligen Unternehmen anzupassen.

 

Auf der anderen Seite sind folgende Nachteile zu nennen:

  • Einschränkung der Kreativität: Durch die ITIL Vorgaben ist es nicht notwendig eine echte Prozessfindung durchzuführen. Man wird kaum etwas neues oder für genau dieses Unternehmen optimales finden.
  • Teilweise mutiert die ITIL Einführung zum Hauptziel, anstatt auf die Themen zu schauen, wegen derer man ITIL einführen sollte. Daher werden Detailziele zu Gunsten einer Gießkannenstandardisierung ignoriert. Auf diese Weise kann die ITIL Einführung die versprochenen Vorteile nicht erbringen.
  • ITIL wird (dem Management) verkauft mit der Versprechung: „Wenn Du ITIL machst, wird alles gut.“ Dieses Versprechen kann ITIL nie halten. ITIL kann eine Methode sein, um einen komplexen IT Betrieb in den Griff zu bekommen und dann schrittweise zu verbessern. Bleibt ITIL eine zusätzliche Dokumentationsaufgabe für sowieso überlastete Administratoren, dann ist die ITIL Einführung nur eine Verschlechterung.
  • Externe Kosten: Ähnlich wie beim ISO 9000 Hype
  • Der Nuztenbeweis von ITIL (Einsparungen/Optimierungen) wurde in keiner uns bekannten wissenschaftlichen Studie belegt.
  • ITIL wurde eigentlich für den Betrieb von staatlichen Systemen „erfunden“. Von Bürokraten für Bürokraten. Das ist bis heute in den Prozessvorschriften spürbar.
  • Das Prozessmodell führt leicht dazu, dass die Mauern zwischen den IT Abteilungen erhöht werden.
  • Es ist kaum möglich, die Unternehmensziele über ITIL Prozesse in der IT abzubilden.
  • Das Marketing für ITIL ist so gut und nachhaltig, dass Kritik am System kaum möglich ist. (Alle Experten sagen ja, es sei ganz toll.)
  • Unter dem Strich bedeutet eine ITIL Einführung immer eine Erhöhung der Administration und damit der „Blindleistung“.

Überblick Projektmanagement

Im Gegensatz zu ITIL als spezifische ITSM Methode, betrachten wir PM im Allgemeinen. Eine Abgrenzung zu einem spezifische PM-System macht keinen Sinn, da sich die PM-Systeme heute kaum noch etwas nehmen.

Das Projekt hat die Umsetzung einer einmaligen, zeitlich begrenzten und klar definierten Aufgabe zum Ziel. Hiervon kann ein IT System betroffen sein – aber muss nicht.

Durch die Einzigartigkeit der Projekte, muss die gewählte Projektmanagement-Methode hinreichend umfangreich sein, um den notwendigen Vorrat an Prozessen, Methoden und Ergebnistypen zu definieren. Auf der anderen Seite muss die Projektmanagement-Methode so flexibel sein, dass der Projektleiter sie auf das jeweilige Projekt zuschneiden, will er nicht einen unnötige Ressourcenbindung durch unpassende Prozesse, Methoden und Ergebnistypen erzeugen.

Ein Schwerpunkt der Projektleiteraufgabe ist die abteilungsübergreifende Diskussion und die daraus folgenden Aktivitäten zur Lösung der Projektaufgabe zu moderieren.

Seine Hauptziele sind: Transparenz und Verbindlichkeit bei der Erstellung des Projektprodukts zu erreichen.

Hierzu beachtet der Projektleiter die Schnittstellen zu den Produkterstellungsprozessen (Entwicklungsmethoden in den Entwicklungsabteilungen) und Prüfmethoden (Test- und Testmanagement in den Testabteilungen).

Dabei müssen auch die entsprechenden Dokumentationen erstellt werden, die zur späteren Wartung des Projektprodukts erforderlich sind. Für den IT Betrieb ist eine entsprechende Betriebsdokumentation bereitzustellen.

 

Die Projektleiter steuern die Projekte – unter Berücksichtigung der Vorgaben durch das durch das Unternehmen vorgegebene PM-System – in geeigneter Weise.

 

ITIL schlägt Prince2 als präferiertes PM-System vor, was daran liegt, dass es vom selben „Hersteller“ vermarktet wird. Bei allen guten Eigenschaften von Prince2 – ITIL verträgt sich auch mit jedem anderen PM-System. Lediglich beim Wortschatz muss für „Nicht-Prince2-Verfahren“ evtl. nachgebessert werden, damit Begriffe im Unternehmen einheitlich verwendet werden.

Daher ist es nicht notwendig, sich auf Prince2 zu beschränken, wenn man auf der Suche nach einem passenden PM-System für das Unternehmen ist.

Schnittstelle zwischen Projekt und Betriebsprozessen

Grundsätzlich kann ein IT-Problem (ITIL-Sprech: Incident) der Auslöser für ein Projekt sein. In diesem Fall würde das Projekt in der „Klammer“ eines Request for Change/ Changes abgewickelt werden: ITIL nimmt sich des Themas über den Prozess Change Management an. Die Idee beim ITIL Change Management ist, die Zahl der Störungen durch einen Change möglichst gering zu halten.

Durch standardisierte Methoden sollen Changes möglichst schnell und kontrolliert durchgeführt werden. Die Überwachung der Change Durchführung bezieht sich auf den Prozessablauf. So gesehen kann ein Projekt (aus ITIL-Sicht) „nichts anderes“ als ein großer Change sein.

Durch diese Sichtweise werden Projekte sehr schön für die Betriebsgruppe eines Unternehmens abstrahiert.

Mit der Realität hat das natürlich genauso viel aber zu tun, als den Kauf eines Flugtickets mit der kompletten Technik und Logistik eines Flugs zu vergleichen.

Trotzdem scheint sich immer die Gefahr einzustellen, dass „Standardisierungsbestrebungen“ aus dem Betriebsbereich in den Projektbereich überschwappen. Im Management findet das Gehör, weil es ja im Betrieb auch so gut funktioniert hat.

 

In den meisten Fällen wird ein Projekt jedoch nicht auf Basis eines „Incidents“, sondern eher aus den Fachabteilungen oder aus strategischen Überlegungen gestartet.

 

Zum Projektende hin, ist dann wieder eine Verbindung zum IT Betrieb da: Ist das Projektprodukt ein IT System oder eine IT Systemänderung, wird diese nach Erstellung mit einem Change (RfC) an Produktion übergeben.

„Das Change Management bei ITIL ist für die Autorisierung von Änderungen in der IT-Infrastruktur verantwortlich und das Configuration Management für die Überwachung des Status von Konfigurationselementen (Configuration Items, CIs) in der IT Organisation.

Das Configuration Management zeigt die Beziehungen zwischen den einzelnen CIs auf, so dass die von der Änderung betroffenen Bereiche erkannt werden. Die Erfassung bzw. Dokumentation von Änderungen und der damit verbundenen Informationen in der CMDB/CMS sind Aktivitäten, die einen Abgleich zwischen den beiden Prozessen fordern.“ [ITIL2008]

Überprüfung des Change- und Projektergebnisses

Nach einem Change findet nach ITIL immer eine Erfolgsprüfung statt. Betrachtet man Projekte nun als Change, dann fühlt sich der IT Betrieb plötzlich für ein erfolgreiches Projektmanagement zuständig.

Auf der anderen Seite sind die Erfolgskriterien der Projekte nicht nur über den störungsfreien IT Betrieb, sondern auch über die Erfüllung des Business Case definiert und die Kundenzufriedenheit definiert.

Für die beiden letzteren Punkte erscheint der IT Betrieb der falsche Zuständige für eine Prüfung zu sein.

Namensgleiche Prozessgebiete

Im folgenden werden verschiedene Projektmanagementprozessgruppen mit den Handlungsvorgaben aus ITIL v3 verglichen mit dem Ziel Synergien bei der Prozessdefinition zu identifizieren. Ggf. können Ergebnistypen gemeinsam verwendet werden.

Risikomanagement

„Das Risikomanagement gehört nicht zu den Kernfunktionen von ITIL®, ist aber wegen seiner zentralen Bedeutung für die IT mit dessen Funktionen eng verknüpft. Es handelt sich hierbei um ein Überwachungssystem, das als Frühwarnsystem vor Entwicklungen warnen soll, die den Fortbestand der Organisation gefährden oder sich zumindest wesentlich auf die Vermögenslage der Organisation auswirken. Ein Risikomanagement muss, um seinen Zweck voll erfüllen zu können, die Organisation ganzheitlich betrachten und geht daher über die IT hinaus. Das Risikomanagement stellt zum Beispiel der Notfallplanung wichtige Informationen zur Risikoanalyse zur Verfügung.“ [ITIL2008]

„Das Risikomanagement teilt sich auf in die Risikoanalyse und das eigentliche Risikomanagement. Die Risikoanalyse bewertet die Risikosituation und identifiziert nicht tragbare Risiken und ermittelt zu ergreifende Gegenmaßnahmen. Im Risikomanagement selbst werden die akzeptablen und finanziell tragbaren Gegenmaßnahmen ergriffen und ihre Wirkung überwacht.“ [ITIL2008]

Risikomanagement in Projekten dient dem Zweck, Abweichungen bei der Projektdurchführung zu antizipieren und darauf zu reagieren. Hierzu werden risikoverhindernde und risikomindernde Maßnahmen definiert und bewertet.

In Abhängigkeit von des Handlungshorizonts entscheidet die Projektleitung, ob Risiken bewusst eingegangen werden oder ob Risiken von Ihrer Schadenswirkung so hoch sind, dass risikoverhindernde Maßnahmen definiert werden müssen.

Von der Idee her, sind die Tätigkeiten im ITIL und Projektmanagement ähnlich. Jedoch konzentriert sich das Risikomanagement in ITIL auf den IT Betrieb und die operativen Betriebsrisiken.

Durch die relative Homogenität der Risikosituation in einem Unternehmen eignet sich das Risikomanagement – bezogen auf den IT Betrieb – für ein hohes Maß an Normierung.

Im Projektmanagement spielen andere Faktoren eine Rolle, da jedes Projekt höchst unterschiedlich ist. Während in einem Weiterentwicklungsprojekt mit gleichen Beteiligten die Risikosituation vielleicht nur aus möglichen Zeitverzögerungen resultiert, könnte in einem anderen Neuentwicklungsprojekt das Hauptrisikopotential aus dem Zusammenspiel der Fachabteilung und einem externen Dienstleister oder einer neuen Technologie resultieren.

Während in beiden Fällen namentlich die selben Risikomanagementprozesse in Kraft treten ist die Struktur der Datenerfassung und auch die Maßnahmensteuerung höchst unterschiedlich. Daher muss jedes Vorschreiben von Ergebnistypen im Projektmanagement dazu führen, dass die Templates schon für das nächste Projekt unpassend sind.

Ein Durchsetzen von festen Templates führt damit unweigerlich zur redundanten Datenpflege im Projektmanagement, da der Projektleiter sowohl die offiziellen Templates, als auch sein für das Projekt passendes Risikomanagement betreiben muss.

Qualitätsmanagement

Qualitätsmanagement in ITIL orientiert sich am PDAC Modell. Der von Deming entwickelte PDCA-Zyklus ist ein Werkzeug, das auf allen Hierarchieebenen anzuwenden ist und auf Qualitäts- und Prozessverbesserung zielt. Er hat das Ziel, in vier Phasen Verbesserungsbedarf zu erkennen, Verbesserungen zu entwickeln und einzuführen. Der PDCA-Zyklus soll so eine ständige Weiterentwicklung im Qualitätsmanagement bewirken und einen kontinuierlichen Verbesserungsprozess in Gang halten.

Im Projektmanagement startet Qualitätsmanagement unter einem völlig anderen Voraussetzungen. Gegenstand des QMs im Projektmanagement sind analytische und konstruktive QM-Maßnahmen, welche exakt für die Projektprodukte zu definieren sind.

Die konstruktiven Maßnahmen werden oft durch stehende Prozessdefinitionen für die Produkterstellung unterstützt. Dazu gehören etwa Entwicklungsrichtlinien oder Erstellungsvorschriften für ein Projektprodukt.

Durch geänderte Umstände, wie ein anderes Projektteam, müssen diese Prozesse jeweils neu implementiert werden.

Für die analytischen Maßnahmen gilt ähnliches. Man kennt den Handlungsumfang, dieser ist aber für die Projektprodukte jeweils neu zu definieren – schon weil sich die Ansprechpartner , Skills und Zuständigkeit für jedes Projekt neu zusammensetzen.

Ein kontinuierliches QM ist im Projektmanagement schon von da her nicht möglich, da Projekte zeitlich begrenzt sind. Hier greifen beispielsweise Lessons Learned Workshops und Projekterfahrungsdatenbanken. Der PDAC-Zyklus ist hier gänzlich unangebracht, stattdessen werden fallweise Prozesse, Maßnahmen und Ergebnisse für Qualitätsplanung, Qualitätssicherung und Qualitätslenkung definiert.

Zusammenfassung

Sowohl IT Betrieb mit ITIL, als auch das Projektmanagement mit Prince2, PMI, GPM oder einer vergleichbaren Methode durchgeführt werden, unterliegen sie einer geordneten Durchführung. Die Schnittstellen zwischen Projektdurchführung und IT Betrieb sind in den Methoden klar definiert.

Ein Überschwappen von Betriebsprozessen in das Projektmanagement und umgekehrt ist zu vermeiden.

Literatur

[ITIL2008] ITIL V3-Basiswissen - Grundlagenwissen und Zertifizierungsvorbereitung für die ITIL-Foundation-Prüfung. Mit über 250 Übungsfragen und Antworten (Zertifizierungen) , Nadin Ebel, Addison-Wesley Verlag, 2008 , ISBN 978-3-8273-2599-0

[ITIL2007] Effective IT Service Management: To ITIL and Beyond! , Rob Addy, Springer Verlag, 2007, ISBN 978-3-540-73197-9