Zertifizierung nach ISO 20000: Projekt
Transcrição
Zertifizierung nach ISO 20000: Projekt
Zertifizierung nach ISO 20000: Projekt- und Dokumentationsmanagement Georg Disterer, Oliver Kunert, Ingo Eibich-Meyer 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] Zertifizierung nach ISO 20000: Projekt- und Dokumentationsmanagement Georg Disterer, Oliver Kunert, Ingo Eibich-Meyer 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 kosten- und 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 insgesamt 7 Hauptbücher 2001 2003 2005 Abbildung 1: Entstehung und Entwicklung der Norm ISO 200003 2 3 Vgl. Disterer (2009) S. 532. Vgl. Disterer (2009) S. 531. Office of Government Commerce OGC veröffentlicht: 2007-06-05 Personenzertifikate insgesamt 5 Hauptbücher 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 Vgl. Disterer (2009) S. 533. 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 Zertifizierungsstelle Abschlussbericht Erfahrungssicherung Reaktion auf Befunde und Vorschläge zu Maßnahmen Umsetzungsprojekt Problem Management Incident Management Release Management Beauftragung Zertifizierungsstelle 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 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 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 Klassifikation von Changes nach 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 von Changes nach 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 … etwa nach "hoch / mittel / niedrig" … etwa nach "hoch / mittel / niedrig" 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) … etwa nach "hoch / mittel / niedrig" Einträge zum Bearbeitungsstand … incl. Record-ID. Hinweis 4 Liste Verfahren Change-Kalender Terminplanung Detailbeschreibung für jede Verbesserungsmöglichkeit Prozessbeschreibung Change Management Prozessbeschreibung Change 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 Prozessbeschreibung Release Management Prozessbeschreibung Release 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 Prozessbeschreibung Release 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. Prozessbeschreibung Release 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.