Zertifizierung nach ISO 20000: Projekt- und ... · PDF fileZertifizierung nach ISO 20000: Projekt- und Dokumentationsmanagement Georg Disterer, Oliver Kunert, Ingo Eibich-Meyer Abstract

Zertifizierung nach ISO 20000: Projekt- und Dokumentationsmanagement

Georg Disterer, Oliver Kunert, Ingo Eibich-Meyer



Hannover, 2010

Fakultät für Wirtschaft und Informatik

Fachhochschule Hannover

Ricklinger Stadtweg 120

30459 Hannover

http://www.fakultaet4.fh-hannover.de

[email protected]

GRASS-MERKUR GmbH & Co. KG

Rothwiese 5

30559 Hannover

Telefon: 05 11 47 54 14 – 0

www.grass-merkur.de

[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 11

2 Projektmanagement zur Zertifizierung 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ög-

lichkeit, ihre Vorgehensweisen an einem internationalen Standard auszurichten

und sich die Konformität mit der Norm offiziell zertifizieren zu lassen. Mittler-

weile steigt die Anzahl von IT-Anbietern, die sich einem Zertifizierungsverfah-

ren unterziehen, um mit dem Zertifikat gegenüber Kunden Vertrauen und Re-

putation aufzubauen. Bei Transformationsprojekten nach ISO 20000 sind ge-

zieltes und systematisches Projekt- und Dokumentationsmanagement erfolgs-

kritisch, 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 Infor-

mationstechnik (IT) zur Unterstützung der Geschäftsprozesse und der Ge-

schäftsabwicklung vieler Unternehmen.

Dabei nehmen IT-Abteilungen der Unternehmen nicht mehr per se eine Mono-

polstellung 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 Wettbe-

werbsmechanismen unterliegen. Somit müssen interne IT-Abteilungen zuneh-

mend als IT-Anbieter kosten- und 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 Leistungser-

bringung von IT-Dienstleistungen, wird daher unter dem Schlagwort der „Indus-

trialisierung der IT“1 angestrebt, wesentliche Prinzipien und Methoden der in-

dustriellen Fertigung umzusetzen, um Qualitäts- und Kostenziele zu erreichen.

Vornehmlich die Standardisierung gilt als wesentlicher Treiber der Industriali-

sierung der IT. Im Bereich der Hardware sowie der System- und Anwendungs-

software 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 Kos-

tenverbesserungen erwartet.

Die Norm ISO 20000 folgt der Forderung nach stärkerer Standardisierung bei

der Erstellung von IT-Dienstleistungen. Daneben werden Ansätze des Quali-

tätsmanagements ähnlich zur Norm ISO 9000 verfolgt. Durch einen gezielten

und systematischen Einsatz einer Reihe von Instrumenten sollen die Anforde-

rungen 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 tech-

nischer Änderungen ermöglicht, wie sie in der IT häufig vorkommen. Standar-

disiertes Vorgehen kann transparent dargestellt und einfach kommuniziert wer-

den und wirkt damit nachvollziehbar, berechenbar und verlässlich. Standardi-

sierung 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 Be-

wertung 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 Transforma-

tionsprozesse der IT dem vorherrschenden Paradigma der Prozessorientie-

rung, um durchgängige Abläufe trotz einer in der Aufbauorganisation veranker-

ten 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äts-

siegel dafür erworben, dass die Voraussetzungen und Vorgaben einer aner-

kannten Organisationsnorm vom IT-Anbieter erfüllt werden. Mit regelmäßigen

Rezertifizierungen wird nachgewiesen, dass die Konformität mit der Norm kon-

tinuierlich über einen längeren Zeitraum erreicht wird.

Der Zertifizierungsprozess erzielt intern wie extern unterschiedliche Wirkun-

gen. 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 nach-

gewiesen werden kann. Damit werden für den Transformationsprozess ausrei-

chende Aufmerksamkeit und Ressourcen eingeworben. Gegenüber dem betei-

ligten Personal dient das Ziel der Zertifizierung auch als Impuls, Verstärkung

und Ansporn, indem das Erringen des Testats als Abschluss der Transformati-

on 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 unab-

hä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-Anbie-

ters 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 briti-

schen Behörde Office of Government Commerce (OGC) entwickelt wird und

derzeit in Version 3 vorliegt (s. Abbildung 1). ITIL ist ein Referenz- oder Rah-

menwerk 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

OGC

1989 2003 2005 2007

ITIL (V1)Central Computer and Tele-communications Agency CCTAveröffentlicht 1989 bis 1995Personenzertifikateinsgesamt 31 Hauptbücher

ITIL (V2)Office of Government Commerce OGC (vormals: CCTA) veröffentlicht 2000 bis 2004Personenzertifikateinsgesamt 7 Hauptbücher

ITIL (V3)Office of Government Commerce OGCveröffentlicht: 2007-06-05Personenzertifikateinsgesamt 5 Hauptbücher

BS 15000British Standard Institute BSIveröffentlicht: 11/2000Unternehmens- u. Personenzertifikatezurü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

2001

ISO 20000International Standard OrganizationISOveröffentlicht: 2005-12-15Unternehmens- u. Personenzertifikatebisher: 421 Unternehmen weltweit, davon 27 Unternehmen in Deutsch-land zertifiziert (2009-07-01)

BS

ISOISO

Abbildung 1: Entstehung und Entwicklung der Norm ISO 200003

2 Vgl. Disterer (2009) S. 532. 3 Vgl. Disterer (2009) S. 531.

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öf-

fentlicht. 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 nachwei-

sen konnten.

Wegen der guten Resonanz hat die britische Standardisierungsbehörde Bri-

tisch Standard Institution (BSI) im Jahr 2004 den Anerkennungsprozess der

BSI 15000 als internationalen ISO-Standard eingeleitet. Letztlich gab die Inter-

national 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).

33 35 54107

14531 35 46

90

180

242

5 66

7

21

34

380

100

200

300

400

500

2004 2005 2006 2007 2008 01.01.2009 01.07.2009

Σ 9

Σ 69Σ 76 Σ 90

Σ 151

Σ 308

Europa

Asien

RoW (Rest of World)

ISO 20000ISO 20000BS 15000BS 15000

Σ 421

Abbildung 2: Anzahl zertifizierter Unternehmen4

4 Vgl. Disterer (2009) S. 533.

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 An-

nahme, dass Normen wie ISO 20000 und Referenzmodelle wie ITIL dort

(noch) keine große Aufmerksamkeit finden; gesicherte Untersuchungsergeb-

nisse 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 Leis-

tungen im Offshoring an Unternehmen in West-Europa und Nord-Amerika an-

bieten und dafür mit dem Zertifikat Vertrauenswürdigkeit und Reputation signa-

lisieren 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 Unterneh-

men 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 Standardisierungsorganisati-

on British Standards Institution BSI6. Nach ISO 20000 besteht das Service Ma-

nagement aus einer Reihe übergeordneter Managementprozesse sowie aus

Prozessen des Service Management in fünf Bereichen (s. Abbildung 3).

5 Vgl. ITSMF (2009). 6 Vgl. Dugmore/Shirley (2006), MacFarlane/Dugmore (2006).

Seite 10

Die übergeordneten Managementprozesse sollen eine strategische Ausrich-

tung der Erbringung von IT-Dienstleistungen sichern, insbesondere eine Aus-

richtung 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 Pla-

nung betrieblichen Handels und der ständigen Überprüfung der Planumset-

zung hervorhebt. Mit einem entsprechenden Prozess der kontinuierlichen Ver-

besserung muss nach vorgegebenen Werten für Kennzahlen und Leistungspa-

rametern (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.

Service Management ProcessesService Delivery Processes

Control Processes

Release Processes RelationshipProcesses

Resolution Processes

Management ProcessesEstablish and communicate service management policy, objectives and plans

Ensure continuing suitability, ade-quacy and effectiveness

Establish procedures and responsi-bilities for required documentation

Define and maintain service mana-gement roles and responsibilities

Manage necessary competencies and training

Planning and implementing service management (PDCA)

Planning and implementing new or changed services

Business Relationship Management

Supplier ManagementRelease Management Incident Management

Problem Management

Configuration ManagementChange Management

Capacity ManagementService Continuity and

Availability Management

Service Level ManagementService Reporting

Information Security Management

Budgeting and Accounting for IT Services

Abbildung 3: Prozesse nach ISO 200008

7 Vgl. ISO 20000-1 (2005) S. 4. 8 Vgl. ISO 20000-1 (2005) S. 1.

Seite 11

Für das Service Management sieht die Norm 14 Prozesse in fünf Prozessbe-

reichen vor. Im Bereich Service Delivery wird die Erstellung von IT-Dienstlei-

stungen gesteuert. Im Bereich „Control“ werden mit den Prozessen Configura-

tion- und Changemanagement alle Änderungen an den Services und an der

IT-Infrastruktur gesteuert und dokumentiert. Mit Prozessen des Releasemana-

gements 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 Daten-

oder Konfigurationsänderungen zu initiieren und zu überwachen. Die Arbeits-

und Geschäftsbeziehungen zu Kunden, Benutzern und Lieferanten werden im

Relationship Management durch die Prozesse Business Relationship Manage-

ment 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 ei-

nes 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-Dienst-

leistungen bereits prozessorientiert erstellt werden. Wenn bereits eine Ausrich-

tung nach ITIL vorliegt, dann kann eine Auditierung innerhalb von 6 bis 9 Mo-

naten vorbereitet werden, sodass die Gesamtdauer bis zur abschließenden

Zertifizierung etwa 9 bis 12 Monate betragen kann. Wenn eine Prozessorien-

tierung 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.

Vor-Audit(Dokumenten-prüfung)Hinweise aus Voraudit aufgreifenHaupt-Audit: Doku-mentenprüfung, Interviews mit Prozessmanagern, AuswertungHinweise aus Haupt-Audit aufgreifenInnen- und Außenwirkung des Zertifikats entfachen

Teilprojekt für jeden Service Prozess aufsetzen und durchführenKonsolidierung der Ergebnisse der TeilprojekteVervollständigung der Dokumen-tationAbstimmung der Ergebnisse mit der Unterneh-mensleitung

Prozesse für Ser-vice ImprovementeinführenProzesse für Pro-cess ImprovementeinführenFührungs-/Berichts-u. Kontrollstruktur implementierenVertragsmanage-ment einführen

Servicekatalog de-taillierenReifegrad ermittelnDokumentations-prozess definieren und etablierenProjekt planenRessourcen-planung durch-führen (Personal, Externe …)Mitarbeiter schulenStakeholder informieren

Ziele und Nutzen der Zertifizie-rung klärenUmfang (Scope) der ange-strebten Zertifizierung fest-legenRessourcenbedarf klären (Grobplanung)Projekt vorplanenEinsatz Externer notwendig?Unterstützung der Unterneh-mensleitung einholen

Re-Zertifizierung alle 3 JahreRegelbetrieb mit kontinuier-licher VerbesserungReaktion auf Hinweise und Mängel aus letzter Prüfung

Regelbetrieb(nach Zertifizierung)Initiierung Vorbereitung Implementierung

Management-Prozesse

Implementierung der Service

Management Prozesse

Prüfung zur Zertifizierung

(Audit)

Dokumentationsmanagement

Projektmanagement

Abbildung 4: Projekt zur Zertifizierung nach ISO 2000010

In der Initiierungsphase ist grundsätzlich zu klären, welche Ziele mit der Zertifi-

zierung angestrebt werden, welcher Nutzen erwartet wird und welche Ressour-

cen (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 Servi-

cekatalog zu erstellen bzw. zu vervollständigen und alle wichtigen Komponen-

ten der Services zu identifizieren und deren Zusammenhänge und Abhängig-

keiten 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ül-

lung der Mindestanforderungen der Norm zu erkennen.

Ein wichtiger Teil der Zertifizierungsprüfungen bezieht sich auf die Dokumenta-

tion der Prozesse. Daher ist die Dokumentation frühzeitig festzulegen, etwa

durch Vorgabe von Strukturen, Gliederungen, Mustern und Namenskonventio-

nen sowie durch Richtlinien zur Dokumentablage, Dokumentfreigabe, Versi-

onskontrolle und Änderungshistorie.

Bei der Implementierung der Management-Prozesse ist zuerst ein übergeord-

netes Steuerungs- und Kontrollsystem festzulegen und einzuführen, das an

den Vorgaben der kontinuierlichen Verbesserung nach dem Zyklus „Plan-Do-

Check-Act“ auszurichten ist. Insbesondere ist festzulegen, wie Verbesserun-

gen der Services (Service Improvements) und der Prozesse des Service-Ma-

nagements (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 Teil-

prozesse 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 Zerti-

fizierungsstelle 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 Leistungspara-

meter 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 er-

läutert und ggf. Verbesserungsmaßnahmen aufgeführt sind, die bis zur nächs-

ten Prüfung durchzuführen sind. Bei positivem Gesamtergebnis erhält das Un-

ternehmen ein offizielles Zertifikat, das die Konformität der Erstellung von IT-

Dienstleistungen 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-Zertifi-

zierung durchgeführt werden, die prinzipiell nach dem hier beschriebenen Vor-

gehen 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 ge-

sorgt werden, dass die komplexen und heterogenen Vorgänge vor und wäh-

rend der Zertifizierung gezielt und koordiniert durchgeführt werden. Die Ergeb-

nisse von Teilprojekten sind für die Projektbeteiligten und die externen Audito-

ren transparent darzustellen.

Die besondere Bedeutung des Dokumentationsmanagements (s. Abschnitt 3)

ist abzuleiten u.a. aus der zentralen Rolle, die die Dokumentation der ITSM-

Prozesse bei den offiziellen Prüfungen zur Zertifizierung einnehmen. Im ersten

Teil der Audits wird eine Dokumentenprüfung durchgeführt13, bei der Vor-Ort-

Prüfung im zweiten Teil wird vor allem geprüft, ob die dokumentierten ITSM-

Prozesse auch tatsächlich so „gelebt“ werden, wie sie dokumentiert sind.

Zudem muss bei Transformationsprojekten zur Einführung einer Prozessorga-

nisation nach ISO 20000 oder anderen Referenzmodellen bei funktionsorien-

tierten Aufbauorganisationen Wissen über Schnittstellen zu vor- und nachgela-

gerten 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 un-

beliebte Tätigkeit, bei der vor allem die Sicherstellung der Konsistenz und Voll-

ständigkeit schwierig ist. Daher kann ein gezieltes Dokumentationsmanage-

ment 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 Envi-

ronments 2) kommt dem Ziel der Zertifizierung insofern entgegen, dass not-

wendigen Dokumente für die Zertifizierung als Spezialistenprodukte im Sinne

von PRINCE2 angesehen werden können. Daher wird im Folgenden ein Vor-

gehen nach PRINCE2 vorausgesetzt.

2.1 Aufbau und Ablauf des Projekts

Kritisch für den Erfolg des Zertifizierungsprojekts sind der Aufbau und der Ein-

satz einer Projektorganisation, die Aufgaben, Rollen und Kompetenzen klar

und eindeutig verteilt. Dadurch werden für alle Beteiligten sowohl die verfügba-

ren Handlungsspielräume, als auch die vorgesehenen Eskalationswege deut-

lich. 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 Zertifizie-

rungsprozesses 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 Rechtfer-

tigung der Durchführung des Zertifizierungsprojekts dar und beschreibt detail-

liert die Ziele und Nutzeffekte, die vom Unternehmen mit der Zertifizierung an-

gestrebt bzw. erwartet werden20. Die Einhaltung der Ziele und Erwartungen

wird während der Projektdurchführung permanent verfolgt, um frühzeitig signi-

fikante Abweichungen aufzudecken und geeignete Korrekturmaßnahmen ein-

zuleiten. Zudem dokumentiert der Business Case Handlungsoptionen, Kosten-

und 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 Projekt-

plan21 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 Unter-

nehmen vorliegt und in welchem Maße dieser Reifegrad für eine Zertifizierung

ausreicht. Die Bestimmung des vorliegenden Reifegrads kann auf Basis öffent-

lich zugänglicher Checklisten oder auf Kriterienkatalogen der vom Unterneh-

men ausgewählten Zertifizierungsstelle erfolgen.

18 Vgl. OGC (2002) S. 12. 19 Vgl. OGC (2002) S. 189. 20 Vgl. OGC (2002) S. 189-191. 21 Vgl. OGC (2002) S. 210-212.

Seite 18

Zur Projektsteuerung werden – nach PRINCE2 – so genannte Management-

Produkte 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 wer-

den Prozesse des übergeordneten Managements und des Service Manage-

ments 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 er-

zeugenden Prozessbeschreibungen und -dokumente fest und enthält Festle-

gungen 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 verfah-

rensbasierte Umgang mit Risiken wird damit in sachlicher und nachvollziehba-

rer 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 ges-

taltet 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 wer-

den muss. Diese Festlegung basiert primär auf den Analyseergebnissen zur

Feststellung des Reifegrads der vorhandenen Prozesse des Service Manage-

ments – 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 Prozessverbesserun-

gen 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, Umset-

zung in Teilprojekten, Auditierung und des Projektabschlusses auf. Planung

und Steuerung des Gesamtprojekts sowie der Umsetzungsprojekte folgen da-

mit der Systematik nach PRINCE2, nach der für Projekte als Kernprozesse des

Projektmanagements zu unterscheiden sind: Start und Initialisierung, Steue-

rung der Kernphasen, Managen der Umsetzungsprojekte, Steuerung der Pha-

senübergänge, sowie das Abschließen eines Projektes.22

Umsetzungsprojekt

Initialisierung

Umsetzungsprojekt

Umsetzungsprojekt

Problem Management

IT Service Continuity Mgmt

Information Security Mgmt

Change Management

Incident Management

Release Management

Configuration Management

Service Level Management

Umsetzungsprojekt

Capacity Management

Business Relationship Mgmt

Availability Management

Supplier Management

Audit

Interne Reifegradprüfung

Beauftragung Zertifizierungsstelle

Sichtprüfung durch Zertifizierungsstelle

Vor-Ort-Prüfung durch Zertifizierungsstelle

Reaktion auf Befunde und Vorschläge zu Maßnahmen

Abschluss

Abschlussbericht

Erfahrungssicherung

Kernphasen

Steuerung der Phasen-übergänge

Steuerung der Umsetzungs-projekte zur Produktlieferung

Spezialisten-Produkt nach PRINCE2

Management-Produkt nach PRINCE2

Übergeordnetes Managementsystem und Qualitätssicherung

Projektmanagement: Aufbau-/Ablauforganisation

Business Case

Ressourcenplanung

Abbildung 5: Ablauf des Zertifizierungsprojekts sowie der Teilprojekte

22 Vgl. OGC (2002) S. 195ff.

Seite 20

Bei den Umsetzungsprojekten ist die Einführung der übergeordneten Mana-

gementprozesse 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 Umsetzungsprojek-

te mit einer erheblichen Belastung aus der Projektarbeit zu rechnen.

Für die einzelnen Umsetzungsprojekte für die Prozesse des Service Manage-

ments sind jeweils drei Schritte zu unterscheiden: Konzeption, Implementie-

rung und Übergang in die Routineorganisation. Die Konzeption kann i.d.R. in

drei bis vier Workshops erfolgen, an denen die Teamleitung, die künftigen Pro-

zessmanager sowie Experten der jeweilige Fachdomäne teilnehmen. Zur Kon-

zeption 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 de-

ren Einfluss aufzunehmen und ihnen Mitwirkungsmöglichkeiten einzuräumen.

Während der Implementierung werden für die Prozesse des Service Manage-

ments die notwendigen Dokumente erstellt. Dafür ist für jeden Prozess detail-

liert festzulegen, welche Dokumente zur Prozessdurchführung und den Nach-

weis der Normkonformität notwendig sind, und welchen Typus diese Doku-

mente haben, also etwa Prozess- und Verfahrensbeschreibungen, Festlegun-

gen zu Records und Listen. Diese Dokumente werden nach der Nomenklatur

von PRINCE2 als Spezialistenprodukte angesehen und gelten damit als we-

sentliche Arbeitsergebnisse der Umsetzungsprojekte. In Abschnitt 3 sind diese

Seite 21

Dokumente exemplarisch für die Prozesse des Change und Release Manage-

ment aus dem Text der Norm ISO 20000 abgeleitet.

Der neue Prozess wird dann in der Organisation bekannt gemacht und die un-

mittelbar Prozessbeteiligten werden von den Prozessmanagern informiert und

eingewiesen. Der Aufbau des Berichtswesens (laufendes Monitoring der Leis-

tungen, Aufzeigen von Trends, Eskalation in Ausnahmefällen) an der Schnitt-

stelle zum Service Management bildet den Abschluss der Implementierung.

2.2 Projektpersonal

Die Ausrichtung der Prozesse des Service Managements nach ISO 20000 be-

wirkt 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 er-

folgskritisch. So ist etwa von jüngeren Mitarbeitern eine höhere Flexibilität bei

der Änderung der Denk- und Arbeitsweisen zu erwarten, ältere Mitarbeiter kön-

nen 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 Reorganisations-

projekten oder aus den Bereichen industrieller Betriebsführung auswirken. Das

Ziel einer höheren Industrialisierung - insbesondere Standardisierung - der IT-

Prozesse 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 Lenkungs-

ausschuss der Auftraggeber des Projekts hochrangig vertreten sein, möglichst

Seite 22

also durch Vertreter der Geschäftsführung. Ebenso sollten jene Fachabteilun-

gen, 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 Lenkungs-

ausschuss vertreten sein.

Bei der Auswahl der Projektleitung sollten ausgeprägte Kenntnisse und Erfah-

rungen zur Prozessorientierung nach ITIL oder ISO 20000 vorausgesetzt wer-

den. Um die Projektleitung frei von Traditionen und Routinen der Vergangen-

heit agieren lassen zu können, können Berater eingesetzt werden, die die not-

wendigen 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 Dokumentati-

on. Während der Umsetzung werden den an den Prozessen des Service Ma-

nagements 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 ver-

fü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 Routineorgani-

sation übernehmen, sollten mit etwa 3 bis 5 Mitarbeitern besetzt werden. Da-

von 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“ Prozess-

Manager bestellt werden.

Seite 23

Zudem sind Arbeits- und Kommunikationsbeziehungen zwischen den Mitglie-

dern des Projektteams und der (später) für den Betrieb zuständigen Routine-

organisation vorzusehen. So ist es für den Erfolg des Zertifizierungsprojekts

wichtig, so früh wie möglich Schlüsselrollen der zukünftigen Routineorganisa-

tion zu benennen. Insbesondere die steuernde, koordinierende und kontrollie-

rende 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 Doku-

mentation sollte für alle Projektmitglieder im Zugriff stehen. Dafür ist eine Sys-

tematik 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 Dokumentenmana-

gement unterstützt werden, andernfalls kann eine gemeinsame Nutzung eines

zentralen Ablagesystems vorgesehen werden. Für die Systematik müssen al-

lerdings 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 wer-

den. 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 Manage-

ment-Produkten, die die Projektdokumentation wiedergeben, und Spezialisten-

Seite 24

Produkten, die die Produktdokumentation wiedergeben23. Bei den Spezialis-

tenprodukten 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 jeweili-

gen Dokumenttypen Prozessbeschreibungen, Verfahren, Records und Listen

vorzunehmen (s. Abschnitt 3 und Anhang).

Management-Produkte (nach PRINCE2)

Spezialisten-Produkte (nach PRINCE2)

Berichte

Meetings

Projektorganisation

Review

Risiken/Risiko-Log

Prozesse

Personal

Tools

Audit……

…

…

…

…

Prozesse des übergeord-neten Managementsystems

Prozesse des ServiceManagements

Abbildung 6: Ablagestruktur

23 Vgl. OGC (2002) S. 313.

Seite 25

Jour Fix: Die Projektleitung sowie die Teamleiter bzw. Prozessverantwortli-

chen 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 Projektar-

beit ausgesetzt sind. In den Umsetzungsprojekten für die Prozesse des Servi-

ce Managements können während der Implementierung und des Übergangs in

die Routineorganisation die regelmäßigen Sitzungen des Projekts in die Regel-

kommunikation 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 geeig-

net 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 - In-

put - Process - Output - Customer" und bezeichnet eine Darstellungsform aus

der Projektmanagementmethode Six Sigma, mit der in Diskussionen ein ge-

meinsames Verständnis zu Inhalten und Ausprägungen von Prozessen entwi-

ckelt 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 Ein-

satz spezieller Werkzeuge oder Software gefordert, der Einsatz herkömmlicher

klassischer Darstellungsform wie Text, Tabelle und Diagramm kann ausrei-

chend 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 Prozess-

schritten kann die Darstellung von Mindmaps - ggf. mit entsprechender Soft-

ware - unterstützen, die Arbeit in Workshops und Arbeitsgruppen mit hohem

Detailgrad darzustellen. Der Einsatz von Mindmaps setzt allerdings eine ge-

wisse Vertrautheit mit dieser Arbeitsweise voraus.

Portal: Zur Unterstützung der Kommunikation während des Zertifizierungspro-

jekts können Projektportale oder ähnliche Kollaborationsprojekte eingesetzt

werden, insbesondere wenn die Projektmitglieder an verschiedenen Standor-

ten 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 Pro-

zesse 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 ent-

sprechender 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 Vor-

Ort-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 doku-

mentiert, mögliche Befunde oder Maßnahmen zu Verbesserungspotentialen

aufgeführt – und ggf. durch die Prüfer die Empfehlung zur Zertifizierung aus-

gesprochen. Das Ausstellen und Überreichen des Zertifikats durch die Zertifi-

zierungsstelle 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 we-

sentlichen Projektergebnisse, Aussagen zum Projektverlauf und zum Ressour-

cenverbrauch sowie Hinweise auf Befunde oder Maßnahmen zu bestehenden

Verbesserungspotentialen. Letzteres ist besonders wichtig mit Blick auf zu-

kü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 Erkennt-

nisse aus dem Projektverlauf sammeln und nach dem Motto „Positives verstär-

ken - Negatives abschwächen“ auswerten, um daraus Lerneffekte für zukünfti-

ge Projekte zu erzielen.

Aus bisherigen Zertifizierungsprojekten können die folgend beschriebenen Er-

folgsfaktoren benannt werden.

Verantwortung der Geschäftsführung: Die Einbindung und das Engagement

der Geschäftsführung ist notwendig, da erfahrungsgemäß während der Pro-

jektlaufzeit Barrieren und Hürden auftreten, weil durch das Zertifizierungspro-

jekt 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 Projektorganisa-

tion an die Routineorganisation klar geregelt und abgegrenzt werden.

Projektcontrolling: Die Einhaltung der Zeit- und Ressourcenpläne sind konse-

quent 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 o-

der 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 fol-

gen. 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 Aus-

richtung 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 be-

schreibt24. Zum anderen ist die Dokumentation bei den Prüfungen zur Zertifi-

zierung 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 Prozes-

se Change Management und Release Management detailliert. Dabei wird da-

von ausgegangen, dass im Rahmen übergeordneter Managementprozesse fol-

gende grundsätzliche Vorgaben ausgearbeitet und dokumentiert sind: Ziele

und Strategien des IT Service Managements26, verfügbarer organisatorischer

Rahmen (Rollen, Verantwortlichkeiten, Risikomanagement …)27, Service-Kata-

log 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 Mana-

gement-System festzulegen, incl. der Rollen bei der Bearbeitung (Erstellung,

Änderung, Freigabe), der Handhabung der Aufbewahrung (Aufbewahrungsort,

24 ISO 20000-1 S. 4. 25 Vgl. ISO 20000-1 S. 4. 26 Vgl. Bock/Macek/Oberdorfer/Pumsenberger (2006) S. 74. 27 Vgl. Bock/Macek/Oberdorfer/Pumsenberger (2006) S. 74.

Seite 30

Aufbewahrungsdauer, Archivierung), der Namensregeln für Dateien und Ord-

ner sowie der Mechanismen zur Versionskontrolle29. Die Norm ISO 20000 ent-

hält keine definitiven Vorgaben zu Handhabung und Lenkung von Dokumen-

ten, empfehlenswert ist, die Vorschriften zu den genannten Regelungsbedar-

fen in Form eines Prozesses (Document Change Process) und geeigneter

Richtlinien (Document Policy) festzulegen30.

Für alle Dokumente ist sicherzustellen, dass deren Lebenszyklus von der Er-

stellung, Ä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 notwendi-

gen Dokumente möglichst unmittelbar aus der Norm abzuleiten. Dies ge-

schieht 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. Unter-

lagen zu Strategien, Richtlinien, Plänen, Verträgen (incl. SLA, Underpinning

Contracts und Operational Level Agreements), sowie Beschreibungen von Pro-

zessen und Verfahren mit normativen und präskriptiven Charakter. Zusätzlich

sind so genannte „Records“ zur Dokumentation zu zählen, die (Zwischen-) Er-

gebnisse 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 Pro-

zess, die eine Änderung an der IT-Infrastruktur dokumentieren.

Für normative und präskriptive Dokumente sind beispielsweise folgende Sta-

tusinformationen entlang des Lebenszyklus zu führen, um eine lückenlose und

überschneidungsfreie Darstellung der jeweils geltenden Dokumentationsstän-

de 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

mittel

niedrig

hochmittelniedrig

Dringlichkeit (urgency)

Wirkung (impact)

Priorität

Abbildung 7: Klassifikation der Priorität

Mit der Einflussgröße Dringlichkeit werden zeitliche Aspekte der Notwendigkeit

einer Änderung gefasst. Gesetzliche, (sicherheits-)technische oder organisato-

rische Vorgaben können eine sofortige Durchführung fordern oder Möglichkei-

ten zu einer Verschiebung einer Änderung eröffnen. Mit der Einflussgröße Wir-

kung werden Effekte einer Änderung auf die beim Kunden zu unterstützenden

Geschäftsprozesse und auf die Organisation und Technik im Service Manage-

ment gefasst.

Das Risikokalkül, dass neben der Priorität die Terminierung von Changes be-

einflusst, 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 Si-

cherungsmaßnahmen vorgesehen, Spezialisten mit Fachkenntnissen hinzuge-

zogen.

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 ver-

schiedene Sachverhalte aufzunehmen sind. Ergänzend sind Hinweise auf ein-

schlägige Fachliteratur eingetragen. Im Ergebnis ist bei den notwendigen Do-

kumenten zu unterscheiden zwischen Beschreibungen von Prozessen und

Verfahren, Records, Klassifikationen und Listen.

Von zentraler Bedeutung ist die Prozessbeschreibung zum Change Manage-

ment, die das Vorgehen bei der Aufnahme, Bewertung und Umsetzung von

Changes beschreibt und Rollen/Verantwortlichkeiten festlegen muss. Bei die-

sen Festlegungen ist entscheidend, die Rollen und Verantwortlichkeiten klar

und eindeutig vorzugeben; dies kann nach dem bewährtem Schema RACI er-

folgen, mit dem in Planungs- und Entscheidungsprozessen die folgenden Rol-

len 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 Ge-

nehmigungen aussprechen dürfen. Im Normalfall wird dafür im Change Mana-

gement das Change Advisory Board zuständig sein, das jedoch Entscheidun-

gen zu klar abgegrenzten Standardänderungen auch dem verantwortlichen

Change Manager übertragen kann.

Im Change-Management-Prozess sind insbesondere die Schnittstellen zum In-

cident Management und zum Problem Management zu detaillieren. Die Pro-

zessbeschreibung muss eine Ergebniskontrolle (ex ante) für Changes vorse-

hen. Zudem muss eine Beschreibung der Schnittstelle zum Qualitätsmanage-

ment35 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 kon-

trollieren ist (RACI).

Ergänzend dazu muss eine Verfahrensbeschreibung für das Change Mana-

gement folgende Regelungsbedarfe klären (incl. Festlegungen gemäß RACI):

• wie Änderungen an Klassifizierungen zum Bearbeitungsstand, zur Dring-lichkeit, 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 Identifi-kation, und Handhabung derartiger Notfälle vorgenommen wird (Notfall-plan);

• wie die Terminierung eines Changes vorgenommen wird; dabei ist insbe-sondere die Schnittstelle zum Release Management zu klären;

• wie die Terminierung aller Changes im Terminplan regelmäßig zu aktuali-sieren ist und die Ergebnisse an alle Beteiligten zu kommunizieren sind.

In Change Records werden alle Änderungen einzeln als (Zwischen-) Ergeb-

nisse des Change-Management-Prozesses beschrieben. Damit sind im Chan-

ge 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 Do-

kumenten, 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 Vergleichbar-

keit 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 dokumentie-

ren und geregelt an den übergeordneten Prozess zur kontinuierlichen Verbes-

serung (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üh-

rungsdaten 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 ver-

schiedene Sachverhalte aufzunehmen sind. Im Ergebnis ist bei den notwendi-

gen Dokumenten zu unterscheiden zwischen Beschreibungen von Prozessen

und Verfahren, Records, Klassifikationen und Listen.

Von zentraler Bedeutung ist die Prozessbeschreibung zum Release Manage-

ment, die das Vorgehen bei der Implementierung von Releases beschreibt und

Rollen/Verantwortlichkeiten (RACI) festlegen muss. In der Prozessbeschrei-

bung sind insbesondere die Schnittstellen zum Change Management, Configu-

ration 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. Zwi-

schen Release, Change und Configuration Management ist das Vorgehen zur

Aktualisierung von Configuration Items festzulegen. Dem Incident Manage-

ment sind rechtzeitig zur Implementierung von Releases notwendige Informati-

onen verfügbar zu machen, u.a. zu Inhalten und Umfang, aber auch zu be-

kannten Einschränkungen oder Mängeln von Releases. Die Prozessbe-

schreibung muss eine Ergebniskontrolle (ex ante) für Releases vorsehen. Da-

bei 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 Festle-

gungen gemäß RACI:

• in welchem Rhythmus werden Releases vorgenommen, welche Release-Fenster stehen zur Verfügung39;

• wie wird der Release-Kalender mit Beteiligten auf IT- und Kundenseite ab-gestimmt;

• wie werden die notwendigen Abstimmungsprozesse zu Inhalten und Ter-minen 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 derarti-ger 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 Inci-dent/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 Re-

lease-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 fest-

zulegen, 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 dokumentie-

ren und geregelt an übergeordneten Prozess zur kontinuierlichen Verbesse-

rung (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 Implemen-

tierungsdaten 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 aus-

zurichten und sich die Konformität mit dieser Norm offiziell zertifizieren zu las-

sen. Die Anzahl von IT-Anbietern, die sich einem Zertifizierungsverfahren un-

terziehen, 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 kosten- und

leistungsorientiert agieren, externe Anbieters sehen sich wachsendem Wettbe-

werbsdruck 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 be-

teiligten Personen, Zeit und Ort der Leistungserstellung ablaufen. Auf diese

Weise wird die Planung, Steuerung und Kontrolle unterstützt und eine syste-

matische 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, berechen-

bar 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 Vorga-

ben 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 An-

sä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 Vorgehenswei-

sen 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., Foun-dations 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: Bri-tish Standards Institution, 2006.

Hochstein, A., Brenner, W., Grundlagen des IT Service Management, in: IT Service Mana-gement, Bd. 1, 2006, Nr. 1, S. 3-7.

ISO/IEC 20000–1 (2005) Information technology – Service management – Part 1: Specifica-tion.

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: In-formation 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

Not

wen

dige

Dok

umen

te n

ach

ISO

200

00 fü

r das

Cha

nge

Man

agem

ent

Abs

chni

tt 9.

2 C

ontr

ol P

roce

sses

/ C

hang

e M

anag

emen

t2

34

Abs

atz

Satz

Einz

elau

ssag

eno

twen

dige

s D

okum

ent

bzw

. Er

gebn

isD

okum

ente

ntyp

bzw

. Er

gebn

isty

pH

inw

eis

1O

bjec

tive:

To

ensu

re a

ll ch

ange

s ar

e as

sess

ed, a

ppro

ved,

impl

emen

ted

and

revi

ewed

in a

con

trol

led

man

ner.

2D

etai

lbes

chre

ibun

g fü

r jed

en C

hang

e in

cl. Z

iel

Rec

ord

… in

cl. R

ecor

d-ID

.

31

… D

etai

lbes

chre

ibun

g fü

r jed

en C

hang

e in

cl. D

ringl

ichk

eit

Rec

ord

Kla

ssifi

katio

n vo

n C

hang

es n

ach

Bea

rbei

tung

ssta

ndK

lass

ifika

tion

Ein

träge

zum

Bea

rbei

tung

ssta

nd

Cha

nge-

Ver

fahr

enV

erfa

hren

Wie

wer

den

Ein

träge

zu

Bea

rbei

tung

ssta

nd g

eänd

ert (

RA

CI)?

(v

gl. D

ugm

ore/

Shi

rley

(200

6) S

. 115

)K

lass

ifika

tion

von

Cha

nges

nac

h D

ringl

ichk

eit

Kla

ssifi

katio

n…

etw

a na

ch "h

och

/ m

ittel

/ n

iedr

ig"

Cha

nge-

Ver

fahr

enV

erfa

hren

Wie

wer

den

Ein

träge

zu

Drin

glic

hkei

t geä

nder

t (R

AC

I)? (v

gl.

Dug

mor

e/S

hirle

y (2

006)

S. 1

15)

2…

Det

ailb

esch

reib

ung

für j

eden

Cha

nge

incl

. Ris

iko,

Wirk

ung,

Nut

zen

aK

lass

ifika

tion

von

Cha

nges

nac

h R

isik

oK

lass

ifika

tion

… e

twa

nach

"hoc

h /

mitt

el /

nie

drig

"

Cha

nge-

Ver

fahr

enV

erfa

hren

Wie

wer

den

Ein

träge

zu

Ris

iko

geän

dert

(RA

CI)?

(vgl

. D

ugm

ore/

Shi

rley

(200

6) S

. 64)

; Ris

ikok

alkü

l (A

sses

smen

t) m

uss

fesg

eleg

t wer

den

sein

bK

lass

ifika

tion

von

Cha

nges

nac

h W

irkun

gK

lass

ifika

tion

… e

twa

nach

"hoc

h /

mitt

el /

nie

drig

"

Cha

nge-

Ver

fahr

enV

erfa

hren

Wie

wer

den

Ein

träge

zu

Wirk

ung

(impa

ct) g

eänd

ert (

RA

CI)?

(v

gl. D

ugm

ore/

Shi

rley

(200

6) S

. 65

und

S. 1

15)

cK

lass

ifika

tion

von

Cha

nges

nac

h N

utze

nK

lass

ifika

tion

… e

twa

nach

"hoc

h /

mitt

el /

nie

drig

"

Cha

nge-

Ver

fahr

enV

erfa

hren

Wie

wer

den

Ein

träge

zu

Nut

zen

geän

dert

(RA

CI)?

4C

hang

e-V

erfa

hren

Ver

fahr

enFü

r Cha

nges

mus

s fe

stge

legt

wer

den,

wie

sie

(fal

lbac

k be

i S

chei

tern

) zur

ückg

eset

zt o

. zur

ückg

enom

men

wer

den;

RA

CI

5P

roze

ssbe

schr

eibu

ng C

hang

e M

anag

emen

tP

roze

ssbe

schr

eibu

ng…

mus

s V

orge

hen

bei E

ntsc

heid

ung

und

Impl

emen

tieru

ng v

on

Cha

nges

fest

lege

n (R

AC

I); d

abei

sin

d S

chni

ttste

llen

zu In

cide

nt

Man

agem

ent u

nd P

robl

em M

anag

emen

t zu

besc

hrei

ben

(vgl

. IS

O 2

0000

-2 S

. 28)

6P

roze

ssbe

schr

eibu

ng C

hang

e M

anag

emen

tP

roze

ssbe

schr

eibu

ngP

roze

ssbe

schr

eibu

ng m

uss

Erg

ebni

skon

trolle

für C

hang

es (e

x an

te) v

orse

hen

7N

otfa

llpla

nV

erfa

hren

Für "

emer

genc

y ch

ange

s" is

t Vor

gehe

n be

i Not

fälle

n (Id

entif

ikat

ion,

Han

dhab

ung;

RA

CI)

fest

zule

gen

(vgl

. M

acFa

rlane

/Dug

mor

e (2

006)

S. 5

4)

1

Ser

vice

and

infra

stru

ctur

e ch

ange

s sh

all h

ave

a cl

early

def

ined

and

do

cum

ente

d sc

ope.

All

requ

ests

for c

hang

e sh

all b

e re

cord

ed a

nd c

lass

ified

, e.g

. urg

ent,

emer

genc

y, m

ajor

, min

or.

Req

uest

s fo

r cha

nges

sha

ll be

ass

esse

d fo

r the

ir ris

k

Req

uest

s fo

r cha

nges

sha

ll be

ass

esse

d fo

r the

ir im

pact

Req

uest

s fo

r cha

nges

sha

ll be

ass

esse

d fo

r the

ir bu

sine

ss b

enef

it

The

chan

ge m

anag

emen

t pro

cess

sha

ll in

clud

e th

e m

anne

r in

whi

ch

the

chan

ge s

hall

be re

vers

ed o

r rem

edie

d if

unsu

cces

sful

.

Req

uest

s fo

r cha

nges

sha

ll be

ass

esse

d fo

r the

ir ris

k, im

pact

and

bu

sine

ss b

enef

it.

Cha

nges

sha

ll be

app

rove

d an

d th

en c

heck

ed, a

nd s

hall

be

impl

emen

ted

in a

con

trolle

d m

anne

r.

All

chan

ges

shal

l be

revi

ewed

for s

ucce

ss a

nd a

ny a

ctio

ns ta

ken

afte

r im

plem

enta

tion.

Ther

e sh

all b

e po

licie

s an

d pr

oced

ures

to c

ontro

l the

aut

horiz

atio

n an

d im

plem

enta

tion

of e

mer

genc

y ch

ange

s.

81

Term

inpl

anun

gV

erfa

hren

Für j

eden

Cha

nge

ist T

erm

in z

ur U

mse

tzun

g zu

pla

nen

(RA

CI);

in

sbes

. ist

Sch

nitts

telle

zu

RM

zu

besc

hrei

ben

Cha

nge-

Kal

ende

rLi

ste

2Te

rmin

plan

ung

Ver

fahr

enC

hang

e-K

alen

der i

st re

gelm

äßig

zu

aktu

alis

iere

n (R

AC

I) un

d an

al

le B

etei

ligte

n zu

kom

mun

izie

ren

91

Pro

zess

besc

hrei

bung

Cha

nge

Man

agem

ent

Pro

zess

besc

hrei

bung

Pro

zess

besc

hrei

bung

mus

s S

chni

tttst

elle

zu

Qua

lität

s-m

anag

emen

t bes

chre

iben

(inc

l. In

puts

/Out

puts

), da

bei

über

geor

dnet

er Q

ualit

ätsm

anag

emen

tpro

zess

nac

h IS

O 2

0000

S

. 4-5

; Cha

nges

sin

d re

gelm

äßig

auf

Mus

ter,

Aus

reiß

er,

Ala

rmsi

gnal

e zu

ana

lysi

eren

und

ggf

. Maß

nahm

en fe

stzu

lege

n2

Pro

zess

besc

hrei

bung

Cha

nge

Man

agem

ent

Pro

zess

besc

hrei

bung

Not

wen

dige

Maß

nahm

en a

us "c

hang

es a

naly

sis"

sin

d ge

rege

lt zu

bea

rbei

ten

(RA

CI)

10P

roze

ssbe

schr

eibu

ng C

hang

e M

anag

emen

tP

roze

ssbe

schr

eibu

ngP

roze

ssbe

schr

eibu

ng m

uss

Iden

tifik

atio

n vo

n V

erbe

sser

unge

n un

d S

chni

tttst

elle

zu

Qua

lität

sman

agem

ent b

esch

reib

en (i

ncl.

Inpu

ts/O

utpu

ts),

dabe

i übe

rgeo

rdne

ter Q

M-P

roze

ss n

ach

ISO

20

000

S. 4

-5D

etai

lbes

chre

ibun

g fü

r jed

e V

erbe

sser

ungs

mög

lichk

eit

Rec

ord

… s

ind

an Q

ualit

ätsm

anag

emen

t wei

terz

ulei

ten

(Con

tinua

l S

ervi

ce Im

prov

emen

t Pla

n C

SIP

)

A s

ched

ule

that

con

tain

s de

tails

of a

ll th

e ch

ange

s ap

prov

ed fo

r im

plem

enta

tion

and

thei

r pro

pose

d im

plem

enta

tion

date

s sh

all b

e m

aint

aine

d an

d co

mm

unic

ated

to re

leva

nt p

artie

s.

The

resu

lts a

nd c

oncl

usio

ns d

raw

n fro

m c

hang

e an

alys

is s

hall

be

reco

rded

.A

ctio

ns fo

r im

prov

emen

t ide

ntifi

ed fr

om c

hang

e m

anag

emen

t sha

ll be

re

cord

ed a

nd in

put i

nto

a pl

an fo

r im

prov

ing

the

serv

ice.

The

sche

dule

d im

plem

enta

tion

date

s of

cha

nges

sha

ll be

use

d as

the

basi

s fo

r cha

nge

and

rele

ase

sche

dulin

g.

Cha

nge

reco

rds

shal

l be

anal

ysed

regu

larly

to d

etec

t inc

reas

ing

leve

ls

of c

hang

es, f

requ

ently

recu

rrin

g ty

pes,

em

ergi

ng tr

ends

and

oth

er

rele

vant

info

rmat

ion.

Not

wen

dige

Dok

umen

te n

ach

ISO

200

00 fü

r das

Rel

ease

Man

agem

ent

Abs

chni

tt 10

.1 R

elea

se P

roce

ss /

Rel

ase

Man

agem

ent

23

4A

bsat

zSa

tzEi

nzel

auss

age

notw

endi

ges

Dok

umen

t bz

w.

Erge

bnis

Dok

umen

tent

yp b

zw.

Erge

bnis

typ

Hin

wei

s

1O

bjec

tive:

To

deliv

er, d

istr

ibut

e an

d tr

ack

one

or m

ore

chan

ges

in a

rele

ase

into

the

live

envi

ronm

ent.

2P

roze

ssbe

schr

eibu

ng R

elea

se

Man

agem

ent

Pro

zess

besc

hrei

bung

Pro

zess

besc

hrei

bung

mus

s S

chni

tttst

elle

zu

Cha

nge

Man

agem

ent u

nd C

onfig

urat

ion

Man

agem

ent b

esch

reib

en (i

ncl.

Inpu

s/O

utpu

ts)

3…

Det

ailb

esch

reib

ung

für j

edes

Rel

ease

in

cl. R

elea

se-T

ypR

ecor

d

aK

lass

ifika

tion

von

Rel

ease

sK

lass

ifika

tion

… K

lass

ifika

tion

von

Rel

ease

s na

ch T

ypb

Rel

ease

verfa

hren

Ver

fahr

enV

erfa

hren

mus

s P

lan/

Vor

gabe

n fü

r Rhy

thm

ik v

on R

elea

ses

enth

alte

n (v

gl.

ISO

200

00-2

S. 3

0)4

1R

elea

seka

lend

erLi

ste

Rel

ease

kale

nder

mus

s m

it K

unde

nsei

te a

bges

timm

t wer

den;

für

Ser

vice

s, S

yste

ms,

Sof

twar

e, H

ardw

are;

Wel

che

Rel

ease

s w

erde

n in

wel

chem

Rel

ease

fens

ter a

usge

führ

t?2

Rel

ease

verfa

hren

Ver

fahr

enV

orge

hen

bei R

elea

ses

mus

s fe

stge

legt

und

mit

Bei

teili

gten

(K

unde

n, B

enut

zer,

Bet

rieb

…) a

bges

timm

t wer

den;

incl

. RA

CI

5R

elea

seve

rfahr

enV

erfa

hren

Vor

gehe

n fü

r Situ

atio

n, d

ass

fehl

gesc

hlag

enes

Rel

ease

zu

rück

gese

tzt o

der r

epar

iert

wer

den

mus

s, m

uss

fest

gele

gt

wer

den

61

Det

ailb

esch

reib

ung

für j

edes

Rel

ease

in

cl. R

elea

se-T

ypR

ecor

d…

die

Bes

chre

ibun

gen

von

Rel

ease

s m

üsse

n D

etai

ls e

ntha

lten

zu: I

mpl

emnt

ieru

ngsd

atum

, Rel

ease

-Art,

Inha

lt, a

uslö

send

es

Ere

igni

s, R

efer

enz

zu b

etro

ffene

n C

hang

es, b

ekan

nten

Feh

lern

un

d P

robl

emen

2P

roze

ssbe

schr

eibu

ng R

elea

se

Man

agem

ent

Pro

zess

besc

hrei

bung

Pro

zess

besc

hrei

bung

mus

s S

chni

tttst

elle

zu

Inci

dent

M

anag

emen

t bes

chre

iben

(in

cl. I

npus

/Out

puts

)7

1P

roze

ssbe

schr

eibu

ng R

elea

se

Man

agem

ent

Pro

zess

besc

hrei

bung

Rel

ease

s un

d "L

iste

alle

r Cha

nges

" (au

s C

hang

e M

anag

emen

) si

nd a

uf K

ollis

ione

n bz

w. W

echs

elw

irkun

gen

zu p

rüfe

n

2P

roze

ssbe

schr

eibu

ng R

elea

se

Man

agem

ent

Pro

zess

besc

hrei

bung

Bei

Sch

nittt

stel

le z

u C

onfig

urat

ion

Man

agem

ent i

st P

flege

von

C

onfig

urat

ion

Rec

ords

zu

deta

illie

ren

(Akt

ualis

ieru

ng v

on C

Is)

3K

lass

ifika

tion

von

Rel

ease

sK

lass

ifika

tion

… e

twa

nach

"em

erge

ncy

/ urg

ent /

maj

or /

min

or"

Ver

fahr

en fü

r Not

fälle

und

drin

glic

he

Fälle

Ver

fahr

enV

orge

hen

in N

otfä

llen

und

drin

glic

hen

Fälle

n (w

ie z

.B. h

ot fi

xes)

is

t fes

tzul

egen

; ins

bes.

Sch

nitts

telle

zu

Not

fallp

lan

im C

hang

e M

anag

emen

t ("e

mer

genc

y ch

ange

s")

1

NO

TE T

he re

leas

e m

anag

emen

t pro

cess

sho

uld

be in

tegr

ated

with

the

conf

igur

atio

n an

d ch

ange

man

agem

ent p

roce

sses

.

The

serv

ice

prov

ider

sha

ll pl

an w

ith th

e bu

sine

ss th

e re

leas

e of

se

rvic

es, s

yste

ms,

sof

twar

e an

d ha

rdw

are.

Pla

ns o

n ho

w to

roll

out t

he re

leas

e sh

all b

e ag

reed

and

aut

horiz

ed b

y al

l rel

evan

t par

ties,

e.g

. cus

tom

ers,

use

rs, o

pera

tions

and

sup

port

staf

f.

The

rele

ase

polic

y st

atin

g th

e fre

quen

cy a

nd ty

pe o

f rel

ease

s sh

all b

e do

cum

ente

d an

d ag

reed

.Th

e re

leas

e po

licy

stat

ing

the

type

of r

elea

ses

…

The

rele

ase

polic

y …

sha

ll be

doc

umen

ted

and

agre

ed.

The

proc

ess

shal

l inc

lude

the

man

ner i

n w

hich

the

rele

ase

shal

l be

reve

rsed

or r

emed

ied

if un

succ

essf

ul.

Pla

ns s

hall

reco

rd th

e re

leas

e da

tes

and

deliv

erab

les

and

refe

r to

rela

ted

chan

ge re

ques

ts, k

now

n er

rors

and

pro

blem

s.

Rel

ease

man

agem

ent p

roce

dure

s sh

all i

nclu

de th

e up

datin

g an

d ch

angi

ng o

f con

figur

atio

n in

form

atio

n an

d ch

ange

reco

rds.

Em

erge

ncy

rele

ases

sha

ll be

man

aged

acc

ordi

ng to

a d

efin

ed p

ro-c

ess

that

inte

rface

s to

the

emer

genc

y ch

ange

man

agem

ent p

roce

ss.

The

rele

ase

man

agem

ent p

roce

ss s

hall

pass

sui

tabl

e in

form

atio

n to

the

inci

dent

man

agem

ent p

roce

ss.

Req

uest

s fo

r cha

nge

shal

l be

asse

ssed

for t

heir

impa

ct o

n re

leas

e pl

ans.

8Te

stve

rfahr

enV

erfa

hren

Vor

gehe

n fü

r Bui

ld u

nd T

est v

on R

elea

ses

ist f

estz

uleg

en; i

ncl.

Abl

auf,

RA

CI u

nd D

okum

enta

tion

der T

ests

/Tes

terg

ebni

sse

91

Test

verfa

hren

Ver

fahr

enV

orge

hen

zum

Tes

ten

mus

s P

rüfu

ng v

orse

hen,

das

s U

nver

ände

rbar

keit

von

Har

d- u

nd S

oftw

are

wäh

rend

Inst

alla

tion,

A

uslie

feru

ng, I

nbet

riebn

ahm

e ge

sich

ert i

st10

1P

roze

ssbe

schr

eibu

ng R

elea

se

Man

agem

ent

Pro

zess

besc

hrei

bung

Pro

zess

besc

hrei

bung

mus

s E

rgeb

nisp

rüfu

ng fü

r Rel

ease

s (e

x an

te) v

orse

hen

2R

elea

se-M

anag

emen

t-Ver

fahr

enV

erfa

hren

Bei

der

Erg

ebni

sprü

fung

mus

s B

ezie

hung

zw

isch

en R

elea

se u

ndau

slös

ende

n In

cide

nts

unte

rsuc

ht w

erde

n3

aR

elea

se-M

anag

emen

t-Ver

fahr

enV

erfa

hren

Bei

Erg

ebni

sprü

fung

mus

s un

ters

ucht

wer

den,

ob

das

Rel

ease

de

n ge

wol

lten

Zwec

k er

füllt

hat

; and

ernf

alls

: Mod

ifika

tion,

R

ücks

etzu

ng o

der Ä

nder

ung

durc

h ne

ues

Rel

ease

; Prü

fung

auf

W

irkun

g bz

gl. B

usin

ess,

Bet

rieb

…b

Pro

zess

besc

hrei

bung

Rel

ease

M

anag

emen

tP

roze

ssbe

schr

eibu

ngP

roze

ssbe

schr

eibu

ng m

uss

Sch

nittt

stel

le z

u Q

ualit

ätsm

anag

e-m

ent b

esch

reib

en (i

ncl.

Inpu

ts/O

utpu

ts),

dabe

i übe

rgeo

rdne

ter

QM

-Pro

zess

nac

h IS

O 2

0000

S. 4

-5D

etai

lbes

chre

ibun

g fü

r jed

e V

erbe

sser

ungs

mög

lichk

eit

Rec

ord

… s

ind

an Q

ualit

ätsm

anag

emen

t wei

terz

ulei

ten

(Con

tinua

l S

ervi

ce Im

prov

emen

t Pla

n C

SIP

)

Ana

lysi

s sh

all p

rovi

de in

put t

o a

plan

for i

mpr

ovin

g th

e se

rvic

e.

Mea

sure

men

ts s

hall

incl

ude

inci

dent

s re

late

d to

a re

leas

e in

the

perio

d fo

llow

ing

a re

leas

e.A

naly

sis

shal

l inc

lude

ass

essm

ent o

f the

impa

ct o

n th

e bu

sine

ss, I

T op

erat

ions

and

sup

port

staf

f res

ourc

es, a

nd s

hall

prov

ide

inpu

t to

a pl

an fo

r im

prov

ing

the

serv

ice.

A c

ontro

lled

acce

ptan

ce te

st e

nviro

nmen

t sha

ll be

est

ablis

hed

to b

uild

an

d te

st a

ll re

leas

es p

rior t

o di

strib

utio

n.

Rel

ease

and

dis

tribu

tion

shal

l be

desi

gned

and

impl

emen

ted

so th

at th

e in

tegr

ity o

f har

dwar

e an

d so

ftwar

e is

mai

ntai

ned

durin

g in

stal

latio

n,

hand

ling,

pac

kagi

ng a

nd d

eliv

ery.

Suc

cess

and

failu

re o

f rel

ease

s sh

all b

e m

easu

red.

Ana

lysi

s sh

all i

nclu

de a

sses

smen

t of t

he im

pact

on

the

busi

ness

, IT

ope

ratio

ns a

nd s

uppo

rt st

aff r

esou

rces

.

Fakultät für Wirtschaft und Informatik

Fachhochschule Hannover

Ricklinger Stadtweg 120

30459 Hannover

http://www.fakultaet4.fh-hannover.de

[email protected]

GRASS-MERKUR GmbH & Co. KG

Rothwiese 5

30559 Hannover

Telefon: 05 11 47 54 14 – 0

www.grass-merkur.de

[email protected]

Titelbild: Martin Pfeiffer, Hannover

Alle Rechte vorbehalten. Hannover, 2010

Autoren Georg Disterer, Prof. Dr., lehrt Wirtschaftsinformatik in der Fa-

kultät für Wirtschaft und Informatik der Fachhochschule

Hannover und arbeitet auf den Gebieten: Informationsmanage-

ment, Projektmanagement, Wissensmanagement. Die Fach-

hochschule bildet über 7.000 Studierende in fünf Fakultäten

aus. In der Fakultät für Wirtschaft und Informatik werden Stu-

diengä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 zertifi-

zierter ITIL-Experte im IT Service Management und zertifizier-

ter Internal Auditor für ISO 20000. Nach Forschungstätigkeiten

an Hochgeschwindigkeitsnetzen berät er nun für das Unter-

nehmen GRASS-MERKUR Kunden bei der Einführung und

Verbesserung von IT-Service Management Prozessen. Sein

Arbeitsschwerpunkt liegt dabei auf der Vorbereitung von Unter-

nehmen 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 GRASS-

MERKUR berät er Kunden in Projekten zum IT-Service Mana-

gement. 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-Serviceunter-

nehmen. GRASS-MERKUR entwirft, entwickelt und implementiert hochwertige Business-

Lö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.

Documents

Zertifizierung nach ISO 20000: Projekt- und ... · PDF fileZertifizierung nach ISO 20000: Projekt- und Dokumentationsmanagement Georg Disterer, Oliver Kunert, Ingo Eibich-Meyer Abstract