02550 Entwicklung eines Reifegradmodells nach ISO/IEC TS 33060
Anhand des neu aufgelegten technischen Standards ISO/IEC TS 33060 wird ein Modell für die Entwicklung eines Reifegradbewertungssystems für Prozesse erarbeitet. In diesem ersten Beitrag werden die relevanten Aspekte des technischen Standards vorgestellt und auf dieser Basis die Prozesse aus ISO/IEC 20000 dokumentiert.
In diesem Beitrag werden die Voraussetzungen für das Reifegradmodell geschaffen. Die praktische Anwendung des Systems wird in einem folgenden Beitrag erklärt und mit Hilfen unterlegt. von: |
1 Zielsetzung
Prozessreifegradmodell
Im Folgenden werden die Grundlagen bereitgestellt, um ein professionelles Bewertungssystem für Prozessreifegrade entwickeln zu können. Das Reifegradmodell wird für die IT-Service-Managementprozesse aus der Normenreihe ISO/IEC 20000 erstellt. In diesem Beitrag werden wir die Voraussetzungen dafür schaffen, indem wir die ISO-20000-Prozesse mit den zugehörigen Informationsprodukten dokumentieren. Die Informationsprodukte dienen als Leistungsindikatoren der Prozesse. Sie werden in dem Prozessreifegradmodell mit Qualitätsindikatoren bewertet. Das Prozessreifegradmodell kann leicht auch auf andere Prozessmodelle (z. B. ITIL v3, ITIL 4, Cobit, Projektmanagementsystem) übertragen werden.
Im Folgenden werden die Grundlagen bereitgestellt, um ein professionelles Bewertungssystem für Prozessreifegrade entwickeln zu können. Das Reifegradmodell wird für die IT-Service-Managementprozesse aus der Normenreihe ISO/IEC 20000 erstellt. In diesem Beitrag werden wir die Voraussetzungen dafür schaffen, indem wir die ISO-20000-Prozesse mit den zugehörigen Informationsprodukten dokumentieren. Die Informationsprodukte dienen als Leistungsindikatoren der Prozesse. Sie werden in dem Prozessreifegradmodell mit Qualitätsindikatoren bewertet. Das Prozessreifegradmodell kann leicht auch auf andere Prozessmodelle (z. B. ITIL v3, ITIL 4, Cobit, Projektmanagementsystem) übertragen werden.
2 Bestandteile des Prozessbewertungsmodells
Zwei Dimensionen
Das in dem technischen Standard ISO/IEC TS 33060 [1] beschriebene Prozessbewertungsmodell besteht aus zwei Dimensionen. In der Prozessdimension werden die Prozesse definiert und mit Leistungsindikatoren versehen. Die zweite Dimension ist die Qualitätsdimension, die aus einem Rahmenwerk zur Messung der Prozessqualität besteht. In diesem Messsystem sind jedem Prozess definierte Qualitätsindikatoren zugeordnet.
Das in dem technischen Standard ISO/IEC TS 33060 [1] beschriebene Prozessbewertungsmodell besteht aus zwei Dimensionen. In der Prozessdimension werden die Prozesse definiert und mit Leistungsindikatoren versehen. Die zweite Dimension ist die Qualitätsdimension, die aus einem Rahmenwerk zur Messung der Prozessqualität besteht. In diesem Messsystem sind jedem Prozess definierte Qualitätsindikatoren zugeordnet.
Leistungs-/Qualitätsindikatoren
Die Systematik für die Definition der Prozessdimension mit zugehörigen Leistungsindikatoren folgt der ISO/IEC TS 33060. Für die Systematik zur Bestimmung der Prozessqualität anhand definierter Qualitätsindikatoren verweist der Standard auf den Normabschnitt 4.2.1 der ISO/IEC 33003 [2] .
Die Systematik für die Definition der Prozessdimension mit zugehörigen Leistungsindikatoren folgt der ISO/IEC TS 33060. Für die Systematik zur Bestimmung der Prozessqualität anhand definierter Qualitätsindikatoren verweist der Standard auf den Normabschnitt 4.2.1 der ISO/IEC 33003 [2] .
Da wir beabsichtigen, ein Reifegradmodell für Prozesse zu erstellen, werden wir in einem zweiten Artikel ein Qualitätsbewertungssystem mit eigenen Qualitätsindikatoren in Excel aufbauen. Wir werden dabei die ITIL-Prozesse aus der Normenreihe ISO/IEC 20000 als Informationsbasis benutzen.
2.1 Prozessdimension
Die Prozessdimension enthält eine definierte Zusammenstellung von Prozessen. In dem vorliegenden technischen Standard wird auf die Prozessliste der Norm ISO IEC/IEEE 15288 [3] verwiesen (vgl. Abbildung 1). Die Prozesse sind in vier Prozessgruppen gegliedert.
Abb. 1: Prozesse eines Systemlebenszyklus
Da wir als Beispiel ein Reifegradmodell für ISO/IEC 20000 erstellen wollen, verwenden wir die Prozesse aus diesem Standard (vgl. Abbildung 2).
Abb. 2: ITSM-Prozesse nach ISO/IEC 20000
Managementsystem
Zusätzlich verlangt ISO/IEC 20000-1 [4] – in Anlehnung an ISO 9000 ff. –, dass ein übergeordnetes Managementsystem zur Steuerung der ITSM-Prozesse eingesetzt wird.
Zusätzlich verlangt ISO/IEC 20000-1 [4] – in Anlehnung an ISO 9000 ff. –, dass ein übergeordnetes Managementsystem zur Steuerung der ITSM-Prozesse eingesetzt wird.
Wenn auch in der ITIL-Literatur nicht explizit propagiert, ist eine solche übergeordnete Steuerungsinstanz hinsichtlich der oft genannten Ende-zu-Ende-Serviceverantwortlichkeit notwendig. Aus diesem Grund gab es in dem Ausbildungspfad der „ITIL Edition 2011” das Seminar „Managing across the Lifecycle”, dessen Intention dem Managementsystem der ISO-Normen zumindest nahekam.
Auch in der Literatur zu ITIL 4 gibt es kein explizites Governancesystem. Immerhin findet sich in der Publikation „Direct, Plan and Improve” unter „Direction via governance, risk, and compliance” (2.5) ein kleiner Hinweis auf eine Governance-Ebene, in der ein Risiko- und Compliance-Management betrieben werden soll.
Unser Reifegradmodell wird neben den prozessbezogenen Themen auch Fragen zu einem Service-Management-System (SMS) enthalten, weshalb dessen Inhalte nachstehend in derselben Form wie die Prozesse beschrieben sind.
2.2 Qualitätsdimension
Die Qualitätsdimension wird auf den Betrieb der Prozesse angewandt. Es wird überprüft, ob der Prozess seine Zielsetzungen erreicht und die erwarteten Ergebnisse liefert. Dazu ist es erforderlich, messbare Prozessattribute zu spezifizieren, die nach wohldefinierten Qualitätskriterien bewertet werden.
Bewertungsindikatoren
Die bewertbaren Prozessattribute stellen somit Indikatoren zur Bestimmung der Leistungsfähigkeit und der Qualität des Prozesses dar. Dementsprechend wird in dem technischen Standard zwischen Leistungsindikatoren und Qualitätsindikatoren unterschieden.
Die bewertbaren Prozessattribute stellen somit Indikatoren zur Bestimmung der Leistungsfähigkeit und der Qualität des Prozesses dar. Dementsprechend wird in dem technischen Standard zwischen Leistungsindikatoren und Qualitätsindikatoren unterschieden.
Praktiken und Informationsprodukte
Die Leistungsindikatoren eines Prozesses beziehen sich auf die grundlegenden Prozesspraktiken (Prozessaktivitäten) und auf die zur Ausführung der Tätigkeiten erforderlichen bzw. bei Ausführung der Tätigkeiten erzeugten Informationsprodukte (Prozessartefakte).
Die Leistungsindikatoren eines Prozesses beziehen sich auf die grundlegenden Prozesspraktiken (Prozessaktivitäten) und auf die zur Ausführung der Tätigkeiten erforderlichen bzw. bei Ausführung der Tätigkeiten erzeugten Informationsprodukte (Prozessartefakte).
Wesentliche Informationsprodukte, die von einem Prozess als Output geliefert werden, können als Leistungsindikatoren genutzt werden. Wenn wir im Abschnitt 3 die zu betrachtenden Prozesse beschreiben, ist es also wichtig, dass wir auch deren Ergebnisartefakte benennen.
Process Measurement Framework
Für die qualitative Bewertung eines Prozesses, also für die Anwendung der Qualitätsdimension, muss ein Rahmenwerk für Prozessmessungen bereitgestellt werden. Der technische Standard definiert dies nicht selbst, sondern bezieht sich auf ein in der ISO/IEC-33xxx-Familie bereits bestehendes Rahmenwerk, das auch schon die für jeden Prozess erforderlichen Qualitätsindikatoren, die Bewertungsmethodik, die horizontale Bewertungsskala wie auch die vertikale Aggregationsmethodik beisteuert (vgl. ISO/IEC 33020 [5] ). In einem folgenden Beitrag werden wir ein eigenes Reifegradmodell als Excel-Anwendung erstellen, das sowohl die Bewertungs- und Aggregationsmethodik als auch die Bewertungsskala umfasst.
Für die qualitative Bewertung eines Prozesses, also für die Anwendung der Qualitätsdimension, muss ein Rahmenwerk für Prozessmessungen bereitgestellt werden. Der technische Standard definiert dies nicht selbst, sondern bezieht sich auf ein in der ISO/IEC-33xxx-Familie bereits bestehendes Rahmenwerk, das auch schon die für jeden Prozess erforderlichen Qualitätsindikatoren, die Bewertungsmethodik, die horizontale Bewertungsskala wie auch die vertikale Aggregationsmethodik beisteuert (vgl. ISO/IEC 33020 [5] ). In einem folgenden Beitrag werden wir ein eigenes Reifegradmodell als Excel-Anwendung erstellen, das sowohl die Bewertungs- und Aggregationsmethodik als auch die Bewertungsskala umfasst.
3 Systematische Prozessbeschreibung
Verbesserung bewerten
Die Anwendung eines Reifegradmodells für Prozesse basiert auf Prozessen, die bereits betrieben werden. Es macht Sinn, eine Reifegradmessung durchzuführen, die sich daraus ergebenden Verbesserungen umzusetzen und nach einer gewissen Betriebszeit die Messung erneut durchzuführen. Damit kann der Erfolg der Verbesserungsmaßnahmen verifiziert werden.
Die Anwendung eines Reifegradmodells für Prozesse basiert auf Prozessen, die bereits betrieben werden. Es macht Sinn, eine Reifegradmessung durchzuführen, die sich daraus ergebenden Verbesserungen umzusetzen und nach einer gewissen Betriebszeit die Messung erneut durchzuführen. Damit kann der Erfolg der Verbesserungsmaßnahmen verifiziert werden.
Voraussetzung
Voraussetzung dafür sind dokumentierte Prozesse. Wir werden die Prozessbeschreibungen an dieser Stelle auf die Teilmenge an Informationen reduzieren, die wir zur Erstellung des Reifegradmesssystems benötigen. Dies gilt insbesondere für die Beschränkung auf Teilprozesse (Aktivitätsgruppen) statt auf Einzelaktivitäten.
Voraussetzung dafür sind dokumentierte Prozesse. Wir werden die Prozessbeschreibungen an dieser Stelle auf die Teilmenge an Informationen reduzieren, die wir zur Erstellung des Reifegradmesssystems benötigen. Dies gilt insbesondere für die Beschränkung auf Teilprozesse (Aktivitätsgruppen) statt auf Einzelaktivitäten.
Allerdings sind alle wesentlichen Informationsartefakte dargestellt, die aus den Einzelaktivitäten unserer ausführlich modellierten Prozesse resultieren. Sie können somit sicher sein, dass alle wesentlichen Informationsobjekte enthalten sind, die für das Zusammenspiel von Einzelaktivitäten sowie Prozessen untereinander erforderlich sind.
Tabelle 1: Kategorien von Informationsprodukten
Kategorie | Beschreibung |
Vereinbarung/Vertrag | Gegenseitige Anerkennung der Bestimmungen und Bedingungen, unter denen eine Zusammenarbeit stattfindet. |
Anforderung | Leitet ein definiertes Vorgehen oder eine Veränderung ein, um ein Anliegen zu erfüllen. |
Produkt | Eine Kombination von interagierenden Elementen, die so organisiert sind, dass sie einen oder mehrere erklärte Zwecke erreichen.
Umfasst immaterielle Systeme wie beispielsweise Dienstleistungen sowie Systemelemente wie Software oder Hardware. |
Dokumentation | Beschreibung eines definierten Tatbestands ohne vorgegebene Informationsstruktur. |
Datensatz | Zusammenstellung verwandter Datenelemente, die als eine Einheit behandelt werden, um einen Informationskontext formal zu dokumentieren. |
Register | Hinreichende Zusammenstellung aller relevanten Informationen zu einem definierten Kontext. |
Bericht | Schriftliche Zusammenstellung der Ergebnisse eines Sachverhalts. |
Prozess/Prozedur | Ein Prozess ist die Gesamtheit aufeinander einwirkender Vorgänge innerhalb eines Systems. Unter dem Begriff „Prozedur” wird hier die detaillierte und konkretisierte Verfahrensordnung eines Prozesses verstanden, inklusive der Benennung, wie, von wem, mit welchen Werkzeugen und Konfigurationen die Umsetzung erfolgen soll. |
Richtlinie | Festlegung einer Absicht und Herangehensweise auf hoher Ebene, um Ziele für eine Dienstleistung, einen Prozess oder ein Managementsystem zu setzen und eine wirksame Kontrolle darüber zu ermöglichen. |
3.1 Service-Management-System (SMS)
Ziele
Die Führungsebene muss die Steuerung des SMS und der Services sicherstellen durch
Die Führungsebene muss die Steuerung des SMS und der Services sicherstellen durch
• | Festlegung und Kommunikation des Umfangs, der Politik und Ziele des Servicemanagements, |
• | Führen eines Servicemanagementplans, der die Politik, die Erreichung der Servicemanagementziele und die Erfüllung der Serviceanforderungen sicherstellt, |
• | Vermittlung der Bedeutung des Servicemanagements innerhalb der Organisation sowie der Erfüllung gesetzlicher und behördlicher Anforderungen und vertraglicher Verpflichtungen, |
• | Bereitstellung der erforderlichen Ressourcen, |
• | Regelmäßige Durchführung von Managementüberprüfungen, |
• | Ermittlung und Steuerung der Servicerisiken, |
• | Erlassen einer Servicemanagementrichtlinie, |
• | Management relevanter Dokumente (Richtlinie, Servicemanagementplan, Servicekatalog, Service Level Agreements (SLAs), Prozessdokumentationen), |
• | Ressourcenmanagement (finanziell, personell). |
Rollen | |
• | Service-Manager |
• | Mitarbeiter Service-Manager |
1. Planen des SMS – Plan
Einführen und Pflegen eines Servicemanagementplans
Die Planung umfasst die Bereitstellung einer Servicemanagementrichtlinie und die Steuerung der Serviceanforderungen. Der Servicemanagementplan enthält mindestens:
• | Ziele des Servicemanagements |
• | Serviceanforderungen |
• | Grenzen und Einschränkungen für das SMS |
• | Richtlinien, Normen, gesetzliche und regulatorische Anforderungen sowie vertragliche Verpflichtungen |
• | Rahmenwerk für Prozesse und Verantwortlichkeiten |
• | Personelle, technische, informationelle und finanzielle Ressourcenplanung |
• | Risikomanagement |
• | Eingesetzte Technologien |
• | Methoden zum Messen, Prüfen und Verbessern des SMS |
Inputs:
Umfang, Politik und Ziele des Servicemanagements
Umfang, Politik und Ziele des Servicemanagements
Outputs:
Servicemanagementplan, Servicemanagementrichtlinie, Risikoregister
Servicemanagementplan, Servicemanagementrichtlinie, Risikoregister
2. Einrichten und Betreiben des SMS – Do
Implementieren und Betreiben des SMS gemäß dem Servicemanagementplan
Aktivitäten
Die Aktivitäten umfassen mindestens:
Die Aktivitäten umfassen mindestens:
• | Zuweisung und Verwaltung von Mitteln und Budgets |
• | Zuweisung von Befugnissen, Verantwortlichkeiten entsprechend den Prozessrollen |
• | Verwaltung der personellen, technischen und Informationsressourcen; |
• | Identifizierung, Bewertung und Management von Servicerisiken |
• | Steuerung der Service-Management-Prozesse |
• | Überwachen der Leistungsfähigkeit des SMS und Erstellen von Leistungsberichten. |
Inputs:
Servicemanagementplan, Servicemanagementrichtlinie
Servicemanagementplan, Servicemanagementrichtlinie
Outputs:
Leistungsberichte
Leistungsberichte
3. Überwachen und Überprüfen des SMS – Check
Einsatz geeigneter Methoden zur Überwachung und Messung des SMS und der Services
Zu diesen Methoden gehören interne Audits und Managementprüfungen.
Die Zielsetzungen der internen Audits und Reviews müssen dokumentiert werden. Die Ergebnisse interner Audits und Reviews, einschließlich Nichtkonformitäten, Problemstellungen und Verbesserungsmaßnahmen, sind zu dokumentieren und zu kommunizieren.
Inputs:
ISO/IEC 20000-1, Servicemanagementplan, Servicemanagementrichtlinie, Risikoregister, Prozessdokumentationen, Kundenfeedbacks, Leistungsberichte
ISO/IEC 20000-1, Servicemanagementplan, Servicemanagementrichtlinie, Risikoregister, Prozessdokumentationen, Kundenfeedbacks, Leistungsberichte
Outputs:
Auditbericht, Reviewbericht
Auditbericht, Reviewbericht
4. Pflegen und Verbessern des SMS – Act
Es soll Ansatz für die kontinuierliche Verbesserung des SMS und der Services existieren, der Bewertungskriterien für die ermittelten Verbesserungsmöglichkeiten enthält.
Das Verbesserungsverfahren sowie die geplanten Verbesserungen sollen dokumentiert sein.
Inputs:
Auditbericht, Reviewbericht
Auditbericht, Reviewbericht
Outputs:
Dokumentiertes Verbesserungsverfahren, Berichte über geplante und durchgeführte Verbesserungen
Dokumentiertes Verbesserungsverfahren, Berichte über geplante und durchgeführte Verbesserungen
3.2.1 CON.1 Change Management
Prozessziele
Das Change Management stellt sicher, dass Änderungen am IT-Betrieb unter dem Aspekt der Risikominimierung effizient und mit möglichst geringen negativen Auswirkungen auf die Qualität der IT-Serviceerbringung umgesetzt werden.
Das Change Management stellt sicher, dass Änderungen am IT-Betrieb unter dem Aspekt der Risikominimierung effizient und mit möglichst geringen negativen Auswirkungen auf die Qualität der IT-Serviceerbringung umgesetzt werden.
Prozessrollen | |
• | Owner Change Management |
• | Change Manager |
• | Change-Anforderer |
• | Change-Ersteller |
• | Change-Koordinator |
• | Change Builder |
• | Change-Autorität |
• | CAB-Mitglied (CAB = Change Advisory Board) |
• | ECAB-Mitglied (Emergency-CAB) |
1. RFC einreichen und erfassen
Es müssen Prozeduren zur Erfassung und Einreichung von Request for Changes (RFCs) definiert werden. Alle angenommenen RFCs müssen gespeichert und mit einer Identifikationsnummer (in chronologischer Reihenfolge) versehen werden.
Es wird empfohlen, dass das Aufzeichnen der RFCs vermittels eines integrierten Service-Management-Tools erfolgt, mit dem sowohl alle Change-Item-(CI-)Daten als auch die Beziehungen zwischen ihnen gespeichert werden. Alle Aktivitäten sollten in dem Change-Management-Datensatz hinterlegt werden.
Inputs:
Change Owner und Change-Anforderer, Change-Anforderungen
Change Owner und Change-Anforderer, Change-Anforderungen
Outputs:
RFC-Datensatz
RFC-Datensatz
2. Change klassifizieren
Jedem RFC wird eine Priorität zugeordnet, die auf den geschäftlichen Auswirkungen und der Dringlichkeit gründet. Dabei ist die Durchführung einer Risikobewertung von essenzieller Wichtigkeit.
Kategorien
Bei der Kategorisierung des Changes werden die Komplexität des Changes sowie der damit verbundene Informations- und Kommunikationsbedarf bewertet. Typische Change-Kategorien sind:
Bei der Kategorisierung des Changes werden die Komplexität des Changes sowie der damit verbundene Informations- und Kommunikationsbedarf bewertet. Typische Change-Kategorien sind:
• | Standard-Change |
• | Normal Change (untergliedert in Minor, Significant, Major Change) |
• | Emergency Change |
Inputs:
RFC-Datensatz
RFC-Datensatz
Outputs:
RFC-Datensatz mit Priorität und Kategorie, Checkliste für Change-Durchführung, zugewiesener Change-Koordinator
RFC-Datensatz mit Priorität und Kategorie, Checkliste für Change-Durchführung, zugewiesener Change-Koordinator
3. Change autorisieren
Die Autorisierungsinstanz im Change Management sollte für jeden Change eine formale Autorisierung aussprechen. Bei Änderungen mit geringem Risiko kann die Autorisierung auch delegiert werden. Die jeweilige Autorisierungsebene für einen Change sollte auf der Basis der Change-Risiken beurteilt werden.
Inputs:
RFC-Datensatz
RFC-Datensatz
Outputs:
Aktualisierter RFC-Datensatz mit Status „Change autorisiert” oder „Change-Autorisierung abgewiesen”, Release-Plan
Aktualisierter RFC-Datensatz mit Status „Change autorisiert” oder „Change-Autorisierung abgewiesen”, Release-Plan
4. Change einplanen
Wenn immer möglich, sollte das Change Management autorisierte Änderungen im Rahmen geplanter Releasezyklen einplanen und eine entsprechende Ressourcenzuordnung vorschlagen.
Softwareänderungen sollten in Form zusammengefasster Releases implementiert werden. Es ist sehr wichtig, dass eine klar definierte Releasestrategie für Softwareprodukte besteht, die mit dem Change Management synchronisiert ist.
Es wird empfohlen, dass das Change Management Forward Schedules of Change (FSCs) erstellt. Die FSC sollten an alle Kunden und Anwender oder deren Vertreter verteilt werden, an die Softwareentwickler, die Mitarbeiter des Service Desks und an andere interessierte Parteien.
Inputs:
Change-Datensatz, Release-Plan, Change-Kalender, Liste der Froozen Zones
Change-Datensatz, Release-Plan, Change-Kalender, Liste der Froozen Zones
Outputs:
Aktualisierter Change-Datensatz mit Change-Zeitfenster, Grobkonzept, aktualisierter Forward Schedule of Change
Aktualisierter Change-Datensatz mit Change-Zeitfenster, Grobkonzept, aktualisierter Forward Schedule of Change
5. Erstellen, testen, freigeben
Autorisierte RFCs sollten zur Change-Erstellung an die entsprechenden technischen Einheiten weitergeleitet werden. Die Change-Erstellung kann umfassen:
• | Erstellen eines neuen Produktivmoduls |
• | Entwickeln einer neuen Version für eines oder mehrere Softwaremodule |
• | externe Beschaffung von Betriebsmitteln oder Dienstleistungen |
• | Vorbereiten von Hardwareänderungen |
• | Erstellen einer neuen oder angepassten Dokumentation |
• | Vorbereiten von Delta-Schulungen für Anwender |
Die Änderungen und – sofern möglich – die Rückfallprozeduren sind vor der Inbetriebnahme zu testen und abzunehmen. Die Testprotokolle sind zu dokumentieren.
Inputs:
Change-Datensatz mit Change-Zeitfenster, Grobkonzept
Change-Datensatz mit Change-Zeitfenster, Grobkonzept
Outputs:
Aktualisierter Change-Datensatz mit Status „Change realisiert” und fachlicher Freigabe durch den Change Owner, realisierter Change, Schulungskonzept, Rollout-Plan, Anwenderdokumentation, Administrationsdokumentation, Rückfallplan
Aktualisierter Change-Datensatz mit Status „Change realisiert” und fachlicher Freigabe durch den Change Owner, realisierter Change, Schulungskonzept, Rollout-Plan, Anwenderdokumentation, Administrationsdokumentation, Rückfallplan
6. Change implementieren
Die Implementierung der Änderungen kann nach der Freigabe eingeplant werden. Dabei sollten Support-Mitarbeiter bereitstehen, die beim Auftreten von Störungen schnell eingreifen können. Wenn möglich, sollte die Umsetzung der Änderungen in begrenzten Umgebungen – beispielsweise im Rahmen einer Pilotierung – in Betracht gezogen werden.
Inputs:
Change-Datensatz, realisierter Change, Rückfallplan, Rollout-Plan, Schulungskonzept, Anwenderdokumentation, Administratordokumentation
Change-Datensatz, realisierter Change, Rückfallplan, Rollout-Plan, Schulungskonzept, Anwenderdokumentation, Administratordokumentation
Outputs:
Aktualisierter RFC-Datensatz mit Status „Change implementiert”
Aktualisierter RFC-Datensatz mit Status „Change implementiert”
7. Review und Abschluss
Das Change Management ist verpflichtet, alle implementierten Änderungen zu prüfen und zu bewerten. Dabei soll sichergestellt werden, dass
• | die Änderung den gewünschten Effekt und die Zielsetzungen erreicht hat, |
• | keine unerwarteten oder unerwünschten Nebeneffekte aufgetreten sind, |
• | der Rückfallplan korrekt funktioniert hat, sofern er eingesetzt werden musste. |
Inputs:
RFC-Datensatz mit Status „Change implementiert”, Change-Beschreibung, Change-Grobkonzept, Change-Aktivitäten, Implementierungsergebnis
RFC-Datensatz mit Status „Change implementiert”, Change-Beschreibung, Change-Grobkonzept, Change-Aktivitäten, Implementierungsergebnis
Outputs:
Aktualisierter Change-Datensatz mit Status „Change Review abgeschlossen” und Review-Ergebnis, Change-Abschlusscode
Aktualisierter Change-Datensatz mit Status „Change Review abgeschlossen” und Review-Ergebnis, Change-Abschlusscode
8. Prozesskontrolle
Das Change Management sollte Folgemaßnahmen aufsetzen, mit denen Problemstellungen oder Ineffizienzen beseitigt werden können, die mit einer ineffektiven Change-Durchführung im Zusammenhang stehen. Darüber hinaus sollte der Change Manager kontinuierlich Effizienz und Effektivität des Change-Management-Prozesses überwachen.
Inputs:
KPI-Auswertung
KPI-Auswertung
Outputs:
Management-Bericht
Management-Bericht
3.2.2 CON.2 Configuration Management
Prozessziele
Das Configuration Management
Das Configuration Management
• | verwaltet alle für das IT-Service-Management (ITSM) relevanten Configuration Items (CIs) und deren Relationen untereinander, |
• | liefert an alle beteiligten Prozesse des IT-Service-Managements die benötigten Informationen über IT-Komponenten, deren Konfiguration und Dokumentation, |
• | stellt für alle anderen ITSM-Prozesse die zentrale Informationsbasis über die zur Serviceerbringung eingesetzte technische und logische Infrastruktur bereit. |
Prozessrollen | |
• | Owner Configuration Management |
• | Configuration-Manager |
• | Configuration-Administrator (Datenverantwortlicher) |
• | Mitarbeiter Configuration Management |
1. Planung
Bei der Planung des Configuration-Management-Prozesses werden Zweck, Umfang, Inhalte und ein Vorgehensmodell zur stufenweisen Implementierung der CIs in Abstimmung mit dem Servicemanagement festgelegt. Das Configuration Management muss den geschäftlichen Interessen entsprechen, die von der IT-Organisation unterstützt werden.
Inputs:
Informationsanforderungen, Planungsdaten für CIs, Service-Katalog
Informationsanforderungen, Planungsdaten für CIs, Service-Katalog
Outputs:
Prozessanforderungen, Dokumentationsrichtlinien, Configuration-Management-Database(CMDB)-Struktur, Tool-Anforderungen, Arbeitsanweisungen, Workflow-Dokumentation, Berichtsstruktur, Einführungskonzept für CIs, Abnahmeerklärung
Prozessanforderungen, Dokumentationsrichtlinien, Configuration-Management-Database(CMDB)-Struktur, Tool-Anforderungen, Arbeitsanweisungen, Workflow-Dokumentation, Berichtsstruktur, Einführungskonzept für CIs, Abnahmeerklärung
2. Identifizierung
Identifizierung konzentriert sich auf die Bestimmung und Pflege der Bezeichnungen und Identifikatoren der physischen Komponenten der IT-Infrastruktur, die gegenseitigen Beziehungen und die relevanten Attribute. Dokumentationen von Basiskonfigurationen (Baselines) werden in Form zusammengehöriger CI-Gruppen beschrieben.
Während des Aufbaus eines Identifizierungssystems werden Entscheidungen hinsichtlich des Umfangs und der Detaillierung der zu erfassenden Informationen getroffen. Für jede Eigenschaft, die erfasst werden soll, müssen zudem ein Verantwortlicher (für die Pflege) und ein Interessent (für die jeweilige Information) identifiziert werden.
Inputs:
Planungsdaten für CIs, CMDB-Struktur, Workflow-Dokumentation, Arbeitsanweisungen, Dokumentationsrichtlinien, Einführungskonzept für CIs
Planungsdaten für CIs, CMDB-Struktur, Workflow-Dokumentation, Arbeitsanweisungen, Dokumentationsrichtlinien, Einführungskonzept für CIs
Outputs:
Aktualisierte CMDB-Inhalte, implementierte Workflows, Templates für CIs
Aktualisierte CMDB-Inhalte, implementierte Workflows, Templates für CIs
3. Überwachung von Änderungen
Um die CMDB stets auf dem neuesten Stand zu halten, müssen die Daten gepflegt werden. Bei jeglicher Änderung der dokumentierten Eigenschaften der CIs oder deren interner Beziehungen, sind diese Änderungen in der CMDB festzuhalten.
Zu diesem Zweck kontrolliert und dokumentiert das Configuration Management alle neu hinzukommenden IT-Komponenten, die einen Beitrag zur IT-Serviceerbringung leisten. Für Hardware kann als Erfassungszeitpunkt das Bestell- oder das Auslieferungsdatum herangezogen werden, während es sich für Software anbietet, sie zum Zeitpunkt ihrer Aufnahme in die Definitive Media Library (DML) zu dokumentieren.
Eine weitere Aufgabe im Rahmen der Kontrolle besteht darin sicherzustellen, dass nur autorisierte CIs in die CMDB aufgenommen werden. Das Configuration Management steht zu diesem Zweck in enger Abstimmung mit dem Change Management.
Inputs:
Soll-Konfiguration CMDB, Inhalte der DML, betriebliche Ist-Konfiguration, Inventarliste, Forward Schedule of Changes
Soll-Konfiguration CMDB, Inhalte der DML, betriebliche Ist-Konfiguration, Inventarliste, Forward Schedule of Changes
Outputs:
Planungsdaten für CIs
Planungsdaten für CIs
4. Statusüberwachung
Der Lebenszyklus einer Komponente lässt sich in unterschiedliche Phasen gliedern. Jeder dieser Phasen kann ein Statuscode zugewiesen werden. Dessen Inhalt wird durch die Eigenschaften der IT-Infrastruktur bestimmt, die aufgezeichnet werden sollen.
Über den Status einer Komponente kann auch geregelt werden, wie das jeweilige CI eingesetzt wird. Wird zum Beispiel ein Status für reservierte Geräte geführt, so dürfen diese Geräte nur für den geplanten Einsatzzweck genutzt werden.
Inputs:
Soll-Konfiguration CMDB, betriebliche Ist-Konfiguration
Soll-Konfiguration CMDB, betriebliche Ist-Konfiguration
Outputs:
Aktualisierter CI-Status
Aktualisierter CI-Status
5. Verifikation und Audit
Diese Aktivität überprüft die Qualität des Configuration-Management-Prozesses sowie die Qualität der CMDB-Inhalte.
Verifikation: Prüfen des Prozesses als Ganzes oder in Teilen
Audit: Kontextsensitive Überprüfung zur Feststellung der Dokumentationsqualität nach Änderungen an der IT-Infrastruktur, nach Durchführung einer Inventur oder im Rahmen geplanter Inspektionen
Inputs:
Soll-Konfiguration CMDB, betriebliche Ist-Konfiguration
Soll-Konfiguration CMDB, betriebliche Ist-Konfiguration
Outputs:
Inventarliste, Soll-Konfiguration CMDB, Einführungskonzept für CIs, offene Informationsanforderungen, offene Prozessanforderungen
Inventarliste, Soll-Konfiguration CMDB, Einführungskonzept für CIs, offene Informationsanforderungen, offene Prozessanforderungen
6. Prozesskontrolle
Zu den Überwachungs- und Steuerungsaufgaben gehören
• | das Messen der Prozessqualität und das Erstellen von Managementberichten, |
• | die proaktive Feststellung des Informationsbedarfs aller an der IT-Serviceerbringung beteiligten Prozesse und Funktionen, |
• | die Überwachung der Informationsauslieferung, |
• | die schrittweise Verbesserung der Prozessqualität im Rahmen eines kontinuierlichen Verbesserungsprozesses. |
Inputs:
KPIs, Informationsanforderungen
KPIs, Informationsanforderungen
Outputs:
Managementbericht, CI-Bericht oder Online-Information
Managementbericht, CI-Bericht oder Online-Information
3.2.3 CON.3 Release and Deployment Management
Prozessziele
Das Release Management stellt den Schutz der Produktivumgebung und die Gewährleistung der Servicequalität durch Einsatz funktional korrekter und zuverlässiger Hard- und Softwarekomponenten sicher.
Das Release Management stellt den Schutz der Produktivumgebung und die Gewährleistung der Servicequalität durch Einsatz funktional korrekter und zuverlässiger Hard- und Softwarekomponenten sicher.
Prozessrollen | |
• | Owner Release Management |
• | Release-Manager |
• | Release-Ersteller |
• | Release-Tester |
• | Release-Deliverer |
1. Release-Planung
Die Release-Planung liefert einen Business Case für das angeforderte Release. Diese umfasst den personellen und technischen Aufwand für Vorbereitung, Anforderungsdefinition, Ausbildung, Testen, Entwicklung, Auslieferung sowie die Abschätzung der benötigten Ressourcen.
Inputs:
Kundenanforderungen, Release-Richtlinien
Kundenanforderungen, Release-Richtlinien
Outputs:
Business-Case, Anforderungsspezifikation, Release-Plan, Auftragsbestätigung
Business-Case, Anforderungsspezifikation, Release-Plan, Auftragsbestätigung
2. Release entwickeln, erstellen, konfigurieren
Planung und Dokumentation der Verfahren zur Erstellung von Releases (nach Möglichkeit als wiederverwendbare Standardprozeduren). Die Anweisungen zur Zusammenstellung eines Releases sind Bestandteil der Release-Definition und sollten als CI behandelt und überwacht werden.
Inputs:
Business Case, Anforderungsspezifikation, Release-Plan, Auftragsbestätigung
Business Case, Anforderungsspezifikation, Release-Plan, Auftragsbestätigung
Outputs:
Erstelltes Release, Release-Dokumentation, Rückfallplan
Erstelltes Release, Release-Dokumentation, Rückfallplan
3. Release-Test und Abnahme
Die Release-Tests sollten durch unabhängige IT-Mitarbeiter und Anwender durchgeführt werden. Auch alle Rückfallverfahren sollten im Rahmen dieser Aktivitäten getestet werden. Getestet werden somit sowohl die Installationsverfahren, die Funktionalität als auch die funktionale Integrität des endgültigen Systems.
Jede Testphase sollte schriftlich abgenommen werden. Die letztliche Abnahme des neuen Releases und dessen Freigabe für die Produktionsumgebung sollten im Change-Management-Prozess liegen.
Die Release-Abnahme sollte in einer kontrollierten Testumgebung mit einer wohldefinierten IT-Infrastruktur erfolgen. Die Konfiguration sollte in den Release-Spezifikationen beschrieben und in der CMDB gespeichert werden.
Ein abgelehntes Release sollte durch das Change Management neu eingeplant werden. Abgelehnte Releases sollten im Change Management als fehlgeschlagene Änderungen behandelt werden.
Inputs:
Erstelltes Release, Release-Dokumentation, Rückfallplan
Erstelltes Release, Release-Dokumentation, Rückfallplan
Outputs:
Testbericht
Testbericht
4. Rollout-Planung
Die Rollout-Planung basiert auf dem Release-Plan und enthält eine detaillierte zeitliche und inhaltliche Planung zur Auslieferung des Releases. Die Rollout-Planung umfasst folgende Aspekte:
• | einen exakten, detaillierten Zeitplan sowie einen Ressourcenplan (Wer macht was?) |
• | eine Liste der zu installierenden und deinstallierenden CIs mit Entsorgungsregelungen für die außer Betrieb zu nehmenden Komponenten |
• | einen nach Standorten unterteilten Handlungsplan |
• | Release Notes und Anwendermitteilungen |
• | Planung der Kommunikationsmaßnahmen |
• | Entwicklung von Beschaffungsplänen |
• | Beschaffung der benötigten Hardware und Software, Verfahren zu deren sicheren Aufbewahrung bis zum Auslieferungstermin und geregelten Übergabe während der Implementierung |
• | Planung von Sitzungen zur Steuerung der involvierten Mitarbeiter und Teams |
Inputs:
Erstelltes Release, Release-Dokumentation, Rückfallplan
Erstelltes Release, Release-Dokumentation, Rückfallplan
Outputs:
Rollout-Plan mit Ressourcenbedarf
Rollout-Plan mit Ressourcenbedarf
5. Kommunikation, Vorbereitung und Schulung
Die Kunden, deren IT-Ansprechpartner und die IT-Mitarbeiter müssen den Planungsstand und die sie betreffenden Auswirkungen kennen. Dies wird normalerweise über Schulungen, Parallelbetrieb und die Einbeziehung in die Release-Abnahmeverfahren erreicht.
Inputs:
Release-Plan, Rollout-Plan, Release-Dokumentation
Release-Plan, Rollout-Plan, Release-Dokumentation
Outputs:
Informierte Kunden, geschulte Anwender und Administratoren
Informierte Kunden, geschulte Anwender und Administratoren
6. Verteilung und Installation
Die Verteilung der Softwarereleases von der Build-Umgebung in die kontrollierte Testumgebung und anschließend in die Produktionsumgebung sollte in dem zugehörigen Change protokolliert werden.
Bei den Beschaffungs-, Lagerhaltungs-, und Verteilprozessen sollte darauf geachtet werden, dass die Systeme und IT-Komponenten sicher und in einwandfreiem Zustand an ihren Zielort ausgeliefert werden. Im Sinne der Anforderungen des Configuration Managements hat eine Zuordnung der IT-Komponenten zu den Bestell- und Lieferdokumenten zu erfolgen.
Die Softwareverteilung sollte so durchgeführt werden, dass die Integrität der Software bei der Zusammenstellung und Auslieferung sichergestellt bleibt.
Inputs:
Release-Plan, Release, Rollout-Plan
Release-Plan, Release, Rollout-Plan
Outputs:
Abnahmedokument Kunde, Dokumentation der installierten Systeme
Abnahmedokument Kunde, Dokumentation der installierten Systeme
7. Prozesskontrolle
Die Aufgaben der Prozesssteuerung umfassen die Definition und kontinuierliche Überwachung von KPIs. Diese dienen der Feststellung, ob die kritischen Erfolgsfaktoren des Prozesses eingehalten werden.
Auf der Basis dieser Messungen werden Managementberichte für den relevanten Personenkreis erstellt.
Inputs:
KPIs, Informationsanforderungen
KPIs, Informationsanforderungen
Outputs:
Managementbericht, CI-Bericht oder Online-Information
Managementbericht, CI-Bericht oder Online-Information