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.
Da wir als Beispiel ein Reifegradmodell für ISO/IEC 20000 erstellen wollen, verwenden wir die Prozesse aus diesem Standard (vgl. Abbildung 2).
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
3.3.1 SD.1 Service Level Management
Prozessziele
Das Service Level Management (SLM) ist der Prozess, in dem IT Services geplant, vereinbart und verwaltet werden. Ziel des Service Level Managements ist die Erfüllung der Kundenanforderungen mit preiswerten, quantifizierbaren IT Services in definierter Qualität. Dazu vereinbart und verwaltet der Prozess Service Level Agreements (SLA).
Das Service Level Management (SLM) ist der Prozess, in dem IT Services geplant, vereinbart und verwaltet werden. Ziel des Service Level Managements ist die Erfüllung der Kundenanforderungen mit preiswerten, quantifizierbaren IT Services in definierter Qualität. Dazu vereinbart und verwaltet der Prozess Service Level Agreements (SLA).
| Prozessrollen | |
| • | Owner Service Level Management |
| • | Service-Level-Manager |
| • | Service-Koordinator |
| • | Service-Owner |
| • | IT-Architekt |
| • | Event- und Monitoring-Manager |
1. Kunden definieren
Vertragspartner der IT festlegen. Kunden haben Budgethoheit und schließen mit der IT für definierte Anwendergruppen SLAs ab.
Inputs:
Struktur Kundenorganisation
Struktur Kundenorganisation
Outputs:
Kundenliste, Kunden mit Bereitschaft zu Vertragsvereinbarung mit IT
Kundenliste, Kunden mit Bereitschaft zu Vertragsvereinbarung mit IT
2. Serviceanforderungen definieren
In mehreren Gesprächsrunden werden zusammen mit den Kunden die Service-Level-Anforderungen erarbeitet. Dabei werden die fachlichen Anforderungen der Kunden erhoben und die technischen Möglichkeiten und Restriktionen der IT aufgezeigt. Die Gespräche werden protokolliert und ggf. gegengezeichnet, sie haben aber keinen vertraglichen Charakter. Die Service Level Requirements (SLR) beschreiben die Anforderungen des Kunden an einen IT Service.
Inputs:
Kunde, Servicekatalog
Kunde, Servicekatalog
Outputs:
SLR-Vereinbarung
SLR-Vereinbarung
3. SLA-Entwurf erstellen
Auf der Basis der Service Level Requirements (SLR) erstellt die IT, in der Regel ohne Kunden, einen SLA-Entwurf. In diesem werden die fachlichen Anforderungen die im SLR dokumentiert sind, in IT-technologischer Nomenklatur ausgedrückt und in eine Vertragsform gegossen.
Input:
SLR-Vereinbarung, Servicekatalog, IT Service
SLR-Vereinbarung, Servicekatalog, IT Service
Output:
SLA-Entwurf, Entwurf der Leistungsauswertungen
SLA-Entwurf, Entwurf der Leistungsauswertungen
4. SLA verhandeln und vereinbaren
Auf der Grundlage des SLA-Entwurfs nimmt die IT mit dem Kunden SLA-Verhandlungen auf. Dabei können die zu vereinbarenden Service Levels von den im Servicekatalog definierten Leistungsinhalten abweichen, sofern sichergestellt ist, dass diese zusätzlichen Leistungsanforderungen von den internen und externen Servicelieferanten auch erbracht werden können.
Input:
SLR-Vereinbarung, SLA-Entwurf, Servicekatalog
SLR-Vereinbarung, SLA-Entwurf, Servicekatalog
Output:
SLA
SLA
5. Serviceberichte planen und erstellen
Die mit den Kunden verhandelten Serviceberichte werden geplant und programmiert. Die zur Erstellung der Berichte erforderlichen Daten werden manuell oder von einem Monitoringsystem bereitgestellt.
Inputs:
SLA, Entwurf der Leistungsauswertungen
SLA, Entwurf der Leistungsauswertungen
Outputs:
Serviceberichte
Serviceberichte
6. Servicequalität überwachen
Überwachung der Serviceleistungsfähigkeit gemäß SLAs. Bei Änderung der Service Levels, vereinbarter Services oder bei Einführung neuer Services sollten die bestehenden Monitoring-Möglichkeiten überprüft und angepasst werden.
Inputs:
Serviceberichte
Serviceberichte
Outputs:
Verbesserungsvorschläge
Verbesserungsvorschläge
7. Steuerung der Kundenzufriedenheit
Methoden
Kundenzufriedenheit ist ein „weicher” Bewertungsfaktor, der regelmäßig gemessen werden sollte. Methoden dafür enthalten:
Kundenzufriedenheit ist ein „weicher” Bewertungsfaktor, der regelmäßig gemessen werden sollte. Methoden dafür enthalten:
| • | periodisch eingesetzte Fragebögen und Kundenumfragen |
| • | Kunden-Feedback von Service-Review-Besprechungen |
| • | Feedback aus einem Post Implementation Review (PIR), das im Rahmen des Change-Management-Prozesses durchgeführt wird |
| • | Telefonumfragen (ggf. nach dem Zufallsprinzip aus dem Service Desk heraus) |
| • | Zufriedenheitsumfragen |
| • | Besprechungen von Anwendergruppen oder Foren |
| • | Analyse von Beschwerden oder positiven Rückmeldungen |
Inputs:
Incidents, Leistungsauswertungen, Verbesserungsvorschläge
Incidents, Leistungsauswertungen, Verbesserungsvorschläge
Outputs:
Verabschiedete Verbesserungsvorschläge
Verabschiedete Verbesserungsvorschläge
8. Service Review und Service-Verbesserung
Um den Erreichungsgrad der Service Levels in der letzten Auswertungsperiode überprüfen und eine Vorschau auf die Anforderungen der kommenden Periode vornehmen zu können, müssen mit dem Kunden regelmäßig Reviews durchgeführt werden. Normalerweise finden solche Besprechungen monatlich, mindestens aber vierteljährlich statt. Besondere Aufmerksamkeit sollte jedem Bruch vereinbarter Service Levels gelten, um genau bestimmen zu können, was den Rückgang an Servicequalität bedingt hat und was unternommen werden kann, um dies für die Zukunft zu verhindern. Falls festgestellt wird, dass Service Levels nicht erreicht worden sind oder nicht erreichbar sind, kann es erforderlich sein, sie neu zu verhandeln und zu vereinbaren.
Inputs:
Incidents, Leistungsauswertungen, verabschiedete Verbesserungsvorschläge, Kundenanforderungen
Incidents, Leistungsauswertungen, verabschiedete Verbesserungsvorschläge, Kundenanforderungen
Outputs:
Aktualisiertes Serviceverbesserungsprogramm
Aktualisiertes Serviceverbesserungsprogramm
9. SLM-Prozesskontrolle
Aufgaben dieser Aktivität sind die Überwachung der Prozessqualität, die Erstellung und Auslieferung von Managementberichten, die Überwachung der Problem- und Fehlerbearbeitung sowie ggf. auch das Anstoßen von Eskalationen.
Inputs:
KPIs
KPIs
Output:
Managementbericht
Managementbericht
3.3.2 SD.2 Service Reporting
Prozessziele
Serviceberichte sind Leistungsberichte. Die Inhalte der Serviceberichte müssen zwischen Dienstleistungserbringer und Leistungsabnehmer definiert und vereinbart werden. Serviceberichte sollten im Minimum einhalten:
Serviceberichte sind Leistungsberichte. Die Inhalte der Serviceberichte müssen zwischen Dienstleistungserbringer und Leistungsabnehmer definiert und vereinbart werden. Serviceberichte sollten im Minimum einhalten:
| • | erreichter Leistungsgrad der vereinbarten Leistungsziele |
| • | relevante Information über signifikante Ereignisse, wie z. B. Major Incidents, neue oder geänderte Services oder Kontinuitätsplanungen |
| • | Mengengerüste bzgl. der Arbeitslast |
| • | Angaben zur durchschnittlichen Arbeitslast und zu regelmäßigen Schwankungen |
| • | Trendauswertungen |
| • | Kundenzufriedenheit, Beschwerden und Verbesserungen aufgrund von Gegenmaßnahmen |
| Prozessrollen | |
| • | Owner Service Reporting |
| • | Service Reporting Manager |
1. Serviceberichte planen
Entwicklung eines Rahmenwerks zur Servicemessung mit folgenden Inhalten:
| • | Messsysteme für Services, Prozesse, Technologien definieren |
| • | Definieren von Verfahren und Richtlinien |
| • | Rollen und Verantwortlichkeiten für die Durchführung von Messungen und Erstellung von Berichten |
| • | Kriterien für die Änderung von Zielgrößen oder Messungen |
| • | Inhaltliche Planung der Serviceberichte |
Inputs:
Serviceanforderungen, SLRs, SLAs
Serviceanforderungen, SLRs, SLAs
Outputs:
Rahmenwerk für Servicemessungen, geplante Serviceberichte
Rahmenwerk für Servicemessungen, geplante Serviceberichte
2. Serviceberichte umsetzen
Realisieren und Umsetzen der Messsysteme, Servicemessungen und Serviceberichte. Berichtsformate sind Periodenberichte oder Ad-hoc-Berichte.
Inputs:
Rahmenwerk für Servicemessungen, geplante Servicebericht
Rahmenwerk für Servicemessungen, geplante Servicebericht
Outputs:
Messsysteme, Servicemessungen und Serviceberichte
Messsysteme, Servicemessungen und Serviceberichte
3. Messen und Berichten
Erheben von Messdaten, Erstellen der Berichte und Ausliefern der Berichte an definierte Adressaten.
Inputs:
Messdaten
Messdaten
Outputs:
Serviceberichte
Serviceberichte
4. Durchführen von Verbesserungsmaßnahmen
Ändern oder Erweitern bestehender Berichte, Anpassen der Zielmessgrößen und Ersetzen obsoleter Messungen und Berichte, beispielsweise nach Technologiewechseln oder im Zuge der Verbesserung des Reifegrads.
Inputs:
Rahmenwerk für Servicemessungen, Messsysteme, Servicemessungen und Serviceberichte
Rahmenwerk für Servicemessungen, Messsysteme, Servicemessungen und Serviceberichte
Outputs:
Service-Verbesserungsplan
Service-Verbesserungsplan
5. Prozesskontrolle
Aufgaben dieser Aktivität sind die Überwachung der Prozessqualität sowie die Erstellung und Auslieferung von Managementberichten.
Inputs:
KPIs
KPIs
Outputs:
Managementbericht
Managementbericht
3.3.3 SD.3 Availability Management
Prozessziele
Ermitteln der Verfügbarkeitsanforderungen des Geschäftsbetriebs sowie Planung der Verfügbarkeitsprofile der IT-Infrastruktur, sodass SLAs eingehalten werden können.
Ermitteln der Verfügbarkeitsanforderungen des Geschäftsbetriebs sowie Planung der Verfügbarkeitsprofile der IT-Infrastruktur, sodass SLAs eingehalten werden können.
| Prozessrollen | |
| • | Owner Availability Management |
| • | Availability Manager |
| • | Mitarbeiter Availability Management |
1. Verfügbarkeit auswerten
Ermitteln der aktuellen Verfügbarkeitsprofile. Gemessen werden die Serviceverfügbarkeit als Ende-zu-Ende-Messung, die Verfügbarkeitsprofile der technischen Komponenten sowie die sich aus dem Auftreten von Ausfällen ergebenden maximalen und minimalen Wiederherstellungszeiten.
Inputs:
Verfügbarkeitsberichte, Verfügbarkeitsstörungen
Verfügbarkeitsberichte, Verfügbarkeitsstörungen
Outputs:
Auswertungen der Ist-Verfügbarkeit nach Services
Auswertungen der Ist-Verfügbarkeit nach Services
2. Verfügbarkeit planen
Die Planung der Sollverfügbarkeit eines Service erfordert die Analyse der Verfügbarkeitsanforderungen. Diese ergeben sich aus den Kundenanforderungen, der geschäftlichen Wichtigkeit der Services, aus Anforderungen des Sicherheits- und Kontinuitätsmanagements sowie aus internen und externen regulatorischen Anforderungen.
Die Planung der erforderlichen Verfügbarkeitsprofile umfasst auch die Wartungsprofile der Systeme hinsichtlich ihrer technologischen Architekturen.
Entsprechend den eingesetzten Architekturen werden auch die Messsysteme und Messkriterien geplant.
Inputs:
Auswertungen der Ist-Verfügbarkeit nach Services, Konfiguration der technischen Infrastruktur, Bewertung der geschäftlichen Wichtigkeit von Services, erforderliche Verbesserungsmaßnahmen
Auswertungen der Ist-Verfügbarkeit nach Services, Konfiguration der technischen Infrastruktur, Bewertung der geschäftlichen Wichtigkeit von Services, erforderliche Verbesserungsmaßnahmen
Outputs:
Verfügbarkeitsanforderungen, Messsysteme, Messkriterien, Kontrollpunkte zur Durchführung von Messungen
Verfügbarkeitsanforderungen, Messsysteme, Messkriterien, Kontrollpunkte zur Durchführung von Messungen
3. Verfügbarkeitsplan umsetzen
Die Messungen werden an den vordefinierten Kontrollpunkten aufgesetzt und in Verfügbarkeitsberichten ausgewertet.
Inputs:
Verfügbarkeitsanforderungen, Messsysteme, Messkriterien, Kontrollpunkte zur Durchführung von Messungen
Verfügbarkeitsanforderungen, Messsysteme, Messkriterien, Kontrollpunkte zur Durchführung von Messungen
Outputs:
Konfigurierte Messsysteme und Verfügbarkeitsberichte
Konfigurierte Messsysteme und Verfügbarkeitsberichte
4. Verfügbarkeit überwachen
Die Messungen werden durchgeführt und in regelmäßig publizierten Berichten ausgewertet. Die Überwachung erfolgt darüber hinaus durch Einbindung in das Incident Management.
Die erreichten Verfügbarkeiten werden gegen die Verfügbarkeits-Service-Levels aus den SLAs gemessen.
Inputs:
Konfigurierte Messsysteme, Verfügbarkeitsberichte, Incidents
Konfigurierte Messsysteme, Verfügbarkeitsberichte, Incidents
Outputs:
Verfügbarkeitsauswertungen
Verfügbarkeitsauswertungen
5. Verbesserung der Verfügbarkeitsprofile
Können die mit den Kunden vereinbarten Verfügbarkeits-Service-Levels dauerhaft nicht oder nur schwer eingehalten werden oder werden aufgrund neuer geschäftlicher Anforderungen bzw. Technologiewechsel neue Messungen oder Verfügbarkeitsprofile erforderlich, so werden diese im Zuge von Verbesserungsmaßnahmen umgesetzt.
Inputs:
Verfügbarkeitsanforderungen, Messanforderungen
Verfügbarkeitsanforderungen, Messanforderungen
Outputs:
Erforderliche Verbesserungsmaßnahmen
Erforderliche Verbesserungsmaßnahmen
6. Prozesskontrolle Availability Management
Aufgaben dieser Aktivität sind die Überwachung der Prozessqualität, die Erstellung und Auslieferung von Managementberichten, die Überwachung der Problem- und Fehlerbearbeitung sowie ggf. auch das Anstoßen von Eskalationen.
Inputs:
KPIs
KPIs
Output:
Managementbericht
Managementbericht
3.3.4 SD.4 Capacity Management
Prozessziele
Planung, Überwachung sowie zeitgerechte und damit kostengünstige Bereitstellung von Kapazität für die IT-Infrastruktur zur Erfüllung der jetzigen und künftigen Geschäftsanforderungen.
Planung, Überwachung sowie zeitgerechte und damit kostengünstige Bereitstellung von Kapazität für die IT-Infrastruktur zur Erfüllung der jetzigen und künftigen Geschäftsanforderungen.
| Prozessrollen | |
| • | Owner Capacity Management |
| • | Capacity Manager |
| • | Mitarbeiter Capacity Management |
Prozessphasen und Artefakte
Technische Kapazität ist in der Regel eine Kombination aus Menge und Durchsatz (Antwortzeitverhalten: Wie lange dauert es, bis eine Menge an Daten verarbeitet und am Endgerät ausgegeben ist, Batch-Laufzeit: Wie lange dauert es, bis eine Menge an Daten verarbeitet ist). Der Kapazitätsbegriff kann aber auch ausschließlich ein Mengenbegriff sein (Speicherplatzbedarf einer Anwendung).
Technische Kapazität ist in der Regel eine Kombination aus Menge und Durchsatz (Antwortzeitverhalten: Wie lange dauert es, bis eine Menge an Daten verarbeitet und am Endgerät ausgegeben ist, Batch-Laufzeit: Wie lange dauert es, bis eine Menge an Daten verarbeitet ist). Der Kapazitätsbegriff kann aber auch ausschließlich ein Mengenbegriff sein (Speicherplatzbedarf einer Anwendung).
1. Business Capacity Management
Planung der Kapazitätsanforderungen aus geschäftlicher Sicht. Dabei geht es einerseits um den Umgang mit unzureichender Kapazität infolge partieller Ausfälle kapazitätskritischer Ressourcen (z. B. Clusterknoten, Memory-Bausteine, Speichersysteme) und um die Identifizierung und Bereitstellung geschäftskritischer Servicebestandteile bei partiellen Ausfällen.
Andererseits geht es um den geplanten Umgang mit begrenzter Kapazität, indem bewusst physikalische Beschränkungen eingerichtet werden (z. B. Beschränkung der Zahl konkurrierender Zugriffe auf Services, Bandbreitenbeschränkungen) oder indem finanzielle Anreize zu ressourcenschonendem Verhalten gegeben werden (z. B. bei Nutzung der Services außerhalb von Stoßzeiten).
Inputs:
Geschäftliche Kapazitätsanforderungen der Kunden, SLAs, Störungsmeldungen
Geschäftliche Kapazitätsanforderungen der Kunden, SLAs, Störungsmeldungen
Outputs:
Service-Verbesserungsplan, Kapazitätskonzept mit Kundenanreizen
Service-Verbesserungsplan, Kapazitätskonzept mit Kundenanreizen
2. Service Capacity Management
Messen der Kapazitätsprofile auf Serviceebene. Sofern die Kapazitätsziele nicht oder nur unzuverlässig erreicht werden, werden die Leistungsprofile über Component Capacity Management optimiert.
Inputs:
SLAs, Kapazitätskonzept mit Kundenanreizen
SLAs, Kapazitätskonzept mit Kundenanreizen
Outputs:
Aktuelles Kapazitätsprofil
Aktuelles Kapazitätsprofil
3. Component Capacity Management
Tuning technischer Systeme, um die Anforderungen an die Servicekapazität erfüllen zu können, die im Service Capacity Management identifiziert wurden.
Nach der Tuning-Maßnahme wird im Service Capacity Management gemessen, ob die erforderliche Servicekapazität nunmehr erreicht wird. Falls nicht, wird im Component Capacity Management der nächste Flaschenhals beseitigt. Dieser iterative Ablauf wird so lange durchgeführt, bis eine ausreichende Servicekapazität erreicht ist.
Inputs:
Aktuelles Kapazitätsprofil, geschäftliche Kapazitätsanforderungen der Kunden, SLAs, Störungsmeldungen, Service-Verbesserungsplan
Aktuelles Kapazitätsprofil, geschäftliche Kapazitätsanforderungen der Kunden, SLAs, Störungsmeldungen, Service-Verbesserungsplan
Output:
Verbessertes Kapazitätsprofil
Verbessertes Kapazitätsprofil
4. Prozesskontrolle Capacity Management
Aufgaben dieser Aktivität sind die Überwachung der Prozessqualität, die Erstellung und Auslieferung von Managementberichten, die Überwachung der Problem- und Fehlerbearbeitung sowie ggf. auch das Anstoßen von Eskalationen.
Inputs:
KPIs
KPIs
Output:
Managementbericht
Managementbericht
3.3.5 SD.5 Service Continuity Management
Prozessziele
Unterstützen des unternehmensweiten Business Continuity Managements (BCM) mit dem Ziel, nach einem Eventualfall den kritischen Geschäftsbetrieb innerhalb des erforderlichen Zeitrahmens wiederherzustellen bzw. dessen Ausfall durch präventive Maßnahmen zu verhindern.
Unterstützen des unternehmensweiten Business Continuity Managements (BCM) mit dem Ziel, nach einem Eventualfall den kritischen Geschäftsbetrieb innerhalb des erforderlichen Zeitrahmens wiederherzustellen bzw. dessen Ausfall durch präventive Maßnahmen zu verhindern.
| Prozessrollen | |
| • | Owner Service Continuity Management |
| • | Service Continuity Manager |
| • | Mitarbeiter Service Continuity Management |
1. Service Continuity Management definieren
Initiierung des Prozesses sowie Definition und Pflege der Grundsätze und Richtlinien des Prozesses. Die Aktivität umfasst:
| • | Definition der Prozessrichtlinien: Diese sollten zumindest die Absichten des Managements und die Zielsetzungen des Prozesses thematisieren |
| • | Bezugsgrößen und Umfang: Es ist zu klären, welche geschäftlichen Bereiche in welchem Umfang abgesichert werden sollen. In diesem Zusammenhang werden die Steuerungs- und Kontrollstrukturen zum Umgang mit geschäftlichen Unterbrechungen sowie die zugehörigen organisatorischen Verantwortlichkeiten definiert. |
| • | Ressourcen zuordnen: Finanzmittel und Personalressourcen. |
| • | Definieren der Projektorganisation und Kontrollstrukturen: Diese gelten nicht nur für das initiale Einführungsprojekt, sondern auch für Anpassungs- und Änderungsmaßnahmen. |
| • | Projekt aufsetzen und Qualitätspläne vereinbaren: Die Qualitätspläne müssen von allen Beteiligten verstanden und akzeptiert sein. Dies ist wichtig, damit die Projektergebnisse den erwarteten Qualitätsanforderungen entsprechen. |
Inputs:
Serviceportfolio, geschäftliche Auswirkungsanalyse, geschäftliche Risikoanalyse, geschäftliche Eventualfallstrategie, geschäftliche Eventualfallpläne
Serviceportfolio, geschäftliche Auswirkungsanalyse, geschäftliche Risikoanalyse, geschäftliche Eventualfallstrategie, geschäftliche Eventualfallpläne
Outputs:
Service-Continuity-Richtlinien, Umfang und organisatorische Verantwortlichkeit
Service-Continuity-Richtlinien, Umfang und organisatorische Verantwortlichkeit
2. Service Continuity Management planen
Die Bestimmung der geschäftlichen Anforderungen an die Kontinuität der IT-Dienste ist die Grundlage zur Planung des geschäftlichen Absicherungsgrades und der damit verbundenen Kosten. Die Planungsphase kann in zwei Bereiche gegliedert werden:
| • | IT-Anforderungsanalyse: Durchführen der Business-Impact- und der Risikoanalyse. |
| • | IT-Notfallstrategie: Aus den Ergebnissen der Anforderungsanalyse werden die erforderlichen Maßnahmen zur Risikominimierung und die Wiederherstellungsoptionen abgeleitet. |
Inputs:
Umfang und organisatorische Verantwortlichkeit, geschäftliche Auswirkungsanalyse, geschäftliche Risikoanalyse, geschäftliche Eventualfallstrategie, geschäftliche Eventualfallpläne
Umfang und organisatorische Verantwortlichkeit, geschäftliche Auswirkungsanalyse, geschäftliche Risikoanalyse, geschäftliche Eventualfallstrategie, geschäftliche Eventualfallpläne
Outputs:
IT-Auswirkungsanalyse, IT-Risikoanalyse, Risikoregister, Service- und IT-Vermögenswerte, Bedrohungsszenarien, Kontinuitätsstrategie
IT-Auswirkungsanalyse, IT-Risikoanalyse, Risikoregister, Service- und IT-Vermögenswerte, Bedrohungsszenarien, Kontinuitätsstrategie
3. Service Continuity Management entwickeln
Nach Abnahme der Strategie werden die IT-Service-Continuity-Pläne entsprechend den geschäftlichen Eventualfallplänen entwickelt. Der Service-Continuity-Plan enthält als übergeordneter Hauptplan eine Reihe technischer Pläne, die üblicherweise als Anhänge beigefügt werden. Diese Pläne enthalten
| • | Notfallpläne, |
| • | Schadensbewertungspläne, |
| • | Bergungspläne, |
| • | Plan unternehmenswichtiger Daten, |
| • | Krisenmanagement- und PR-Pläne, |
| • | Arbeitsplatz- und Servicepläne, |
| • | Sicherheitspläne, |
| • | Personalpläne |
| • | Kommunikationspläne, |
| • | Finanz- und Administrationspläne. |
Inputs:
Serviceportfolio, IT-Auswirkungsanalyse, IT-Risikoanalyse, Risikoregister, Service- und IT-Vermögenswerte, Bedrohungsszenarien, Kontinuitätsstrategie
Serviceportfolio, IT-Auswirkungsanalyse, IT-Risikoanalyse, Risikoregister, Service- und IT-Vermögenswerte, Bedrohungsszenarien, Kontinuitätsstrategie
Outputs:
Service-Continuity-Plan, Schadensbewertungsplan, Rettungsplan, Plan unternehmenswichtiger Daten, Krisenmanagement- und PR-Plan, Arbeitsplatz- und Serviceplan, Sicherheitsplan, Kommunikationsplan, Finanz- und Administrationsplan, Organisationsplan für den Notbetrieb, als relevant für Service-Continuity-Plan gekennzeichnete CIs.
Service-Continuity-Plan, Schadensbewertungsplan, Rettungsplan, Plan unternehmenswichtiger Daten, Krisenmanagement- und PR-Plan, Arbeitsplatz- und Serviceplan, Sicherheitsplan, Kommunikationsplan, Finanz- und Administrationsplan, Organisationsplan für den Notbetrieb, als relevant für Service-Continuity-Plan gekennzeichnete CIs.
3. Service Continuity Management betreiben
Aufgaben
Die Aufgaben der operativen Phase sind:
Die Aufgaben der operativen Phase sind:
| • | Ausbildung, Bewusstseinsbildung und Schulung: Dies sollte bezüglich der abzusichernden Objekte die gesamte Organisation und im Speziellen die IT-Organisation umfassen. Dies stellt sicher, dass die gesamte Belegschaft sich der Auswirkung eines Eventualfallbetriebs bewusst ist und sie mit diesem Notfallbetrieb vertraut sind. |
| • | Review: Durchführung von Reviews in regelmäßigen Abständen bezüglich aller Ergebnisse des Prozesses. Damit wird sichergestellt, dass sie immer aktuell sind. |
| • | Testen: Nach dem initialen Testen ist es erforderlich, ein Programm regelmäßiger Tests aufzulegen, mit dem sichergestellt wird, dass alle kritischen Komponenten der Notfallstrategie, vorzugsweise mindestens einmal jährlich, betrachtet werden. Das Testen der Service-Continuity-Pläne sollte im Einklang mit dem Geschäftsbetrieb und unter Berücksichtigung der Anforderungen des Business-Continuity-Plans erfolgen. Alle Pläne sollten auch nach jeder bedeutsamen geschäftlichen Veränderung getestet werden. Es ist wichtig, dass jede Änderung an IT-Technologie in die Service-Continuity-Pläne aufgenommen und getestet wird. Sicherung und Rücksicherung der IT Services sollten ebenfalls überwacht und getestet werden, damit deren Funktionsfähigkeit allzeit sichergestellt ist. |
| • | Change Management: Der Prozess Change Management sollte sicherstellen, dass alle Änderungen hinsichtlich ihrer Auswirkungen auf die Service-Continuity-Pläne geprüft, autorisiert und in der CMDB hinterlegt werden. |
Inputs:
Service-Continuity-Plan, Schadensbewertungsplan, Rettungsplan, Plan unternehmenswichtiger Daten, Krisenmanagement- und PR-Plan, Arbeitsplatz- und Serviceplan, Sicherheitsplan, Kommunikationsplan, Finanz- und Administrationsplan, Organisationsplan für den Notbetrieb
Service-Continuity-Plan, Schadensbewertungsplan, Rettungsplan, Plan unternehmenswichtiger Daten, Krisenmanagement- und PR-Plan, Arbeitsplatz- und Serviceplan, Sicherheitsplan, Kommunikationsplan, Finanz- und Administrationsplan, Organisationsplan für den Notbetrieb
Outputs:
Aktualisiertes Notfallhandbuch, geschulte Mitarbeiter
Aktualisiertes Notfallhandbuch, geschulte Mitarbeiter
4. Eventualfall bearbeiten
Bei Eintritt eines Eventualfalls wird dieser nach den festgelegten Prozeduren bearbeitet.
Inputs:
Incident-Datensatz mit Incident-Typ „Eventualfall”, Notfallhandbuch
Incident-Datensatz mit Incident-Typ „Eventualfall”, Notfallhandbuch
Outputs:
Wiederhergestellter Normalbetrieb, dokumentierter Eventualfall
Wiederhergestellter Normalbetrieb, dokumentierter Eventualfall
5. Prozesskontrolle Service Continuity Management
Aufgabe dieser Aktivität ist die Überwachung der Bearbeitung aller aufgetretenen Eventualfälle sowie der Prozessqualität im Allgemeinen. Ferner werden Managementberichte erstellt und ausgeliefert.
Inputs:
Eventualfälle, KPIs
Eventualfälle, KPIs
Output:
Managementbericht
Managementbericht
3.3.6 SD.6 Information Security Management
Prozessziele
Der Prozess, bei dem die Vertraulichkeit, Integrität und Verfügbarkeit der Vermögenswerte, Informationen, Daten und IT Services einer Organisation sichergestellt werden. Das Information Security Management ist in der Regel Teil eines organisatorischen Ansatzes für das Security Management, der über den Aufgabenbereich des IT-Service-Providers hinausgeht. Es enthält personelle, prozessorientierte, technische und physikalische Sicherheitsmaßnahmen für die gesamte Organisation.
Der Prozess, bei dem die Vertraulichkeit, Integrität und Verfügbarkeit der Vermögenswerte, Informationen, Daten und IT Services einer Organisation sichergestellt werden. Das Information Security Management ist in der Regel Teil eines organisatorischen Ansatzes für das Security Management, der über den Aufgabenbereich des IT-Service-Providers hinausgeht. Es enthält personelle, prozessorientierte, technische und physikalische Sicherheitsmaßnahmen für die gesamte Organisation.
| Prozessrollen | |
| • | Owner Information Security Management |
| • | Information Security Manager |
| • | Information Security Coordinator |
| • | IT Security Management Board |
| • | Information-Security-Forum |
Prozessphasen und Artefakte
Das Gesamtsystem zur Steuerung dieses Prozesses wird, entsprechend der Norm ISO/IEC 27000, als Information Security Management System (ISMS) bezeichnet.
Das Gesamtsystem zur Steuerung dieses Prozesses wird, entsprechend der Norm ISO/IEC 27000, als Information Security Management System (ISMS) bezeichnet.
1. ISMS einrichten
Erstellen der Richtlinien, Zielsetzungen, Prozesse und Prozeduren des ISMS, die zur Bearbeitung von Risiken und zur Verbesserung der Informationssicherheit erforderlich sind und deren Ergebnisse sich in Einklang mit den übergeordneten Unternehmensleitlinien und Zielsetzungen befinden.
Inputs:
Geschäftliche und regulatorische Anforderungen an das ISMS, Serviceportfolio, Kundenliste, SLAs, geschäftliche Auswirkungs- und Risikoanalyse
Geschäftliche und regulatorische Anforderungen an das ISMS, Serviceportfolio, Kundenliste, SLAs, geschäftliche Auswirkungs- und Risikoanalyse
Outputs:
Richtlinien, Sicherheitsstrategie, Prozesse und Prozeduren
Richtlinien, Sicherheitsstrategie, Prozesse und Prozeduren
2. ISMS implementieren und betreiben
Implementieren und Betreiben von Richtlinien, Steuereinrichtungen, Prozessen und Prozeduren des Information Security Management
Inputs:
Richtlinien, Sicherheitsstrategie, Prozesse und Prozeduren, Sicherheitsstörungen
Richtlinien, Sicherheitsstrategie, Prozesse und Prozeduren, Sicherheitsstörungen
Outputs:
Sicherheitshandbuch, Schutzbedarfsklassifizierung, in Betrieb genommene Prozesse und Prozeduren
Sicherheitshandbuch, Schutzbedarfsklassifizierung, in Betrieb genommene Prozesse und Prozeduren
3. ISMS überwachen und prüfen
Bewerten und, sofern anwendbar, Messen der Leistungsfähigkeit des Prozesses in Bezug auf die ISMS-Richtlinien, Zielsetzungen und praktischen Erfahrungen sowie Erstellen von Managementberichten zu Prüfzwecken.
Inputs:
Risikobericht, Auditrichtlinie, bestehende Auditberichte, Sicherheitsstörungen
Risikobericht, Auditrichtlinie, bestehende Auditberichte, Sicherheitsstörungen
Outputs:
Auditbericht, Katalog der Korrekturmaßnahmen
Auditbericht, Katalog der Korrekturmaßnahmen
4. ISMS pflegen und verbessern
Ergreifen korrektiver und präventiver Maßnahmen, basierend auf den Ergebnissen des internen ISMS-Audits, Revisionen oder anderen relevanten Informationen, mit dem Ziel, eine kontinuierliche Verbesserung des ISMS zu erreichen
Inputs:
Auditbericht, Katalog der Korrekturmaßnahmen
Auditbericht, Katalog der Korrekturmaßnahmen
Outputs:
Maßnahmenplan
Maßnahmenplan
5. ISMS-Prozesskontrolle
Durchführen von Überwachungs- und Steuerungsaufgaben für den Prozess als Gesamtheit.
Inputs:
Auditbericht, Umsetzungsfortschritt Maßnahmenplan, KPIs
Auditbericht, Umsetzungsfortschritt Maßnahmenplan, KPIs
Outputs:
Managementbericht
Managementbericht
3.3.7 SD.7 Budgeting and Accounting for Services
Prozessziele
„Budgeting and Accounting for Services” hat die Aufgabe, innerhalb der IT-Organisation die Kosten für das IT Service Management zu identifizieren, zu überwachen und diese an die IT-Kunden weiter zu berechnen. Der Prozess ist zudem verantwortlich für die Durchführung der Finanzmittelplanung.
„Budgeting and Accounting for Services” hat die Aufgabe, innerhalb der IT-Organisation die Kosten für das IT Service Management zu identifizieren, zu überwachen und diese an die IT-Kunden weiter zu berechnen. Der Prozess ist zudem verantwortlich für die Durchführung der Finanzmittelplanung.
Die Verantwortung für den Prozess liegt innerhalb der IT-Organisation, kann aber auch auf die zentrale Finanzabteilung des Unternehmens übertragen werden.
| Prozessrollen | |
| • | Owner „Budgeting and Accounting for Services" |
| • | Manager „Budgeting and Accounting for Services" |
| • | Mitarbeiter „Budgeting and Accounting for Services" |
1. Finanzmittelplanung (Budgetierung)
Die Finanzplanung ermittelt den kurz- und mittelfristigen Finanzmittelbedarf der IT-Organisation. In den Genehmigungsverfahren für die Finanzpläne wird das jährliche Finanzbudget verhandelt und vereinbart.
Die Finanzplanung besteht aus unterschiedlichen Teilplänen, deren Erstellung im Aufgabenbereich des Prozesses liegt (z. B. Marketing- und Verkaufsfinanzplan, Produktionsfinanzplan, Investitionsfinanzplan).
| • | Nach Bereitstellung der Finanzmittel für die nächste Wirtschaftsperiode beginnen die Überwachung der Finanzmittelausgaben und die Durchführung von Überprüfungen gegen das vorhandene Budget. Es muss sichergestellt werden, dass die Finanzmittel für den ursprünglich geplanten Verwendungszweck eingesetzt werden. Dazu müssen die laufenden Betriebsausgaben überwacht werden. Das Gleiche gilt auch für Projekte. Dazu muss sichergestellt werden, dass die ursprünglich geplanten Projektkosten eingehalten werden. |
Inputs:
Finanzpläne, Kostenstellenplan, Projektübersicht
Finanzpläne, Kostenstellenplan, Projektübersicht
Outputs:
Budget- und Ausgabenfortschreibung
Budget- und Ausgabenfortschreibung
2. IT-Kostenrechnung (IT Accounting)
Aufgaben
Aufbau eines IT-Kostenrechnungssystems. Dieses sollte folgende Aufgaben erfüllen:
Aufbau eines IT-Kostenrechnungssystems. Dieses sollte folgende Aufgaben erfüllen:
| • | Abgleich der Ist-Kosten gegen das Budget |
| • | Entwickeln und Führen einer durchgängigen Investitionsstrategie, die die Optionen und Möglichkeiten der aktuellen IT-Technologien berücksichtigt. Dazu ist eine enge Kooperation mit den technischen Know-how-Trägern innerhalb der IT-Organisation notwendig |
| • | Bereitstellen eines Kostenrahmens für den IT-Betrieb und die IT-Leistungserbringung |
| • | Liefern von Beiträgen, die eine Bewertung und Priorisierung der Ressourcennutzung unterstützen |
| • | Erstellen von Individualkalkulationen (Preisfindung, Projektkalkulationen, Kosten-Nutzen-Analysen, ROI-Berechnungen etc.) unter Berücksichtigung aller finanziellen Abhängigkeiten und der bestehenden Risiken |
| • | Unterstützen der Einführung einer Leistungsverrechnung, indem die erforderliche Kalkulationsbasis bereitgestellt wird |
Zur Berechnung der Servicekosten muss ein Kostenrahmen mit allen relevanten Kosten gebildet werden. Dazu müssen die Kosten kategorisiert und klassifiziert werden. Es werden Kostenmodelle entwickelt, anhand deren die Kosten auf unterschiedliche Berechnungsziele (z. B. auf Kundengruppen oder Services) umgelegt werden.
Inputs:
Kostenartenplan, Kostenstellenplan
Kostenartenplan, Kostenstellenplan
Outputs:
Kostenträger, Kostenmodelle
Kostenträger, Kostenmodelle
3. Service-Leistungsverrechnung
Die Service-Leistungsverrechnung ermittelt die Verkaufspreise für Services. Über die Leistungsverrechnung müssen mindestens alle entstandenen Kosten gedeckt werden. In der Leistungsverrechnung werden also nicht nur die entstandenen Kosten (und ggf. ein Gewinnzuschlag) betrachtet, sondern auch die Mengengerüste für die definierten Leistungseinheiten.
Ziele
Die Service-Leistungsverrechnung hat folgende Ziele:
Die Service-Leistungsverrechnung hat folgende Ziele:
| • | Es wird ein Abrechnungssystem entwickelt, das die unternehmensstrategischen Vorgaben berücksichtigt. |
| • | Es wird ein Verfahren eingeführt, mit dem die entstandenen Kosten für die IT-Leistungserbringung an die IT-Kunden weiterberechnet werden können. |
| • | Es erfolgt eine Beeinflussung des Kunden- und Anwenderverhaltens durch Schaffung eines Kostenbewusstseins. Dabei ist es ausreichend, wenn im Rahmen einer internen Leistungsverrechnung Kostenstellen belastet werden können, ohne dass tatsächlich Geldflüsse ausgelöst werden. |
| • | Durch die Weiterverrechnung der Kosten haben die Kunden ein Interesse an dem Umfang und der Qualität der Leistungserbringung. Dies fördert die Bestrebungen des Service Level Managements, die Serviceprofile für die Kunden differenziert und passgenau zu gestalten. Damit gelingt es, ein optimales Preis-Leistungs-Verhältnis für die auszuliefernden Services herzustellen. |
| • | Verbesserungen an Services, die zu höheren Servicekosten führen, werden nur durchgeführt, wenn es aufseiten der IT-Kunden eine entsprechende Nachfrage gibt oder, anders ausgedrückt, wenn es für diese Verbesserungen eine konkrete geschäftliche Notwendigkeit gibt. |
Inputs:
Serviceportfolio, Kostenmodelle, Kundenstruktur, Mengengerüste
Serviceportfolio, Kostenmodelle, Kundenstruktur, Mengengerüste
Outputs:
Leistungsverrechnungssystem
Leistungsverrechnungssystem
4. Prozesskontrolle
Aufgaben dieser Aktivität sind die Überwachung der Prozessqualität sowie die Erstellung und Auslieferung von Managementberichten.
Inputs:
KPIs
KPIs
Outputs:
Managementbericht
Managementbericht
3.4.1 REL.1 Business Relationship Management
Prozessziele
Identifizieren der von Kunden geforderten Serviceergebnisse und Koordinieren der Kundeninteressen über alle Lebenszyklusphasen hinweg.
Identifizieren der von Kunden geforderten Serviceergebnisse und Koordinieren der Kundeninteressen über alle Lebenszyklusphasen hinweg.
| Prozessrollen | |
| • | Owner des Business Relationship Management |
| • | Business Relationship Manager |
1. Definieren der Kommunikationsstrategie
| • | Vision und Teamgrundsätze formulieren |
| • | Managementunterstützung sicherstellen |
| • | Kommunikationsplan definieren |
| • | Strukturelemente definieren |
Strukturelemente sind Kommunikationsmittel, die die Zusammenarbeit erleichtern. Dazu gehören
| • | Arbeitsgruppen (z. B. integriertes CAB, „One and One”-Meeting) |
| • | Prozessforen, deren Mitglieder proaktiv an der Entwicklung, Innovation und Verbesserung spezifischer Prozesse arbeiten (z. B. ISM-Forum) |
| • | Ausschüsse als Instanzen, die formale Entscheidungen treffen |
Inputs:
Servicestrategie, Organisationsstruktur, Zielgruppen
Servicestrategie, Organisationsstruktur, Zielgruppen
Outputs:
Kommunikationsplan, Kommunikationsmittel, Strukturelemente
Kommunikationsplan, Kommunikationsmittel, Strukturelemente
2. Steuerung der Interessenvertreter
Die Aufgaben umfassen:
| • | Abweichungsanalysen durchführen |
| • | Arbeitsgruppen und Arbeitspakete definieren |
| • | Planung der Zielerreichung |
| • | Kunden-Feedback einholen |
| • | Reviews durchführen und Review-Berichte erstellen |
Inputs:
Kommunikationsplan, Kommunikationsmittel, Strukturelemente
Kommunikationsplan, Kommunikationsmittel, Strukturelemente
Outputs:
Feedback-Ergebnisse, Review-Berichte
Feedback-Ergebnisse, Review-Berichte
3. Prozesskontrolle
Aufgaben dieser Aktivität sind die Überwachung der Prozessqualität sowie die Erstellung und Auslieferung von Managementberichten.
Inputs:
KPIs
KPIs
Outputs:
Managementbericht
Managementbericht
3.4.2 REL.2 Supplier Management
Prozessziele:
Folgende Zielsetzungen sollen erreicht werden:
Folgende Zielsetzungen sollen erreicht werden:
| • | Optimale Wertschöpfung hinsichtlich der Serviceerbringung durch das Zusammenspiel aller internen und externen IT-Leistungserbringer |
| • | Abstimmung mit dem Service Level Management und Vertragsmanagement hinsichtlich der Gestaltung der erforderlichen Leistungsprofile der Leistungserbringer und Steuerung der Interaktionen zwischen den Leistungserbringern |
| • | Steuerung der Providerverträge hinsichtlich Vertragsabschluss, Vertragsergänzung, Vertragsauflösung als Unterstützung für das Vertragsmanagement |
| Prozessrollen | |
| • | Owner Supplier Management |
| • | Supplier Manager |
| • | Lieferanten-Koordinator |
1. Planung Supplier Management
Führen einer Liefer- und Lieferantenstrategie sowie Definition von Richtlinien zur Steuerung der Lieferantenintegration.
Auswahl der internen und externen Leistungserbringer und inhaltliche Ausprägung der Lieferantenverträge.
Initiierung von Vertragsauflösungen und/oder Abschluss neuer Lieferantenverträge bei einer kontinuierlichen Verfehlung von SLAs, bei der geplanten Veränderung bestehender Leistungsprofile oder bei der Einführung neuer Services.
Inputs:
IT-Strategie, Servicekatalog, SLAs, Spezifikation zur Änderung von Leistungsprofilen, geplante neue Services
IT-Strategie, Servicekatalog, SLAs, Spezifikation zur Änderung von Leistungsprofilen, geplante neue Services
Outputs:
Liefer- und Lieferantenstrategie, Lieferantenrichtlinie, Lieferantenverträge, Lieferantenvertragsdatenbank
Liefer- und Lieferantenstrategie, Lieferantenrichtlinie, Lieferantenverträge, Lieferantenvertragsdatenbank
2. Steuerung von Lieferanten und Kontrakten
Steuerung der Zusammenarbeit zwischen Lieferanten, der integrierten Auslieferung der vereinbarten Servicebestandteile sowie der Integration der Prozesse des Auftraggebers mit den Prozessen der Lieferanten.
Inputs:
Leistungsberichte der Lieferanten, Störungen, Anforderung geänderter Leistungsprofile
Leistungsberichte der Lieferanten, Störungen, Anforderung geänderter Leistungsprofile
Outputs:
SLA-Erfüllung, Einhaltung der vertraglich vereinbarten Lieferantenleistung, Spezifikation zur Änderung von Leistungsprofilen
SLA-Erfüllung, Einhaltung der vertraglich vereinbarten Lieferantenleistung, Spezifikation zur Änderung von Leistungsprofilen
3. Bewerten der Service-Leistungsprofile
Auswerten der mit den internen und externen Leistungserbringern vereinbarten Operational Levels. Die Auswertungen erfolgen in regelmäßigen Zeitabständen oder kontinuierlich; Erstellung von Leistungsberichten.
Inputs:
Servicekatalog, SLAs, Leistungsmessungen der Lieferanten
Servicekatalog, SLAs, Leistungsmessungen der Lieferanten
Output:
Leistungsbericht
Leistungsbericht
4. Prozesskontrolle
Aufgaben dieser Aktivität sind die Überwachung der Prozessqualität sowie die Erstellung und Auslieferung von Managementberichten.
Inputs:
KPIs
KPIs
Outputs:
Managementbericht
Managementbericht
3.5.1 RES.1 Incident Management und Service Request Management
Prozessziele
Das Incident Management minimiert die Auswirkungen von Servicestörungen auf Geschäftsprozesse durch die Wiederherstellung beeinträchtigter IT Services innerhalb des vereinbarten Zeitraums und in definierter Qualität.
Das Incident Management minimiert die Auswirkungen von Servicestörungen auf Geschäftsprozesse durch die Wiederherstellung beeinträchtigter IT Services innerhalb des vereinbarten Zeitraums und in definierter Qualität.
Es trägt zu einer hohen Anwenderzufriedenheit bei, weil es diese in allen Belangen der IT-Serviceerbringung unterstützt.
| Prozessrollen | |
| • | Owner Incident Management |
| • | Incident Manager |
| • | Service-Desk-Koordinator |
| • | First Level Supporter |
| • | Second Level Suppoter |
| • | Third Party Supporter |
1. Erkennen und Erfassen
Die wichtigsten Aktivitäten sind:
| • | Annehmen der Anwenderanliegen |
| • | Erfassen der Grunddaten einer Störung oder Serviceanforderung |
| • | falls erforderlich, Einbeziehen des Second-Level-Supports |
| • | Zuordnung eines Bearbeiters |
Inputs:
Störungsdetails oder Serviceanforderungen, Kontaktdaten des Melders
Störungsdetails oder Serviceanforderungen, Kontaktdaten des Melders
Outputs:
Dokumentierte Störung oder Serviceanforderung, Incident-ID
Dokumentierte Störung oder Serviceanforderung, Incident-ID
2. Klassifizieren und erste Unterstützung
Aktivitäten:
| • | Klassifizierung der Störung oder Serviceanforderung |
| • | Abgleichen mit bekannten Fehlern und Problemen |
| • | Auswerten der zugehörigen Konfigurationsdetails |
| • | Erste Unterstützung leisten (Störungsdetails auswerten, schnelle Lösung finden) |
| • | Ggf. weiterleiten der Störung oder Serviceanforderung an eine nachgelagerte Unterstützungsinstanz |
Inputs:
Dokumentierte Störung oder Serviceanforderung, Ticket-ID
Dokumentierte Störung oder Serviceanforderung, Ticket-ID
Outputs:
Änderungsantrag zur Störungsauflösung, aktualisierte Störungsdetails, Umgehungslösung, nachgelagerte Bearbeitungsgruppe
Änderungsantrag zur Störungsauflösung, aktualisierte Störungsdetails, Umgehungslösung, nachgelagerte Bearbeitungsgruppe
3. Untersuchung und Diagnose
Die wichtigsten Aktivitäten sind:
| • | Bearbeiten der Störung oder Serviceanforderung |
| • | Sammeln und analysieren zugehöriger Informationen |
| • | Finden einer Störungslösung oder |
| • | weiterleiten an den Third Party Support |
Input:
Aktualisierte Dokumentation der Störung oder Serviceanforderung
Aktualisierte Dokumentation der Störung oder Serviceanforderung
Outputs:
Aktualisierte Dokumentation der Störung oder Serviceanforderung, Umgehungslösung
Aktualisierte Dokumentation der Störung oder Serviceanforderung, Umgehungslösung
4. Lösung und Wiederherstellung
Die wichtigsten Aktivitäten sind:
| • | Auflösen der Störung anhand der gefundenen Lösung oder des Workarounds |
| • | Durchführen der Wiederherstellungsmaßnahmen |
| • | Erfüllen der Serviceanforderungen |
Inputs:
Aktualisierte Dokumentation der Störung, Lösung oder Workaround
Aktualisierte Dokumentation der Störung, Lösung oder Workaround
Outputs:
Wiederhergestellter Service, umgesetzte Serviceanforderung
Wiederhergestellter Service, umgesetzte Serviceanforderung
5. Dokumentieren und Schließen
Die wichtigsten Aktivitäten sind:
| • | Lösungsbestätigung vom Anwender oder Melder der Störung bzw. Serviceanforderung |
| • | Dokumentieren der Ursachenkategorie |
| • | Dokumentieren der Abschlusskategorie |
Inputs:
Wiederhergestellter Service, umgesetzte Serviceanforderung
Wiederhergestellter Service, umgesetzte Serviceanforderung
Outputs:
Aktualisierte Dokumentation der Störung oder Serviceanforderung, dokumentierte Wiederherstellungsmaßnahmen, gesetzter Abschlussstatus
Aktualisierte Dokumentation der Störung oder Serviceanforderung, dokumentierte Wiederherstellungsmaßnahmen, gesetzter Abschlussstatus
6. Prozesskontrolle
Aufgaben dieser Aktivität sind die Überwachung der Prozessqualität sowie die Erstellung und Auslieferung von Managementberichten.
Inputs:
KPIs
KPIs
Outputs:
Managementbericht
Managementbericht
3.5.2 RES.2 Problem Management
Prozessziele
Ziel des Problem Managements ist die Minimierung negativer Auswirkungen von Incidents und Problemen, die aus Fehlern der IT-Infrastruktur resultieren, auf den Geschäftsbetrieb. Des Weiteren soll das Wiederauftreten von Incidents aufgrund dieser Fehlersituation vermieden werden. Zur Erreichung dieser Zielsetzung arbeitet das Problem Management an der Ermittlung der eigentlichen Ursachen von Incidents und initiiert anschließend Maßnahmen zur Verbesserung oder Korrektur der bestehenden Situation.
Ziel des Problem Managements ist die Minimierung negativer Auswirkungen von Incidents und Problemen, die aus Fehlern der IT-Infrastruktur resultieren, auf den Geschäftsbetrieb. Des Weiteren soll das Wiederauftreten von Incidents aufgrund dieser Fehlersituation vermieden werden. Zur Erreichung dieser Zielsetzung arbeitet das Problem Management an der Ermittlung der eigentlichen Ursachen von Incidents und initiiert anschließend Maßnahmen zur Verbesserung oder Korrektur der bestehenden Situation.
| Prozessrollen | |
| • | Owner Problem Management |
| • | Problem Manager |
| • | Mitarbeiter Problem Management |
1. Problem identifizieren und erfassen
Die Behandlung aufgetretener Incidents als Problem findet in folgenden Situationen statt:
| • | wenn die Analyse der Störungsdaten auf wiederkehrende Störungen oder auf Störungen mit starken Auswirkungen auf den Geschäftsbetrieb hinweist und noch keine Problembearbeitung stattgefunden hat, |
| • | wenn die Analyse der IT-Infrastruktur auf ein Problem hinweist, das potenziell zu Störungen führen kann. |
Zu beachten ist, dass manche Probleme von Mitarbeitern außerhalb des Problem Managements identifiziert werden, z. B. durch das Incident Management oder das Capacity Management. Ungeachtet dessen sollten alle Probleme an den Problem-Management-Prozess gemeldet und von diesem dokumentiert werden.
Problemdatensätze werden unabhängig von Störungsdatensätzen erfasst, sollten aber grundsätzlich mit allen zugehörigen Störungsdatensätzen verknüpft werden.
Inputs:
Dokumentierte Störungen
Dokumentierte Störungen
Output:
Dokumentiertes und mit den betroffenen Störungen verknüpftes Problem
Dokumentiertes und mit den betroffenen Störungen verknüpftes Problem
2. Problem klassifizieren
Für jedes Problem muss der Aufwand ermittelt werden, der für die Beseitigung der Störungsursache erforderlich ist. Der Bearbeitungsaufwand sollte nicht größer sein als der durch die Störungsvermeidung entstehende Nutzen. Deshalb muss der Einfluss des Problems auf bestehende Services bestimmt werden. Dieser Prozess wird als „Klassifizierung” bezeichnet.
Schritte
Die Schritte bei der Problemklassifizierung gleichen denen der Störungsklassifizierung und dienen zur Ermittlung von:
Die Schritte bei der Problemklassifizierung gleichen denen der Störungsklassifizierung und dienen zur Ermittlung von:
| • | Kategorie |
| • | Auswirkung |
| • | Dringlichkeit |
| • | Priorität |
Input:
Dokumentiertes und mit den betroffenen Störungen verknüpftes Problem
Dokumentiertes und mit den betroffenen Störungen verknüpftes Problem
Output:
Klassifiziertes Problem
Klassifiziertes Problem
3. Problem untersuchen und diagnostizieren
Der Prozess der Problemuntersuchung gleicht dem der Incidentuntersuchung. Hinsichtlich ihres vorrangigen Ziels unterscheiden sich beide Prozesse jedoch wesentlich. Ziel des lncident Managements ist die schnelle Wiederherstellung des Service, wogegen das Problem Management auf eine verlässliche Diagnose der Störungsursache abzielt.
Inputs:
Dokumentiertes und mit den betroffenen Störungen verknüpftes Problem, klassifiziertes Problem
Dokumentiertes und mit den betroffenen Störungen verknüpftes Problem, klassifiziertes Problem
Output:
Bekannte Ursache aufgetretener Störungen
Bekannte Ursache aufgetretener Störungen
4. Bekannten Fehler dokumentieren
Der Status „Bekannter Fehler” wird dem Problemdatensatz zugewiesen, sobald die zugrunde liegende Ursache eines Problems gefunden und ein Workaround ermittelt ist.
Known Error Database
Der „Bekannte Fehler” wird zusammen mit einer vom Incident Management anwendbaren Umgehungslösung in der Known Error Database gespeichert.
Der „Bekannte Fehler” wird zusammen mit einer vom Incident Management anwendbaren Umgehungslösung in der Known Error Database gespeichert.
Wird ein neues Release ausgerollt, so liegen im Entwicklungsbereich möglicherweise bereits Informationen über „Bekannte Fehler” vor. Diese müssen dem Problem Management gemeldet werden, damit sie in die Known Error Database eingetragen und damit dem Incident Management bekannt gemacht werden können.
Inputs:
Dokumentiertes und mit den betroffenen Störungen verknüpftes Problem, klassifiziertes Problem, bekannte Ursache aufgetretener Störungen
Dokumentiertes und mit den betroffenen Störungen verknüpftes Problem, klassifiziertes Problem, bekannte Ursache aufgetretener Störungen
Outputs:
„Bekannter Fehler”, Eintrag in die Known Error Database
„Bekannter Fehler”, Eintrag in die Known Error Database
5. Lösung erarbeiten und Änderungsantrag stellen
Die Mitarbeiter des Problem Managements erarbeiten ein Lösungskonzept mit den Maßnahmen zur Beseitigung des Fehlers. Sofern erforderlich, stellen sie anschließend einen Änderungsantrag.
Nach der Freigabe der Änderung wird die Lösung unter der Steuerung des Change Managements umgesetzt und ausgerollt.
Input:
Known Error Database mit dokumentiertem „Bekanntem Fehler”
Known Error Database mit dokumentiertem „Bekanntem Fehler”
Outputs:
Lösungskonzept, Änderungsantrag, aktualisierter Problemdatensatz
Lösungskonzept, Änderungsantrag, aktualisierter Problemdatensatz
6. Bearbeitung abschließen
Nachdem die Lösung des Problems ausgerollt worden ist und sich in produktivem Einsatz befindet, erfolgt ein Post Implementation Review. Dabei wird geprüft, ob die Störungen noch auftreten. Falls dies nicht der Fall ist, kann der entsprechende Eintrag in der Known Error Database deaktiviert werden, da er zukünftig nicht mehr benötigt wird.
Nach Abschluss des Post Implementation Reviews wird die Problembearbeitung geschlossen.
Inputs:
Lösungskonzept, Änderungsantrag, implementierte Lösung
Lösungskonzept, Änderungsantrag, implementierte Lösung
Outputs:
Dokumentiertes Review, abgeschlossener Problemdatensatz
Dokumentiertes Review, abgeschlossener Problemdatensatz
7. Prozesskontrolle
Aufgaben dieser Aktivität sind die Überwachung der Prozessqualität sowie die Erstellung und Auslieferung von Managementberichten.
Inputs:
KPIs
KPIs
Outputs:
Managementbericht
Managementbericht
Quellen
1
ISO/IEC TS 33060:2020 – Informationstechnik – Prozessbewertung – Prozessbewertungsmodell für Systemlebenszyklus-Prozesse (Englischer Titel: Information technology – Process assessment – Process assessment model for system life cycle processes)
2
ISO/IEC 33003:2015 – Informationstechnik – Prozessbewertung – Anforderungen an ein Rahmenwerk zur Prozessmessung (Englischer Titel: Information technology – Process assessment – Requirements for process measurement frameworks)
3
ISO/IEC/IEEE 15288:2015 – System- und Software-Engineering – System-Lebenszyklus-Prozesse (Englischer Titel: Systems and software engineering –System life cycle processes)
4
ISO/IEC 20000-1:2018 – Informationstechnik – Servicemanagement – Teil 1: Anforderungen an Servicemanagementsysteme (Englischer Titel: Information technology – Service management – Part 1: Service management system requirements)
5
ISO/IEC 33020:2019 – Informationstechnik – Prozessbewertung – Prozessmessrahmen zur Bewertung der Prozessfähigkeit (Englischer Titel: Information technology – Process assessment – Process measurement framework for assessment of process capability)
