Zertifizierung nach ISO 20000: Projekt

Transcrição

Zertifizierung nach ISO 20000:
Projekt- und Dokumentationsmanagement
Georg Disterer, Oliver Kunert, Ingo Eibich-Meyer
Hannover, 2010
Fakultät für Wirtschaft und Informatik
GRASS-MERKUR GmbH & Co. KG
Fachhochschule Hannover
Rothwiese 5
Ricklinger Stadtweg 120
30559 Hannover
30459 Hannover
Telefon: 05 11 47 54 14 – 0
http://www.fakultaet4.fh-hannover.de
www.grass-merkur.de
[email protected]
[email protected]
Abstract
3
1 Einleitung
4
1.1 ISO 20000 als Standard für das IT Service Management
7
1.2 Inhalt und Aufbau der Norm ISO 20000
9
1.3 Vorgehen zur Zertifizierung nach ISO 20000
2 Projektmanagement zur Zertifizierung
11
16
2.1 Aufbau und Ablauf des Projekts
16
2.2 Projektpersonal
21
2.3 Werkzeuge
23
2.4 Audit
26
2.5 Projektabschluss und Erfahrungssicherung
27
3 Dokumentationsanforderungen für Change und Release Management
29
3.1 Dokumenttypen und deren Beschreibungsmerkmale
30
3.2 Dokumente im Change Prozess
33
3.3 Dokumente im Release Prozess
36
4 Zusammenfassung und Ausblick
39
Literaturverzeichnis
41
Anhang
42
Seite 3
Abstract
Die Norm ISO/IEC 20000 bietet Anbietern von IT-Dienstleistungen die Möglichkeit, ihre Vorgehensweisen an einem internationalen Standard auszurichten
und sich die Konformität mit der Norm offiziell zertifizieren zu lassen. Mittlerweile steigt die Anzahl von IT-Anbietern, die sich einem Zertifizierungsverfahren unterziehen, um mit dem Zertifikat gegenüber Kunden Vertrauen und Reputation aufzubauen. Bei Transformationsprojekten nach ISO 20000 sind gezieltes und systematisches Projekt- und Dokumentationsmanagement erfolgskritisch, um die angestrebte Prozessorientierung bei der Leistungserbringung
nachhaltig in der Organisation zu verankern. Der Beitrag gibt Hinweise für das
Projektmanagement sowie für das Dokumentenmanagement am Beispiel der
ausgewählten Prozesse Change Management und Release Management.
Seite 4
1
Einleitung
Seit Ende des Jahres 2005 existiert für die Planung, Steuerung und Kontrolle
der Leistungserbringung von IT-Dienstleistungen die Norm ISO/IEC 20000 als
internationaler Standard. Mittlerweile steigt die Anzahl der Anbieter, die sich
einem entsprechenden Zertifizierungsverfahren nach ISO 20000 unterziehen,
um damit einen Nachweis ihrer Konformität mit dem Standard zu erhalten und
diesen gegenüber ihren Kunden als Qualitätszertifikat zu führen. Ursache für
das wachsende Interesse ist die steigende Bedeutung des Einsatzes von Informationstechnik (IT) zur Unterstützung der Geschäftsprozesse und der Geschäftsabwicklung vieler Unternehmen.
Dabei nehmen IT-Abteilungen der Unternehmen nicht mehr per se eine Monopolstellung für die Leistungserbringung von IT-Dienstleistungen ein, sondern
die Beziehungen zwischen Fachabteilungen und IT-Abteilungen werden als
Kunden-/Lieferantenbeziehungen angesehen, die (auch) Markt- und Wettbewerbsmechanismen unterliegen. Somit müssen interne IT-Abteilungen zunehmend als IT-Anbieter kostenund leistungsorientiert agieren, externe Anbieters
sehen sich wachsendem Wettbewerbsdruck ausgesetzt. Für das IT-ServiceManagement, d.h. für die Planung, Steuerung und Kontrolle der Leistungserbringung von IT-Dienstleistungen, wird daher unter dem Schlagwort der „Industrialisierung der IT“1 angestrebt, wesentliche Prinzipien und Methoden der industriellen Fertigung umzusetzen, um Qualitäts- und Kostenziele zu erreichen.
Vornehmlich die Standardisierung gilt als wesentlicher Treiber der Industrialisierung der IT. Im Bereich der Hardware sowie der System- und Anwendungssoftware wurde in den vergangenen Jahrzehnten bereits eine weitgehende
Standardisierung vollzogen. Nunmehr werden von einer stärkeren Standardi-
1
Hochstein/Brenner (2006) S. 4, Walter/Böhmann/Krcmar (2007) S. 6.
Seite 5
sierung der Erstellung von IT-Dienstleistungen erhebliche Qualitäts- und Kostenverbesserungen erwartet.
Die Norm ISO 20000 folgt der Forderung nach stärkerer Standardisierung bei
der Erstellung von IT-Dienstleistungen. Daneben werden Ansätze des Qualitätsmanagements ähnlich zur Norm ISO 9000 verfolgt. Durch einen gezielten
und systematischen Einsatz einer Reihe von Instrumenten sollen die Anforderungen an die Qualität und Kosten von IT-Dienstleistungen erfüllt werden. Die
wesentlichen Instrumente sind Standardisierung, Prozessorientierung und
Qualitätsmanagement.
Die Standardisierung aller Vorgehensweisen sichert, dass Vorgänge bei der
Erstellung von IT-Dienstleistungen unabhängig von beteiligten Personen, Zeit
und Ort der Leistungserstellung ablaufen. Auf diese Weise wird die Planung,
Steuerung und Kontrolle unterstützt und eine systematische Handhabung technischer Änderungen ermöglicht, wie sie in der IT häufig vorkommen. Standardisiertes Vorgehen kann transparent dargestellt und einfach kommuniziert werden und wirkt damit nachvollziehbar, berechenbar und verlässlich. Standardisierung ist auch die Voraussetzung für interne oder externe Vergleiche der
Qualität und Kosten verschiedener IT-Anbieter sowie für eine Prüfung und Bewertung der Vorgehensweisen durch unabhängige Dritte – etwa im Zuge einer
Zertifizierung.
Eine prozessorientierte Ausrichtung der Erstellung von IT-Dienstleistungen soll
Störungen vermeiden und Friktionen vermindern. Damit folgen die Transformationsprozesse der IT dem vorherrschenden Paradigma der Prozessorientierung, um durchgängige Abläufe trotz einer in der Aufbauorganisation verankerten vertikalen Arbeitsteilung zu sichern.
In Anlehnung an Prinzipien des Qualitätsmanagements werden die Prozesse
der Erstellung von IT-Dienstleistungen laufend Prüfungen und Bewertungen
unterzogen, um ständig und nachhaltig Störungen und Friktionen zu mindern
sowie Maßnahmen der Ressourcenschonung zu identifizieren.
Seite 6
Durch ein von unabhängiger Stelle ausgegebenes Zertifikat wird ein Qualitätssiegel dafür erworben, dass die Voraussetzungen und Vorgaben einer anerkannten Organisationsnorm vom IT-Anbieter erfüllt werden. Mit regelmäßigen
Rezertifizierungen wird nachgewiesen, dass die Konformität mit der Norm kontinuierlich über einen längeren Zeitraum erreicht wird.
Der Zertifizierungsprozess erzielt intern wie extern unterschiedliche Wirkungen. Gegenüber der Unternehmensleitung kann die Zertifizierung als relativ
klar umrissenes Ziel eines aufwändigen Transformationsprozesses dienen,
dessen Erfolg am Ende klar und eindeutig durch das erlangte Zertifikat nachgewiesen werden kann. Damit werden für den Transformationsprozess ausreichende Aufmerksamkeit und Ressourcen eingeworben. Gegenüber dem beteiligten Personal dient das Ziel der Zertifizierung auch als Impuls, Verstärkung
und Ansporn, indem das Erringen des Testats als Abschluss der Transformation hervorgehoben wird. Mit dem Streben nach einer Zertifizierung wird auch
das Verankern von Prozessen des Qualitätsmanagements in der Organisation
verstärkt.
Extern dient das Zertifikat gegenüber Kunden als Nachweis durch eine unabhängige Stelle, dass alle Voraussetzungen und Vorgaben einer anerkannten
Organisationsnorm erfüllt werden. Dieser Nachweis kann als Qualitätssiegel
die Wettbewerbsfähigkeit eines IT-Anbieters steigern, wenn Kunden bei der
Auswahl von IT-Anbietern auf die Einhaltung der Norm achten, wie es etwa in
öffentlichen Vergabeverfahren häufig und bei privatwirtschaftlichen Verfahren
zunehmend zu beobachten ist. Das Zertifikat kann im Marketing des IT-Anbieters eingesetzt werden, da der Nachweis der Konformität mit anerkannten
Standards Vertrauenswürdigkeit und Verlässlichkeit signalisiert. Da die Norm
ISO 20000 noch relativ „jung“ ist, können derzeit auch Verbesserungen der
Reputation angenommen werden, wenn IT-Anbieter relativ früh („first mover“)
einem viel versprechenden Ansatz zur Verbesserung von IT-Dienstleistungen
nachgehen.
Seite 7
1.1 ISO 20000 als Standard für das IT Service Management
Die Norm ISO 20000 basiert auf dem Referenzmodell „Information Technology
Infrastructure Library“ (ITIL), das seit Ende der achtziger Jahre von der britischen Behörde Office of Government Commerce (OGC) entwickelt wird und
derzeit in Version 3 vorliegt (s. Abbildung 1). ITIL ist ein Referenz- oder Rahmenwerk für die prozessorientierte Erstellung von IT-Dienstleistungen. Dazu
enthält ITIL eine Kollektion von „Common Practices“, also eine Sammlung von
Verfahren und Vorgehensweisen, die sich in der Praxis bewährt haben. ITIL
gilt de facto als Standard zur Ausrichtung aller Aufgaben des ITSM, jedoch
liegt für ITIL keine internationale Legitimation oder offizielle Anerkennung vor.2
ISO
ISO 20000

BS
International Standard Organization
ISO
veröffentlicht: 2005-12-15
Unternehmens- u. Personenzertifikate
bisher: 421 Unternehmen weltweit,
davon 27 Unternehmen in Deutschland zertifiziert (2009-07-01)
BS 15000

British Standard Institute BSI
veröffentlicht: 11/2000
Unternehmens- u. Personenzertifikate
zurückgezogen vom BSI 12/2005 (wg.
Nachfolge durch ISO 20000)
Umstieg auf ISO 20000 bis 7/2007
möglich; Zertifikate nach BS 15000
verloren danach Gültigkeit
OGC
ITIL (V1)

Central Computer and Telecommunications Agency CCTA
veröffentlicht 1989 bis 1995
Personenzertifikate
insgesamt 31 Hauptbücher
1989
ITIL (V3)
ITIL (V2)

Office of Government Commerce
OGC (vormals: CCTA)
veröffentlicht 2000 bis 2004
Personenzertifikate
2001
2003

2005
Abbildung 1: Entstehung und Entwicklung der Norm ISO 200003
2
3
Vgl. Disterer (2009) S. 532.
Office of Government
Commerce OGC
veröffentlicht: 2007-06-05
Personenzertifikate
2007
Seite 8
In Großbritannien wurde im Jahr 2000 die nationale Norm BS 15000 als ein
Qualitätsmanagementsystem für die Erstellung von IT-Dienstleistungen veröffentlicht. An der Ausarbeitung der Norm waren viele Autoren von ITIL beteiligt,
so dass starke Überlappungen der Inhalte bestehen und die Abweichungen
zwischen BS 15000 und ITL gering sind. Auf Basis von BS 15000 war eine
Zertifizierung möglich, mit der Unternehmen die Einhaltung der Norm nachweisen konnten.
Wegen der guten Resonanz hat die britische Standardisierungsbehörde Britisch Standard Institution (BSI) im Jahr 2004 den Anerkennungsprozess der
BSI 15000 als internationalen ISO-Standard eingeleitet. Letztlich gab die International Standard Organization (ISO) Ende 2005 die Norm ISO 20000 heraus,
mit der eine weltweit anerkannte Norm für das ITSM vorliegt, nach denen sich
Unternehmen deren Einhaltung zertifizieren lassen können. Zum 1.7.2009 sind
421 Unternehmen nach ISO 20000 zertifiziert (s. Abbildung 2).
500
Σ 421
400
34
RoW (Rest of World)
242
Asien
145
Europa
Σ 308
300
21
200
Σ 151
180
7
100
Σ 76
Σ 90
5
31
6
35
6
46
33
35
38
54
2005
2006
2007
2008
Σ 69
Σ9
0
2004
BS 15000
90
107
ISO 20000
Abbildung 2: Anzahl zertifizierter Unternehmen4
4
01.01.2009
01.07.2009
Seite 9
Von den 145 in Europa zertifizierten Unternehmen stammen mit 54 relativ viele
Unternehmen in Großbritannien, teilweise dadurch zu erklären, dass dort mit
der nationalen Norm BS 15000 ein Vorläufer existierte, von dem zu ISO 20000
ein vereinfachter Übergang bis Mitte 2007 möglich war. Die relativ geringe Zahl
von 20 zertifizierten Unternehmen in U.S.A. bestätigt die derzeit gängige Annahme, dass Normen wie ISO 20000 und Referenzmodelle wie ITIL dort
(noch) keine große Aufmerksamkeit finden; gesicherte Untersuchungsergebnisse dazu liegen nicht vor. Die hohe Zahl von 242 zertifizierten Unternehmen
in Asien ist auch dadurch zu erklären, dass viele dieser IT-Anbieter ihre Leistungen im Offshoring an Unternehmen in West-Europa und Nord-Amerika anbieten und dafür mit dem Zertifikat Vertrauenswürdigkeit und Reputation signalisieren wollen. In Deutschland sind am 1.7.2009 27 Unternehmen zertifiziert5.
1.2 Inhalt und Aufbau der Norm ISO 20000
Die Norm ist kodifiziert in den beiden Dokumenten:
ISO 20000-1 Information technology - Service Management –
Part 1: Specification
ISO 20000-2 Information technology - Service Management –
Part 2: Code of practice.
Das erste Dokument spezifiziert die Vorgaben, deren Einhaltung ein Unternehmen mindestens nachweisen muss, um ein Zertifikat zu erhalten. Das zweite
Dokument enthält Leitlinien und Empfehlungen für eine Zertifizierung. Daneben
gibt es weitere Hilfestellungen von der britischen Standardisierungsorganisation British Standards Institution BSI6. Nach ISO 20000 besteht das Service Management aus einer Reihe übergeordneter Managementprozesse sowie aus
Prozessen des Service Management in fünf Bereichen (s. Abbildung 3).
5
6
Vgl. ITSMF (2009).
Vgl. Dugmore/Shirley (2006), MacFarlane/Dugmore (2006).
Seite 10
Die übergeordneten Managementprozesse sollen eine strategische Ausrichtung der Erbringung von IT-Dienstleistungen sichern, insbesondere eine Ausrichtung an den Zielen der (internen und externen) Kunden der IT-Abteilungen
sowie an Effizienz- und Wirtschaftlichkeitszielen. Im Sinne eines dezidierten
Qualitätsmanagements muss eine kontinuierliche Verbesserung der Prozesse
etabliert werden. Dabei nimmt die Norm direkten Bezug7 auf den aus dem
klassischen Qualitätsmanagement bekannten Zyklus „Plan-Do-Check-Act“
(PDCA-Cycle) von Deming, der die Notwendigkeit einer Integration der Planung betrieblichen Handels und der ständigen Überprüfung der Planumsetzung hervorhebt. Mit einem entsprechenden Prozess der kontinuierlichen Verbesserung muss nach vorgegebenen Werten für Kennzahlen und Leistungsparametern (Plan) kontinuierlich die laufende Ausführung (Do) der Prozesse überwacht (Check) und ggf. Maßnahmen zur Verbesserung (Act) identifiziert,
priorisiert, durchgeführt und kontrolliert werden.
Management Processes
Service Management Processes
Establish and communicate service
management policy, objectives and
plans
Service Delivery Processes
Capacity Management
Service Continuity and
Availability Management
Service Level Management
Service Reporting
Information Security
Management
Budgeting and Accounting
for IT Services
Control Processes
Release Processes
Configuration Management
Change Management
Resolution Processes
Release Management
Incident Management
Problem Management
Relationship
Processes
Business Relationship
Management
Supplier Management
Ensure continuing suitability, adequacy and effectiveness
Establish procedures and responsibilities for required documentation
Define and maintain service management roles and responsibilities
Manage necessary competencies
and training
Planning and implementing service
management (PDCA)
Planning and implementing new or
changed services
Abbildung 3: Prozesse nach ISO 200008
7
8
Vgl. ISO 20000-1 (2005) S. 4.
Vgl. ISO 20000-1 (2005) S. 1.
Seite 11
Für das Service Management sieht die Norm 14 Prozesse in fünf Prozessbereichen vor. Im Bereich Service Delivery wird die Erstellung von IT-Dienstleistungen gesteuert. Im Bereich „Control“ werden mit den Prozessen Configuration- und Changemanagement alle Änderungen an den Services und an der
IT-Infrastruktur gesteuert und dokumentiert. Mit Prozessen des Releasemanagements werden Einführungen neuer Versionen und Releases vorgenommen.
Dabei sind auch Abhängigkeiten und Reihenfolgebeziehungen zwischen den
Releaseständen verschiedener Systeme zu beachten und notwendige Datenoder Konfigurationsänderungen zu initiieren und zu überwachen. Die Arbeitsund Geschäftsbeziehungen zu Kunden, Benutzern und Lieferanten werden im
Relationship Management durch die Prozesse Business Relationship Management und Supplier Management bearbeitet. Im Bereich Resolution Processes
werden Störungen und Fehler im Betrieb von IT-Services behoben.
1.3 Vorgehen zur Zertifizierung nach ISO 20000
Zertifikate nach ISO 20000 werden an Unternehmen auf Antrag und nach Prüfung durch autorisierte Zertifizierungsstellen (Registered Certification Body
RCB) vergeben. In Abbildung 4 sind die generellen Phasen und Aufgaben eines solchen Zertifizierungsprojekts wiedergegeben.
Die Gesamtdauer eines Zertifizierungs-Prozesses hängt von der Größe und
Komplexität des Unternehmens ab sowie von dem Maß, in dem IT-Dienstleistungen bereits prozessorientiert erstellt werden. Wenn bereits eine Ausrichtung nach ITIL vorliegt, dann kann eine Auditierung innerhalb von 6 bis 9 Monaten vorbereitet werden, sodass die Gesamtdauer bis zur abschließenden
Zertifizierung etwa 9 bis 12 Monate betragen kann. Wenn eine Prozessorientierung nach ITIL oder ähnlichen Referenzwerken erst im Rahmen des Zertifi-
Seite 12
zierungsprojekts vorgenommen werden muss, dann kann der Zeitraum bis zu
3 Jahren dauern9.
Dokumentationsmanagement
Initiierung
Implementierung
ManagementProzesse
Vorbereitung
Implementierung
der Service
Management
Prozesse
Prüfung zur
Zertifizierung
(Audit)
Regelbetrieb
(nach Zertifizierung)
Projektmanagement

Ziele und Nutzen der Zertifizierung klären
Umfang (Scope) der angestrebten Zertifizierung festlegen
Ressourcenbedarf klären
(Grobplanung)
Projekt vorplanen
Einsatz Externer notwendig?
Unterstützung der Unternehmensleitung einholen

Servicekatalog detaillieren
Reifegrad ermitteln
Dokumentationsprozess definieren
und etablieren
Projekt planen
Ressourcenplanung durchführen (Personal,
Externe …)
Mitarbeiter schulen
Stakeholder
informieren

Prozesse für Service Improvement
einführen
Prozesse für Process Improvement
einführen
Führungs-/Berichtsu. Kontrollstruktur
implementieren
Vertragsmanagement einführen

Teilprojekt für
jeden Service
Prozess aufsetzen
und durchführen
Konsolidierung
der Ergebnisse
der Teilprojekte
Vervollständigung
der Dokumentation
Abstimmung der
Ergebnisse mit
der Unternehmensleitung

Vor-Audit
(Dokumentenprüfung)
Hinweise aus
Voraudit aufgreifen
Haupt-Audit: Dokumentenprüfung,
Interviews mit
Prozessmanagern,
Auswertung
Hinweise aus HauptAudit aufgreifen
Innen- und
Außenwirkung des
Zertifikats entfachen

Re-Zertifizierung alle 3 Jahre
Regelbetrieb mit kontinuierlicher Verbesserung
Reaktion auf Hinweise und
Mängel aus letzter Prüfung
Abbildung 4: Projekt zur Zertifizierung nach ISO 2000010
In der Initiierungsphase ist grundsätzlich zu klären, welche Ziele mit der Zertifizierung angestrebt werden, welcher Nutzen erwartet wird und welche Ressourcen (Zeit, Personal, Finanzen) - nach erster Schätzung - aufzuwenden sind. In
der Vorbereitungsphase ist festzustellen, welche der notwendigen Prozesse
des übergeordneten Managements sowie des Service-Managements bereits
eingeführt sind und in welchem Maß sie normkonform sind. Dazu ist der Servicekatalog zu erstellen bzw. zu vervollständigen und alle wichtigen Komponenten der Services zu identifizieren und deren Zusammenhänge und Abhängigkeiten aufzudecken. Die Wertschöpfungskette von Zulieferern (Suppliern) über
die internen Leistungsstellen bis zu den Kunden ist aufzunehmen. Damit ist zu
mitteln, welcher Grad der „Reife“ bei der IT-Leistungserstellung bereits vorliegt,
und in welchem Maße dieser Reifegrad für eine Zertifizierung ausreicht. Zur
9 Vgl. Disterer (2009) S. 533.
10 Vgl. Disterer (2009) S. 533.
Seite 13
Unterstützung liegen Checklisten vor11, um notwendige Änderungen zur Erfüllung der Mindestanforderungen der Norm zu erkennen.
Ein wichtiger Teil der Zertifizierungsprüfungen bezieht sich auf die Dokumentation der Prozesse. Daher ist die Dokumentation frühzeitig festzulegen, etwa
durch Vorgabe von Strukturen, Gliederungen, Mustern und Namenskonventionen sowie durch Richtlinien zur Dokumentablage, Dokumentfreigabe, Versionskontrolle und Änderungshistorie.
Bei der Implementierung der Management-Prozesse ist zuerst ein übergeordnetes Steuerungs- und Kontrollsystem festzulegen und einzuführen, das an
den Vorgaben der kontinuierlichen Verbesserung nach dem Zyklus „Plan-DoCheck-Act“ auszurichten ist. Insbesondere ist festzulegen, wie Verbesserungen der Services (Service Improvements) und der Prozesse des Service-Managements (Process Improvements) durchzuführen sind. Zur Implementierung
der Prozesse des Service-Management sind Teilprojekte zu definieren, da die
beschränkten Personalressourcen in der Regel nicht zulassen, dass alle Teilprozesse gleichzeitig eingeführt werden.
Die Prüfung zur Zertifizierung (Audit) besteht im ersten Teil aus einer Sichtprüfung aller Dokumente (Übersichten, Prozessbeschreibungen, Kennzahlen ...),
die der Zertifizierungsstelle zu übersenden sind. Diese Prüfung dient der Zertifizierungsstelle zur Vorbereitung der Hauptprüfung. Danach führen Vertreter
der Zertifizierungsstelle den zweiten Prüfungsteil in Form einer mehrtägigen
Begehung vor Ort durch. Dabei werden mit allen Verantwortlichen Interviews
geführt, in denen sie die Prozesse beschreiben, Details und Besonderheiten
erläutern, Prozessdokumentationen erklären, Kennzahlen und Leistungsparameter und deren Entwicklung begründen sowie zu erkannten Schwachstellen
und eingeleiteten Verbesserungsmaßnahmen berichten12. Abschließend er-
11 Z.B. bei ITSMF o.J.
12 Für Beispielfragen der Prüfungen siehe etwa Bock/Macek/Oberdorfer/Pumsenberger (2006) S. 253-265.
Seite 14
stellt die Zertifizierungsstelle einen Bericht, in dem das Prüfungsergebnis erläutert und ggf. Verbesserungsmaßnahmen aufgeführt sind, die bis zur nächsten Prüfung durchzuführen sind. Bei positivem Gesamtergebnis erhält das Unternehmen ein offizielles Zertifikat, das die Konformität der Erstellung von ITDienstleistungen mit den Anforderungen nach ISO 20000 bescheinigt.
Die Phase des Regelbetriebs beginnt nach Erteilung des Zertifikats, das eine
Gültigkeit von 3 Jahren besitzt. Nach Ablauf der Gültigkeit kann eine Re-Zertifizierung durchgeführt werden, die prinzipiell nach dem hier beschriebenen Vorgehen durchgeführt wird, jedoch in der Regel weniger Aufwand verursacht.
Die unterstützenden Prozesse des Projekt- und Dokumentationsmanagements
(s. Abbildung 4) sind für Unternehmen, die eine Zertifizierung anstreben, von
besonderer Bedeutung. Im Projektmanagement (s. Abschnitt 2) muss dafür gesorgt werden, dass die komplexen und heterogenen Vorgänge vor und während der Zertifizierung gezielt und koordiniert durchgeführt werden. Die Ergebnisse von Teilprojekten sind für die Projektbeteiligten und die externen Auditoren transparent darzustellen.
Die besondere Bedeutung des Dokumentationsmanagements (s. Abschnitt 3)
ist abzuleiten u.a. aus der zentralen Rolle, die die Dokumentation der ITSMProzesse bei den offiziellen Prüfungen zur Zertifizierung einnehmen. Im ersten
Teil der Audits wird eine Dokumentenprüfung durchgeführt13, bei der Vor-OrtPrüfung im zweiten Teil wird vor allem geprüft, ob die dokumentierten ITSMProzesse auch tatsächlich so „gelebt“ werden, wie sie dokumentiert sind.
Zudem muss bei Transformationsprojekten zur Einführung einer Prozessorganisation nach ISO 20000 oder anderen Referenzmodellen bei funktionsorientierten Aufbauorganisationen Wissen über Schnittstellen zu vor- und nachgelagerten Stellen und Zuständigkeiten kommuniziert werden, um „funktionale Si-
13 Vgl. Disterer (2009) S. 533 und Schmitt (2007) S. 42.
Seite 15
los“14 zu vermeiden. Eine durchgängige und einheitliche Dokumentation aller
Prozesse ist ein wesentliches Instrument für diesen Wissenstransfer. Damit
dient die Dokumentation auch als „Leitfaden“ bei der Transformation und auf
dem Weg zur Zertifizierung15.
Außerdem ist die Dokumentation von Prozessen eine mühsame und eher unbeliebte Tätigkeit, bei der vor allem die Sicherstellung der Konsistenz und Vollständigkeit schwierig ist. Daher kann ein gezieltes Dokumentationsmanagement und die Vorgabe der zu erstellenden Dokumente sowie deren Inhalt,
Struktur und Layout eine wesentliche Unterstützung darstellen.
14 Vgl. Böhmann/Krcmar (2004) S. 12, Bon et al. (2008) S. 19, ITGI (2005a) S. 11.
15 Vgl. Schmitt (2007) S. 11.
Seite 16
2
Projektmanagement zur Zertifizierung
Die Vorbereitungen eines Unternehmens auf eine Zertifizierung nach ISO
20000 sowie deren Durchführung sind wegen deren Umfang und Komplexität
unter Verwendung einer Methodik zum Projektmanagement zu steuern. Der
produktbasierte Ansatz16 der Methodik PRINCE2 (Projects in Controlled Environments 2) kommt dem Ziel der Zertifizierung insofern entgegen, dass notwendigen Dokumente für die Zertifizierung als Spezialistenprodukte im Sinne
von PRINCE2 angesehen werden können. Daher wird im Folgenden ein Vorgehen nach PRINCE2 vorausgesetzt.
2.1 Aufbau und Ablauf des Projekts
Kritisch für den Erfolg des Zertifizierungsprojekts sind der Aufbau und der Einsatz einer Projektorganisation, die Aufgaben, Rollen und Kompetenzen klar
und eindeutig verteilt. Dadurch werden für alle Beteiligten sowohl die verfügbaren Handlungsspielräume, als auch die vorgesehenen Eskalationswege deutlich. Der Aufbau eines Zertifizierungsprojekts folgt klassischen Vorgaben des
Projektmanagements17 und besteht aus den Ebenen:
Lenkungsausschuss, der die Interessen der Unternehmensleitung, des
Auftraggebers sowie weiterer betroffener Organisationseinheiten vertritt;
Projektleitung, die im wesentlichen vom Verantwortlichen für das Zertifizierungsprozesses wahrgenommen wird, ggf. unterstützt von Stabs- und
Unterstützungsstellen wie z.B. Projektbüro;
Projektteams, die unter Leitung von Teamleitern für die Durchführung der
notwendigen Projektarbeiten zuständig sind.
16 Vgl. OGC (2002) S. 2.
17 Vgl. etwa OGC (2002) S. 25-36.
Seite 17
Der Ablauf des Zertifizierungsprojekts folgt den Vorgaben nach PRINCE2.18
Danach ist bei der Projektinitialisierung zuvorderst ein Business Case für das
Vorhaben zu erstellen19. Der Business Case stellt die wirtschaftliche Rechtfertigung der Durchführung des Zertifizierungsprojekts dar und beschreibt detailliert die Ziele und Nutzeffekte, die vom Unternehmen mit der Zertifizierung angestrebt bzw. erwartet werden20. Die Einhaltung der Ziele und Erwartungen
wird während der Projektdurchführung permanent verfolgt, um frühzeitig signifikante Abweichungen aufzudecken und geeignete Korrekturmaßnahmen einzuleiten. Zudem dokumentiert der Business Case Handlungsoptionen, Kostenund Zeitpläne, Risiken und Bewertungsmaßstäbe, um das Projektcontrolling zu
unterstützen. Als Beispiel könnte der Business Case Hinweise enthalten, dass
Schlüsselpersonen nicht in ausreichendem Maß Arbeitskapazitäten für das
Zertifizierungsprojekt bereitstellen können, wenn sie durch andere Tätigkeiten
zu sehr ausgelastet werden. Dazu sollte ein Bewertungsmaßstab festgelegt
werden, der z.B. festschreibt, dass diese Schlüsselpersonen mindestens zu 50
% für Projektarbeiten freizustellen sind. Im Projektverlauf ist die Einhaltung
dieser Vorgabe dann zu kontrollieren und ggf. gegenzusteuern.
Im Rahmen der Initialisierung des Zertifizierungsprojekts sind in einem Projektplan21 der Projektgegenstand, der geplante Ablauf sowie der erwartete Umfang
des Projekts festzulegen, um eine Ressourcenplanung erstellen zu können.
Dafür ist zu ermitteln, welcher Reifegrad bei den aktuellen Prozesse im Unternehmen vorliegt und in welchem Maße dieser Reifegrad für eine Zertifizierung
ausreicht. Die Bestimmung des vorliegenden Reifegrads kann auf Basis öffentlich zugänglicher Checklisten oder auf Kriterienkatalogen der vom Unternehmen ausgewählten Zertifizierungsstelle erfolgen.
18
19
20
21
Vgl. OGC (2002) S. 12.
Vgl. OGC (2002) S. 189.
Vgl. OGC (2002) S. 189-191.
Vgl. OGC (2002) S. 210-212.
Seite 18
Zur Projektsteuerung werden – nach PRINCE2 – so genannte ManagementProdukte eingesetzt, die von den eigentlichen Endprodukten des Projekts
(Spezialisten-Produkten) zu unterscheiden sind. Diese Pläne sind während der
Projektinitialisierung aufzusetzen und dann im Projektverlauf zu pflegen.
Projektplan und Phasenpläne: Auf der Basis der zu realisierenden Produkte
ist der Projektplan zu entwerfen. Hierbei sind die bestimmende Faktoren der
vorgesehene Zeithorizont sowie die Kapazitäten des Projektteams, mit denen
die Projektphasen in Dauer, Umfang und Tiefe zu bestimmen sind. Dabei werden Prozesse des übergeordneten Managements und des Service Managements zu Gruppen zusammengefasst und einzelnen Umsetzungsprojekten zur
Konzeption, Implementierung und Übergabe in den Betrieb zugewiesen.
Qualitätsplan: Der Qualitätsplan legt die Anforderungen an die Güte der zu erzeugenden Prozessbeschreibungen und -dokumente fest und enthält Festlegungen zur Gestalt und zum Detailgrad sowie zur Dokumentenlenkung. Diese
Festlegungen können als Vorgaben aus einem Qualitätsmanagementsystem
übernommen werden, sofern dies schon existiert.
Risikoprotokoll: Zur transparenten und umfassenden Risikohandhabung ist
während des Projektes ein Risikoprotokoll zu führen. Der geregelte und verfahrensbasierte Umgang mit Risiken wird damit in sachlicher und nachvollziehbarer Form durchgeführt.
Für die Umsetzungsprojekte sollte die Arbeitsteilung zwischen den Teams den
zu implementierenden Prozessen des übergeordneten Managements und des
Service Managements entsprechen, so dass jedes Team einen Prozess gestaltet und umsetzt. Wegen mangelnder Ressourcen werden meist nicht alle
Prozesse parallel umgesetzt werden können, so dass eine Reihenfolge bei der
Umsetzung der einzelnen Prozesse des Service Managements festgelegt werden muss. Diese Festlegung basiert primär auf den Analyseergebnissen zur
Feststellung des Reifegrads der vorhandenen Prozesse des Service Managements – und ist damit unternehmensspezifisch. Daneben sind inhaltliche Inter-
Seite 19
dependenzen zwischen den Prozessen zu beachten. Dabei ist möglichst dafür
zu sorgen, dass frühzeitig im Projektverlauf signifikante Prozessverbesserungen erzielt werden, um damit sowohl im Projekt als auch in der Umgebung des
Projekts positive Wirkungen freizusetzen. Abbildung 5 zeigt beispielhaft einen
Projektablauf nach PRINCE2 und weist die Phasen der Initialisierung, Umsetzung in Teilprojekten, Auditierung und des Projektabschlusses auf. Planung
und Steuerung des Gesamtprojekts sowie der Umsetzungsprojekte folgen damit der Systematik nach PRINCE2, nach der für Projekte als Kernprozesse des
Projektmanagements zu unterscheiden sind: Start und Initialisierung, Steuerung der Kernphasen, Managen der Umsetzungsprojekte, Steuerung der Phasenübergänge, sowie das Abschließen eines Projektes.22
Initialisierung
Audit
Abschluss
Kernphasen
Interne Reifegradprüfung
Projektmanagement:
Aufbau-/Ablauforganisation
Business Case
Steuerung der Umsetzungsprojekte zur Produktlieferung
Steuerung der Phasenübergänge
Ressourcenplanung
Umsetzungsprojekt
Change Management
Sichtprüfung durch
Zertifizierungsstelle
Vor-Ort-Prüfung durch
Abschlussbericht
Erfahrungssicherung
Reaktion auf Befunde und
Vorschläge zu Maßnahmen
Umsetzungsprojekt
Problem Management
Incident Management
Release Management
Beauftragung
Umsetzungsprojekt
Capacity Management
Business Relationship Mgmt
IT Service Continuity Mgmt
Availability Management
Configuration Management
Information Security Mgmt
Service Level Management
Supplier Management
Umsetzungsprojekt
Übergeordnetes Managementsystem und Qualitätssicherung
Abbildung 5: Ablauf des Zertifizierungsprojekts sowie der Teilprojekte
22 Vgl. OGC (2002) S. 195ff.
Management-Produkt nach PRINCE2
Spezialisten-Produkt nach PRINCE2
Seite 20
Bei den Umsetzungsprojekten ist die Einführung der übergeordneten Managementprozesse sowie der Qualitätssicherung von besonderer Bedeutung, da
diese ein Rahmenwerk für die Prozesse des Service Managements vorgeben.
Daher ist mit der Einführung der übergeordneten Managementprozesse sowie
der Qualitätssicherung zu beginnen und ggf. während und nach den anderen
Umsetzungsprojekten Anpassungen und Überarbeitungen vorzunehmen.
Bei der Festlegung der Reihenfolge der Umsetzungsprojekte sowie der Anzahl
parallel umzusetzender Prozesse ist die Fähigkeit der Organisation und der
beteiligten Mitarbeiter zu beachten, sich neben der alltäglichen Routine dem
Projekt zu widmen. Insbesondere ist für die Teamleiter der Umsetzungsprojekte mit einer erheblichen Belastung aus der Projektarbeit zu rechnen.
Für die einzelnen Umsetzungsprojekte für die Prozesse des Service Managements sind jeweils drei Schritte zu unterscheiden: Konzeption, Implementierung und Übergang in die Routineorganisation. Die Konzeption kann i.d.R. in
drei bis vier Workshops erfolgen, an denen die Teamleitung, die künftigen Prozessmanager sowie Experten der jeweilige Fachdomäne teilnehmen. Zur Konzeption sollten auch Beteiligte hinzugezogen werden, die wichtige Kenntnisse
zur Ausgangssituation (IST-Zustand) beitragen können. Auch Betroffene, die
Prozessänderungen eher ablehnend gegenüberstehen, sollten zur Förderung
der Akzeptanz der Arbeitsergebnisse frühzeitig eingebunden werden, um deren Einfluss aufzunehmen und ihnen Mitwirkungsmöglichkeiten einzuräumen.
Während der Implementierung werden für die Prozesse des Service Managements die notwendigen Dokumente erstellt. Dafür ist für jeden Prozess detailliert festzulegen, welche Dokumente zur Prozessdurchführung und den Nachweis der Normkonformität notwendig sind, und welchen Typus diese Dokumente haben, also etwa Prozess- und Verfahrensbeschreibungen, Festlegungen zu Records und Listen. Diese Dokumente werden nach der Nomenklatur
von PRINCE2 als Spezialistenprodukte angesehen und gelten damit als wesentliche Arbeitsergebnisse der Umsetzungsprojekte. In Abschnitt 3 sind diese
Seite 21
Dokumente exemplarisch für die Prozesse des Change und Release Management aus dem Text der Norm ISO 20000 abgeleitet.
Der neue Prozess wird dann in der Organisation bekannt gemacht und die unmittelbar Prozessbeteiligten werden von den Prozessmanagern informiert und
eingewiesen. Der Aufbau des Berichtswesens (laufendes Monitoring der Leistungen, Aufzeigen von Trends, Eskalation in Ausnahmefällen) an der Schnittstelle zum Service Management bildet den Abschluss der Implementierung.
2.2 Projektpersonal
Die Ausrichtung der Prozesse des Service Managements nach ISO 20000 bewirkt eine wesentliche Veränderung der Denk- und Arbeitsweisen und damit
des Selbstverständnisses der Mitarbeiter und der Kultur des Unternehmens.
Daher ist für ein Zertifizierungsprojekt mit verschiedenen Herausforderungen
und Barrieren zu rechnen und die personelle Besetzung des Projektteams erfolgskritisch. So ist etwa von jüngeren Mitarbeitern eine höhere Flexibilität bei
der Änderung der Denk- und Arbeitsweisen zu erwarten, ältere Mitarbeiter können dagegen eher fundierte Kenntnisse und Erfahrungen einbringen. Auch
kann eine langjährige persönliche Kenntnis der Beteiligten eine Grundlage für
vertrauensvolle Zusammenarbeit im Projekt sein.
Positiv können sich Erfahrungen von Projektmitgliedern aus Reorganisationsprojekten oder aus den Bereichen industrieller Betriebsführung auswirken. Das
Ziel einer höheren Industrialisierung - insbesondere Standardisierung - der ITProzesse wird eher negativ beeinflusst werden, wenn viele Projektmitglieder
aus Arbeitszusammenhängen stammen, in denen stark manufakturartig auf
Basis großer handwerklicher Fertigkeiten von Einzelnen gearbeitet wird. Eine
überwiegende Technikorientierung vieler Projektmitglieder wird das Erreichen
einer größeren Service- bzw. Kundenorientierung eher erschweren.
Der Bedeutung eines Zertifizierungsprojekts entsprechend sollte im Lenkungsausschuss der Auftraggeber des Projekts hochrangig vertreten sein, möglichst
Seite 22
also durch Vertreter der Geschäftsführung. Ebenso sollten jene Fachabteilungen, die zu den bedeutendsten Benutzern der IT-Systeme zu zählen sind,
durch kompetente Vertreter im Lenkungsausschuss mitwirken. Die Rolle der
Lieferanten wird i.d.R. durch die Leitung des Rechenzentrums im Lenkungsausschuss vertreten sein.
Bei der Auswahl der Projektleitung sollten ausgeprägte Kenntnisse und Erfahrungen zur Prozessorientierung nach ITIL oder ISO 20000 vorausgesetzt werden. Um die Projektleitung frei von Traditionen und Routinen der Vergangenheit agieren lassen zu können, können Berater eingesetzt werden, die die notwendigen Kenntnisse und Erfahrungen mit Zertifikaten nach ITIL oder ISO
20000 und Referenzen nachweisen können.
Die Kernaufgabe der Mitglieder des Projektteams besteht in der Erstellung der
Spezialistenprodukte, also im Wesentlichen der normkonformen Dokumentation. Während der Umsetzung werden den an den Prozessen des Service Managements beteiligten Mitarbeiter ihre Rollen und Verantwortlichkeiten nach
ISO 20000 erläutert und vermittelt werden müssen. Daher sollten zumindest
einige Mitglieder des Projektteams über fundierte Kenntnisse zu ISO 2000 verfügen und ggf. mit entsprechenden Zertifikaten nachweisen können. Bei einer
externen Projektleitung durch Berater wird das Projektteam Wissen zu internen
Zusammenhängen, technischen Abhängigkeiten und kulturellen Spezifika der
Organisation beitragen müssen.
Die Umsetzungsprojekte, die für einzelne Prozesse des Service Managements
die Konzeption, die Implementierung und den Übergang in die Routineorganisation übernehmen, sollten mit etwa 3 bis 5 Mitarbeitern besetzt werden. Davon sollte mindestens ein Mitarbeiter fundierte Kenntnisse und Erfahrungen in
dem fachlichen Bereich des jeweiligen Prozesses aufweisen. Als Teamleiter
der Umsetzungsprojekte sollten die zukünftig jeweils „zuständigen“ ProzessManager bestellt werden.
Seite 23
Zudem sind Arbeits- und Kommunikationsbeziehungen zwischen den Mitgliedern des Projektteams und der (später) für den Betrieb zuständigen Routineorganisation vorzusehen. So ist es für den Erfolg des Zertifizierungsprojekts
wichtig, so früh wie möglich Schlüsselrollen der zukünftigen Routineorganisation zu benennen. Insbesondere die steuernde, koordinierende und kontrollierende Rollen des Service Managements in der Routineorganisation sollte im
Projektverlauf frühzeitig besetzt werden, um einen reibungslosen Übergang zu
sichern.
2.3 Werkzeuge
Von den zahlreich bekannten Werkzeugen werden hier besonders relevante
diskutiert.
Ablagesystematik: Die im Verlauf eines Zertifizierungsprojekts erstellte Dokumentation sollte für alle Projektmitglieder im Zugriff stehen. Dafür ist eine Systematik notwendig, die das geordnete Einstellen von Dokumenten sowie die
schnelle Suche nach Dokumenten sichert. Bei umfangreichen und komplexen
Vorhaben kann diese Systematik von einer Software zum Dokumentenmanagement unterstützt werden, andernfalls kann eine gemeinsame Nutzung eines
zentralen Ablagesystems vorgesehen werden. Für die Systematik müssen allerdings strenge Regeln für Ablagepfade, Namenskonventionen für Ordner und
Dateien, Kennzeichnungspflichten in Dateien (z.B. zur Dokumenthistorie und
zu Bearbeitern) und zur Versionsführung vorgegeben und durchgesetzt werden. Die Systematik muss verschiedene Bearbeitungsstände (z.B. Entwurf,
Prüfung, Freigabe) berücksichtigen und beim Übergang von Prozessen in die
Routineorganisation die Überleitung der Verantwortung für die Dokumentation
vom Projektteam auf die Linienorganisation erkennbar werden lassen.
Die Struktur der Ablage folgt dabei der Systematik nach PRINCE2 (s.
Abbildung 6) und gibt auf oberster Ebene die Unterscheidung nach Management-Produkten, die die Projektdokumentation wiedergeben, und Spezialisten-
Seite 24
Produkten, die die Produktdokumentation wiedergeben23. Bei den Spezialistenprodukten stehen die Prozessbeschreibungen im Vordergrund, da sie die
normkonforme Durchführung der Prozesse des übergeordneten Managements
sowie des Service-Managements beschreiben. Für die Beschreibungen der
Prozesse des übergeordneten Managementsystems sowie der Prozesse des
Service Managements sind Verfeinerungen der Systematik nach den jeweiligen Dokumenttypen Prozessbeschreibungen, Verfahren, Records und Listen
vorzunehmen (s. Abschnitt 3 und Anhang).
Management-Produkte (nach PRINCE2)
Berichte
Meetings
Projektorganisation
Review
Risiken/Risiko-Log
Spezialisten-Produkte (nach PRINCE2)
Prozesse
Personal
Tools
Prozesse des übergeordneten Managementsystems
…
Audit
…
…
Prozesse des Service
Managements
…
…
…
Abbildung 6: Ablagestruktur
23 Vgl. OGC (2002) S. 313.
Seite 25
Jour Fix: Die Projektleitung sowie die Teamleiter bzw. Prozessverantwortlichen sollten in regelmäßigen Sitzungen zum Projektfortschritt diskutieren, um
frühzeitig Friktionen oder Verzögerungen zu erkennen. Weitere Fachexperten
können ggf. hinzugezogen werden. So kann insbesondere schnell reagiert
werden, wenn Teammitglieder Doppelbelastungen aus Routine- und Projektarbeit ausgesetzt sind. In den Umsetzungsprojekten für die Prozesse des Service Managements können während der Implementierung und des Übergangs in
die Routineorganisation die regelmäßigen Sitzungen des Projekts in die Regelkommunikation der für die neuen Prozesse verantwortlichen Linienorganisation
überführt werden.
Workshops: Zur Konzeption und Implementierung der Prozesse des Service
Managements sind gemeinsame Arbeitssitzungen aller Beteiligten geeignet,
um Inhalte und Ausprägungen von Prozessschritten zu bestimmen und geeignet zu dokumentieren. Zwischen den Workshops können notwendige Arbeiten
an die Teilnehmer delegiert werden.
Qualitätsmanagement durch SIPOC: Die Abkürzung steht für "Supplier - Input - Process - Output - Customer" und bezeichnet eine Darstellungsform aus
der Projektmanagementmethode Six Sigma, mit der in Diskussionen ein gemeinsames Verständnis zu Inhalten und Ausprägungen von Prozessen entwickelt werden kann. Darstellungen mit SIPOC-Diagrammen heben für Prozesse
ab, auf die Zulieferer, deren Leistungen Eingang in einen Prozess bilden, die
Leistungserstellung im Prozess, das Ergebnis des Prozesses sowie auf die
Kunden, die Prozessergebnisse verwenden.
Modellierungswerkzeuge: Von den Zertifizierungsstellen wird nicht der Einsatz spezieller Werkzeuge oder Software gefordert, der Einsatz herkömmlicher
klassischer Darstellungsform wie Text, Tabelle und Diagramm kann ausreichend sein. Daher können gewohnte SW-Werkzeuge (Bürosoftware für Text,
Tabelle, Grafik) für den Entwurf und die Darstellung von Prozessmodellen ein-
Seite 26
gesetzt werden, so lange Umfang und Komplexität der Prozesslandschaft nicht
spezielle Werkzeuge erforderlich werden lassen.
Mindmap: Bei der Konzeption der Inhalte und Ausprägungen von Prozessschritten kann die Darstellung von Mindmaps - ggf. mit entsprechender Software - unterstützen, die Arbeit in Workshops und Arbeitsgruppen mit hohem
Detailgrad darzustellen. Der Einsatz von Mindmaps setzt allerdings eine gewisse Vertrautheit mit dieser Arbeitsweise voraus.
Portal: Zur Unterstützung der Kommunikation während des Zertifizierungsprojekts können Projektportale oder ähnliche Kollaborationsprojekte eingesetzt
werden, insbesondere wenn die Projektmitglieder an verschiedenen Standorten arbeiten.
2.4 Audit
Zur Vorbereitung der Prüfungen im Rahmen der Zertifizierung sollte intern auf
Basis von Checklisten oder Kriterienkatalogen ermittelt werden, ob alle Prozesse einen ausreichenden Reifegrad haben.
Gemeinsam mit der vom Unternehmen ausgewählten Zertifizierungsstelle
müssen die Prüfungen (Audits) vorbereitet werden; dafür ist ein ausreichender
zeitlicher Vorlauf von mehreren Wochen vorzusehen, während dessen ein entsprechender Auftrag mit der Zertifizierungsstelle abgeschlossen und Termine
u.ä. abgesprochen werden.
Dann prüft die Zertifizierungsstelle die gesamte Prozessdokumentation im
Rahmen einer Sichtprüfung auf Normkonformität. Bei der anschließenden VorOrt-Prüfung, die einige Tage in Anspruch nehmen kann, wird die Umsetzung
der Prozessbeschreibungen und die Einhaltung aller Richtlinien und Vorgaben
gemäß der Norm sowie die Wirksamkeit des Qualitätsmanagementsystems
geprüft.
Seite 27
In einem abschließenden Bericht werden die Ergebnisse der Prüfungen dokumentiert, mögliche Befunde oder Maßnahmen zu Verbesserungspotentialen
aufgeführt – und ggf. durch die Prüfer die Empfehlung zur Zertifizierung ausgesprochen. Das Ausstellen und Überreichen des Zertifikats durch die Zertifizierungsstelle erfolgt dann zeitnah.
2.5 Projektabschluss und Erfahrungssicherung
Formal wird das Zertifizierungsprojekt abgeschlossen mit der Übergabe eines
Abschlussberichtes an den Lenkungsausschuss. Der Bericht enthält die wesentlichen Projektergebnisse, Aussagen zum Projektverlauf und zum Ressourcenverbrauch sowie Hinweise auf Befunde oder Maßnahmen zu bestehenden
Verbesserungspotentialen. Letzteres ist besonders wichtig mit Blick auf zukünftig anstehende Überwachungsaudits, damit entsprechende Arbeiten in der
Verantwortung des Service Managements systematisch durchgeführt werden.
Zusätzlich sollten am Ende Erfahrungen aus dem Zertifizierungsprojekt gezielt
gesammelt und aufbereitet werden. So können zum Beispiel im Rahmen eines
Workhops die Teamleiter oder alle Projektmitglieder Eindrücke und Erkenntnisse aus dem Projektverlauf sammeln und nach dem Motto „Positives verstärken - Negatives abschwächen“ auswerten, um daraus Lerneffekte für zukünftige Projekte zu erzielen.
Aus bisherigen Zertifizierungsprojekten können die folgend beschriebenen Erfolgsfaktoren benannt werden.
Verantwortung der Geschäftsführung: Die Einbindung und das Engagement
der Geschäftsführung ist notwendig, da erfahrungsgemäß während der Projektlaufzeit Barrieren und Hürden auftreten, weil durch das Zertifizierungsprojekt viele Denk- und Vorgehensweise im Unternehmen stark verändert werden.
Der Wandel vom individuellem Handwerk zur industriellen Fertigung bei der
Erstellung von IT-Dienstleistungen stellt eine Umwälzung dar. Die Entschei-
Seite 28
dungs- und Durchsetzungskraft der Geschäftsführung ist dann gefordert, wenn
das Projektziel der Zertifizierung gefährdet ist.
Regeln zu Verantwortungen: Die Aufgaben und Verantwortlichkeiten zu den
Prozessen des Service Managements müssen in den Umsetzungsprojekten
klar und eindeutig zu regeln. Ebenso muss die Übergabe von Projektorganisation an die Routineorganisation klar geregelt und abgegrenzt werden.
Projektcontrolling: Die Einhaltung der Zeit- und Ressourcenpläne sind konsequent zu kontrollieren, um bei Abweichungen rechtzeitig Maßnahmen einleiten
zu können. Prozeduren zur Änderung von Projektplänen müssen eingeführt
und eingehalten werden. Nach der Methodik PRINCE2 ist auch die Einhaltung
der Qualitätsziele frühzeitig und regelmäßig zu prüfen, die Prüfungsergebnisse
sind projektintern zu kommunizieren.
Einbindung externer Expertise: Ausreichend fachliche Expertise in Fragen
der prozessorientierten Organisation der IT – also etwa Kenntnisse zu ITIL oder ISO 20000 – ist nur selten in Unternehmen und Organisationen in einem
für ein Zertifizierungsprojekt ausreichendem Maße vorhanden. Zudem können
Externe als Moderatoren Personen und kritische Themen (Kultur, Tradition …)
unbefangener ansprechen. Bei der Kontrolle des Projektfortschritts sowie der
Qualität von Zwischen- und Endergebnissen der Projektarbeit hilft die neutrale
Stellung Externer, deren Hinweise und Vorschläge anzunehmen.
Werkzeugeinsatz folgt Arbeitsprozessen: Der Einsatz von Werkzeugen und
Tools sollte jedenfalls den Anforderungen der zu unterstützenden Prozesse folgen. Auch in den Unternehmen und Organisationen bereits eingeführte und
gewohnte Werkzeuge und Tools gehören auf den Prüfstand, ob sie den neuen
Anforderungen gerecht werden.
Seite 29
3
Dokumentationsanforderungen für Change und Release Management
Die folgende Beschreibung der formalen und inhaltlichen Anforderungen an die
Dokumentation stellt einen Leitfaden dar, der Transformationsprojekte zur Ausrichtung an der Norm ISO 20000 sowie zur Vorbereitung einer entsprechenden
Zertifizierungsprüfung unterstützen soll.
Die Dokumentation hat in diesen Projekten eine herausragende Rolle, da zum
Einen die Norm explizit Anforderungen an ein Dokumentationssystem beschreibt24. Zum anderen ist die Dokumentation bei den Prüfungen zur Zertifizierung von zentraler Bedeutung, da der erste Teil der Auditierung aus einer
Sichtprüfung aller Dokumente durch die Zertifizierungsstelle besteht und beim
zweiten Teil die Dokumente den Prüfern als Richtschnur dienen. Im (späteren)
laufenden Betrieb soll die Dokumentation die effektive Planung, Steuerung und
Kontrolle im Service Management sicherstellen25.
Im Folgenden werden Dokumentationsanforderungen am Beispiel der Prozesse Change Management und Release Management detailliert. Dabei wird davon ausgegangen, dass im Rahmen übergeordneter Managementprozesse folgende grundsätzliche Vorgaben ausgearbeitet und dokumentiert sind: Ziele
und Strategien des IT Service Managements26, verfügbarer organisatorischer
Rahmen (Rollen, Verantwortlichkeiten, Risikomanagement …)27, Service-Katalog mit einer Aufzählung und Beschreibung aller Services, die angestrebten
Qualitätsniveaus (Service Level) sowie den Kunden der Services28.
Die Handhabung und Lenkung aller Dokumente ist im übergeordneten Management-System festzulegen, incl. der Rollen bei der Bearbeitung (Erstellung,
Änderung, Freigabe), der Handhabung der Aufbewahrung (Aufbewahrungsort,
24
25
26
27
ISO 20000-1 S. 4.
Vgl. ISO 20000-1 S. 4.
Vgl. Bock/Macek/Oberdorfer/Pumsenberger (2006) S. 74.
Vgl. Bock/Macek/Oberdorfer/Pumsenberger (2006) S. 74.
Seite 30
Aufbewahrungsdauer, Archivierung), der Namensregeln für Dateien und Ordner sowie der Mechanismen zur Versionskontrolle29. Die Norm ISO 20000 enthält keine definitiven Vorgaben zu Handhabung und Lenkung von Dokumenten, empfehlenswert ist, die Vorschriften zu den genannten Regelungsbedarfen in Form eines Prozesses (Document Change Process) und geeigneter
Richtlinien (Document Policy) festzulegen30.
Für alle Dokumente ist sicherzustellen, dass deren Lebenszyklus von der Erstellung, Änderung, Prüfung und Ablage lückenlos dargestellt wird31. Dabei
sind verschiedene Dokumenttypen zu unterscheiden (Abschnitt 3.1).
Wegen der beschriebenen hohen Bedeutung der Dokumentation bei einer
Ausrichtung an der Organisationsnorm ISO 20000 liegt es nahe, die notwendigen Dokumente möglichst unmittelbar aus der Norm abzuleiten. Dies geschieht durch eine detaillierte Inhaltsanalyse es Textes der Norm für das
Change Management in Abschnitt 3.2 und für das Release Management in
Abschnitt 3.3.
3.1 Dokumenttypen und deren Beschreibungsmerkmale
Die notwendige Dokumentation umfasst zwei Typen von Dokumenten32. Unterlagen zu Strategien, Richtlinien, Plänen, Verträgen (incl. SLA, Underpinning
Contracts und Operational Level Agreements), sowie Beschreibungen von Prozessen und Verfahren mit normativen und präskriptiven Charakter. Zusätzlich
sind so genannte „Records“ zur Dokumentation zu zählen, die (Zwischen-) Ergebnisse von Prozessen beschreiben und damit deskriptiven Charakter besit-
28 Vgl. Schmitt (2007) S. 12.
29 Vgl. Bock/Macek/Oberdorfer/Pumsenberger (2006) S. 60 und S. 107-113, MacFarlane/Dugmore (2006) S. 15, Schmitt
(2007) S. 18.
30 Vgl. Schmitt (2007) S. 11.
31 Vgl. ISO 20000-1 S. 4; ebenso Dohle/Schmidt/Zielke/Schürmann (2009) S. 27, MacFarlane/Dugmore (2006) S. 15,
Schmitt (2007) S. 18.
32 Vgl. ISO 20000-1 S. 2-3.
Seite 31
zen, zum Beispiel Change Records als (Zwischen-)Ergebnisse im Change Prozess, die eine Änderung an der IT-Infrastruktur dokumentieren.
Für normative und präskriptive Dokumente sind beispielsweise folgende Statusinformationen entlang des Lebenszyklus zu führen, um eine lückenlose und
überschneidungsfreie Darstellung der jeweils geltenden Dokumentationsstände zu ermöglichen:
• Im Entwurf
• In Prüfung
• Freigabe erteilt
• Gültig (seit)
• Ungültig (seit).
Für Records sind folgende Statusinformationen festzuhalten, um den aktuelle
Bearbeitungsstand darzustellen:
• erfasst
• in Arbeit
• geprüft / beantragt / genehmigt
• zurückgestellt (bis)
• erledigt.
Für Records sind zudem Bewertungen und Klassifizierungen der jeweiligen
Bearbeitungsobjekte festzuhalten, um die weiteren Bearbeitungen gezielt
steuern und kontrollieren zu können. Dabei wird die Terminierung von Change
Records nach Priorität und Risiko33 vorgenommen.
Die Klassifizierung der Priorität geschieht i.d.R. auf einer 3-stufigen Skala nach
dem Schema „hoch / mittel / niedrig“ (s. Abbildung 7) oder auf entsprechenden
5-stufigen Skalen. In die Klassifizierung der Priorität fließen Bewertungen von
33 Vgl. ISO 20000-1 S. 28.
Seite 32
Dringlichkeit (urgency) und Wirkung (impact) der Änderung ein, die jeweils auf
3-stufigen Skala nach dem Schema „hoch / mittel / niedrig“ festzulegen sind.
hoch
Dringlichkeit
(urgency)
Priorität
mittel
niedrig
niedrig
mittel
hoch
Wirkung (impact)
Abbildung 7: Klassifikation der Priorität
Mit der Einflussgröße Dringlichkeit werden zeitliche Aspekte der Notwendigkeit
einer Änderung gefasst. Gesetzliche, (sicherheits-)technische oder organisatorische Vorgaben können eine sofortige Durchführung fordern oder Möglichkeiten zu einer Verschiebung einer Änderung eröffnen. Mit der Einflussgröße Wirkung werden Effekte einer Änderung auf die beim Kunden zu unterstützenden
Geschäftsprozesse und auf die Organisation und Technik im Service Management gefasst.
Das Risikokalkül, dass neben der Priorität die Terminierung von Changes beeinflusst, berücksichtigt Sicherheits- und Vermögensrisiken34 und schließt Prüfungen ein wie:
• Kann die Änderung vorher vollständig getestet werden?
• Sind die (Fern-)Wirkungen der Änderung auf die IT-Infrastruktur begrenzt
oder von geringer Komplexität?
34 Vgl. ISO 20000-2 S. 15.
Seite 33
• Sind ausreichende Kenntnisse und Erfahrungen zur Durchführung der
Änderung vorhanden?
• Sind bewährte und sichere Fallback-Verfahren einsetzbar?
• Können durch die Änderung Vermögensschäden ausgelöst werden?
Die üblicherweise in Risikokalkülen berücksichtigten Größen der Schadenshöhe und der Schadenswahrscheinlichkeit sollten herangezogen werden, auch
wenn das in der Norm nicht ausdrücklich so dargestellt ist.
Bei hoher Risikobewertung eines Changes wird bei der Terminierung die
Durchführung in unkritischen Betriebszeiten vorgesehen, umfangreichere Sicherungsmaßnahmen vorgesehen, Spezialisten mit Fachkenntnissen hinzugezogen.
3.2 Dokumente im Change Prozess
In anliegender Tabelle 1 sind aus dem entsprechenden Originaltext der Norm
(Spalte 1) die notwendigen Dokumente (Spalte 2), der Dokumenttyp (Spalte 3)
und weitere Hinweise (Spalte 4) für das Change Management abgeleitet. Der
Originaltext der Norm ist in Spalte 1 in mehrere Teilsätze zerlegt, wenn verschiedene Sachverhalte aufzunehmen sind. Ergänzend sind Hinweise auf einschlägige Fachliteratur eingetragen. Im Ergebnis ist bei den notwendigen Dokumenten zu unterscheiden zwischen Beschreibungen von Prozessen und
Verfahren, Records, Klassifikationen und Listen.
Von zentraler Bedeutung ist die Prozessbeschreibung zum Change Management, die das Vorgehen bei der Aufnahme, Bewertung und Umsetzung von
Changes beschreibt und Rollen/Verantwortlichkeiten festlegen muss. Bei diesen Festlegungen ist entscheidend, die Rollen und Verantwortlichkeiten klar
und eindeutig vorzugeben; dies kann nach dem bewährtem Schema RACI erfolgen, mit dem in Planungs- und Entscheidungsprozessen die folgenden Rollen identifiziert werden:
Seite 34
• Responsible: … für die Durchführung/Ausführung der Arbeit zuständig;
• Approver (or Approving authority): … für die Genehmigung/Abnahme der
Arbeitsergebnisse;
• Consulted: … für die Lieferung von fachlichen Details, Meinungen und
Einschätzungen zuständig;
• Informed … über den Verlauf und die Ergebnisse der Arbeit zeitnah und
vollständig zu informieren;
Entscheidend ist die eindeutige Festlegung der Rollen oder Instanzen, die Genehmigungen aussprechen dürfen. Im Normalfall wird dafür im Change Management das Change Advisory Board zuständig sein, das jedoch Entscheidungen zu klar abgegrenzten Standardänderungen auch dem verantwortlichen
Change Manager übertragen kann.
Im Change-Management-Prozess sind insbesondere die Schnittstellen zum Incident Management und zum Problem Management zu detaillieren. Die Prozessbeschreibung muss eine Ergebniskontrolle (ex ante) für Changes vorsehen. Zudem muss eine Beschreibung der Schnittstelle zum Qualitätsmanagement35 vorliegen, die Inputs und Outputs zum Qualitätsmanagementprozess
festlegt. Dabei sind Verbesserungsmöglichkeiten geregelt aufzunehmen und
weiterzuleiten. Im Rahmen einer regelmäßigen Analyse („change analysis“)
sind die Änderungen auf Muster, Ausreißer oder Alarmsignale zu untersuchen
und ggf. Maßnahmen festzulegen, deren Bearbeitung zu steuern und zu kontrollieren ist (RACI).
Ergänzend dazu muss eine Verfahrensbeschreibung für das Change Management folgende Regelungsbedarfe klären (incl. Festlegungen gemäß RACI):
• wie Änderungen an Klassifizierungen zum Bearbeitungsstand, zur Dringlichkeit, zur Wirkung und zum Risiko von Changes vorgenommen werden;
• wie Changes im Fall des Scheitern zurückgesetzt oder zurückgenommen
werden (fallback);
35 Vgl. ISO 20000-1 S. 4-5.
Seite 35
• wie im Falle von "emergency changes" vorzugehen ist und wie die Identifikation, und Handhabung derartiger Notfälle vorgenommen wird (Notfallplan);
• wie die Terminierung eines Changes vorgenommen wird; dabei ist insbesondere die Schnittstelle zum Release Management zu klären;
• wie die Terminierung aller Changes im Terminplan regelmäßig zu aktualisieren ist und die Ergebnisse an alle Beteiligten zu kommunizieren sind.
In Change Records werden alle Änderungen einzeln als (Zwischen-) Ergebnisse des Change-Management-Prozesses beschrieben. Damit sind im Change Record für jede Änderung Merkmale zu führen wie:
• Beschreibung des Ziels der Änderung;
• Angaben zu Bearbeitungsstand, Dringlichkeit, Wirkung, Risiko;
• Referenzen zu auslösenden Incidents bzw. Problems und Belege zu Dokumenten, die Change-Notwendigkeit belegen (z.B. Screenshots)36.
Für die notwendigen Beschreibungen von Änderungen in Change Records
sind Klassifikationen festzulegen, die der Systematisierung und Vergleichbarkeit der Einträge dienen. Benötigt werden Klassifizierungen für die Merkmale
Bearbeitungsstand, Dringlichkeit, Wirkung und Risiko, die auf 3-stufigen Skala
nach dem Schema „hoch / mittel / niedrig“ vorgenommen werden können (s.
Abschnitt 3.1).
In Improvement Records sind Verbesserungsmöglichkeiten zu dokumentieren und geregelt an den übergeordneten Prozess zur kontinuierlichen Verbesserung (Qualitätsmanagement) weiterzuleiten, damit diese dort verfolgt werden
können (Continual Service Improvement Plan CSIP)37.
Der Terminplan ordnet als Liste alle Änderungen den geplanten Durchführungsdaten zu („forward schedule of change“).
36 Vgl. Dugmore/Shirley (2006) S. 115.
37 Vgl. Bon/Polter/Verheijen (2008) S. 53.
Seite 36
3.3 Dokumente im Release Prozess
In anliegender Tabelle 2 sind aus dem entsprechenden Originaltext der Norm
(Spalte 1) die notwendigen Dokumente (Spalte 2), der Dokumenttyp (Spalte 3)
und weitere Hinweise (Spalte 4) für das Release Management abgeleitet. Der
Originaltext der Norm ist in Spalte 1 in mehrere Teilsätze zerlegt, wenn verschiedene Sachverhalte aufzunehmen sind. Im Ergebnis ist bei den notwendigen Dokumenten zu unterscheiden zwischen Beschreibungen von Prozessen
und Verfahren, Records, Klassifikationen und Listen.
Von zentraler Bedeutung ist die Prozessbeschreibung zum Release Management, die das Vorgehen bei der Implementierung von Releases beschreibt und
Rollen/Verantwortlichkeiten (RACI) festlegen muss. In der Prozessbeschreibung sind insbesondere die Schnittstellen zum Change Management, Configuration Management und Incident Management zu detaillieren. Dabei sind die
vorgesehenen Releases aus dem Release Management und die Changes aus
Change Management auf Kollisionen bzw. Wechselwirkungen zu prüfen. Zwischen Release, Change und Configuration Management ist das Vorgehen zur
Aktualisierung von Configuration Items festzulegen. Dem Incident Management sind rechtzeitig zur Implementierung von Releases notwendige Informationen verfügbar zu machen, u.a. zu Inhalten und Umfang, aber auch zu bekannten Einschränkungen oder Mängeln von Releases. Die Prozessbeschreibung muss eine Ergebniskontrolle (ex ante) für Releases vorsehen. Dabei sind Auswirkungen von Releases auf IT- und Kundenseite zu prüfen und
Verbesserungsmöglichkeiten ggf. geregelt aufzunehmen und weiterzuleiten.
Zudem muss eine Beschreibung der Schnittstelle zum Qualitätsmanagement38
vorliegen, die Inputs und Outputs zum Qualitätsmanagementprozess festlegt.
Verbesserungsmöglichkeiten sind geregelt aufzunehmen und weiterzuleiten.
38 Vgl. ISO 20000-1 S. 4-5.
Seite 37
Ergänzend zur Prozessbeschreibung muss eine Verfahrensbeschreibung für
das Release Management folgende Regelungsbedarfe klären incl. der Festlegungen gemäß RACI:
• in welchem Rhythmus werden Releases vorgenommen, welche ReleaseFenster stehen zur Verfügung39;
• wie wird der Release-Kalender mit Beteiligten auf IT- und Kundenseite abgestimmt;
• wie werden die notwendigen Abstimmungsprozesse zu Inhalten und Terminen von Releases mit Beteiligten auf IT- und Kundenseite durchgeführt
• wie wird ggf. ein fehlgeschlagenes Release zurückgesetzt;
• wie im Falle von Notfällen ("emergency“) und dringlichen Fällen (etwa hot
fixes) vorzugehen ist und wie die Identifikation, und Handhabung derartiger Fälle vorgenommen wird; das Verfahren ist ggf. mit dem Notfallplan
des Change Management abzustimmen;
• wie werden Releases getestet? Wie werden Testverlauf und -gebnisse
dokumentiert? Wie gesichert, dass Einsatzumgebung eines Releases
(Hard-/Software) vor und während Implementierung unverändert bleiben?
• Wie wird geprüft, ob das für das Release auslösende Ereignis oder Incident/Problem ausreichend gelöst wurde. Wenn der Zweck eines Releases
nicht erreicht wurde, wie wird Release modifiziert oder zurückgesetzt?
In Release Records werden alle Releases als (Zwischen-)Ergebnisse des Release-Management-Prozesses beschrieben. Dafür sind im Release Record für
jedes Record Merkmale zu führen wie:
• Inhalt/Umfang des Releases;
• vorgesehenes Implementierungsdatum;
• Release-Art (emergency/urgent/major/minor)
• auslösendes Ereignis oder Incident/Problem;
• Referenz zu betroffenen Changes, bekannten Fehlern und Problemen.
Für die notwendigen Beschreibungen von Releases sind Klassifikationen festzulegen, die der Systematisierung und Vergleichbarkeit der Einträge dienen.
Dabei ist vor allem eine geeignete Typisierung von Releases festzulegen.
Seite 38
In Improvement Records sind Verbesserungsmöglichkeiten zu dokumentieren und geregelt an übergeordneten Prozess zur kontinuierlichen Verbesserung (Qualitätsmanagement) weiterzuleiten, damit diese dort verfolgt werden
können (Continual Service Improvement Plan CSIP)40.
Der Relase-Kalender ordnet als Liste alle Releases den geplanten Implementierungsdaten zu.
39 Vgl. ISO 20000-2 S. 30.
40 Vgl. Bon/Polter/Verheijen (2008) S. 53.
Seite 39
4
Zusammenfassung und Ausblick
Seit Ende des Jahres 2005 existiert für die Planung, Steuerung und Kontrolle
der Leistungserbringung von IT-Dienstleistungen die Norm ISO/IEC 20000 als
internationaler Standard. Die Norm bietet Anbietern von IT-Dienstleistungen
die Möglichkeit, ihre Vorgehensweisen an einem internationalen Standard auszurichten und sich die Konformität mit dieser Norm offiziell zertifizieren zu lassen. Die Anzahl von IT-Anbietern, die sich einem Zertifizierungsverfahren unterziehen, nimmt zu. Ursache für das wachsende Interesse ist die steigende
Bedeutung des Einsatzes von Informationstechnik (IT) zur Unterstützung der
Geschäftsprozesse und der Geschäftsabwicklung vieler Unternehmen. Dabei
müssen auch interne IT-Abteilungen zunehmend als IT-Anbieter kostenund
leistungsorientiert agieren, externe Anbieters sehen sich wachsendem Wettbewerbsdruck ausgesetzt.
Für das IT-Service-Management, d.h. für die Planung, Steuerung und Kontrolle
der Leistungserbringung von IT-Dienstleistungen, wird daher die Übertragung
wesentlicher Prinzipien und Methoden der industriellen Fertigung angestrebt,
um Qualitäts- und Kostenziele zu erreichen.
Dabei werden insbesondere von einer stärkeren Standardisierung erhebliche
Verbesserungen erwartet. Die Standardisierung aller Vorgehensweisen sichert,
dass Vorgänge bei der Erstellung von IT-Dienstleistungen unabhängig von beteiligten Personen, Zeit und Ort der Leistungserstellung ablaufen. Auf diese
Weise wird die Planung, Steuerung und Kontrolle unterstützt und eine systematische Handhabung technischer Änderungen ermöglicht, wie sie in der IT
häufig vorkommen. Standardisiertes Vorgehen kann transparent dargestellt
und einfach kommuniziert werden und wirkt damit nachvollziehbar, berechenbar und verlässlich. Standardisierung ist auch die Voraussetzung für interne
oder externe Vergleiche verschiedener IT-Anbieter sowie für eine Prüfung und
Bewertung der Vorgehensweisen durch unabhängige Dritte – etwa im Zuge ei-
Seite 40
ner Zertifizierung. Durch ein von unabhängiger Stelle ausgegebenes Zertifikat
wird ein Qualitätssiegel dafür erworben, dass die Voraussetzungen und Vorgaben einer anerkannten Organisationsnorm vom IT-Anbieter erfüllt werden.
Die Norm ISO 20000 folgt dieser Forderung nach stärkerer Standardisierung
bei der Erstellung von IT-Dienstleistungen. Zugleich werden mit der Norm Ansätze des Qualitätsmanagements ähnlich zur Norm ISO 9000 verfolgt.
Allerdings sind Transformationsprojekten nach ISO 20000 umfangreiche und
komplexe Vorhaben, die ein systematisches und gezieltes Projektmanagement
erfordern. Zudem spielt die Dokumentation von Prozessen und Vorgehensweisen sowohl in den Transformationsprojekten, als auch bei Zertifizierungen und
im Betrieb eine entscheidende Rolle. Daher bieten Hinweise zum Projekt- und
Dokumentationsmanagement wichtige Unterstützung bei der Ausrichtung nach
ISO 20000.
Seite 41
Literaturverzeichnis
Bock, W., Macek, G., Oberndorfer, T., Pumsenberger, R., ITIL Zertifizierung nach BS 15000
/ ISO 20000, Bonn: Galileo, 2006.
Böhmann, T., Krcmar, H., Grundlagen und Entwicklungstrends im IT-Servicemanagement,
in: Handbuch der modernen Datenverarbeitung HMD, 2004, Nr. 237, S. 7-21.
Bon, J.v., Jong, A.d., Kolthof, A., Pieper, M., Tjassing, R., Veen, A.v.d., Verheijen, T., Foundations in IT Service Management basierend auf ITIL V3, 3. Aufl., Zaltbommel: Van
Haren, 2008.
Bon, J.v., Polter, S., Verheijen, T., ISO/IEC 20000: An Introduction, Zaltbommel: Van Haren,
2008.
Disterer, G., Zertifizierung der IT nach ISO 20000, in: Wirtschaftsinformatik, Bd. 51, 2009,
Nr. 6, S. 530-534.
Dohle, H., Schmidt, R.Z.F., Schürmann, T., ISO 20000, Heidelberg: DPunkt, 2009.
Dugmore, J., Shirley, L., A Managers' Guide to Service Management, 5. Aufl., London: British Standards Institution, 2006.
Hochstein, A., Brenner, W., Grundlagen des IT Service Management, in: IT Service Management, Bd. 1, 2006, Nr. 1, S. 3-7.
ISO/IEC 20000–1 (2005) Information technology – Service management – Part 1: Specification.
ISO/IEC 20000–2 (2005) Information technology – Service management – Part 2: Code of
practice.
ITGI (Hrsg.), Aligning CobiT, ITIL and ISO 17799 for Business Benefit - A Management
Briefing from ITGI and OGC, in: IT Governance Institute (Hrsg.), Rolling Meadows:
2005.
ITSMF (2009) http://www.isoiec20000certification.com. Abruf am 2009-07-01.
ITSMF (oJ) http://www.itsmf.com. Abruf am 2009-01-07.
MacFarlane, I., Dugmore, J., IT Service Management - Self-Assessment Workbook, 3. Aufl.,
London: British Standards Institution, 2006.
OGC Office of Government Commerce (Hrsg.), PRINCE2, 3. Aufl., London: 2002.
Schmitt, T., Roadmap ISO/IEC 20000 - Leitfaden für eine erfolgreiche Zertifizierung, Sursee:
getITservices, 2007.
Walter, S.M., Böhmann, T., Krcmar, H., Industrialisierung der IT - Grundlagen, Merkmale
und Ausprägungen eines Trends, in: Handbuch der modernen Datenverarbeitung
HMD, 2007, Nr. 256, S. 6-16.
Zaddach, M., Reorganisation der IT und ISO 20000-Einführung - Lessons Learned, in: Information Management & Consulting, Bd. 22, 2007, Nr. 2, S. 87-90.
Seite 42
Anhang
Notwendige Dokumente nach ISO 20000 für das Change Management
Notwendige Dokumente nach ISO 20000 für das Release Management
Verfahren
Klassifikation
Verfahren
Klassifikation von Changes nach
Wirkung
Change-Verfahren
Klassifikation
Change-Verfahren
Verfahren
Klassifikation
Klassifikation von Changes nach Risiko
… Detailbeschreibung für jeden Change
incl. Risiko, Wirkung, Nutzen
Dringlichkeit
Change-Verfahren
Prozessbeschreibung
Prozessbeschreibung
Prozessbeschreibung Change
Management
All changes shall be reviewed for success and any actions taken after Prozessbeschreibung Change
Management
implementation.
There shall be policies and procedures to control the authorization and Notfallplan
implementation of emergency changes.
Verfahren
Verfahren
Verfahren
6
7
3
Change-Verfahren
Change-Verfahren
The change management process shall include the manner in which
the change shall be reversed or remedied if unsuccessful.
Changes shall be approved and then checked, and shall be
implemented in a controlled manner.
5
2
c Requests for changes shall be assessed for their business benefit Klassifikation von Changes nach Nutzen Klassifikation
b Requests for changes shall be assessed for their impact
a Requests for changes shall be assessed for their risk
2 Requests for changes shall be assessed for their risk, impact and
business benefit.
4
3
1
2
Satz
Einzelaussage
1
notwendiges Dokument bzw.
Dokumententyp bzw.
Ergebnis
Ergebnistyp
Objective: To ensure all changes are assessed, approved, implemented and reviewed in a controlled manner.
Detailbeschreibung für jeden Change
Record
Service and infrastructure changes shall have a clearly defined and
incl. Ziel
documented scope.
… Detailbeschreibung für jeden Change Record
1 All requests for change shall be recorded and classified, e.g. urgent,
incl. Dringlichkeit
emergency, major, minor.
Klassifikation
Bearbeitungsstand
Change-Verfahren
Verfahren
Absatz
Notwendige Dokumente nach ISO 20000 für das Change Management
Abschnitt 9.2 Control Processes / Change Management
Wie werden Einträge zu Nutzen geändert (RACI)?
Für Changes muss festgelegt werden, wie sie (fallback bei
Scheitern) zurückgesetzt o. zurückgenommen werden; RACI
… muss Vorgehen bei Entscheidung und Implementierung von
Changes festlegen (RACI); dabei sind Schnittstellen zu Incident
Management und Problem Management zu beschreiben (vgl.
ISO 20000-2 S. 28)
Prozessbeschreibung muss Ergebniskontrolle für Changes (ex
ante) vorsehen
Für "emergency changes" ist Vorgehen bei Notfällen
(Identifikation, Handhabung; RACI) festzulegen (vgl.
MacFarlane/Dugmore (2006) S. 54)
Wie werden Einträge zu Wirkung (impact) geändert (RACI)?
(vgl. Dugmore/Shirley (2006) S. 65 und S. 115)
… etwa nach "hoch / mittel / niedrig"
Wie werden Einträge zu Risiko geändert (RACI)? (vgl.
Dugmore/Shirley (2006) S. 64); Risikokalkül (Assessment) muss
fesgelegt werden sein
Wie werden Einträge zu Dringlichkeit geändert (RACI)? (vgl.
Dugmore/Shirley (2006) S. 115)
Wie werden Einträge zu Bearbeitungsstand geändert (RACI)?
(vgl. Dugmore/Shirley (2006) S. 115)
Einträge zum Bearbeitungsstand
… incl. Record-ID.
Hinweis
4
Liste
Verfahren
Change-Kalender
Terminplanung
Detailbeschreibung für jede
Verbesserungsmöglichkeit
Management
Management
Record
Prozessbeschreibung
Prozessbeschreibung
Prozessbeschreibung
Verfahren
Terminplanung
1 Change records shall be analysed regularly to detect increasing levels Prozessbeschreibung Change
of changes, frequently recurring types, emerging trends and other
Management
relevant information.
2 A schedule that contains details of all the changes approved for
implementation and their proposed implementation dates shall be
maintained and communicated to relevant parties.
1 The scheduled implementation dates of changes shall be used as the
basis for change and release scheduling.
2 The results and conclusions drawn from change analysis shall be
recorded.
Actions for improvement identified from change management shall be
10
recorded and input into a plan for improving the service.
9
8
Prozessbeschreibung muss Schnitttstelle zu Qualitätsmanagement beschreiben (incl. Inputs/Outputs), dabei
übergeordneter Qualitätsmanagementprozess nach ISO 20000
S. 4-5; Changes sind regelmäßig auf Muster, Ausreißer,
Alarmsignale zu analysieren und ggf. Maßnahmen festzulegen
Notwendige Maßnahmen aus "changes analysis" sind geregelt
zu bearbeiten (RACI)
Prozessbeschreibung muss Identifikation von Verbesserungen
und Schnitttstelle zu Qualitätsmanagement beschreiben (incl.
Inputs/Outputs), dabei übergeordneter QM-Prozess nach ISO
20000 S. 4-5
… sind an Qualitätsmanagement weiterzuleiten (Continual
Service Improvement Plan CSIP)
Change-Kalender ist regelmäßig zu aktualisieren (RACI) und an
alle Beteiligten zu kommunizieren
Für jeden Change ist Termin zur Umsetzung zu planen (RACI);
insbes. ist Schnittstelle zu RM zu beschreiben
7
6
5
4
3
1
2
2
The release policy stating the frequency and type of releases shall be
documented and agreed.
a The release policy stating the type of releases …
b The release policy … shall be documented and agreed.
Prozessbeschreibung
Dokumententyp bzw.
Ergebnistyp
3
Record
Prozessbeschreibung
Detailbeschreibung für jedes Release
incl. Release-Typ
Prozessbeschreibung Release
Management
Management
Management
1 Plans shall record the release dates and deliverables and refer to
related change requests, known errors and problems.
2 The release management process shall pass suitable information to the
incident management process.
1 Requests for change shall be assessed for their impact on release
plans.
2 Release management procedures shall include the updating and
changing of configuration information and change records.
Verfahren für Notfälle und dringliche
Fälle
3 Emergency releases shall be managed according to a defined pro-cess Klassifikation von Releases
that interfaces to the emergency change management process.
Verfahren
Klassifikation
Prozessbeschreibung
Prozessbeschreibung
Verfahren
Releaseverfahren
The process shall include the manner in which the release shall be
reversed or remedied if unsuccessful.
Verfahren
Liste
2 Plans on how to roll out the release shall be agreed and authorized by Releaseverfahren
all relevant parties, e.g. customers, users, operations and support staff.
Releasekalender
… Detailbeschreibung für jedes Release Record
incl. Release-Typ
Klassifikation von Releases
Klassifikation
Releaseverfahren
Verfahren
notwendiges Dokument bzw.
Ergebnis
Objective: To deliver, distribute and track one or more changes in a release into the live environment.
NOTE The release management process should be integrated with the Prozessbeschreibung Release
Management
configuration and change management processes.
Satz
Einzelaussage
1
1 The service provider shall plan with the business the release of
services, systems, software and hardware.
Absatz
Notwendige Dokumente nach ISO 20000 für das Release Management
Abschnitt 10.1 Release Process / Relase Management
Vorgehen in Notfällen und dringlichen Fällen (wie z.B. hot fixes)
ist festzulegen; insbes. Schnittstelle zu Notfallplan im Change
Management ("emergency changes")
… etwa nach "emergency / urgent / major / minor"
Bei Schnitttstelle zu Configuration Management ist Pflege von
Configuration Records zu detaillieren (Aktualisierung von CIs)
Vorgehen für Situation, dass fehlgeschlagenes Release
zurückgesetzt oder repariert werden muss, muss festgelegt
werden
… die Beschreibungen von Releases müssen Details enthalten
zu: Implemntierungsdatum, Release-Art, Inhalt, auslösendes
Ereignis, Referenz zu betroffenen Changes, bekannten Fehlern
und Problemen
Prozessbeschreibung muss Schnitttstelle zu Incident
Management beschreiben (incl. Inpus/Outputs)
Releases und "Liste aller Changes" (aus Change Managemen)
sind auf Kollisionen bzw. Wechselwirkungen zu prüfen
… Klassifikation von Releases nach Typ
Verfahren muss Plan/Vorgaben für Rhythmik von Releases
enthalten (vgl. ISO 20000-2 S. 30)
Releasekalender muss mit Kundenseite abgestimmt werden; für
Services, Systems, Software, Hardware; Welche Releases
werden in welchem Releasefenster ausgeführt?
Vorgehen bei Releases muss festgelegt und mit Beiteiligten
(Kunden, Benutzer, Betrieb …) abgestimmt werden; incl. RACI
Prozessbeschreibung muss Schnitttstelle zu Change
Management und Configuration Management beschreiben (incl.
Inpus/Outputs)
Hinweis
4
A controlled acceptance test environment shall be established to build
and test all releases prior to distribution.
Testverfahren
9
b Analysis shall provide input to a plan for improving the service.
Prozessbeschreibung
Record
Detailbeschreibung für jede
Verbesserungsmöglichkeit
Verfahren
Verfahren
Prozessbeschreibung
Verfahren
Verfahren
Management
1 Release and distribution shall be designed and implemented so that the Testverfahren
integrity of hardware and software is maintained during installation,
handling, packaging and delivery.
10 1 Success and failure of releases shall be measured.
Management
2 Measurements shall include incidents related to a release in the period Release-Management-Verfahren
following a release.
3 Analysis shall include assessment of the impact on the business, IT
operations and support staff resources, and shall provide input to a
plan for improving the service.
a Analysis shall include assessment of the impact on the business, Release-Management-Verfahren
IT operations and support staff resources.
8
Bei Ergebnisprüfung muss untersucht werden, ob das Release
den gewollten Zweck erfüllt hat; andernfalls: Modifikation,
Rücksetzung oder Änderung durch neues Release; Prüfung auf
Wirkung bzgl. Business, Betrieb …
Prozessbeschreibung muss Schnitttstelle zu Qualitätsmanagement beschreiben (incl. Inputs/Outputs), dabei übergeordneter
QM-Prozess nach ISO 20000 S. 4-5
… sind an Qualitätsmanagement weiterzuleiten (Continual
Service Improvement Plan CSIP)
Vorgehen zum Testen muss Prüfung vorsehen, dass
Unveränderbarkeit von Hard- und Software während Installation,
Auslieferung, Inbetriebnahme gesichert ist
Prozessbeschreibung muss Ergebnisprüfung für Releases (ex
ante) vorsehen
Bei der Ergebnisprüfung muss Beziehung zwischen Release und
auslösenden Incidents untersucht werden
Vorgehen für Build und Test von Releases ist festzulegen; incl.
Ablauf, RACI und Dokumentation der Tests/Testergebnisse
Fakultät für Wirtschaft und Informatik
GRASS-MERKUR GmbH & Co. KG
Fachhochschule Hannover
Rothwiese 5
Ricklinger Stadtweg 120
30559 Hannover
30459 Hannover
Telefon: 05 11 47 54 14 – 0
http://www.fakultaet4.fh-hannover.de
www.grass-merkur.de
[email protected]
[email protected]
Titelbild: Martin Pfeiffer, Hannover
Alle Rechte vorbehalten. Hannover, 2010
Autoren
Georg Disterer, Prof. Dr., lehrt Wirtschaftsinformatik in der Fakultät für Wirtschaft und Informatik der Fachhochschule
Hannover und arbeitet auf den Gebieten: Informationsmanagement, Projektmanagement, Wissensmanagement. Die Fachhochschule bildet über 7.000 Studierende in fünf Fakultäten
aus. In der Fakultät für Wirtschaft und Informatik werden Studiengänge der Wirtschaftinformatik, Betriebswirtschaftslehre
und Informatik angeboten. Die Studierenden profitieren von
einem intensiven Praxisbezug von Forschung und Lehre.
Oliver Kunert, Dr., Dipl.-Inf, studierte Informatik und ist zertifizierter ITIL-Experte im IT Service Management und zertifizierter Internal Auditor für ISO 20000. Nach Forschungstätigkeiten
an Hochgeschwindigkeitsnetzen berät er nun für das Unternehmen GRASS-MERKUR Kunden bei der Einführung und
Verbesserung von IT-Service Management Prozessen. Sein
Arbeitsschwerpunkt liegt dabei auf der Vorbereitung von Unternehmen auf eine Zertifizierung nach ISO 20000.
Ingo Eibich-Meyer, Dipl.-Ing., studierte Nachrichtentechnik und
ist zertifizierter ITIL-Experte im IT Service Management und
zertifizierter Internal Auditor für ISO 20000. Für GRASSMERKUR berät er Kunden in Projekten zum IT-Service Management. Der Schwerpunkt seiner Arbeiten liegt dabei in der
Auditierung von IT-Services und deren Leistungserbringung
durch IT-Organisationen.
GRASS-MERKUR GmbH & Co. KG ist ein unabhängiges Beratungs- und IT-Serviceunternehmen. GRASS-MERKUR entwirft, entwickelt und implementiert hochwertige BusinessLösungen, die mit modernsten Technologien im eigenen Rechenzentrum betrieben werden.
Das IT-Service Management ist ISO 20000 zertifiziert. Die Berater von GRASS-MERKUR
bringen bei Kunden Kompetenz und Erfahrungen aus dem eigenen RZ-Betrieb zu Themen
wie ITIL und ISO 20000 sowie Housing, Hosting und Managed Services ein.