Elektronische Gesundheitskarte und Telematikinfrastruktur
Übergreifende Richtlinien zum Betrieb der TI
Version |
|
Revision |
548770 |
Stand |
|
Status |
freigegeben |
Klassifizierung |
öffentlich |
Referenzierung |
gemRL_Betr_TI |
Dokumentinformationen
Änderungen zur Vorversion
ÄnderungenAnpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion beruhen auf P 15.2können Sie der nachfolgenden Tabelle entnehmen.
Dokumentenhistorie
Version |
Stand |
Kap./ Seite |
Grund der Änderung, besondere Hinweise |
|
|||||
|
|
|
|
|
|||||
|
|
|
|
|
|||||
|
|
|
|
|
|||||
|
|
|
|
|
|||||
|
|
|
|
|
|||||
|
|
|
|
|
|||||
|
|
|
|
|
|||||
|
|
|
|
|
|||||
|
|
|
|
|
|||||
|
|
|
|
gematik |
|||||
|
|
|
|
gematik |
|||||
2.1. |
|
|
|
gematik |
|||||
|
|
|
|
|
|||||
|
|
|
|
|
|||||
|
|
|
freigegeben |
gematik |
|||||
|
|
|
|
|
|||||
Inhaltsverzeichnis
DokumentinformationenDokumentinformationen
InhaltsverzeichnisInhaltsverzeichnis
1 Einordnung des DokumentsDokumentes
1.4 AbgrenzungAbgrenzungen des Dokuments
2 Prozessübergreifende Regelungen
2.1 Organisationen in § 274 Abs. 1 SGB V in der Rolle eines AnbietersZentrales TI-ITSM-System
2.2 Prozessübergreifende Begriffserläuterungen2.1.1 Übergreifendes ITSM der TI
2.2.1 Information, Eskalation, Report2.1.2 Kommunikation
2.2.2 Teilnehmer-ID (TID)2.1.2.1 Kommunikation außerhalb des TI-ITSM-Systems
2.2.3 Prozessübergreifende Kommunikation2.1.3 TI-ITSM-Reporting
2.2.4 Betriebshandbuch-Auszug2.2 ITSM der TI-ITSM-Teilnehmer
2.3 Reporting2.2.1 Auszüge aus dem Betriebshandbuch der TI-ITSM-Teilnehmer
2.3.1 Konsolidiertes Reporting2.3 Auditierung von TI-ITSM-Teilnehmern
2.3.2 Ad-hoc Reporting2.4 Zentrale Koordinierung durch den Gesamtverantwortlichen TI
2.3.3 Service Level Requirements (SLR)2.4.1 Eskalationen im übergreifenden TI-ITSM
2.4 Auditierung von ITSM-TI-Teilnehmern2.4.2 Taskforce als Instrument der Deeskalation im übergreifenden TI-ITSM
2.5 Konvention zur Übermittlung von Prozessdaten3 Incident Management
2.5.1 Basisfeldtypen von Prozessdaten3.1 Begriffsbestimmungen
3 Service Level Management (SLM)3.1.1 Übergreifender Incident
3.1 Betrachtungsgegenstand des übergreifenden SLM3.2 Prozessdurchführung Incident Management
3.2 Begriffserläuterungen3.2.1 Übergreifenden Incident erfassen und qualifizieren
3.2.1 Service Level Requirements3.2.1.1 Übergreifenden Incident erfassen
3.3 Grundsätze des übergreifenden SLM3.2.1.2 Übergreifenden Incident qualifizieren
3.3.1 Gliederung des SLM in Service Level Cluster3.2.1.3 Serviceverantwortung für übergreifenden Incident zuweisen
3.4 Prozessdurchführung übergreifendes SLM3.2.2 Serviceverantwortung für übergreifenden Incident prüfen
3.4.1 Messung der Service Level3.2.3 Lösung für übergreifenden Incident erstellen
3.4.2 Bereitstellung des Service Level Reports3.2.4 Unterstützung für einen übergreifenden Incident einfordern
3.4.3 Service Review3.2.5 Lösung für einen übergreifenden Incident prüfen
4 Performance Management (PERF)3.2.6 Übergreifenden Incident schließen
4.1 Betrachtungsgegenstand des übergreifenden PERF3.3 Abweichungen im Prozessablauf
4.2 Begriffserläuterungen3.3.1 Übergreifenden Incident eskalieren
4.2.1 Performance3.3.2 Mitwirkung in einer Taskforce
4.3 Prozessdurchführung des übergreifenden PERF3.4 Verfahren für die Lösung eines Security-Incidents
4.3.1 Messung der Performance3.5 Verfahren für die Lösung eines Incidents mit Datenschutzrelevanz
4.3.2 Bereitstellung des Performance Reports3.6 Verfahren für die Lösung von Notfall-Incidents
4.3.3 Bereitstellung von Ad-hoc Performance Reports3.7 Service Level Requirements
4.3.4 Service Level Requirements (SLR)4 Problem Management
5 Change & Release Management (CHG & RLM)4.1 Begriffsbestimmungen
5.1 Betrachtungsgegenstand des übergreifenden CHG & RLM4.1.1 Übergreifendes Problem
5.2 Begriffserläuterungen4.2 Prozessdurchführung Problem Management
5.3 Prozessdurchführung übergreifendes RLM4.2.1 Übergreifendes Problem erfassen und qualifizieren
5.4 Prozessdurchführung übergreifendes CHG4.2.1.1 Übergreifendes Problem erfassen
5.4.1 Eigeninitiierten Produktänderungsbedarf feststellen4.2.1.2 Übergreifendes Problem qualifizieren
5.4.2 Vorprüfung durchführen4.2.1.3 Serviceverantwortung für übergreifendes Problem zuweisen
5.4.3 lokalen Produkt-Change durchführen & abschließen4.2.2 Serviceverantwortung für übergreifendes Problem prüfen
5.4.4 Eigeninitiierten Produkt-RfC aufzeichnen4.2.3 Lösung für übergreifendes Problem erstellen
5.4.5 Produkt-RfC registrieren4.2.3.1 Problem Ursachenanalyse durchführen
5.4.6 Produkt-RfC bewerten & autorisieren4.2.3.2 Lösung für übergreifendes Problem entwickeln und implementieren
5.4.7 Produkt-Change umsetzen4.2.3.3 Stornierung oder Abbruch der Bearbeitung eines Problem-Tickets
5.4.8 Produkt-Change abschließen4.2.4 Lösungsunterstützung für übergreifendes Problem
5.4.9 Produkt-Change: Phasen und Statusübergänge4.2.5 Lösung für übergreifendes Problem prüfen
5.4.10 Produkt-Change: Behandlung von Standard Changes4.2.6 Übergreifendes Problem schließen
5.4.11 Produkt-Change: Durchführung von Emergency Changes4.3 Abweichungen im Prozessablauf
5.5 Service Level Requirements (SLR)4.3.1 Übergreifendes Problem eskalieren
5.6 Informationspflichten4.3.2 Mitwirkung in einer Taskforce
5.7 Dokumentation4.4 Service Level Requirements
5.8 Eskalationen5 Request Fulfillment
5.9 Prozessreporting (Vorgangsdaten) CHG5.1 Begriffsbestimmungen
6 Configuration Management (CM)5.1.1 Service Request
6.1 Betrachtungsgegenstand des übergreifenden CM5.1.2 Beschwerdemanagement
6.2 Begriffserläuterungen5.2 Prozessdurchführung Request Fulfillment
6.2.1 Konfigurationselement (Configuration Item, CI)5.2.1 Service Request erfassen
6.2.2 Konfiguration5.2.2 Service Request prüfen
6.2.3 TI-Konfigurationsdatenbank5.2.3 Service Request erfüllen
6.2.4 Konfigurationsdaten5.2.4 Service Request verifizieren und schließen
6.3 Prozessdurchführung zur Bereitstellung von Konfigurationsdaten6 Configuration Management
6.3.1 Prozessreporting (Konfigurationsdaten) CM6.1 Begriffsbestimmungen
6.3.2 SPED Report6.1.1 Konfigurationselement (Configuration Item, CI)
6.3.3 Bereitstellung Ad-hoc Report6.1.2 TI-Konfigurationsdatenbank
6.4 Obliegenheiten SBV/GTI6.1.3 TI-Stammdaten
7 Knowledge Management (KM)6.1.4 TI-Konfigurationsdaten
7.1 Betrachtungsgegenstand des KM6.1.5 Lokale Konfigurationsdaten
7.2 Begriffserläuterungen6.2 Prozessdurchführung Configuration Management
7.2.1 Wissensdatenbank (WDB)6.2.1 Schema der TI-Konfigurationsdatenbank pflegen
7.3 Prozessdurchführung Bereitstellung der Produktinformation6.2.2 Konfigurationsdaten pflegen
7.3.1 Bereitstellung der Produktinformation6.2.2.1 Übermittlung von Konfigurationsdaten nach lokal autorisierten Produkt-Changes
7.4 Obliegenheiten SBV/GTI7 Change & Release Management
8 Incident Management (INC)7.1 Begriffsbestimmungen
8.1 Betrachtungsgegenstand des übergreifenden INC7.1.1 Request for Change (RfC)
8.2 Begriffserläuterungen7.1.2 Produkt-Change
8.2.1 Lokaler Incident7.1.2.1 Master-Change
8.2.2 Übergreifender Incident7.1.2.2 Sub-Change
8.2.3 Anwendersupport7.1.3 Produkttyp-Change
8.2.4 ITSM-TI-Teilnehmersupport7.1.4 Emergency-Change
8.2.5 Supportverantwortung7.1.5 Betriebliches Change-Bewertungsgremium (BCB)
8.2.6 Lösungsverantwortung7.1.6 Change Advisory Board (CAB)
8.3 Grundsätze des übergreifenden INC7.1.7 Emergency Change Advisory Board (eCAB)
8.3.1 Zentrale INC-Koordinierung durch den GTI7.1.8 Post Implementation Review (PIR)
8.3.2 Übergabe der Lösungsverantwortung7.1.9 Change- & Release-Kalender
8.3.3 Incident-Melder7.2 Prozessdurchführung Change & Release Management
8.3.4 Incident-Bearbeiter7.2.1 Produkt-Change: Request for Change (RfC) erstellen
8.3.5 Betroffener Anwender7.2.2 Produkt-Change: RfC bewerten
8.4 Prozessdurchführung Anwendersupport INC7.2.3 Produkt-Change: RfC genehmigen
8.4.1 Incident-Erstmeldung im Anwendersupport7.2.4 Produkt-Change umsetzen
8.4.2 Vorprüfung im Anwendersupport7.2.5 Produkt-Change: Umsetzung verifizieren
8.4.3 Ablehnung im Anwendersupport7.2.6 Produkt-Change abschließen
8.4.4 Lösung und Schließung im lokalen Incident Management7.3 Abweichungen im Prozessablauf
8.4.5 Interne Erfassung, Kategorisierung & Priorisierung übergreifender Incidents7.4 Verfahren für einen Standard-Change
8.4.6 Strukturierte Informationsübermittlung übergreifender Incidents7.5 Verfahren für einen Emergency-Change
8.4.7 Schließung übergreifender Incidents7.6 Service Level Requirements
8.4.8 Service Level Requirements (SLR)8 Knowledge Management
8.5 Prozessdurchführung ITSM-TI-Teilnehmersupport INC8.1 Begriffsbestimmungen
8.5.1 Feststellung, Lösung und Schließung im lokalen INC8.1.1 Wissensdatenbank (WDB) des TI-ITSM-Systems
8.5.2 Qualifizierte Incident-Erstmeldung im ITSM-TI-Teilnehmersupport8.2 Prozessdurchführung Knowledge Management
8.5.3 Vorprüfung im ITSM-TI-Teilnehmersupport8.2.1 Wissen identifizieren und übermitteln
8.5.4 Ablehnung im ITSM-TI-Teilnehmersupport9 Service Level Management
8.5.5 Lösung übergreifender Incidents9.1 Begriffsbestimmungen
8.5.6 Schließung übergreifender Incidents9.1.1 Service Level
8.5.7 interne Dokumentation übergreifender Incidents9.1.2 Service Level Report
8.5.8 strukturierte Informationsübermittlung übergreifender Incidents9.2 Prozessdurchführung Service Level Management
8.5.9 Service Level Requirements (SLR)9.2.1 Messung der Service Level
8.6 Informationspflichten9.2.2 Bereitstellung des Service Level Reports
8.7 Dokumentation9.2.3 Teilnahme am Service Review
8.8 Eskalationen10 Performance Management
8.9 Prozessreporting (Vorgangsdaten) INC10.1 Begriffsbestimmungen
8.10 Obliegenheiten SBV/GTI10.1.1 Performance
9 Problem Management (PRO)10.2 Prozessdurchführung Performance Management
9.1 Betrachtungsgegenstand des übergreifenden PRO10.2.1 Performance messen
9.2 Begriffserläuterungen10.2.2 Performance reporten
9.2.1 Problem10.2.3 Performance bewerten, planen und steuern
9.2.2 Lokales Problem10.2.4 Service Monitoring (finale Lösung)
9.2.3 Übergreifendes Problem11 Servicekatalog Management
9.2.4 Problemerkennender11.1 Begriffsbestimmungen
9.2.5 Problemlösungsverantwortlicher11.1.1 Servicekatalog
9.2.6 Lösungsunterstützender11.1.2 Serviceverzeichnis
9.3 Grundsätze des übergreifenden Problem Managements11.2 Prozessdurchführung Servicekatalog Management
9.3.1 Zentrale PRO Koordinierung durch den SBV TI11.2.1 Definition der angebotenen Services
9.4 Prozessdurchführung problemerkennende ITSM-TI-Teilnehmer11.2.2 Servicekatalog freigeben
9.4.1 Problemerkennung12 Notfall Management
9.4.2 Vorprüfung12.1 Begriffsbestimmungen
9.4.3 Lösung und Schließung im lokalen Problem Management12.1.1 Notfall
9.4.4 Erfassung, Kategorisierung & Priorisierung übergreifender Probleme12.1.2 Lokaler Notfall
9.4.5 Anfrage zur Unterstützung übergreifender Probleme12.1.3 TI-Notfall
9.4.6 Ermittlung der Problemlösungsverantwortung bei übergreifenden Problemen12.1.4 TI-Notfallvorsorge
9.4.7 Problemschließung12.1.5 TI-Notfallmaßnahme
9.4.8 Service Level Requirements (SLR)12.1.6 Notbetrieb
9.5 Prozessdurchführung lösungsunterstützende ITSM-TI-Teilnehmer12.1.7 TI-Notfallbewältigung
9.5.1 Vorprüfung12.1.8 Emergency Management Committee (EMC)
9.5.2 Ablehnung12.1.9 Lösungsteam
9.5.3 Unterstützung Problembearbeitung12.2 Prozessdurchführung Notfallvorsorge
9.5.4 Service Level Requirements (SLR)12.2.1 Analyse der Auswirkungen möglicher Notfälle der Produktinstanzen
9.6 Prozessdurchführung problemlösungsverantwortlicher ITSM-TI-Teilnehmer12.2.2 Entwicklung und Pflege der Notfallvorsorgedokumentation
9.6.1 Vorprüfung12.2.3 Umsetzung Vorkehrungen zur Notfallvorsorge
9.6.2 Ablehnung12.3 Prozessdurchführung TI-Notfallbewältigung
9.6.3 Problem Ursachenanalyse12.3.1 TI-Notfallerkennung
9.6.4 Anfrage zur Bereitstellung der Testumgebung bei SBV12.3.2 Eskalation TI-Notfälle
9.6.5 Anfrage zu Produkttypvorgaben12.3.3 Sofortmaßnahmen TI-Notfälle
9.6.6 Problem Lösungsentwicklung und -implementierung12.3.4 Bewältigung TI-Notfälle
9.6.7 Schließung übergreifendes Problem12.3.5 Koordination der TI-Notfallbewältigung durch den Gesamtverantwortlichen TI
9.6.8 Service Level Requirements (SLR)12.3.5.1 Notfallbeurteilung
9.7 Informationspflichten12.3.5.2 Notfallfeststellung
9.8 Dokumentation12.3.5.3 Einberufung des Emergency Management Committee (EMC)
9.9 Eskalationen12.3.5.4 Zusammenstellung des Lösungsteams
9.10 Obliegenheiten SBV/GTI12.3.5.5 Durchführung der Notfallmaßnahmen
9.11 Prozessreporting (Vorgangsdaten) PRO12.3.5.6 Notfalldeeskalation
9.12 Obliegenheiten lösungsunterstützende SV/SBV12.3.6 Wiederherstellung
9.12.1 Vorprüfung12.3.7 Nachbearbeitung/Notfallauswertung
9.12.2 Ablehnung12.4 Informationspflichten
9.12.3 Unterstützung Problembearbeitung12.5 Dokumentation
10 Notfallmanagement (NM)12.5.1 TI-Notfall-Logbuch
10.1 Betrachtungsgegenstand des übergreifenden Notfallmanagement12.5.2 Wiederherstellungsbericht
10.2 Begriffserläuterungen13 Vorschriften für CSV-Reporting
10.2.1 Notfall13.1 Basisfeldtypen von Prozessdaten
10.2.2 lokaler Notfall14 Anhang A – Verzeichnisse
10.2.3 TI-Notfall14.1 Abkürzungen
10.2.4 TI-Notfallvorsorge14.2 Glossar
10.2.5 TI-Notfallmaßnahme14.3 Abbildungsverzeichnis
10.2.6 Notbetrieb14.4 Tabellenverzeichnis
10.2.7 TI-Notfallbewältigung14.5 Referenzierte Dokumente
10.2.8 Emergency Management Committee (EMC)14.5.1 Dokumente der gematik
10.2.9 Lösungsteam14.5.2 Weitere Dokumente
10.3 Grundsätze des übergreifenden Notfallmanagements
10.3.1 Kommunikation des übergreifenden Notfallmanagements
10.3.2 zentrale Koordination von TI-Notfällen durch das EMC
10.4 Prozessdurchführung Notfallvorsorge
10.4.1 Analyse der Auswirkungen möglicher Notfälle der Produktinstanzen
10.4.2 Entwicklung und Pflege der Notfallvorsorgedokumentation
10.4.3 Umsetzung Vorkehrungen zur Notfallvorsorge
10.5 Prozessdurchführung TI-Notfallbewältigung
10.5.1 Eskalation TI-Notfälle
10.5.2 Sofortmaßnahmen TI-Notfälle
10.5.3 Bewältigung TI-Notfälle
10.5.4 Koordination der TI-Notfallbewältigung durch SBV
10.5.5 Wiederherstellung
10.5.6 Rollback-Verfahren
10.5.7 Nachbearbeitung/Notfallauswertung
10.5.8 Service Level Requirements (SLR)
10.6 Informationspflichten
10.7 Dokumentation
11 Request Fulfillment (RF)
11.1 Betrachtungsgegenstand des Request Fulfillment
11.2 Begriffserläuterungen
11.2.1 Service Request
11.2.2 Complaint Management
11.3 Grundsätze des Request Fulfillment
11.3.1 Zentrale RF Koordinierung durch den GTI
11.3.2 Service Request-Melder
11.3.3 Service Request-Bearbeiter
11.4 Prozessdurchführung Request Fulfillment
11.4.1 Qualifizierte Service Request -Meldung im ITSM-TI-Teilnehmersupport
11.4.2 Prüfung Service Request
11.4.3 Bearbeitung des Service Requests
11.4.4 Schließung des Service Requests und Bestätigung an Melder
12 Anhang – Verzeichnisse
12.1 Abkürzungen
12.2 Glossar
12.3 Abbildungsverzeichnis
12.4 Tabellenverzeichnis
12.5 Referenzierte Dokumente
12.5.1 Dokumente der gematik
12.5.2 Weitere Dokumente
13 Anhang B – Webservice-Schnittstelle
14 Anhang C – Mapping Tabelle Service Level ORS1 – OPB
1 Einordnung des DokumentsDokumentes
1.1 Zielsetzung
Die vorliegenden „Übergreifenden Richtlinien zum Betrieb der TI“ definieren die betrieblichen Mitwirkungspflichten und Schnittstellen zur übergreifenden Zusammenarbeit der Teilnehmer der TITelematikinfrastruktur (TI) im IT-Servicemanagement (ITSM-TI-ITSM) auf prozessualer Ebene. Die übergreifende Richtlinie zum Betrieb der gilt sinngemäß auchübergreifenden Richtlinien gelten für den Betrieb der Referenz- undaller Betriebsumgebungen (Referenzumgebung (RU), Testumgebung. Als ITSM-TI (TU), Produktivumgebung (PU)). TI-ITSM-Teilnehmer sind Anbieter und Service Provider Endnutzernahe Dienste (SPED), verantwortlich für Anwendungsservices, Basisservices, TI-nahe Anwendungen und Anwenderkomponenten. Die zur Erbringung der TI-Services benötigten Produkte müssen zugelassen sein.
Eine abschließende Übersicht der ITSM-TI-ITSM-Teilnehmer in OPB findet sich im Betriebskonzept [gemKPT_Betr#Tab_KPT_Betr_TI_002 Teilnehmer am 001 TI-ITSM-TITeilnehmer].
Hinweis
Anforderungen, die im vorliegenden Dokument definiert sind und sich an eine Teilmenge der ITSM-TI-ITSM-Teilnehmer richten, bspw. an die Anbieter zentraler Produkte, sind deutlich an diese adressiert.
Die Mitwirkung der gematik am ITSM- TI-ITSM erfolgt über explizit benannte Rollen (z. B. Servicebetriebsverantwortlicher - SBV)die Rolle „Gesamtverantwortlicher TI“.
Die gematik Rollen (SBV, SV, GBV TI) haben in den ITSM-TI Betriebsprozessen gegenüber den Anbietern und SPEDs einen anderen Fokus: diese verantworten die Umsetzung ihrer Service-, Support- und Produktverantwortung gegenüber ihren Servicenehmern. Die gematik Rollen hingegen haben Ergebnisverantwortung für die ITSM-TI Betriebsprozesse und nehmenIn dieser Rolle hat die gematik Ergebnisverantwortung für die TI-ITSM-Betriebsprozesse und nimmt dort folgende Funktionen ein:
- Koordination von Vorgängen nach erfolgter Anfrage durch
Anbieter und SPEDs (z.TI-ITSM-Teilnehmer (z. B. Koordination einer Taskforce im Problem Management (PRO)) - Eskalation von Vorgängen bei erkanntem Eskalationsbedarf oder nach erfolgter Eskalation durch
Anbieter / SPEDs (z.TI-ITSM-Teilnehmer (z. B. ein Problem wurde imPROProblem Management an denGBV-Gesamtverantwortlichen TI eskaliert; Eskalationsstufe 2) - Steuerung der
ITSM-TI-ITSM-Prozesse, um die festgelegten Prozess- und Servicequalitäten sicher zu erreichen und konkrete Maßnahmen bei Nichterreichung zu setzen (z. B. Durchführung von Service Reviews imSLMService Level Management (SLM) zur Einleitung von Optimierungsmaßnahmen bei denAnbietern / SPEDsTI-ITSM-Teilnehmern).
Die Richtlinien treffen keine Vorgaben zu internen ITSM-Prozessen der einzelnen Teilnehmer der TI.
Folgende Prozesse werden im ITSM-TI betrachtet:TI-ITSM betrachtet:
- Incident Management: Regelungen für den Umgang mit Störungen, die zu einer Qualitätsminderung der TI-Services führen können,
- Problem Management: Regelungen für das Management von unbekannten Ursachen einer eingetretenen/möglichen Störung und der nachhaltigen Beseitigung der identifizierten Störungsursachen,
- Request Fulfillment: Regelungen für das Bearbeiten von Service Requests. Dabei handelt es sich um das Nachfragen nach vordefinierten Dienstleistungen bzw. das Stellen allgemeiner Anfragen und/oder Beschwerden, die von berechtigten TI-Akteuren oder zukünftigen TI-ITSM-Teilnehmern durchgeführt werden,
- Configuration Management: Regelungen für das Management der für die TI-Services erforderlichen Beschreibungsdaten,
- Change & Release Management: Regelungen für das Management von Änderungen der TI-Services sowie Regelungen für das Management zur Überführung von Releases in den Wirkbetrieb,
- Knowledge Management: Regelungen für das Management von Informationen aus dem und für den Wirkbetrieb der TI-Services,
- Service Level Management: Regelungen für das Management zur Definition, Kontrolle sowie Optimierung der Service Level über alle Betriebseinheiten hinweg,
- Performance Management: Regelungen für das Management zur Sicherstellung einer adäquaten Dimensionierung und definierter Service Level konformer Leistungserbringung der TI,
o Change & Release Management: Regelungen für das Management von Änderungen der TI-Basis-Services und Anwendungsservices sowie Regelungen für das Management zur Überführung von Releases in den Wirkbetrieb,
o Configuration Management: Regelungen für das Management der für die TI-Basis-Services und Anwendungsservices erforderlichen Beschreibungsdaten,
o Knowledge Management: Regelungen für das Management von Informationen aus dem und für den Wirkbetrieb der TI-Basis-Services und Anwendungsservices,
o Incident Management: Regelungen für den Umgang mit Störungen, die zu einer Qualitätsminderung der TI-Basis-Services oder der Anwendungsservices führen können,
o Problem Management: Regelungen für das Management von unbekannten Ursachen einer eingetretenen/möglichen Störung und nachhaltiger Beseitigung der identifizierten Störungsursachen,
o Notfallmanagement: Regelungen für die Notfallvorsorge und die Notfallbewältigung der TI-Basis-Services und der Anwendungsservices.
o Request Fulfillment: Regelungen für das Bearbeiten von Service-Requests. Dabei handelt es sich um Nachfrage nach vordefinierten Dienstleistungen bzw. Stellung allgemeiner Anfragen und/oder Beschwerden, die von berechtigten TI-Akteuren oder zukünftigen ITSM-TI-Teilnehmern durchgeführt werden.
In Kapitel 2 werden die prozessübergreifenden Begriffe und Grundsätze, die Regelungen zum Reporting und die Zuordnung der ITSM-Prozesse zu den ITIL-Lebenszyklusphasen eingeführt. Es werden die betrieblichen Rollen definiert und deren Verantwortungsteilung beschrieben. Zugleich werden den Rollen Teilaufgaben zugeordnet, die sich aus den Aufgabenbereichen des Betriebs der TI ergeben.
Die Aufgabenbereiche sind an ITIL® V3Servicekatalog-Management: Regelungen für die Erstellung und Bereitstellung von Servicekatalogen der TI-ITSM-Teilnehmer,- Notfallmanagement: Regelungen für die Notfallvorsorge und die Notfallbewältigung der TI-Services.
Die Aufgabenbereiche sind an die IT Infrastructure Library V3 (ITIL® V3) angelehnt. Alle Aufgabenfelder werden in Form von übergreifenden IT-Service-Management-Prozessen mit den jeweiligen Aufgaben und Zielen vorgestellt. Sie orientieren sich an den ITIL-Lebenszyklusphasen des „Service Design“ zur Erstellung, Weiterentwicklung und Pflege von Vorgaben, der „Service Transition“ zur Überführung der Vorgaben in den Wirkbetrieb und der „Service Operation“ in der Unterstützung des Wirkbetriebs der TI-Services.
1.2 Zielgruppe
Das Dokument richtet sich an die bezeichneten ITSM-TI-ITSM-Teilnehmer.
1.3 Geltungsbereich
Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur (TI) des Deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungsverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z. B. Dokumentenlandkarte, Anbietertypsteckbrief, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.
Schutzrechts-/Patentrechtshinweis
Die nachfolgende Richtlinie ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Richtlinie in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Richtlinie angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.
1.4 AbgrenzungAbgrenzungen des Dokuments
Nicht alle ITSM-Prozesse gemäß ITIL® V3 sind im Rahmen dieses Richtliniendokumentes geregelt. Dies ergibt sich insbesondere
- durch die Fokussierung auf die Mitwirkungspflichten durch
Anbieter und SPEDsTI-ITSM-Teilnehmer im Wirkbetrieb der TI,und - durch Umsetzungsanforderungen, die ausschließlich durch ein spezifisches Reporting umzusetzen sind
Aus oben genannten Gründen sind innerhalb dieses Dokumentes folgende ITSM-Prozesse nicht geregelt:
- Service Design: Weiterentwicklung der TI, Information Security Management
- Service Transition: Subprozesse des Change Managements (On-/Offboarding zentraler Produktinstanzen, Inbetriebnahme und Änderung dezentraler Produktinstanzen der TI), Testmanagement
- Service Operation: Operativer Betrieb und Überwachung.
Regelungen für Anwender, Versicherte und DVOs (Dienstleister vor Ort) werden nicht definiert.
1.5 Methodik
Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID in eckigen Klammern sowie die dem Request for Change (RFC) 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet. Sie werden im Dokument wie folgt dargestellt:
<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]
Dabei umfasst die Anforderung sämtliche innerhalb der TextmarkenAfo-ID und der Textmarke angeführten Inhalte.
2 Prozessübergreifende Regelungen
In diesem Kapitel werden Begriffe und Regelungen eingeführt, die für alle nachfolgend beschriebenen ITSM-Prozesse Gültigkeit haben.
Begriffe, die im Kontext des übergreifenden Betriebes einer Konkretisierung bedürfen, werden in diesem Dokument in den Kapiteln „Begriffserläuterungen“ definiert. Dabei wird zwischen prozessübergreifenden und prozessspezifischen Begriffserläuterungen unterschieden.
Prozessübergreifende Begriffserläuterungen werden zentral in diesem Dokument eingeführt und sind über alle in diesem Dokument beschriebenen ITSM-Prozesse hinweg gültig.
Prozessspezifische Begriffserläuterungen werden prozessspezifisch eingeführt und sind nur im Kontext des jeweiligen ITSM Prozesses gültig.
Ergänzende Informationen mit nicht normativem Inhalt, die zum Fördern des gemeinsamen Verständnisses der ITSM-TI-Teilnehmer (siehe Kapitel 2.2.2) beitragen (z.B. Prozessablaufdiagramme, ergänzende Beschreibungen oder Kontaktinformationen), werden bei Bedarf im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank (siehe Kapitel 7.2.1) bereitgestellt.
2.1 Organisationen in § 274 Abs. 1 SGB V in der Rolle eines Anbieters
Sofern eine im § 274 Abs. 1 SGB V genannte Organisation, die gemäß § 274 Abs. 1 SGB V regelmäßig durch eine im § 274 Abs. 1 SGB V benannte Stelle geprüft wird, in der Rolle eines Anbieters auftritt, muss sie - unabhängig vom angebotenen Produkt bzw. der angebotenen Anwendung – die Anforderungen aus Tabelle xy nicht nachweisen.
Tabelle 1: Tab_Betr_TIP_050 zeigt Anforderungen, die bei einer Prüfung nach § 274 Abs. 1 SGB V, der gematik nicht nachgewiesen werden müssen.
|
|
|
2.2 Prozessübergreifende Begriffserläuterungen
Nachfolgend werden die wesentlichen prozessübergreifenden Begriffe erläutert, die Anforderungen zur prozessübergreifenden Kommunikation der ITSM-TI-Teilnehmer auf Grundlage der ZID sowie die Mindestinhalte des vorzulegenden Betriebshandbuchs dargestellt.
2.2.1 Information, Eskalation, Report
1. Information: Bei einer Information handelt es sich um eine für den jeweiligen Empfänger strukturierte und aufbereitete Sammlung von Daten, die - zu festgelegten Prozesszeitpunkten - durch den Versender an definierte Adressaten verschickt werden.
2. Eskalation: Eine Eskalation wird angestoßen, um die gefährdete Zielerreichung dennoch sicherzustellen. In den Richtlinien wird unter dem Begriff „Eskalation“ prinzipiell eine hierarchische Eskalation verstanden. Eine Eskalation beinhaltet ähnliche Merkmale wie eine strukturierte Information.
a. Funktionale „Eskalationen“ sind im Umfang der definierten ITSM-Prozesse Zuweisungen bzw. Weiterleitungen von speziellen Aufgaben an andere Prozessbeteiligte.
3. Report: Bei einem Report handelt es sich um eine für den jeweiligen Empfänger strukturierte und aufbereitete Sammlung von Daten, die nach der originären Prozessdurchführung - zu festgelegten Zeitpunkten oder ad-hoc - durch den Versender an definierte Adressaten verschickt werden.
2.2.2 Teilnehmer-ID (TID)
Die Teilnehmer-ID identifiziert die Teilnehmer im Betrieb der TI (Beteiligte am IT-Servicemanagement gemäß dieser Richtlinie) eineindeutig. Sie ist vom Typ „String [5]“ und wird von gematik vergeben. Die ID über alle Teilnehmer wird in Listenform von der gematik im Rahmen des Knowledge Managements veröffentlicht. Ist eine Hersteller-ID/Anbieter-ID gemäß [gemSpec_OM] vorhanden, wird sie verwendet.
2.2.3 Prozessübergreifende Kommunikation
Hinweis zur Weiterentwicklung der Betriebsdokumente und des TI-ITSM-Tools
Die Richtlinie Betrieb wird im Zuge neuerer Erkenntnisse und Anpassungen an aktuelle Standards überarbeitet und die zentrale Anwendung zum Informationsaustausch der Akteure im ITSM der TI - Zentrale Informationsdrehscheibe (ZID) - wird durch eine Nachfolgeanwendung (TI-ITSM-Tool) geplant zum 30.09.2017 abgelöst. Die Nachfolgeanwendung (TI-ITSM-Tool) bietet neben der bereits etablierten Webportal-Schnittstelle eine standardisierte Webservice-Schnittstelle an. Der strukturierte Datenaustausch per CSV-Datei wird abgelöst.
Zukünftigen Teilnehmern wird empfohlen, über das Webportal der ZID teilzunehmen und strukturierte Reports via CSV zu senden.
Es steht den Teilnehmern frei, die automatisierte CSV-Schnittstelle der ZID zu nutzen. Diese steht jedoch nur noch bis zur Ablösung durch die Nachfolgeanwendung (TI-ITSM-Tool) zeitlich begrenzt zur Verfügung und wird nach der Migration der ZID auf die Nachfolgeanwendung abgeschaltet. Im Anschluss kann der Teilnehmer ausschließlich über das Webportal oder per Webservice am ITSM der TI teilnehmen.
Um eine möglichst reibungslose Prozesskommunikation und effiziente Prozessdurchführung zwischen den ITSM-TI-Teilnehmern und den zuständigen Serviceverantwortlichen (SV) bzw. Servicebetriebsverantwortlichen (SBV) sicherzustellen, werden nachfolgend die übergreifenden Anforderungen für die Bereitstellung von Kommunikationsschnittstellen und Ansprechpartnern definiert. Die Kommunikationsschnittstelle und die Ansprechpartner bilden den SPOC (Single Point of Contact) des jeweiligen ITSM-TI-Teilnehmers im Rahmen der Prozesskommunikation.
Die zuständigen SV/SBV errichten ihrerseits Kommunikationsschnittstellen und stellen Ansprechpartner im Rahmen der Prozesskommunikation zur Verfügung. Die Übersicht der im übergreifenden ITSM zu verwendenden Kontaktdaten (E-Mail-Adressen, Telefonnummern) wird im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank hinterlegt.
Die nachfolgenden Anforderungen an die Kommunikation zwischen den Prozessbeteiligten basieren auf einer ursprünglich vorgesehenen bilateralen Kommunikation via E-Mail und dem Austausch strukturierter CSV-Dateien. Um jedoch für alle Beteiligten eine einheitliche und transparente Daten- und Prozesskonsistenz für die übergreifenden ITSM-Prozessabläufe im Incident-, Problem- und Change-Management zu erreichen, wird mit der Zentralen Informationsdrehscheibe (ZID) ein zentrales ITSM-System zur Verfügung gestellt. Dieses bildet die zentrale Kommunikationsschnittstelle für alle Prozessbeteiligten. Wichtig ist, dass die ZID nur die übergreifenden Kommunikationsprozesse unterstützt (keine lokalen Prozesse) und hier auch nur die Kommunikationsvorgänge im Incident-, Problem- und Change-Management. Für Teilnehmer, die sich in den übergreifenden INC- und PRO-Prozessen für die Benutzung des Webportals entscheiden, kann hingegen die ZID zum führenden ITSM-System werden. Auch diese Teilnehmer müssen den INC „lokal“ dokumentieren, d. h. in diesem Fall in der ZID. Die Dokumentation sollte allerdings bereits vollständig in der ZID vorliegen.
Die ZID stellt für den gesicherten Austausch und die Generierung von Prozessinformationen mehrere Schnittstellen zur Verfügung. Ein Prozessbeteiligter kann im Incident- und Problem-Management über die ZID dabei entweder (weiterhin) seine Kommunikationsschnittstelle durch die Versendung von E-Mails mit angehängten CSV-Dateien einrichten, oder er realisiert den Austausch mit der ZID über eine Webservice-Schnittstelle oder er entscheidet sich für die manuelle Bedienung im Webportal. Grundsätzlich besteht die Möglichkeit, Incidents, Problems und Changes im Webportal der ZID einzusehen.
Die ZID stellt im Incident- und Problem-Management sicher, dass über die vom Prozessbeteiligten einmalig vorab getroffene Entscheidung des Kommunikationsweges (E-Mail mit CSV oder Webservice oder Webportal) sämtliche der im Folgenden beschriebenen Kommunikationsschritte abgebildet werden.
Bei der Kommunikation im Change Management wird im Wesentlichen davon ausgegangen, dass die Informationsübermittlung zwischen den Prozessbeteiligten per E-Mail ohne CSV-Dateien erfolgt. Daher bietet die ZID für diesen Prozess keine Webservice-Schnittstelle an, sondern es steht ausschließlich das Webportal der ZID zur Verfügung. Die Benutzung des Webportals für übergreifende Produkt-RfCs bzw. Produkt-Changes steht jedoch jedem ITSM-TI-Teilnehmer frei. Falls sich ein ITSM-TI-Teilnehmer im Rahmen des Change Managements für die Nutzung des Webportals entscheidet, sind die für diesen Prozess definierten Übermittlungs- und Dokumentationspflichten auch möglichst durchgehend in der ZID zu erfüllen.
Der Zugriff auf die Webservice-Schnittstelle und das Webportal der ZID durch die ITSM-TI-Teilnehmer wird durch Eingabe von Melder-individuellen Anmeldeinformationen (Anmeldenamen und Passwort) abgesichert. Zusätzlich wird der Zugriff auf definierte IP-Adress-Bereiche beschränkt, wobei der IP-Adress-Bereich nachvollziehbar dem entsprechenden ITSM-TI-Teilnehmer zuzuordnen sein muss. Weiterhin wird die Datenübertragung durch ein Server-Zertifikat abgesichert.
Bei Ausfall der ZID oder anderen vom GTI/SBV zur Verfügung gestellten Kommunikationsschnittstellen bzw. Informationssystemen, hat die Absicherung der Kommunikation durch die ITSM-TI-Teilnehmer zu erfolgen.2.1 Zentrales TI-ITSM-System
2.1.1 Übergreifendes ITSM der TI
Das ITSM der TI verantwortet die übergreifende Bearbeitung von Vorgängen in der TI.
Wesentliche Aufgaben sind:
- die gleichartige Behandlung aller übergreifenden Vorgänge und
- die lückenlose Übergabe von Informationen zu übergreifenden Vorgängen zwischen den betroffenen TI-ITSM-Teilnehmern.
Es werden keine normativen Vorgaben zu lokalen Prozessen der TI-ITSM-Teilnehmer gemacht.
Übergreifender Vorgang
Vorgänge sind Auslöser für die in diesen Richtlinien beschriebenen TI-ITSM-Prozesse.
Ein übergreifender Vorgang liegt vor, wenn
- zur Bewältigung mehrere der am TI-ITSM-Prozess beteiligten TI-ITSM-Teilnehmer involviert werden müssen oder
- ein im Verantwortungsbereich des TI-ITSM-Teilnehmers festgestellter lokaler Vorgang die Kriterien gemäß GS-A_3884 oder GS-A_3964 erfüllt. Die lokale Kategorisierung sollte die übergreifende Bedeutung des Vorgangs anzeigen (mit Priorität 1 oder 2).
Alle Informationen, die bei der Bearbeitung eines Vorgangs entstehen, sind Vorgangsdaten.
2.1.2 Kommunikation
Die Kommunikationsschnittstellen und die Ansprechpartner bilden den SPOC (Single Point of Contact) des jeweiligen TI-ITSM-Teilnehmers im Rahmen der Prozesskommunikation. Diese Schnittstellen sollen die Erreichbarkeit der TI-ITSM-Teilnehmer untereinander sicherstellen.
Voraussetzung zur Teilnahme am ITSM der TI ist die Nutzung des zentralen TI-ITSM-Systems.
GS-A_4090 - Kommunikationssprache
Alle TI-ITSM-Teilnehmer MÜSSEN sowohl schriftlich als auch mündlich in deutscher Sprache kommunizieren. Dies gilt insbesondere für die gemäß GS-A_4085 festgelegten Kommunikationsschnittstellen und für alle Dokumentationen.
[<=]
GS-A_3886 - Nutzung des TI-ITSM-Systems bei der Übermittlung eines übergreifenden Vorgangs
Alle TI-ITSM-Teilnehmer MÜSSEN zur Informationsübermittlung eines übergreifenden Vorgangs vorrangig das TI-ITSM-System nutzen.
[<=]
Das TI-ITSM-System vergibt für jeden Vorgang eine eindeutige Referenznummer. Die Referenznummer des lokalen ITSM-Systems des TI-ITSM-Teilnehmers kann mitgeführt werden.
GS-A_4085 - Etablierung von Kommunikationsschnittstellen durch die TI-ITSM-Teilnehmer
Alle TI-ITSM-Teilnehmer MÜSSEN im Rahmen der übergreifenden Betriebsprozesse mindestens die nachfolgenden Kommunikationsschnittstellen etablieren:
- Telefon (z.B. zur Rücksprache zu einem TI-ITSM-Vorgang);
- E-Mail (z.B. zur Übermittlung von Ad-hoc-Reports);
- TI-ITSM-System zur Informationsübermittlung eines übergreifenden Vorgangs entsprechend GS-A_3886.
[<=]
GS-A_4085 - Etablierung von4086 - Erreichbarkeit der Kommunikationsschnittstellen durch die ITSM-TI-Teilnehmer
Die ITSM-Alle TI-ITSM-Teilnehmer MÜSSEN im Rahmen der übergreifenden Betriebsprozesse geeignetedie Kommunikationsschnittstellen etablieren. Diese Schnittstellen MÜSSEN neben der Erreichbarkeit sicherstellen, dass die Übermittlung der definierten strukturierten Prozessdaten im Rahmen der ZID durchführbar ist. Der Informationsaustausch per E-Mail zwischen TI-Teilnehmern hat verschlüsselt mittels S/MIME (Secure / Multipurpose Internet Mail Extensions) zu erfolgen. Die für die Kommunikation notwendigen Zertifikate werden über das Knowledge Management den ITSM-TI-Teilnehmern zur Verfügung gestellt.Die ITSM-TI-Teilnehmer MÜSSEN alle im Rahmen der prozessübergreifenden Kommunikation zu versendenden E-Mails auf ihre Größe überprüfen. Dabei MUSS grundsätzlich sichergestellt sein, dass E-Mails die Größe von 5 MB nie überschreiten. Eine Ausnahme stellen E-Mails mit dem Adressaten SBV/GTI mit einer maximalen Größen von 20 MB dar.Weiterführend sind folgende Regelungen zu beachtenwährend der festgelegten Servicezeiten erreichbar halten und einer regelmäßigen Eingangsprüfung und Bearbeitung unterziehen.
[<=]
GS-A_4088 - Benennung von Ansprechpartnern
TI-ITSM-Teilnehmer MÜSSEN entsprechend ihrer Rolle (gemKPT_Betr#Tab_KPT_Betr_TI_003 Mitwirkungsverpflichtung im TI-ITSM) Kontaktdaten im TI-ITSM-System eintragen und aktuell halten für:
• Der Betreff einer E-Mail ist immer der Dateiname der in der E-Mail angehängten CSV-Datei.
• Bei der Anwendung von E-Mail-Komprimierung:
o CSV-Dateien sind von Komprimierungsmaßnahmen ausgeschlossen
o Komprimierung der Dateianhänge im zip-Datei-Format
o Mit „normaler“ Kompression/Kompressionsstärke
o Mit Kompressionsmethode/-verfahren „Deflate“ (#4.4.5 - compression method 8)
o Unverschlüsselt, d. h. ohne Passwort
Nicht selbst-entpackend (d.h. zip als exe)kaufmännische Ansprechpartner,- technische Ansprechpartner,
- Ansprechpartner/Funktionspostfächer für jeden einzelnen TI-ITSM-Prozess,
- Ansprechpartner/Funktionspostfach für die Eskalation,
- Ansprechpartner/Teilnehmer für das Emergency Management Committee,
- Ansprechpartner/Funktionspostfach für Informationssicherheit,
- Ansprechpartner/Funktionspostfach für Datenschutz,
- Ansprechpartner/Funktionspostfach für Notfall-Management,
- Ansprechpartner/Funktionspostfach Außenkommunikation (u.a. Krisenkommunikation).
• Die ZID wird immer mit der Empfängeradresse des ZID-Postfaches des adressierten Teilnehmers antworten.
[<=]
GS-A_4086 - Erreichbarkeit von Kommunikationsschnittstellen der ITSM-TI Teilnehmer
Die ITSM-TI-Teilnehmer MÜSSEN die Kommunikationsschnittstellen während der festgelegten Servicezeiten erreichbar halten und einer regelmäßigen Eingangsprüfung und Bearbeitung unterziehen.
[<=]
Die Service Level Requirements zu den Servicezeiten werden in den jeweiligen ITSM Prozessen dieses Dokumentes definierthier genannten Ansprechpartner MÜSSEN mit der entsprechenden Fach- und Entscheidungskompetenz ausgestattet sein.
[<=]
Mehrfachnennungen und/oder Nennung eines Ansprechpartners/Funktionspostfachs für mehrere Bereiche sind möglich.
2.1.2.1 Kommunikation außerhalb des TI-ITSM-Systems
Bei Ausfall des TI-ITSM-Systems müssen die TI-ITSM-Teilnehmer die Bearbeitung der Vorgänge fortsetzen. Die Kommunikation erfolgt dann über die gemäß GS-A_4088 angegebenen Kommunikationsschnittstellen.
GS-A_4087 - Erreichbarkeit der Kommunikationsschnittstelle bei Rufbereitschaften außerhalb der Servicezeiten der ITSM-TI-Teilnehmer5402 - Eigenverantwortliches Handeln bei Ausfall von Kommunikationsschnittstellen
Bei ITSM-TI-Teilnehmern, bei denen Rufbereitschaften etabliert werden sollen, MUSS die Kommunikationsschnittstelle während der vereinbarten Rufbereitschaftszeiten stetig erreichbar sein und regelmäßiger Eingangsprüfung und Bearbeitung durch den ITSM-TI-Teilnehmer unterliegen.
[<=] Ausfall des TI-ITSM-Systems oder anderer Kommunikationsschnittstellen MUSS die Kommunikation durch die TI-ITSM-Teilnehmer eigenverantwortlich untereinander sichergestellt werden. Vorgänge müssen im TI-ITSM-System nachdokumentiert werden.
[<=]
GS-A_4088 - Bereitstellung eines technischen Ansprechpartners durch ITSM-TI-Teilnehmer5401 - Verschlüsselte E-Mail-Kommunikation
ITSM-TI-Teilnehmer MÜSSEN im Rahmen der übergreifenden Betriebsprozesse allen Prozessbeteiligten einen technischen Ansprechpartner bereitstellen.
[<=]
GS-A_4089 - Bereitstellung eines kaufmännischen Ansprechpartners durch ITSM-TI-Teilnehmer
ITSM-TI-Teilnehmer MÜSSEN im Rahmen der übergreifenden Betriebsprozesse allen Prozessbeteiligten einen kaufmännischen Ansprechpartner bereitstellen.
[<=]
GS-A_4892 - Eingangsbestätigung für den Melder
Dem Übermittler/Erfasser der Prozessdaten muss unverzüglich eine Eingangsbestätigung übermittelt werden, bei den übergreifenden Prozessen im Incident-, Problem- und Change-Management verläuft die Kommunikation über die ZID. Für per Web-Service bzw. Webportal angebundene Empfänger entfällt diese Pflicht, hier übernimmt die ZID das Ausstellen einer Eingangsbestätigung an den per CSV-angebundenen Absender (über die ZID-Postfachadresse des Empfängers). Die „technischen Empfangsbestätigungen“ werden durch eine einheitliche Notation in der Betreffzeile der E-Mail gekennzeichnet. Die Betreffzeile ist wie folgt zu kodieren:
a. [<Präfix>˽<originaler Betreff der Nachricht >]
b. In der Empfangsbestätigung ist KEINE CSV-Datei anzufügen!
c. Mailformat ist Plain-Text
Es darf auf eine empfangene Eingangsbestätigung keine erneute Eingangsbestätigung generiert werdenDer Informationsaustausch per E-Mail zwischen allen TI-ITSM-Teilnehmern MUSS verschlüsselt mittels Secure/Multipurpose Internet Mail Extensions (S/MIME) erfolgen. Das für diese Kommunikation notwendige Zertifikat MUSS vom Eigentümer der E-Mail-Adressen selbst beschafft und allen TI-ITSM-Teilnehmern zur Verfügung gestellt werden.
[<=]
Die Zurverfügungstellung der E-Mail-Zertifikate erfolgt durch alle TI-ITSM-Teilnehmer in der Wissensdatenbank der TI.
Der TI-ITSM-Teilnehmer sollte alle anderen TI-ITSM-Teilnehmer durch den Versand einer mit seinem Zertifikat signierten E-Mail über dieses Zertifikat informieren. Wird ein bestehendes Zertifikat ersetzt, sollte diese Information mindestens zwei Wochen vor dem Ablauf der Gültigkeit des alten Zertifikates erfolgen.
2.1.3 TI-ITSM-Reporting
Informationen zu übergreifenden Vorgängen, wie Vorgangsdaten, Lösungsdokumentation etc., sind im zentralen TI-ITSM-System vorhanden. Der Gesamtverantwortliche TI wird die im System vorhandenen Daten zum übergreifenden TI-Reporting verwenden.
Der Gesamtverantwortliche TI wird einmal im Monat die vom TI-ITSM-System zur Verfügung gestellten und aus den übermittelten Daten das TI-Reporting aufbereiten.
e. Der <Präfix> hat zu lauten „#ERHALTEN#“
[<=]
GS-A_4090 - Kommunikationssprache zwischen den Prozessbeteiligten
ITSM-TI-Teilnehmer MÜSSEN im Rahmen der Prozesskommunikation sowohl schriftlich als auch mündlich in deutscher Sprache kommunizieren. Dies gilt insbesondere für die durch diese Richtlinien geregelte Kommunikation an den Prozessschnittstellen (bspw. mittels E-Mails, Formularen).
[<=]
GS-A_4091 - Dokumentationssprache
ITSM-TI-Teilnehmer MÜSSEN alle im Rahmen der übergreifenden Betriebsprozesse zu erstellenden Dokumentationen in deutscher Sprache verfassen.
[<=] Gesamtverantwortliche TI kann ad hoc, also außerplanmäßig, Reports anfordern. Dabei kann es erforderlich werden, andere Kennzahlen (innerhalb eines zumutbaren Umfangs für den TI-ITSM-Teilnehmer) abzufragen. Entsteht solch eine Notwendigkeit zur Erhebung weiterer Messgrößen, werden diese gemeinsam mit den betroffenen TI-ITSM-Teilnehmern individuell abgestimmt.
GS-A_4095 - Übermittlung von Ad-hoc-Reports
TI-ITSM-Teilnehmer MÜSSEN den vom Gesamtverantwortlichen TI angeforderten Ad-hoc-Report über die benannte Kommunikationsschnittstelle (entsprechend GS-A_4085) im geforderten Format (entsprechend GS-A_5248, GS-A_5249, GS-A_5608) und Zeitfenster übermitteln.
[<=]
2.2.4 Betriebshandbuch-Auszug
Um eine gesicherte Verbindung der ITSM-TI-Teilnehmer Prozesse mit den übergreifenden ITSM-TI Prozessen zu ermöglichen, müssen die implementierten Prozesse der ITSM-TI-Teilnehmer mindestens an den Schnittstellen nachvollziehbar sein. Des Weiteren müssen die vor- und nachgelagerten Prozesse hinsichtlich der Sicherstellung der Qualität dargestellt werden.
Die relevanten Auszüge aus dem Betriebshandbuch der ITSM-TI-Teilnehmer sollen hier die geeigneten Steuerungs- und Kontrollmöglichkeit bieten: initial im Zuge der Anbieterzulassung und im Bedarfsfall als Grundlage von anlassbezogenen Prozessprüfungen.
Um für die ITSM-TI-Teilnehmer Mehraufwand und die Offenbarung von möglichen Betriebsgeheimnissen zu vermeiden, können daher Auszüge aus den bestehenden Betriebshand-büchern bzw. providerspezifischen Betriebskonzepten nachgenutzt werden ITSM der TI-ITSM-Teilnehmer
2.2.1 Auszüge aus dem Betriebshandbuch der TI-ITSM-Teilnehmer
Die Prozessschnittstellen der TI-ITSM-Teilnehmer müssen für die übergreifende Kommunikation mit dem TI-ITSM-System prozessseitig und technisch kompatibel sein. Der Nachweis der Etablierung geeigneter TI-ITSM-Schnittstellenprozesse muss auszugsweise durch Vorlage eines Betriebshandbuches erfolgen.
GS-A_5343 - Definition inhaltlicher Auszüge aus dem Betriebshandbuch
Die Auszüge aus dem Betriebshandbuch des TI-ITSM-Teilnehmers MÜSSEN nachfolgende Themen beinhalten:
1.Einführung
• Anbieterbezeichnung und -identifikation
• Version
•- Version
- Freigabe- und Prüfungsverantwortung
•,soweit vorhanden•2.Systemüberblick•••3.Aufnahme, Unterbrechung und Beendigung des Betriebes
• Aufnahme
• Wiederaufnahme
4. Unterbrechung / Beendigung des Betriebes
• Unterbrechung
• Beendigung
5.Initiale Aufnahme des Betriebs (insbesondere Reihenfolge, Rahmenbedingungen)- (kontrollierte) Unterbrechung des Betriebs (Übergang in den Notbetrieb)
- Wiederaufnahme des Normalbetriebs (Wiederherstellung des Normalbetriebs)
- Beendigung des Betriebs (insbesondere Reihenfolge der Abschaltung, Aufräumarbeiten)
- Darstellung des lokalen ITSM (vor- und nachgelagerte Prozesse im Verhältnis zu den übergreifenden ITSM
• Incident Management
• Problem Management
• Notfallmanagement
• Service Level Management
• Performance Managment
• Configuration Management
• Change & Release Management
• Knowledge Management.
6. Integration des lokalen ITSM in das übergreifende ITSM der TI (übergreifende Prozesse)
• Incident Management
• Problem Management
• Notfallmanagement
• Service Level Management
• Performance Managment
• Configuration Management
• Change & Release Management
• Knowledge Management.
7. Relevanter Teil des Servicekataloges
8. Nachweis zur Umsetzung der Anforderungen.Insbesondere sind hier die in diesen Richtlinien beschriebenen ITSM-Prozesse in den internen Prozessabläufen des Anbieters kompakt darzustellen.- Alle weiteren internen ITSM-Prozesse des Anbieters sind aufzulisten und kurz zu beschreiben soweit diese für die Prozesse gemäß diesen Richtlinien begleitend erforderlich sind.
- Das Ziel der Darstellung ist die korrekte Verzahnung zwischen dem lokalen ITSM und den übergreifenden ITSM-Prozessen.
- Integration des lokalen ITSM in das übergreifende ITSM der TI (übergreifende Prozesse)
- Die Bedienung der in diesen Richtlinien beschriebenen TI-ITSM-Prozesse durch den Anbieter ist ausführlich zu beschreiben.
- Schnittstellen und Interaktionen zwischen den internen ITSM-Prozessen des Anbieters und übergreifenden TI-ITSM-Prozessen sind zu dokumentieren.
- Relevanter Teil des Servicekataloges
- Nachweis zur Umsetzung der Anforderungen.
[<=]
2.3 Auditierung von TI-ITSM-Teilnehmern
Es besteht die Möglichkeit, anlassbezogene Audits durchzuführen. Audits werden durchgeführt, wenn die Prozesskommunikation zwischen den am Betrieb beteiligten TI-ITSM-Teilnehmern nachhaltig gestört bzw. die Serviceerbringung gegenüber dem Anwender bzw. Versicherten gefährdet ist.
Die Audits dienen der Prüfung der korrekten Umsetzung der Richtlinien insbesondere mit dem Ziel, Schnittstellen- und Prozessprobleme zwischen TI-ITSM-Teilnehmern zu identifizieren. Die Erkenntnisse der anlassbezogenen Audits können auch zur Optimierung der Richtlinien führen, um die Reibungsverluste im Zusammenspiel der TI-ITSM-Teilnehmer untereinander zu minimieren.
GS-A_4855 - Auditierung von TI-ITSM-Teilnehmern
TI-ITSM-Teilnehmer MÜSSEN Auditierungen durch Gesamtverantwortlichen TI zur Überprüfung der Einhaltung von Produktvorgaben ermöglichen und angemessen unterstützen.
Sofern ein TI-ITSM-Teilnehmer bereits gesetzlichen Vorgaben einer Auditierung unterliegt, ihm also eine Prüfung durch eine in der gesetzlichen Vorgabe benannte Instanz vorgeschrieben ist, unterliegt er nicht der Auditierung gemäß dieser Anforderung. Der TI-ITSM-Teilnehmer MUSS die gesetzliche Vorgabe gegenüber dem Gesamtverantwortlichen TI benennen. Fachdienste VSDM, KTR-AdV, KTR-Consumer und TSP eGK sind von dieser Anforderung ausgeschlossen.
[<=]
Umfang und Zeitpunkt des Audits stimmt der Gesamtverantwortliche TI mit dem zuständigen Serviceverantwortlichen ab.
GS-A_3917 - Bereitstellung der ITSM-Dokumentation bei Audits
TI-ITSM-Teilnehmer MÜSSEN bei der Durchführung von Audits auf Verlangen die ITSM-Dokumentationen (d.h. TI-ITSM relevante Tickets im ITSM-System) aller relevanten Vorgänge pro ITSM-Prozess bereitstellen.
[<=]
2.4 Zentrale Koordinierung durch den Gesamtverantwortlichen TI
Die Koordination der Vorgangsbearbeitung erfolgt i.d.R. durch die betroffenen TI-ITSM-Teilnehmer in Eigenverantwortung.
Ausschließlich bei Eskalationen eines Vorgangs oder Vorgängen mit TI-übergreifender Auswirkung kann der Gesamtverantwortliche TI – zur Gewährleistung der Performance, Sicherheit und Stabilität der zentralen und dezentralen Produkte – eine zentrale Koordinierung der Aktivitäten der anderen Beteiligten übernehmen.
2.4.1 Eskalationen im übergreifenden TI-ITSM
Eine Eskalation wird angestoßen, um eine gefährdete Zielerreichung dennoch sicherzustellen. In den „Übergreifenden Richtlinien zum Betrieb der TI“ wird unter dem Begriff „Eskalation“ prinzipiell eine hierarchische Eskalation verstanden. Funktionale Eskalationen sind im Umfang der definierten ITSM-Prozesse Zuweisungen bzw. Weiterleitungen von speziellen Aufgaben an andere Prozessbeteiligte.
GS-A_3920 - Eskalationseinleitung durch den TI-ITSM-Teilnehmer
TI-ITSM-Teilnehmer MÜSSEN bei übergreifenden Vorgängen eine hierarchische Eskalation an den Gesamtverantwortlichen TI einleiten, wenn einer der nachfolgenden Aspekte zutrifft:
- es kann kein serviceverantwortlicher TI-ITSM-Teilnehmer (entsprechend [gemKPT_Betr#Tab_KPT_Betr_TI_002]) ermittelt werden
ODER
- es kann keine Einigung über die Serviceverantwortung für den übergreifenden Vorgang mit anderen TI-ITSM-Teilnehmern erzielt werden
ODER
- es kann keine Einigung über die Lösungsunterstützung für den übergreifenden Vorgang mit anderen TI-ITSM-Teilnehmern erzielt werden
ODER
- es treten bei der Bewertung oder Durchführung eines Produkt-Changes schwerwiegende Konflikte auf
ODER
- es ist zur Gewährleistung der Performance, Sicherheit und Stabilität der zentralen und dezentralen Produkte eine übergeordnete Koordination notwendig.
[<=]
2.3 Reporting4.2 Taskforce als Instrument der Deeskalation im übergreifenden TI-ITSM
Zur Unterstützung der strategischen und operativen Betriebsführung sowie zur Überwachung der Einhaltung von Vorgaben ist durch die ITSM-TI-Teilnehmer ein Reporting zu etablieren. In diesem Kapitel werden hierzu die übergreifenden Anforderungen sowie der inhaltliche Aufbau an das regelmäßige, konsolidierte Reporting sowie an das unregelmäßige Ad-hoc-Reporting beschrieben.
2.3.1 Konsolidiertes Reporting
Ziel des konsolidierten Reportings ist die Bereitstellung der relevanten Reporting-Inhalte in einem einheitlichen Verfahren sowie deren strukturierte Übermittlung an den SBV.
Der konsolidierte Report setzt sich aus insgesamt acht Einzelreports zusammen. Die Inhalte des Reports werden durch die in der folgenden Tabelle referenzierten Kapitel bzw. Dokumente definiert. Werden für einen Einzelreport keine Inhalte definiert, bzw. sind diese für den jeweiligen Produkttyp nicht relevant, muss der entsprechende Einzelreport nicht übermittelt werden.
Tabelle 2: Tab_Betr_TIP_025 Bestandteile des konsolidierten Reportings Der Gesamtverantwortliche TI kann bei Vorgängen der Priorität 1 „kritisch“ und 2 „hoch“ mit (produkt-)übergreifender Auswirkung eine Taskforce zur Behebung des Vorgangs bilden. Diese wird aus mehreren der am Betriebsprozess beteiligten TI-ITSM-Teilnehmern zusammengesetzt.
GS-A_3922 - Mitwirkung bei Taskforces
TI-ITSM-Teilnehmer MÜSSEN bei Aufforderung durch den Gesamtverantwortlichen TI an einer Taskforce zur Behebung von übergreifenden Vorgängen mit der Priorität 1 oder 2 teilnehmen, der Taskforce gemäß der zeitlichen Vorgabe der Aufforderung beitreten, die Lösungsfindung und die Erstellung des Abschlussberichtes unterstützen.
[<=]
3 Incident Management
Das Incident Management verantwortet die schnellstmögliche Beseitigung von Störungen in der TI bzw. die Schaffung eines Workarounds (Umgehungslösung) für eine aufgetretene Störung in allen Betriebsumgebungen. Die Suche nach der Ursache von wiederkehrenden Störungen (die sogenannte Root-Cause-Analyse) wird in diesem Fall im Prozess Problem Management erfolgen.
Wesentliche Aufgabe des Incident Managements ist die:
- gleichartige Behandlung aller übergreifenden Incidents;
- lückenlose Übergabe von Informationen zu übergreifenden Incidents zwischen den betroffenen TI-ITSM-Teilnehmern.
Es werden keine normativen Vorgaben zum lokalen Incident Management der TI-ITSM-Teilnehmer gemacht.
3.1 Begriffsbestimmungen
3.1.1 Übergreifender Incident
Ein übergreifender Incident liegt vor, wenn
- zur Bewältigung mehrere der am Betriebsprozess beteiligten TI-ITSM-Teilnehmer involviert werden müssen oder
- ein im Verantwortungsbereich des TI-ITSM-Teilnehmers festgestellter lokaler Incident die Kriterien gemäß GS-A_3884 erfüllt; die lokale Kategorisierung sollte die übergreifende Bedeutung des Incidents anzeigen (mit Priorität 1 oder 2) oder
- der Service des TI-ITSM-Teilnehmers nicht oder nicht im Rahmen der vereinbarten SLAs gemäß [gemSpec_Perf] erbracht werden kann oder
- der Service als Unterstützungsservice den Service eines anderen TI-ITSM-Teilnehmers negativ beeinträchtigt.
Zur Bearbeitung des übergreifenden Incidents muss sichergestellt sein, dass an den Schnittstellen zwischen den Prozessbeteiligten eine konsistente Kommunikation, auf Grundlage der Dokumentation des übergreifenden Incidents erfolgt.
Incidents, auf die diese Definition nicht zutrifft, sind lokale Incidents und werden im Rahmen des lokalen Incident-Prozesses des TI-ITSM-Teilnehmers verarbeitet.
3.2 Prozessdurchführung Incident Management
3.2.1 Übergreifenden Incident erfassen und qualifizieren
3.2.1.1 Übergreifenden Incident erfassen
Erlangt ein TI-ITSM-Teilnehmer Kenntnis über eine Servicestörung bzw. einen vom erwarteten Betriebsverhalten abweichenden Service muss er auf Basis der GS-A_3876 eine Vorprüfung vornehmen.
GS-A_3876 - Prüfung auf übergreifenden Incident
TI-ITSM-Teilnehmer MÜSSEN jeden gemeldeten Incident dahingehend prüfen, ob es sich um einen übergreifenden Incident handelt, für den zur Incident-Lösung die serviceverantwortlichen und/oder lösungsunterstützenden TI-ITSM-Teilnehmer und/oder der Gesamtverantwortliche TI herangezogen werden sollen. [<=]
Sofern die Prüfung ergibt, dass ein übergreifender Incident vorliegt muss dieser gemäß GS-A_3886 im TI-ITSM-System erfasst werden. Pflichtangaben für die Ersterfassung werden vom TI-ITSM-System vorgegeben.
3.2.1.2 Übergreifenden Incident qualifizieren
GS-A_5449 - Typisierung eines übergreifenden Incidents als „sicherheitsrelevant“
TI-ITSM-Teilnehmer MÜSSEN einen Vorgang als „sicherheitsrelevant“ markieren, wenn die Vertraulichkeit bzw. Integrität eines schutzbedürftigen Informationsobjektes gefährdet ist.
[<=]
GS-A_5450 - Typisierung eines übergreifenden Incidents als „datenschutzrelevant“
TI-ITSM-Teilnehmer MÜSSEN eine Störung als „datenschutzrelevant“ markieren, wenn personenbezogene Daten gemäß Art. 4 Nr. 1 DSGVO betroffen sind.
[<=]
GS-A_4125 - TI-Notfallerkennung
TI-ITSM-Teilnehmer MÜSSEN potenzielle TI-Notfälle im operativen Betrieb im Rahmen des Incident Managements feststellen. Potenzielle TI-Notfälle werden als Incidents der Priorität 1 mit Kennzeichnung „TI-Notfall“ klassifiziert.
[<=]
Gemeldete TI-Notfälle werden zuerst als potenziell aufgenommen, und es gilt Kapitel 12.3.5.1 und 12.3.5.2.
GS-A_3884 - Festlegung von Dringlichkeit und Auswirkung von übergreifenden Incidents
TI-ITSM-Teilnehmer MÜSSEN zur Ermittlung der Priorität eines übergreifenden Incidents die beiden Faktoren „Dringlichkeit“ und „Auswirkung“ festlegen.
Tabelle 1: Tab_Betr_TIP_026 INC – Festlegung der Dringlichkeit
|
|
|
||||||
Hoch |
|
|
|
|||||
Mittel |
|
|
|
|||||
Niedrig |
|
|
|
|||||
|
|
|
||||||
|
|
|
||||||
|
|
|
||||||
|
|
|
||||||
|
|
|
||||||
Neben den inhaltlichen Aspekten, die primär in den jeweiligen ITSM-Prozessen bzw. -Prozesskapiteln geregelt werden, gelten für das konsolidierte Reporting, übergreifende Regelungen, die insbesondere die Struktur, die Reportingfrequenz, als auch die Übermittlung des konsolidierten Reports an den SBV regeln:
GS-A_4092 - Übermittlung des konsolidierten Reports
ITSM-TI-Teilnehmer MÜSSEN folgende Reports im Rahmen des konsolidierten Reports per E-Mail an den SBV oder den durch den SBV benannten Empfänger bzw. Funktionspostfächer übermitteln: Service Level Report, Performance Report, Change Report, Configuration Report, Incident Report, Problem Report, Datenschutz Report, Security Report. [<=]
GS-A_4093 - Dateinamen der Einzelreports im konsolidierten und Ad-hoc Reporting
ITSM-TI-Teilnehmer MÜSSEN die an den SBV zu übermittelnden Einzelreports innerhalb des konsolidierten Reportings sowie den zu übermittelnden Ad-hoc Report eineindeutig mit folgenden Dateinameninhalten
o Jahr und dem Monat (JJJJMM)
o der Reportart, Konsolidiertes Reporting (KR) oder Ad-hoc Report (AR)
o der Bezeichnung des Einzelreports bei konsolidiertem Reporting (KR) oder inhaltliche Zuordnung beim Ad-hoc-Report (SL, PERF, CHG, CM, INC, PRO, DSM, ISM), wobei der Konfiguration-Report (CM) wie folgt zu differenzieren ist
• CMPO für Konfiguration-Report zum CI „Produktverantwortliche Organisation“
• CMPR für Konfiguration-Report zum CI „Produkt“
o Teilnehmer-ID des ITSM-TI-Teilnehmers bzw. weiterer Beteiligter im Betrieb der TI (TID)
o der fortlaufenden Versionsnummer (VNR) (Hochzählung der Versionsnummer bei Veränderung der übermittelten Daten zum vorherigen Einzelreport oder zum vorherigen Ad-hoc Report)
und nach dem Schema für Konsolidiertes Reporting (KR) „JJJJMM-KR-SL/PERF/CHG/CMPO/CMPR/INC/PRO/DSM/ISM-TID-VNR“ erstellen. (Beispiel: 201209-KR-SL-12345-01) oder nach dem Schema für Ad-hoc Report (AR) „JJJJMM-AR- SL/PERF/CHG/CMPO/CMPR/INC/PRO/DSM/ISM-TID-VNR“ erstellen. (Beispiel: 201209-AR-SL-12345-01 oder 201210-AR-PERF-12345-01). [<=]
2.3.2 Ad-hoc Reporting
Neben der regelmäßigen Zusendung des konsolidierten Reportings kann der SBV Ad-hoc, also außerplanmäßige, Reports anfordern. Dabei kann der Servicebetriebsverantwortliche (SBV) oder der Gesamtverantwortliche der TI (GTI) auf den vorhandenen Vorgangsdaten-/Kennzahlenpool aus den Einzelreports des konsolidierten Reportings zurückgreifen oder andere Kennzahlen (innerhalb eines zumutbaren Umfangs für den ITSM-TI-Teilnehmer) abfragen. Entsteht die Notwendigkeit zur Erhebung weiterer Messgrößen, werden diese gemeinsam mit den betroffenen ITSM-TI-Teilnehmern individuell abgestimmt.
GS-A_4095 - Übermittlung von Ad-hoc Reports
ITSM-TI-Teilnehmer MÜSSEN den vom SBV angeforderten Ad-hoc Report per E-Mail an den SBV oder den durch den SBV benannten Empfänger übermitteln.
[<=]
GS-A_4096 - Weiterbearbeitbarkeit und Auswertbarkeit des Ad-hoc Reports
ITSM-TI-Teilnehmer MÜSSEN den vom SBV angeforderten Ad-hoc Report in einem weiterbearbeitbaren und auswertbaren Format an den SBV oder den durch den SBV benannten Empfänger versenden.
[<=]
GS-A_4097 - Dateiformat und -struktur des Ad-hoc Reports
ITSM-TI-Teilnehmer SOLLEN, sofern nicht abweichend vereinbart, für den angeforderten Ad-hoc Report in dem vom SBV vorgegebenen Dateiformat und vorgegebenen Dateistruktur verwenden. Dateiformat und Dateistruktur richten sich dabei nach den Vorgaben für Struktur und Format des konsolidierten Reportings.
[<=]
GS-A_4099 - Zulieferungszeit des Ad-hoc Reports an den SBV oder GTI
ITSM-TI-Teilnehmer MÜSSEN den Ad-hoc Report, sofern nicht abweichend mit dem SBV vereinbart, unverzüglich an den SBV versenden. [<=]
2.3.3 Service Level Requirements (SLR)
GS-A_4094 - Service Level Requirements Serviceerbringung
ITSM-TI-Teilnehmer MÜSSEN innerhalb des konsolidierten Reportings einmal im Monat spätestens zum 5. Werktag des Folgemonats die Reports an den jeweiligen SBV oder den durch den SBV benannten Empfänger übermitteln. Service Level werden im Betriebskonzept [gemKPT_Betr] ausgeprägt.
[<=]
2.4 Auditierung von ITSM-TI-Teilnehmern
Es besteht die Notwendigkeit anlassbezogene Audits durchzuführen. Audits werden durchgeführt, wenn die Prozesskommunikation zwischen den am Betrieb beteiligten ITSM-TI-Teilnehmern nachhaltig gestört bzw. die Serviceerbringung gegenüber dem Anwender bzw. Versicherten gefährdet ist.
Die Audits dienen der Prüfung der korrekten Umsetzung der Richtlinien insbesondere mit dem Ziel Schnittstellen-/Prozessprobleme zwischen ITSM-TI-Teilnehmern zu identifizieren. Die Erkenntnisse der anlassbezogenen Audits können zur Optimierung der Richtlinien führen, um die Reibungsverluste im Zusammenspiel der ITSM-TI-Teilnehmer untereinander zu minimieren.
GS-A_4855 - Auditierung von ITSM-TI-Teilnehmern
ITSM-TI-Teilnehmer MÜSSEN Auditierungen durch den zuständigen SBV sowie den GTI zur Überprüfung der Einhaltung von Produktvorgaben ermöglichen und angemessen unterstützen. Das Audit darf im Rahmen der Prüfungsdurchführung nicht gegen gesetzliche Vorgaben verstoßen, denen ITSM-TI-Teilnehmer unterliegen. Umfang und Zeitpunkt des Audits hat der GTI bzw. der zuständige SBV mit dem zuständigen SV abzustimmen. Der zuständige SV muss der Durchführung des Audits zustimmen. [<=]
2.5 Konvention zur Übermittlung von Prozessdaten
GS-A_5200 - Konvention zu Dateinamen zur Übermittlung von Incident- und Problemdokumentationen
1. Für die Zusendung der CSV- Dateien gilt:Die ITSM-TI-Teilnehmer MÜSSEN die Namen der CSV-Dateien wie folgt bilden:<Zeitstempel>_<ITSM-Prozess>_<Referenznummer>_<Meldungstyp>_<TID>.csv
1. <Zeitstempel> Zeitpunkt der Übermittlung YYYYMMDDThhmmss+/-hh (gemäß ISO 8601)
2. <ITSM-Prozess> Bezeichnung des zugrundeliegenden ITSM-Prozesses: „INC“ für Incidentmanagement bzw. „PRO“ oder Problemmanagement
3. <Referenznummer> fortlaufende Nummer der Dokumentation des zugrundeliegenden Incidents oder Problems gemäß GS-A_3880 oder Problems gemäß GS-A_3961
4. <Meldungstyp>
5.
a. „WE“: Weiterleitung im Sinne der funktionalen Eskalation mit Übergang der Lösungsverantwortung
b. „AN“ Annahme des übergreifende Incidents oder Problems gemäß GS-A_3904 und übergreifenden Problemen gemäß GS-A_3975
c. „AL“ Ablehnung von übergreifen Incidents oder Problems gemäß GS-A_3905 und übergreifendenden Problemen gemäß GS-A_3976 und GS-A_3982
d. „RQ“: Anfrage ohne Übergang der Lösungsverantwortung
e. „ES“: Eskalation an den SBV oder GTI
f. „SI“: Statusinformation an den SBV oder GTI
g. „NI“ Nachreichen von Informationen zum übergreifenden Incident / Problem- in beide Richtungen – siehe Beispiele
6.
7. <TID> Teilnehmer-ID des Service Providers der aktuell den Versand der strukturierten Information vornimmt / TID des E-Mail-Absenders
2. Die Nutzung der Webservice-Schnittstelle erfolgt durch eine Kopplung der lokalen Ticket-/Informationssysteme mit der ZID, der alleinige Austausch von XML-Dateien wird nicht unterstützt. Die ITSM-TI-Teilnehmer arbeiten dabei nach dem Pull-Prinzip und fragen Daten zyklisch ab. Aktiv werden von der ZID keine Webservices der ITSM-TI-Teilnehmer angesprochen. Die für den Aufbau des CSV-Dateinamens definierten Daten sind beim Senden als Pflichtfelder zu übermitteln. Eine Reihenfolge ist dabei nicht zu beachten. Es gelten die Vorgaben an die Webservice-Schnittelle gemäß den Tabellen Tab_Betr_TIP_040, Tab_Betr_TIP_041, Tab_Betr_TIP_042, Tab_Betr_TIP_043 (siehe Anhang C). Bei fehlerhaften oder fehlenden Angaben erfolgt als Antwort in der Webservice-Schnittstelle von der ZID eine Fehlermeldung mit Hinweis auf den/die Fehler bzw. die fehlenden Felder oder erwarteten Daten. Die Übermittlung eines neuen Incidents oder Problems, d. h. die übermittelte Incident- oder Problem-Referenznummer ist neu und in der ZID noch nicht vorhanden, kann nur mit dem Meldungstyp „WE“ (Weiterleitung) erfolgen. Weitere Beispiele werden in der Wissensdatenbank dokumentiert. 3. Für die Erfassung der Prozessdaten im Webportal gelten die Inhaltsdefinition für das übergreifende Incident Management (siehe GS-A_3882) und für das übergreifende Problem Management (siehe GS-A_4000). Das Webportal der ZID stellt darüber hinaus sicher, dass für die Nutzer des Webportals die notwendigen Prozessdaten aller notwendigen Meldungstypen sowie Eingangsbestätigungen durch die ZID selbst erzeugt werden, d.h. es ist keine Erzeugung bspw. von Statusinformationen (Meldungstyp SI) parallel zur ZID notwendig. Ebenso werden durch das Webportal die weiteren für die Prozessverarbeitung notwendigen Daten wie die Referenznummer gemäß GS-A_3880 bzw. GS-A_3961 erzeugt. Die im Webportal befüll- und verarbeitbaren Daten entsprechen grundlegend denen in den CSV-Dateien. Die konkrete Umsetzung und Darstellung des Webportals kann als Beispielbeschreibung der Wissensdatenbank entnommen werden. [<=]
Um doppelte Einträge im Worklog zu verhindern und damit die Entwicklung eines Ticketverlaufes möglichst einfach nachzuvollziehen, ist grundsätzlich zu empfehlen, ausschließlich die letzte Änderung des Worklogs aus dem lokalen ITSM-System in das übergreifende ITSM zu übermitteln.
Incident Management:
Tabelle 3: Tab_Betr_TIP_028 Übersicht Meldungstypen – Incident Management
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Problem Management:
Tabelle 4: Tab_Betr_TIP_029 Übersicht Meldungstypen – Problem Management
Tabelle 2: Tab_Betr_TIP_027 INC – Festlegung von Auswirkung
|
|
Beschreibung |
|||||
|
|
|
|||||
|
|
|
|||||
|
|
|
|||||
|
|
|
|||||
|
|
|
|||||
|
|
|
|||||
|
|
|
|||||
GS-A_5248 - Konventionen zur Struktur von Prozessdaten
• Für CSV- Dateien gilt :
ITSM-TI-Teilnehmer MÜSSEN die Struktur der CSV-Dateien für Statusinformationen und Eskalationen sowie der Prozesskommunikation nach den Vorgaben aus [RFC4180] und den nachfolgenden Konkretisierungen bauen:
• In der ersten Zeile sind die Feldnamen (Header) und ab der zweiten Zeile sind die zu übermittelnden Werte enthalten (Datensatz). Diese sind durch Semikolon (ASCII-59) zu trennen.
• Zeichensatzkodierung UTF-8 ohne ByteOrderMark liefern.
• Sämtliche Feldinhalte innerhalb der CSV-Datei (d.h. die Inhalte der Datensätze UND die Inhalte des Headers) sind in ASCII-34-Zeichen zu setzen (Quoting).
• Leere Felder müssen quotiert werden.
• Innerhalb der Feldinhalte ist jedes ASCII-34-Zeichen durch ASCII-39-Zeichen zu ersetzen.
• Zeilendelimiter ist die Zeichenfolge ASCII-13-Zeichen (Carriage return), ASCII-10-Zeichen (Line feed).
• Comments sind nicht zugelassen.
• Leere Zeilen sind nicht zugelassen.
• Leerzeichen am Rand von Feldinhalten werden nicht ignoriert, d.h. sie sind vom Sender zu entfernen, wenn sie nicht intendiert sind.
• Ist in einem Feldinhalt kein Zeichen enthalten, wird das als NULL-Wert, d.h. nicht gefüllter Feldwert interpretiert.
• Der auf Grundlage von Basisfeldtypen (Tabelle 6: Tab_Betr_TIP_030 Basisfeldtypen von CSV-Dateien) festgelegte Wertebereich in Spalte „Typ“ muss erfüllt werden.
• Als Basis für Datums- und Zeitformate dient die ISO-Norm 8601.
• Folgende Formate sind zu benutzen:
o für Werte innerhalb der CSV-Datei: YYYY-MM-DDThh:mm:ss±hh
o als Bestandteil eines Dateinamens: YYYYMMDDThhmmss±hh
• Jede Datei darf im Rahmen der Prozesskommunikation nur einen Datensatz enthalten. Reports dürfen mehrere Datensätze enthalten.
• Für den Webservice gelten die gleichen Konventionen zur Struktur und das Webservice Schemata gemäß dem Anhang C.
• Für die Erfassung der Prozessdaten im Webportal werden die Konventionen im entsprechenden Formular dargestellt.
[<=]
[<=]
Die Ermittlung der Priorität erfolgt durch das TI-ITSM-System nach der Vorschrift in der Tab_Betr_TIP_009: Prioritätenmatrix.
Tabelle 3: Tab_Betr_TIP_009 INC – Prioritätenmatrix
Dringlichkeit |
Auswirkung |
|||
|
Hoch |
Mittel |
Niedrig |
|
Hoch |
1 |
2 |
3 |
|
Mittel |
2 |
3 |
4 |
|
Niedrig |
3 |
4 |
4 |
|
3.2.1.3 Serviceverantwortung für übergreifenden Incident zuweisen
Der Melder ermittelt über das betroffene bzw. vermutete verursachende Produkt den Serviceverantwortlichen. Dabei wird er vom TI-ITSM-System durch eine kontextsensitive Vorschlagsliste unterstützt. Durch Auswahl des entsprechenden TI-ITSM-Teilnehmers wird die Weiterleitung des Incidents ermöglicht und die übergreifende Bearbeitung initiiert.
Zur Identifikation des richtigen serviceverantwortlichen TI-ITSM-Teilnehmers werden innerhalb des Betriebskonzepts [gemKPT_Betr] die Leistungs- und Supportmodelle definiert. Zudem werden in der zentralen Wissensdatenbank des TI-ITSM-Systems Kontaktinformationen von TI-ITSM-Teilnehmern bereitgestellt.
3.2.2 Serviceverantwortung für übergreifenden Incident prüfen
Der Empfänger des übergreifenden Incidents muss bei Erhalt der Meldung seine (vermutete) Verantwortung verifizieren:
GS-A_3902 - Prüfung auf Serviceverantwortung
TI-ITSM-Teilnehmer MÜSSEN jeden an sie gerichteten übergreifenden Incident dahingehend prüfen, ob der Incident in der eigenen Serviceverantwortung liegt.
[<=]
GS-A_3904 - Annahme eines übergreifenden Incidents
TI-ITSM-Teilnehmer MÜSSEN einen übergreifenden Incident annehmen, wenn sie die Serviceverantwortung haben.
[<=]
GS-A_3905 - Ablehnung eines übergreifenden Incidents
TI-ITSM-Teilnehmer MÜSSEN die Ablehnung eines übergreifenden Incidents mit einer qualifizierten Rückmeldung an den meldenden TI-ITSM-Teilnehmer versehen, aus der nachvollziehbar zu entnehmen ist, warum keine Bearbeitung erfolgen kann.
[<=]
3.2.3 Lösung für übergreifenden Incident erstellen
Der serviceverantwortliche TI-ITSM-Teilnehmer beginnt unverzüglich mit der Bearbeitung der Störung. Er wird im TI-ITSM-System die Lösung und die dafür notwendigen Aktivitäten nachvollziehbar dokumentieren. Dadurch können die Erkenntnisse für Diagnosen und Lösungen im Rahmen des Problem Managements genutzt werden.
GS-A_3907 - Lösung von übergreifenden Incidents
Der serviceverantwortliche TI-ITSM-Teilnehmer MUSS nach erfolgter Erstellung bzw. Annahme eines übergreifenden Incidents unverzüglich mit der Incident-Bearbeitung beginnen und – innerhalb der vereinbarten Lösungszeiten – eine Lösung für den Incident herbeiführen und diesen beheben.
[<=]
3.2.4 Unterstützung für einen übergreifenden Incident einfordern
Während der Lösungsfindung für einen übergreifenden Incident kann der serviceverantwortliche TI-ITSM-Teilnehmer andere TI-ITSM-Teilnehmern um Unterstützung bitten.
Der serviceverantwortliche TI-ITSM-Teilnehmer wechselt durch die Anfrage zur Lösungsunterstützung nicht. Der Empfänger dieser Anfrage wird den übermittelten Vorgang hinsichtlich seiner zu leistenden Lösungsunterstützung prüfen.
GS-A_5587 - Ablehnung der Lösungsunterstützung bei einem übergreifenden Incident
TI-ITSM-Teilnehmer, die die Lösungsunterstützung eines übergreifenden Incidents ablehnen, MÜSSEN dies mit einer qualifizierten Rückmeldung an den anfragenden TI-ITSM-Teilnehmer durchführen, aus der nachvollziehbar zu entnehmen ist, warum keine Lösungsunterstützung möglich ist.
[<=]
3.2.5 Lösung für einen übergreifenden Incident prüfen
Nachdem der serviceverantwortliche TI-ITSM-Teilnehmer den übergreifenden Incident gelöst hat, wird der meldende TI-ITSM-Teilnehmer über das TI-ITSM-System informiert und zur Prüfung aufgefordert, sofern er den Incident nicht gegen sich selbst gestellt hat.
GS-A_5400 - Prüfung der Lösung durch den Melder eines übergreifenden Incidents
Der meldende TI-ITSM-Teilnehmer MUSS die ihm vorgelegte Lösung des übergreifenden Incidents prüfen und sein Ergebnis dem serviceverantwortlichen TI-ITSM-Teilnehmer innerhalb der Verifikationsfrist (entsprechend [gemKPT_Betr#TIP1-A_7265]) über das TI-ITSM-System mitteilen.
[<=]
GS-A_5250 - Ablehnung der Lösung eines übergreifenden Incidents
Wird die Lösung eines Incidents durch den meldenden TI-ITSM-Teilnehmer abgelehnt MUSS der serviceverantwortliche TI-ITSM-Teilnehmer den übergreifenden Incident erneut bearbeiten, die Messung der Lösungszeit wird dann fortgesetzt.
[<=]
3.2.6 Übergreifenden Incident schließen
Nach erfolgreicher Verifikation erfolgt die vollständige Schließung des Incidents durch den serviceverantwortlichen TI-ITSM-Teilnehmer.
GS-A_3888 - Verifikation vor Schließung eines übergreifenden Incident
TI-ITSM-Teilnehmer MÜSSEN vor der Schließung einer übergreifenden Incident-Dokumentation sicherstellen, dass der Incident behoben ist.
Ist der Incident nicht behoben, dann ist der bestehende Incident weiterzubearbeiten. Es beginnt keine erneute Lösungszeit.
Liegt nach Ablauf der Verifikationsfrist (entsprechend [gemKPT_Betr#TIP1-A_7265]) keine Rückmeldung durch den meldenden TI-ITSM-Teilnehmer vor, KANN der übergreifende Incident geschlossen werden.
[<=]
GS-A_3889 - Schließung eines übergreifenden Incidents
Serviceverantwortliche TI-ITSM-Teilnehmer MÜSSEN nach verifizierter Behebung der Störung die Dokumentation eines übergreifenden Incidents abschließend bearbeiten und diesen Incident schließen.
[<=]
3.3 Abweichungen im Prozessablauf
3.3.1 Übergreifenden Incident eskalieren
Die Koordination der Vorgangsbearbeitung erfolgt i.d.R. durch die betroffenen TI-ITSM-Teilnehmer in Eigenverantwortung. Kommt es zu Hindernissen im Prozessablauf, steht den TI-ITSM-Teilnehmern das Instrument der Eskalation an den Gesamtverantwortlichen TI nach den Vorgaben der GS-A_3920 zur Verfügung.
3.3.2 Mitwirkung in einer Taskforce
TI-ITSM-Teilnehmer können durch den Gesamtverantwortlichen TI zur Mitwirkung in einer Taskforce gemäß GS-A_3922 aufgerufen werden. Diese Taskforce ist ein Instrument zur Lösung von kritischen Incidents der Priorität 1 oder 2.
Die prozessübergreifende Regelung zur Eskalation und Mitwirkung in einer Taskforce erfolgt in Kapitel 2.4 Zentrale Koordinierung durch den Gesamtverantwortlichen TI.
3.4 Verfahren für die Lösung eines Security-Incidents
Security Incidents werden wie alle anderen Incidents behandelt. Es erfolgt ggf. eine reduzierte bzw. eingeschränkte Kommunikation. Die Entscheidung darüber führt der Gesamtverantwortliche TI unter Einbeziehung beratender Fachexperten herbei.
3.5 Verfahren für die Lösung eines Incidents mit Datenschutzrelevanz
Incidents mit Datenschutzrelevanz werden wie alle anderen Incidents behandelt. Es erfolgt ggf. eine reduzierte bzw. eingeschränkte Kommunikation. Die Entscheidung darüber führt der Gesamtverantwortliche TI unter Einbeziehung beratender Fachexperten herbei.
3.6 Verfahren für die Lösung von Notfall-Incidents
Wird ein Incident als Notfall qualifiziert, greift das in diesen Richtlinien beschriebene Verfahren zur Bewältigung von TI-Notfällen.
Die Dokumentation des vom Gesamtverantwortlichen TI festgestellten Notfalls erfolgt im Notfallmanagement. Ein entsprechender Verweis erfolgt im zugehörigen Incident-Ticket.
3.7 Service Level Requirements
Die Ermittlung der Service Level Reaktionszeit, Qualifikationszeit, Lösungszeit, erfolgt direkt im TI-ITSM-System. Die Ausgestaltung der Service Level erfolgt im Betriebskonzept [gemKPT_Betr].
GS-A_3911 - Service Level Requirements im übergreifenden Incident Management
Die TI-ITSM-Teilnehmer MÜSSEN die Servicezeiten gemäß TIP1-A_7265 [gemKPT_Betr] im übergreifenden Incident Management einhalten.
[<=]
4 Problem Management
Der Problem Management Prozess verantwortet die nachhaltige Stabilisierung aller TI-Betriebsumgebungen, der RU, TU und PU. Die Ursachen wiederkehrender Störungen werden vom Problem Management analysiert, bewertet und – falls technisch und wirtschaftlich machbar – durch neue stabile Lösungen beseitigt.
Im Gegensatz zum wirkungsorientierten Incident Management, bei dem es um schnellstmögliche Wiederherstellung beeinträchtigter TI-Services geht, arbeitet das Problem Management ursachenorientiert, d.h. der Prozess zielt auf eine definitive, nachhaltige Beseitigung von Störungsursachen.
Um zwischen den verschiedenen TI-ITSM-Teilnehmern sicherzustellen, dass
- Probleme gemäß ihrer Auswirkungen eine konsistent gleiche Behandlung erfahren,
- im Rahmen der Unterstützung der Problembearbeitung, sofern mehrere TI-ITSM-Teilnehmer involviert werden müssen, die Übergabe von Problemen untereinander reibungslos und nachvollziehbar gewährleistet wird,
- eine zuverlässige Lösung von aufgetretenen Problemen anbieterübergreifend gewährleistet ist,
ist durch TI-ITSM-Teilnehmer ein übergreifendes Problem Management zu etablieren.
4.1 Begriffsbestimmungen
4.1.1 Übergreifendes Problem
Ein übergreifendes Problem liegt vor, wenn
- zu seiner Ursachenanalyse und Lösung mehrere der am Betriebsprozess beteiligten TI-ITSM-Teilnehmer involviert werden müssen oder
- ein im Verantwortungsbereich des TI-ITSM-Teilnehmers festgestelltes lokales Problem die Kriterien gemäß GS-A_3964 erfüllt; die lokale Kategorisierung sollte die übergreifende Bedeutung des Problems anzeigen (mit Priorität 1 oder 2) oder
- ein Koordinationsbedarf durch den Gesamtverantwortlichen der TI festgestellt wird.
Zur Bearbeitung des übergreifenden Problems muss sichergestellt sein, dass an den Schnittstellen zwischen den Prozessbeteiligten eine konsistente Kommunikation, auf Grundlage der Dokumentation des übergreifenden Problems erfolgt.
Problems, auf die diese Definition nicht zutrifft, sind lokale Problems und werden im Rahmen des lokalen Problem-Prozesses des TI-ITSM-Teilnehmers verarbeitet.
4.2 Prozessdurchführung Problem Management
4.2.1 Übergreifendes Problem erfassen und qualifizieren
4.2.1.1 Übergreifendes Problem erfassen
GS-A_3958 - Problemerkennung durch TI-ITSM-Teilnehmer
TI-ITSM-Teilnehmer MÜSSEN geeignete Maßnahmen implementieren, um proaktiv und reaktiv eine Problemerkennung zu ermöglichen.
[<=]
GS-A_5249 - Reservierte Zeichen in den Prozessdaten3959 - Prüfung auf übergreifendes Problem
ITSM-TI-Teilnehmer MÜSSEN die in Tabelle 5: Tab_Betr_TIP_049 reservierte Zeichen Ersetzungstabelle benannten Zeichenketten in den [String] Basisfeldtypen der zu übermittelnden Prozessdaten der Incident- und Problemdokumentationen vermeiden und entsprechend ersetzen.
[<=]
Tabelle 5: Tab_Betr_TIP_049 reservierte Zeichen ErsetzungstabelleTI-ITSM-Teilnehmer MÜSSEN jedes erkannte Problem dahingehend prüfen, ob es sich um ein übergreifendes Problem handelt, für das zur Problem-Lösung die serviceverantwortlichen und/oder lösungsunterstützenden TI-ITSM-Teilnehmer sowie der Gesamtverantwortliche TI herangezogen werden sollen.
[<=]
Sofern die Prüfung ergibt, dass ein übergreifendes Problem vorliegt muss dieses gemäß GS-A_3886 im TI-ITSM-System erfasst werden. Pflichtangaben für die Ersterfassung werden vom TI-ITSM-System vorgegeben.
4.2.1.2 Übergreifendes Problem qualifizieren
GS-A_3964 - Festlegung von Dringlichkeit und Auswirkung von übergreifenden Problems
TI-ITSM-Teilnehmer MÜSSEN zur Ermittlung der Priorität eines übergreifenden Problems die beiden Faktoren „Dringlichkeit“ und „Auswirkung“ festlegen.
Tabelle 4: Tab_Betr_TIP_102 PRO – Festlegung von Dringlichkeit
|
|
|
||||||||
|
|
|
||||||||
|
|
|
||||||||
Hoch |
|
|
|
|||||||
|
|
|
||||||||
|
|
|
||||||||
2.5.1 Basisfeldtypen von Prozessdaten
Tabelle 6 definiert Basisfeldtypen, die in konkreten Definitionen fachlicher Tabellen referenziert werden. In der Definition der fachlichen Tabellen können diese Basisfeldtypen weiter durch Constraints konkretisiert werden, z. B. durch Einschränkung auf eine fachlich definierten Wertemenge.
Tabelle 6: Tab_Betr_TIP_030 Basisfeldtypen von CSV-Dateien
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3 Service Level Management (SLM)
Mit Hilfe des Service Level Management (SLM) werden die Service Level über alle Betriebseinheiten definiert, kontrolliert und optimiert.
Ziele des übergreifenden SLM sind:
o die vereinbarten Service Level zu messen, um die Sicherstellung der aktuell vereinbarten (technischen und prozessualen) Qualität zu gewährleisten.
o die gemessenen Service Level zu analysieren und zu optimieren, um zukünftig die Sicherstellung der IT-Service-Qualität und Performance - möglichst effizient - zu gewährleisten.
Abbildung 1: SLM – Prozessausschnitt „Service Level Management“ veranschaulicht den für die ITSM-TI-Teilnehmer relevanten Prozessausschnitt.
Abbildung 1: SLM – Prozessausschnitt „Service Level Management“
3.1 Betrachtungsgegenstand des übergreifenden SLM
Grundlage und Arbeitsmittel für die Aufgabenwahrnehmung des Service Level Managements durch den SBV und den GTI sowie der damit verknüpften Zielerreichung ist der Service Level Report des konsolidierten Reportings (siehe Kapitel 2.3.1 „Konsolidiertes Reporting“).
Betrachtungsgegenstand des übergreifenden SLM sind daher die Regelungen, welche zum Reporting der Service Level im Rahmen des Service Level Reportings festzulegen sind.
3.2 Begriffserläuterungen
3.2.1 Service Level Requirements
Service Level Requirements enthalten die inhaltlichen, als auch schematischen Anforderungen (Qualitätsdimension, Beschreibung der Qualitätsdimension, Ausprägungstyp) für die durch ITSM-TI-Teilnehmer zu messenden Service Level.
Die in der Richtlinie definierten, durch ITSM-TI-Teilnehmer zu messenden Service Level Requirements werden im Betriebskonzept [gemKPT_Betr] ausgeprägt, mit Werten hinterlegt und bilden damit die vollständigen, durch ITSM-TI-Teilnehmer zu erreichenden Service Level ab.
Hinweis:
Die Service Level IDs wurden im Zuge der Weiterentwicklung der Betriebsdokumentation von ORS1 auf OPB optimiert: Eineindeutige Service Level IDs, die die prioritätsbestimmte Ausprägung der SL IDs berücksichtigen und die Tool Implementierung vereinfachen. Eine Referenztabelle der „ORS1 Service Level IDs“ zu den in OPB geltenden findet sich in Anhang C.
3.3 Grundsätze des übergreifenden SLM
Die nachfolgenden Grundsätze bilden die übergeordneten Regelungen des übergreifenden Service Level Managements für ITSM-TI-Teilnehmer.
3.3.1 Gliederung des SLM in Service Level Cluster
Innerhalb des Service Level Managements wird in drei verschiedene Service Level Cluster unterschieden:
• Service Level Performance - hierunter werden alle zu messenden technischen Kennzahlen (bspw. hinsichtlich Bearbeitungszeit, Durchsatz und Verfügbarkeit) zusammengefasst.
Dabei wird die Service Level Performance im Betriebskonzept [gemKPT_Betr] nach folgendem Schema gebildet:
Tabelle 7: Tab_Betr_TIP_023 SLM – Service Level "Performance"
Tabelle 5: Tab_Betr_TIP_103 PRO – Festlegung von Auswirkung
Auswirkung |
Beschreibung |
||||||||
Hoch |
|
||||||||
|
|
|
|
|
|||||
Niedrig |
|
|
|
|
|
||||
• Service Level Prozess - hierunter werden alle prozessbezogen zu messenden Service Level Requirements der übergreifenden ITSM-Prozesse mit Fokus auf die Prozessqualität (bspw. Reaktionszeit) zusammengefasst.
In dem vorliegenden Dokument sind diese mit „Prozess“ gekennzeichneten SLRs
• für das Incident Management den Kapiteln 8.4.8 „Service Level Requirements (SLR)“ und 8.5.9 „Service Level Requirements (SLR)“ zu entnehmen,
• für das Problem Management den Kapiteln 9.4.8 „Service Level Requirements (SLR)“, 9.5.4 „Service Level Requirements (SLR)“ und 9.6.8 „Service Level Requirements (SLR)“ zu entnehmen,
• für das Change Management dem Kapitel 5.5 „Service Level Requirements (SLR)“ zu entnehmen.
• Service Level Serviceerbringung - hierunter werden alle qualitativen, servicebezogen zu messenden Service Level Requirements der übergreifenden ITSM-TI-Prozesse mit dem Schwerpunkt auf die Serviceerbringung (bspw. Rufbereitschaft) zusammengefasst.
In dem vorliegenden Dokument sind diese mit „Serviceerbringung“ gekennzeichneten SLRs
• für das konsolidierte Reporting dem Kapitel 2.3.3 „Service Level Requirements (SLR)“ zu entnehmen,
• für das Incident Management den Kapiteln 8.4.8 „Service Level Requirements (SLR)“ und 8.5.9 „Service Level Requirements (SLR)“ zu entnehmen,
• für das Problem Management den Kapiteln 9.4.8 „Service Level Requirements (SLR)“, 9.5.4 „Service Level Requirements (SLR)“ und 9.6.8 „Service Level Requirements (SLR)“ zu entnehmen,
• für das Performance Management dem Kapitel 4.3.4 „Service Level Requirements (SLR)“ zu entnehmen,
• für das Notfallmanagement dem Kapitel 10.5.8 „Service Level Requirements (SLR)“ zu entnehmen.
3.4 Prozessdurchführung übergreifendes SLM
Innerhalb der jeweiligen ITSM-Prozessbeschreibungen dieses Dokumentes sind, abhängig vom Prozess, verschiedene Service Level Requirements beschrieben, die durch den ITSM-TI-Teilnehmer zu messen, zu berichten und zu optimieren sind. Da die Service Level Requirements in diesem Dokument ausschließlich die schematischen Inhalte, als Grundlage der Service Level darstellen, werden diese im Betriebskonzept [gemKPT_Betr] mit Werten hinterlegt und bilden erst damit die vollständige Anforderung als Service Level.
Während des Wirkbetriebs werden diese spezifischen, durch ITSM-TI-Teilnehmer zu messenden und zu berichtenden Requirements durch den SV fortgeschrieben und gepflegt sowie deren Einhaltung durch den SBV überwacht.
3.4.1 Messung der Service Level
GS-A_4100 - Messung der Service Level
ITSM-TI Teilnehmer MÜSSEN zur Kontrolle und Optimierung der vereinbarten Service Level alle Service Level innerhalb der Cluster „Service Level Performance“, „Service Level Prozess“ und „Service Level Serviceerbringung“ messen.
[<=]
3.4.2 Bereitstellung des Service Level Reports
GS-A_4101 - Übermittlung der Service Level Messergebnisse
ITSM-TI-Teilnehmer MÜSSEN die Service Level Messergebnisse im Rahmen des konsolidierten Reportings an die durch den SBV benannte Kommunikationsschnittstelle übermitteln.
[<=]
[<=]
4.2.1.3 Serviceverantwortung für übergreifendes Problem zuweisen
Der problemerkennende TI-ITSM-Teilnehmer ermittelt für das betroffene und verursachende Produkt den Serviceverantwortlichen. Dies wird durch das TI-ITSM-System unterstützt. Durch Auswahl des vermutlich verursachenden Serviceverantwortlichen wird die Weiterleitung des Problems ermöglicht und die übergreifende Bearbeitung initiiert.
Ein Problem kann auch dem Gesamtverantwortlichen TI zugewiesen werden, wenn die Ursache des Problems in einer unvollständigen bzw. ungenauen Spezifikation begründet wird.
Zur Identifikation des richtigen serviceverantwortlichen TI-ITSM-Teilnehmers werden innerhalb des Betriebskonzepts die Leistungs- und Supportmodelle definiert. Zudem werden im TI-ITSM-System Kontaktinformationen von TI-ITSM-Teilnehmern bereitgestellt.
4.2.2 Serviceverantwortung für übergreifendes Problem prüfen
Der Empfänger des übergreifenden Problems muss bei Erhalt der Meldung seine (vermutete) Verantwortung verifizieren.
GS-A_3975 - Prüfung auf Serviceverantwortung zum übergreifenden Problem
TI-ITSM-Teilnehmer MÜSSEN jedes an sie gerichtete übergreifende Problem dahingehend prüfen, ob das Problem in der eigenen Serviceverantwortung liegt. [<=]
GS-A_3981 - Annahme eines übergreifenden Problems
TI-ITSM-Teilnehmer MÜSSEN das übergreifende Problem annehmen, wenn sie die Serviceverantwortung haben.
[<=]
GS-A_3982 - Ablehnung eines übergreifenden Problems
TI-ITSM-Teilnehmer MÜSSEN das abgelehnte übergreifende Problem mit einer qualifizierten Rückmeldung an den meldenden TI-ITSM-Teilnehmer versehen, aus der nachvollziehbar zu entnehmen ist, warum keine Bearbeitung erfolgen kann.
[<=]
4.2.3 Lösung für übergreifendes Problem erstellen
4.2.3.1 Problem Ursachenanalyse durchführen
Der serviceverantwortliche TI-ITSM-Teilnehmer beginnt unverzüglich mit der Ursachenanalyse des Problems. Er wird im TI-ITSM-System die Ursache nachvollziehbar dokumentieren.
GS-A_3983 - Ursachenanalyse eines übergreifenden Problems durch Serviceverantwortlichen
Der serviceverantwortliche TI-ITSM-Teilnehmer MUSS nach erfolgter Erstellung bzw. Annahme eines übergreifenden Problems unverzüglich mit der Problem-Bearbeitung beginnen und – innerhalb der vereinbarten Lösungszeiten – eine Lösung für das Problem herbeiführen und dieses beheben.
[<=]
Benötigen serviceverantwortliche TI-ITSM-Teilnehmer eine TI-Testumgebung, muss dies vorab angefragt werden. Dazu stellen sie einen Service Request im TI-ITSM-System.
GS-A_3984 - Service Request zur Bereitstellung der TI-Testumgebung (RU/TU)
TI-ITSM-Teilnehmer MÜSSEN für die Nutzung (d.h. zur Anbindung) der TI-Testumgebung (RU/TU) einen Service Request im TI-ITSM-System stellen.
[<=]
4.2.3.2 Lösung für übergreifendes Problem entwickeln und implementieren
Die Lösungsentwicklung erfolgt durch den serviceverantwortlichen TI-ITSM-Teilnehmer. Dabei kann er von anderen am Prozess beteiligten TI-ITSM-Teilnehmern sowie vom Gesamtverantwortlichen TI unterstützt werden.
GS-A_3986 - Koordination bei übergreifenden Problems
Der serviceverantwortliche TI-ITSM-Teilnehmer MUSS die Koordination zwischen allen erforderlichen Lösungs- bzw. Unterstützungsbeteiligten im Rahmen der Problemlösungsentwicklung übernehmen.
[<=]
Wird für die Lösung eines Problems eine Änderung an der TI benötigt, ist diese Änderung über den Change & Release Management-Prozess anzustoßen.
GS-A_3987 - Initiierung eines Change Request
Der serviceverantwortliche TI-ITSM-Teilnehmer MUSS während der Problemlösungsentwicklung einen Change Request über das TI-ITSM-System mit Verweis auf das zugrundeliegende Problem initiieren, in dem die Durchführung von Autorisierung, Entwicklung, Test und Implementierung der Lösung dokumentiert wird.
[<=]
4.2.3.3 Stornierung oder Abbruch der Bearbeitung eines Problem-Tickets
GS-A_5377 - Durchführung einer Problemstornierung
Der serviceverantwortliche TI-ITSM-Teilnehmer KANN ein Problem stornieren, falls einer der folgenden Aspekte zutrifft:
- die ursächliche Störung, der bekannte Fehler oder die bekannte Ursache hat sich nachvollziehbar und dokumentiert erledigt;
ODER
- das Ticket wurde irrtümlich angelegt.
[<=]
GS-A_5588 - Abbruch der Problembearbeitung
Der serviceverantwortliche TI-ITSM-Teilnehmer KANN die Problembearbeitung mit Zustimmung des Gesamtverantwortlichen TI abbrechen, falls die Auswirkungen des Problems und der Aufwand zu deren Behebung in keinem wirtschaftlichen oder sicherheitsrelevanten Verhältnis zueinander stehen.
[<=]
Der Gesamtverantwortliche TI wird die Stornierung oder den Abbruch eines Problems prüfen und alle Beteiligten informieren. Bei Ablehnung muss das Problem vom serviceverantwortlichen TI-ITSM-Teilnehmer wieder in die Lösungsbearbeitung übernommen werden.
4.2.4 Lösungsunterstützung für übergreifendes Problem
Während der Erarbeitung einer Lösung für ein übergreifendes Problem kann der serviceverantwortliche TI-ITSM-Teilnehmer auf die Mitwirkung von anderen TI-ITSM-Teilnehmern angewiesen sein.
Die Unterstützungsleistung wird über das TI-ITSM-System angefordert. Die Lösungsverantwortung verbleibt beim serviceverantwortlichen TI-ITSM-Teilnehmer.
GS-A_5589 - Prüfung auf Verantwortung zur Lösungsunterstützung
TI-ITSM-Teilnehmer MÜSSEN jede an sie gerichtete Anfrage zur Lösungsunterstützung eines übergreifenden Problems dahingehend prüfen, ob sie zur Lösungsunterstützung gemäß Betriebskonzept verpflichtet sind.
[<=]
GS-A_3977 - Annahme der Verantwortung zur Lösungsunterstützung
TI-ITSM-Teilnehmer MÜSSEN die Anfrage zur Lösungsunterstützung eines übergreifenden Problems annehmen, wenn sie die gemäß TIP1-A_7266 [gemKPT_Betr] für die Servicekomponenten mitverantwortlich sind.
[<=]
GS-A_3976 - Ablehnung der Lösungsunterstützung
TI-ITSM-Teilnehmer MÜSSEN die Ablehnung der Lösungsunterstützung des übergreifenden Problems mit einer qualifizierten Rückmeldung an den serviceverantwortlichen TI-ITSM-Teilnehmer versehen, aus der nachvollziehbar zu entnehmen ist, warum keine Lösungsunterstützung erfolgen kann.
[<=]
4.2.5 Lösung für übergreifendes Problem prüfen
Nachdem der serviceverantwortliche TI-ITSM-Teilnehmer das übergreifende Problem gelöst hat, wird der problemerkennende TI-ITSM-Teilnehmer über das TI-ITSM-System informiert und zur Prüfung aufgefordert, sofern er das Problem nicht gegen sich selbst gestellt hat.
GS-A_3988 - Prüfung der Lösung durch den Melder eines übergreifenden Problems
Der meldende TI-ITSM-Teilnehmer MUSS die ihm vorgelegte Lösung des übergreifenden Problems prüfen und sein Ergebnis dem serviceverantwortlichen TI-ITSM-Teilnehmer innerhalb der Verifikationsfrist (entsprechend [gemKPT_Betr#TIP1-A_7265]) über das TI-ITSM-System mitteilen.
[<=]
GS-A_3989 - Ablehnung der Lösung eines übergreifenden Problems
Wird die Lösung eines übergreifenden Problems durch den meldenden TI-ITSM-Teilnehmer abgelehnt, MUSS der serviceverantwortliche TI-ITSM-Teilnehmer das übergreifende Problem erneut bearbeiten, die Messung der Lösungszeit wird dann fortgesetzt.
[<=]
4.2.6 Übergreifendes Problem schließen
GS-A_4102 - Dateistruktur des Service Level Reports3971 - Verifikation vor Schließung eines übergreifenden Problems
ITSM-TIServiceverantwortliche TI-ITSM-Teilnehmer MÜSSEN Service Level Messungen nach folgendem Schema (die Reihenfolge ist verbindlich) für den Service Level Report aufbereiten:vor der Schließung einer übergreifenden Problem-Dokumentation sicherstellen, dass das Problem gelöst ist.
Ist das Problem nicht gelöst, dann ist das bestehende Problem weiterzubearbeiten. Es beginnt keine erneute Lösungszeit.
Liegt nach Ablauf der Verifikationsfrist (entsprechend [gemKPT_Betr#TIP1-A_7265]) keine Rückmeldung durch den problemerkennenden TI-ITSM-Teilnehmer vor, KANN das übergreifende Problem geschlossen werden.
[<=]
Tabelle 8: Tab_Betr_TIP_002 SLM – Reportinhalte Service Level Report
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[<=] GS-A_3990 - Schließung eines übergreifenden Problems
Serviceverantwortliche TI-ITSM-Teilnehmer MÜSSEN nach verifizierter Lösung des Problems die Dokumentation des übergreifenden Problems abschließend bearbeiten und das Problem schließen.
[<=]
GS-A_4103 - Dateiformat des Service Level Reports3991 - WDB-Aktualisierung nach Schließung eines übergreifenden Problems
ITSM-TIServiceverantwortliche TI-ITSM-Teilnehmer MÜSSEN den an den SBV zu versendenden Service Level Report im CSV-Format übermitteln. nach der Behebung eines übergreifenden Problems die Wissensdatenbank der TI um die relevanten Problemlösungsinformationen aktualisieren.
[<=]
4.3 Abweichungen im Prozessablauf
ITSM-TI-Teilnehmer MÜSSEN bei den an den SBV zu versendenden Reports GS-A_5248 beachten.
[<=]
Für die Webportal-nutzenden Teilnehmer wird der Service Level Report (Prozess und Serviceerbringung) über die ZID zur Verfügung gestellt.
3.4.3 Service Review
Service Reviews werden zur Feststellung von notwendigen Optimierungsaktivitäten -sowohl auf Ebene der Vorgaben als auch auf Ebene der Umsetzung - durchgeführt. Service Reviews erfolgen bei Bedarf und werden durch den SBV einberufen. Die Art der Durchführung des Service Reviews wird durch den SBV festgelegt (bspw. Telefonkonferenz, E-Mail). Präsenztermine für ITSM-TI-Teilnehmer werden durch den SBV, soweit möglich, vermieden und nur einberufen, sofern eine Notwendigkeit hierfür besteht.
ITSM-TI-Teilnehmer, die Optimierungsaktivitäten eigenverantwortlich definiert haben, erfassen diese im Service Level Report4.3.1 Übergreifendes Problem eskalieren
Die Koordination der Vorgangsbearbeitung erfolgt i.d.R. durch die betroffenen TI-ITSM-Teilnehmer in Eigenverantwortung. Kommt es zu Hindernissen im Prozessablauf, steht den TI-ITSM-Teilnehmern das Instrument der Eskalation an den Gesamtverantwortlichen TI nach den Vorgaben der GS-A_3920 zur Verfügung.
4.3.2 Mitwirkung in einer Taskforce
TI-ITSM-Teilnehmer können durch den Gesamtverantwortlichen TI zur Mitwirkung in einer Taskforce gemäß GS-A_3922 aufgerufen werden. Diese Taskforce ist ein Instrument zur Lösung von kritischen Problems der Priorität 1 oder 2.
Die prozessübergreifende Regelung zur Eskalation und Mitwirkung in einer Taskforce erfolgt in Kapitel 2.4 Zentrale Koordinierung durch den Gesamtverantwortlichen TI.
4.4 Service Level Requirements
Die Ermittlung der Service Level Reaktionszeit und Lösungszeit, erfolgt direkt im TI-ITSM-System. Die Ausgestaltung der Service Level erfolgt im Betriebskonzept [gemKPT_Betr].
GS-A_3972 - Service Level Requirements im übergreifenden Problem Management für TI-ITSM-Teilnehmer
Die TI-ITSM-Teilnehmer MÜSSEN die Servicezeiten gemäß TIP1-A_7265 [gemKPT_Betr] im übergreifenden Problem Management einhalten.
[<=]
5 Request Fulfillment
Das Ziel des Prozesses Request Fulfillment ist es, alle regulären betrieblichen Leistungsanfragen der TI-ITSM-Teilnehmer zu erfassen und in standardisierten Verfahren zu bearbeiten. Damit soll eine kontrollierte, bedarfsgerechte und aufwandsminimierte Erledigung der Service Requests sichergestellt werden. Die Teilnahme wird übergreifend in [gemKPT_Betr#Tab_KPT_Betr_TI_003] geregelt.
5.1 Begriffsbestimmungen
5.1.1 Service Request
Ein Service Request repräsentiert einen abrufbaren Service aus dem Business Servicekatalog der TI.
5.1.2 Beschwerdemanagement
Per Service Request können Hinweise oder Reklamationen eines TI-ITSM-Teilnehmers zu TI-Services eingehen. Diese werden vom Gesamtverantwortlichen TI bearbeitet bzw. angenommen und weitergeleitet.
5.2 Prozessdurchführung Request Fulfillment
5.2.1 Service Request erfassen
Eine Service Request Meldung wird durch einen TI-ITSM-Teilnehmer oder zukünftigen TI-ITSM-Teilnehmer initiiert. Der gestellte Service Request richtet sich an den Serviceverantwortlichen laut Business Servicekatalog. Dieser besitzt die Bearbeitungsverantwortung.
Die Erstellung eines Service Requests erfolgt im TI-ITSM-System.
GS-A_4397 - Teilnahme am Service Review5590 - Nutzung Business-Servicekatalog bei der Erfassung von Service Requests
ITSM-TI-ITSM-Teilnehmer MÜSSEN am Service Review teilnehmen und die bilateral vereinbarten Optimierungsaktivitäten umsetzen.den im TI-ITSM-System veröffentlichten Business-Servicekatalog bei der Erfassung von Service Requests nutzen und alle geforderten Informationen laut der dort genannten Servicebeschreibung dem Service Request beifügen.
[<=]
[<=]
Sollten die im Service Review zwischen ITSM-TI-Teilnehmer und SBV vereinbarten Optimierungen keinen belastbaren Erfolg zeigen, so steht dem SBV als weitere Option die Durchführung von Audits (außer Anbieter Fachdienste VSDM und Anbieter TSP eGK) offen. Damit sollen erkannte prozessuale Defizite – insbesondere in den Prozessen INC, PRO und CHG – sowie technische Defizite (Performance Zielwerte der von Anbietern verantworteten TI-Produkte) beseitigt werden.
4 Performance Management (PERF)5.2.2 Service Request prüfen
Ein Service Request wird vom Serviceverantwortlichen auf Vollständigkeit und Plausibilität geprüft.
GS-A_5351 - Prüfung von Service Requests
Der Serviceverantwortliche MUSS den Service Request eines TI-ITSM-Teilnehmers auf Vollständigkeit und Plausibilität prüfen.
[<=]
Der Serviceverantwortliche kann eine Priorisierung des Service Request anhand der Geschäftsanforderung (z.B. Zulassungstermine, Projektfortschritt etc.) vornehmen.
5.2.3 Service Request erfüllen
Für die Bearbeitung des Service Requests ist der Serviceverantwortliche zuständig. Er organisiert die Weiterleitung des Service Requests und stellt dem Melder die Lösung zur Verfügung.
GS-A_5352 - Lösung bzw. Bearbeitung des Service Requests
Der Serviceverantwortliche MUSS sicherstellen, dass jeder Service Request gemäß Bedingungen des Servicekataloges (SLA) bearbeitet und abgeschlossen wird.
[<=]
5.2.4 Service Request verifizieren und schließen
Die Lösung wird an den Melder des Service Requests über das TI-ITSM-System übermittelt.
GS-A_5591 - Verifikation des Service Requests
TI-ITSM-Teilnehmer MÜSSEN die Verifikation eines ausgeführten Services gemäß der im Servicekatalog beschriebenen Angaben durchführen und das Ergebnis im TI-ITSM-System dokumentieren.
[<=]
Je nach Vorgabe des Servicekatalogs können der Serviceverantwortliche, der Melder oder weitere TI-ITSM-Teilnehmer an der Verifikation beteiligt sein. Die Verifikation kann entfallen, sofern der Servicekatalog keine Angaben hierzu macht.
Der Service Request wird nach positivem Abschluss der Verifikationsmaßnahmen oder Ablauf der Verifikationsfrist im TI-ITSM-System geschlossen.
GS-A_5592 - Schließung des Service Requests
TI-ITSM-Teilnehmer MÜSSEN vor Schließung eines Service Requests die fehlerfreie Lieferung des Services durch den Servicenehmer verifizieren lassen. Bei negativer Verifikation ist für diesen Service kein neuer Request zu stellen. Stattdessen ist der bestehende Service Request weiterzubearbeiten.
[<=]
GS-A_5593 - Schließung des Service Requests ohne Verifikation
TI-ITSM-Teilnehmer DÜRFEN Service Requests schließen, wenn die Verifikationsfrist (entsprechend [gemKPT_Betr#TIP1-A_7265]) ohne Rückmeldung überschritten ist.
[<=]
6 Configuration Management
Das PerformanceConfiguration Management fasst die ITIL-Prozesse „Capacity Management“ und „Availability Management“ zusammen. Dabei hat das Performance Management zum Ziel, adäquate Kapazitäten und die geforderten Verfügbarkeiten für die TI zu gewährleistenstellt den TI-ITSM-Teilnehmern Informationen über die für die Erbringung von TI-Services erforderlichen Konfigurationselemente und deren Beziehungen untereinander bereit. Der Prozess sorgt für die Konsistenz der Daten und deren Bereitstellung für die Nutzung in TI-ITSM-Prozessen und Aufgaben.
Um dieses Ziel zu unterstützen, müssen ITSM-TI-Teilnehmer Performance-Messungen durchführen und diese an die zuständige servicebetriebsverantwortliche Instanz berichten. Die entsprechenden Analysen und Optimierungen im Design werden durch den SBV initiiert bzw. vorgenommen. Interne Optimierungsmaßnahmen der ITSM-TI-Teilnehmer sind nicht Bestandteil der Richtlinie und werden vorausgesetzt.
Dieses Kapitel enthält ausschließlich Anforderungen an Anbieter von zentralen Produkten der TI.
Abbildung 2: PERF – Gesamtüberblick „Performance Management“ veranschaulicht den ITSM-TI-Teilnehmer- relevanten Prozessausschnitt und gibt eine Zuordnung der einzelnen Prozessinhalte zu den nachfolgenden KapitelnFokus der nachfolgenden Configuration-Management-Regelungen im Betrieb ist die Bereitstellung der Konfigurationsdaten durch die TI-ITSM-Teilnehmer.
6.1 Begriffsbestimmungen
6.1.1 Konfigurationselement (Configuration Item, CI)
Ein Konfigurationselement (Configuration Item, kurz: CI) ist eine formalisierte Beschreibung einer zum Betrieb erforderlichen Komponente über deren gesamten Lebenszyklus. Konfigurationselemente werden durch das Configuration Management dokumentiert und im TI-ITSM-System verwaltet. Ein CI wird eineindeutig durch eine CI-ID identifiziert.
Aufbau Configuration Item ID (CI-ID):
Entspricht dem Wertebereich vom XML-Datentyp „string“ mit Pattern "CI-[ 0-9]{7}". Fixe Länge: 10 Zeichen.
A_17764 - Verwendung CI-ID
Der TI-ITSM-Teilnehmer MUSS die von dem Gesamtverantwortlichen TI vorgegebene CI-ID für jede von ihm betriebene Produktinstanz verwenden. [<=]
Die CI-ID wird automatisiert vom GTI vergeben und dem TI-ITSM-Teilnehmer im Rahmen der betrieblichen Prozesse mitgeteilt. Eine CI-ID repräsentiert Konfigurationsdaten des betreffenden Konfigurationselementes (CIs), die in der CMDB des TI-ITSM-Systems gespeichert sind (bspw. Produkttyp, Produkt, Betriebsumgebung und Anbieter). Diese Daten können unterschiedlicher Art und Detaillierungstiefe sein (bspw. Standorte, Instanzen, weitere Konfigurationsdaten). Die CI-ID wird u.a. bei der Identifizierung von Rohdaten-Performance-Berichten (siehe [gemSpec_Perf#2.5.1]) oder bei der Durchführung von Produkt-Changes im Rahmen des betrieblichen Change Management Prozesses verwendet.
6.1.2 TI-Konfigurationsdatenbank
Die TI-Konfigurationsdatenbank (Configuration Management Database - CMDB) ist ein Teil des TI-ITSM-Systems, welches Informationen über Konfigurationselemente und deren Beziehungen untereinander verwaltet sowie diese im Rahmen der TI-ITSM-Prozesse zur Verfügung stellt.
Im Rahmen des Configuration Managements der TI gibt es unterschiedliche Kategorien von Konfigurationselementen.
Abbildung 21: PERF – Gesamtüberblick „Performance Management“
4.1 Betrachtungsgegenstand des übergreifenden PERF
Fokus der nachfolgenden Performance-Management-Regelungen im übergreifenden Betrieb sind die durch die Anbieter durchzuführenden Performance-Messungen und das dazugehörige Reporting an die servicebetriebsverantwortliche Instanz. Die Performance-Messungen der dezentralen Produkte werden nicht betrachtet.
4.2 Begriffserläuterungen
4.2.1 Performance
Die Performance umfasst gemäß [gemSpec_Perf] die Dimensionen Bearbeitungszeit, Durchsatz und Verfügbarkeit.
4.3 Prozessdurchführung des übergreifenden PERF
Zur Sicherung der notwendigen Leistungen und Kapazitäten in der geforderten Verfügbarkeit, zur rechtzeitigen Einleitung von notwendigen Schritten zur Leistungsanpassung sowie zur Vermeidung von Überkapazitäten in der TI müssen Anbieter Performance-Messungen durchführen und die Ergebnisse berichten.
Die Messergebnisse dienen dabei
• im ersten Schritt der Analyse der aktuellen Performance sowie der Prognoseerstellung für zukünftige Performance-Anforderungen der Anwendungsservices und des TI-Plattform Services und
• im zweiten Schritt der - falls erforderlich - Anpassung der Kapazität, um Überkapazitäten oder bestehende bzw. drohende Engpässe zu kompensieren und die vereinbarten Service Level aufrechterhalten zu können.
4.3.1 Messung der Performance
Die Messungen erfolgen innerhalb der lokalen Systeme und Prozesse des Anbieters und müssen die Vorgaben (bspw. Messvorschriften) gemäß [gemSpec_Perf] für die Messung der Performance einhalten.
4.3.2 Bereitstellung des Performance Reports
GS-A_4106 - Reportinhalte und Format des Performance Reports
Anbieter MÜSSEN Performance-Messungen nach folgendem Schema (die Reihenfolge ist verbindlich) an den zuständigen SBV übermitteln CM – TI-Services: Beziehung und CIs (Auszug) der CMDB-TI zur lokalen CMDB der TI-ITSM-Teilnehmer
6.1.3 TI-Stammdaten
Damit die im TI-ITSM abgebildeten Prozesse von allen TI-ITSM-Teilnehmern konform zu den Vorgaben der TI genutzt werden können, sind grundlegende Daten zur Verfügung zu stellen. Diese Daten werden als TI-Stammdaten bezeichnet und vom Gesamtverantwortlichen TI im TI-ITSM-System gepflegt. Zu diesen TI-Stammdaten gehören:
Tabelle 96: Tab_Betr_TIP_003 PERF – Reportinhalte von Performance Messungen100 CM – TI-Stammdaten Datenpflege Gesamtverantwortlicher TI
|
|
Beschreibung |
|
Beispiel |
|||||||
|
|
|
|
|
|||||||
|
|
|
|
|
|||||||
|
|
|
|
|
|||||||
|
|
|
|
|
|||||||
|
|
|
|
|
|||||||
|
|
|
|
|
|||||||
|
|
|
|
|
|||||||
|
|
|
|
|
|||||||
Der Performance Report ist als CSV-Datei zu übermitteln. Anbieter MÜSSEN bei den an den SBV zu versendenden Reports die AFO GS-A_5248 beachten. Tausendertrennzeichen werden nicht verwendet. [<=]
4.3.3 Bereitstellung von Ad-hoc Performance Reports
GS-A_4108 - Inhalt von Ad-hoc Reports
Anbieter MÜSSEN für das Ad-hoc Reporting Daten aus dem vorhandenen Performance-Kenngrößen-Pool des Performance Reports oder andere - durch den SBV benannte - Kennzahlen (innerhalb eines zumutbaren Umfangs für den Anbieter) dem SBV bereitstellen. Für die Bereitstellung der Reports gelten die Regelungen gemäß „GS-A_4097“. Entsteht die Notwendigkeit zu Erhebung weiterer Kennzahlen, werden diese gemeinsam mit den betroffenen Anbietern individuell abgestimmt.
[<=]
4.3.4 Service Level Requirements (SLR)
GS-A_4109 - Service Level Requirements Anbieter-Performance-Messungen
Anbieter MÜSSEN mindestens folgende Service Level einhalten und an den GTI berichten:
Configuration Items – Organisation, Produkte und Servicekatalog – werden im Rahmen des Zulassungsprozesses vom Gesamtverantwortlichen TI angelegt. Während des gesamten Leistungszeitraumes werden diese Informationen vom Serviceverantwortlichen aktuell gehalten.
Die von den TI-ITSM-Teilnehmern verantworteten Produkte werden als logische Produktinstanzen und deren konkrete – für die Steuerung des übergreifenden Betriebs notwendigen – Konfigurationsdaten der Produktinstanz ausgeprägt.
Tabelle 107: Tab_Betr_TIP_004 PERF-Performance-Messungen Anb. „Serviceerbringung”101 CM – TI-Konfigurationsdaten
|
|
Beschreibung |
|
Beispiel |
||||
|
|
|
|
|
||||
Produkte |
Von einem TI-ITSM-Teilnehmer und der jeweiligen Betrieblichen Rolle verantworteten generischen Produkte |
VPN-Zugangsdienst vom Anbieter VPN-Zugangsdienst des TI-ITSM-Teilnehmers 1 |
||||||
Servicekatalog |
Definiert die zur Serviceerbringung notwendigen Business – sowie technischen Services und bildet diese ggf. konkret mit SLAs aus. |
Produkt Zentrales Netz des AZPD - Bereitstellen eines SZZP für alle Bedarfsträger |
||||||
Logische Produktinstanzen |
Konkrete Ausprägung des generischen Produktes in einer spezifischen Betriebsumgebung |
VPN-Zugangsdienst in der Betriebsumgebung RU; Konnektor in der Betreibumgebung PU |
||||||
Konfigurationsdaten Produktinstanz |
Detaillierte Daten zu der logischen Produktinstanz |
Produktversion; Produkttypversion, Status |
||||||
Service Level werden im Betriebskonzept [gemKPT_Betr] ausgeprägt. [<=]
5 Change & Release Management (CHG & RLM)
Der Changeprozess gilt unter dem Vorbehalt notwendiger Anpassungen aus Erkenntnissen der Erprobung ORS1.
Das Release Management hat die Überführung von Releases in den Wirkbetrieb zur Aufgabe. Es koordiniert die Entwicklung, den Test, die Verifikation sowie das Deployment der durch das Service Design definierten und geplanten Funktionen. Das Release Management stellt sicher, dass ein Release ausschließlich aus zugelassenen sowie aus einem Satz zu einander kompatibler Konfigurationseinheiten besteht.
Das Change Management hat die Aufgabe sicherzustellen, dass alle Änderungen an Produkten und den darauf basierenden Services kontrolliert durchgeführt werden. Innerhalb des Change Managements werden Änderungsanträge (Requests for Change) aufgezeichnet, bewertet sowie autorisiert und die daraus resultierenden Umsetzungen als Änderungsanforderungen (Change) koordiniert.
Da ein Release im Kontext der TI aus einer Vielzahl von Changes besteht, sind beide ITSM-Prozesse eng miteinander verzahnt und werden innerhalb dieses Dokumentes integrativ beschrieben. Die nachfolgende Abbildung veranschaulicht hierzu Regelungen des übergreifenden Change & Release Managements und verdeutlicht den für Anbieter relevanten Prozessausschnitt.
Abbildung 3: CHG & RM – Gesamtkontext "Change & Release Management"
5.1 Betrachtungsgegenstand des übergreifenden CHG & RLM
In diesem Abschnitt wird das übergreifende Change Management für Produkte sowie die im Change Management Prozess enthaltenen Übergabepunkte zum und vom Release Management der Produkte geregelt.
Das Change & Release Management der anderen Level (TI, Service, Produkttyp) wird innerhalb dieser Richtlinie nur insoweit dargestellt, wie es zur Einordnung des Produkt-Levels in den Gesamtkontext notwendig ist.
Das „lokale“ Release Management der Produkte in Verantwortung der Anbieter wird in dieser Richtlinie nur insofern geregelt, wie es zur Sicherstellung der ordnungsgemäßen Umsetzung des Change & Release Managements notwendig ist.
Nicht weiter betrachtet wird das Release Management der TI in Verantwortung des GTI.
5.2 Begriffserläuterungen
Die Begriffe RfC (Request for Change), Change Request und Änderungsantrag werden synonym verwendet.
Die Begriffe Change und Änderungsanforderung werden synonym verwendet.
Korrigierender Change: Bei einem korrigierenden Change handelt es sich um Korrekturänderungen der TI bzw. des Services bzw. des Produkttyps bzw. des Produktes.
Erweiterungs-Change: Bei einem Erweiterungs-Change handelt es sich um ergänzende Änderungen der TI bzw. des Services bzw. des Produkttyps bzw. des Produktes.
Übergreifender Change- und Releasekalender: Der Change- und Releasekalender ist Bestandteil der betriebsunterstützenden Verfahren und Systeme der Telematikinfrastruktur. 6.1.5 Lokale Konfigurationsdaten
Hier handelt es sich um spezifische Konfigurationsdaten die nur vom TI-ITSM-Teilnehmer gepflegt werden. Diese sind nicht grundsätzlich Teil der übergreifenden TI-Konfigurationsdaten.
6.2 Prozessdurchführung Configuration Management
6.2.1 Schema der TI-Konfigurationsdatenbank pflegen
Der Gesamtverantwortliche TI legt die Struktur der Konfigurationselemente und deren Beschreibung durch Attribute fest. Er stellt diese Struktur den TI-ITSM-Teilnehmern über das TI-ITSM-System zur Verfügung.
Der Change- und Releasekalender dient allen am Betrieb der TI Beteiligten dazu, sich über anstehende und durchgeführte Änderungen und Releasewechsel informieren zu können. Er ist zugleich ein Organisations- und Planungsinstrument im Rahmen des Change & Release Managements. Er ersetzt nicht die aktive Steuerung von Changes und Releasewechseln in der TI, sondern ermöglicht eine langfristige Vorschau auf geplante Änderungen und ist ein zusätzliches Hilfsmittel bei der Analyse von Störungsursachen bezüglich der Identifikation von Seiteneffekten bereits umgesetzter Änderungen.
Anbieter können bspw. zur erneuten Verifikation von Change- und Releaseplanungen oder zur Analyse von Störungsursachen den Change- und Releasekalender nutzen.
Change Advisory Board (CAB): Gremium, bestehend allen relevanten Interessensvertretern, die von der Durchführung eines konkreten Changes betroffen sind (RfC Ersteller, Change Durchführer, vom Change betroffene andere produktverantwortliche Anbieter, gematik Rollen). Aufgabe des CAB ist die gemeinsame Bewertung durch die „change stakeholder“ und die folgende Autorisierung oder Ablehnung eines Changes durch den SBV.
Emergency Change Advisory Board (eCAB): Stand-by Organisationsform des CAB, organisiert durch die Rollen GTI und SBV. Ziel und Aufgabe des eCAB besteht darin, bei auftretenden Anforderungen zur Durchführung eines Notfall Changes (Emergency Change) eine Bewertung und Autorisierung / Ablehnung herbeizuführen.
Change Level: Differenzierung des Changes nach Objekt und Umfang des Changes. Folgende Change Level sind festgelegt:
Tabelle 11: Tab_Betr_TIP_044 CHG – Change Level
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Im Kapitel „5.4 Prozessdurchführung übergreifendes CHG“ erfolgt eine Darstellung zur Durchführung von Produkt Changes (Change Level 1). Eine Präzisierung zur Behandlung der weiteren Change Level (2, 3 und 4) sowie zum Release Management erfolgt in einer späteren Version dieses Dokuments.
Lokaler Change: Änderung, die nach erfolgter Vorprüfung durch den Anbieter keine erwarteten Wechselwirkungen mit anderen Produkten der TI hat und im lokalen Change Management des Anbieters durchgeführt werden kann. Eine Autorisierung durch den SBV ist für die Change Durchführung nicht erforderlich.
Ein Change kann als lokaler Change durchgeführt werden, wenn:
• Vereinbarte Service Level durch den Change nicht verletzt werden
• Geltende Produkttypspezifikationen durch den Change nicht berührt werden
• Der Change lokal auf das Produkt oder eine Produktinstanz begrenzt ist.
Weitere Ausführungen zur Durchführung von lokalen Produkt Changes finden sich im Kap. 5.4.2 und Kap. 5.4.3.
Übergreifender Change: Änderung, die nach erfolgter Vorprüfung durch den Anbieter oder durch den SBV mögliche Auswirkungen auf die Produkttypspezifikation und/oder erwartete Wechselwirkungen mit anderen Produkten der TI haben kann und unter Kontrolle des übergreifenden Change Managements der TI durchgeführt werden muss. Übergreifende Changes sind genehmigungspflichtig, d.h. eine Autorisierung durch den SBV ist für die Change-Durchführung erforderlich.
Weitere Ausführungen zur Durchführung von übergreifenden Produkt Changes finden sich im Kap. 5.4.4 ff.
Change Dringlichkeit (Urgency): Bewertung der erforderlichen Dringlichkeit bei Umsetzung eines Changes. Dies ist insbesondere bei fehlerkorrigierenden Changes notwendig.
Tabelle 12: Tab_Betr_TIP_045 CHG – Change Dringlichkeit
|
|
|
|
|
|
|
|
|
|
Change Kategorie: Die Beschreibung der möglichen Auswirkungen und des daher erforderlichen Risikomanagements erfolgt durch den Begriff „Kategorie“; diese betrachtet Umfang, Komplexität und Schwere eines Changes.
„Kategorie“ bestimmt damit die möglichen Auswirkungen, die die Durchführung eines Changes auf die Geschäftsprozesse der TI-Anwender haben kann, betrachtet also das damit verbundene Risiko.
Tabelle 13: Tab_Betr_TIP_046 CHG – Festlegung von Change Kategorie und Auswirkung
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Emergency Change (Notfall Change): Ein Change, der so bald wie möglich umgesetzt werden muss, um auf eine Notsituation angemessen reagieren zu können. Übergeordnetes Ziel ist, größeren Schaden zu vermeiden oder zu beheben, beispielsweise um einen Major Incident zu lösen oder um eine kritische Sicherheitslücke durch ein Sicherheits-Patch zu schließen.
Tabelle 14: Tab_Betr_TIP_048 CHG – Kriterien für Emergency Changes
|
|
|
|
Die Anwendung der hier beschriebenen Change Parameter (lokal, übergreifend, Dringlichkeit, Change Kategorie, Emergency Change) für die Durchführung von Produkt- Changes wird im Kapitel „5.4 Prozessdurchführung übergreifendes CHG“ beschrieben.
5.3 Prozessdurchführung übergreifendes RLM
In einem Release werden unterschiedliche Services zu einem TI-Release bzw. unterschiedliche Produkttypen und Produkte zu einem Service-Release zusammengefasst, die zum gleichen Releasetermin im Rahmen eines einheitlichen Releaseprozesses produktiv gesetzt werden.
Der Begriff Release ist in diesem Zusammenhang im Sinne eines Containers zu verstehen, der die einzelnen Service-, Produkttyp- oder Produktversionen enthält. Das übergreifende Release Management erfolgt auf den Ebenen:
Release Management der TI,
Release Management der TI-Services,
Release Management der Produkttypen,
Release Management der Produkte.
Auf der Ebene der Services und Produkttypen wird ein Release in der Regel mehrere Änderungen beinhalten. Auf Ebene der Produkte kann ein Release bereits aus einer Änderung bestehen.
Jede dieser Ebenen prägt ihr eigenes Release Management aus, so dass Umfang, Aufgaben, Stakeholder und Betroffene je nach Gegenstand der Releases variieren.
Release Management der TI:
Das Release Management der TI verantwortet die strategische Releaseplanung für die TI. Auf dieser Ebene steht der Planungsaspekt im Vordergrund, der Funktionsumfang eines TI-Releases wird vereinbart und die Bereitstellung sowie Implementierung wird mit den Stakeholdern abgestimmt. Die Planung der TI-Releases legt den zeitlichen Rahmen und die Termine für die Ebene Release Management der TI-Services fest. Diese Termine werden im Change- und Releasekalender dokumentiert. Der Test und die Überführung der TI-Releases in den Wirkbetrieb werden in enger Kooperation mit der Ebene Release Management der TI-Services durchgeführt. Verantwortlich für das Release Management der TI ist der GTI.
Beispiel für TI-Release: Das ORS1-Release als Gesamtmenge aller bereitzustellenden Anwendungs- und Basisservices auf Basis der Produkttyp-Spezifikationen und den realisierten, implementierten und zugelassenen Produkten im Wirkbetrieb, mit dem dazugehörigen und freigegebenen Dokumentenset. Ein Release Label zu diesem TI-Release ist derzeit noch nicht festgelegt.
Da das Release Management der TI ausschließlich durch den GTI durchgeführt wird, wird es in dieser Richtlinie nicht weiter betrachtet.
Release Management der TI-Services:
Auf der Ebene des Release Managements der TI-Services planen und koordinieren die serviceverantwortlichen Instanzen (Rolle SV) die Bereitstellung, den Test und die Überführung von Service Releases und Produkttyp-Changes in den Wirkbetrieb.
Der SV wird während der Anpassung der Produkttypen - bei Bedarf - bei Anbietern und Herstellern eine Befragung zum geplanten Produkttyp-Change durchführen. Die Befragung wird sich insbesondere auf die Kriterien Machbarkeit (inkl. Kompatibilität) und Kostenwirkung (inkl. Migrationsaufwand) fokussieren.
GS-A_4414 - Beteiligung von Anbietern und Herstellern an der Bewertung von Produkttyp-Changes mittels Befragung
Anbieter und Hersteller MÜSSEN bei der Befragung zu geplanten Produkttyp-Changes durch den SV mitwirken und den SV in seiner Releaseplanung beratend unterstützen.
[<=]
Beispiel für TI-Service-Release: Das Release des Anwendungsservices VSDM als Gesamtmenge aller auf Basis der Produkttyp-Spezifikationen zugelassenen Produkte, die genau den Anwendungsservice VSDM bilden. Die zugelassenen Produkte sind als Produktinstanzen im Wirkbetrieb implementiert, mit dem dazugehörigen und freigegebenen Dokumentenset. Das Release Label zu diesem TI-Service-Release ist derzeit noch nicht festgelegt.
Release Management der Produkte:
Das operative Release Management der Produkte verantworten die ITSM-TI-Teilnehmer auf Grundlage ihrer Produktverantwortung. Die Entwicklung der Produkte, ihr Test und die Überführung der Produktinstanzen in den Wirkbetrieb müssen die Produkttyp-Spezifikationen, die Vorgaben aus dem übergeordneten TI-Service Release sowie die Änderungsaufträge aus dem Change Management beachten.
Beispiel für Produkt-Release: Die fertige, veröffentlichte und zugelassene Version eines Produktes eines Anbieters wird als Produkt-Release bezeichnet. Beispiele für zugelassene Produkt-Releases finden sich auf der Homepage der Zulassungsstelle der gematik.
5.4 Prozessdurchführung übergreifendes CHG
Abbildung 4: CHG – Gesamtüberblick „Change Management der Produkte“
Im Rahmen des übergreifenden Change Managements verantworten die Anbieter auf Grundlage ihrer Produktverantwortung (in Abstimmung mit dem SBV) das Change Management der Produkte.
Alle Produktänderungen werden
o durch das lokale Change Management des Anbieters koordiniert und
o innerhalb des lokalen Change Managements des Anbieters umgesetzt.
Innerhalb des übergreifenden Change Managements wird dabei grundsätzlich in zwei Produkt-Change-Typen unterschieden:
a. in lokal autorisierte Changes (informationspflichtig im Rahmen des Configuration Managements)
b. und in genehmigungspflichtige Changes.
Die Entscheidung, um welchen Change Typ es sich handelt, muss innerhalb der Vorprüfung des Produktänderungsbedarfs (siehe Kapitel 5.4.2) erfolgen.
Sofern nicht anders ausgewiesen, werden nachfolgend die für Anbieter relevanten Regelungen zur Identifikation des Change Typs sowie des Prozessablaufs für genehmigungspflichtige Produkt Changes dargelegt. Im vorliegenden Dokument werden Changes zentraler Produkte, verantwortet von Anbietern, behandelt. Eine Präzisierung der Changes dezentraler Produkte erfolgt in einer späteren Version.
Eine Übersicht aller RfCs und deren Status wird in einem FSC (Forward Schedule of Change) über die Wissensdatenbank zur Verfügung gestellt. Weiterhin werden RfCs abhängig von ihrem Status im CAB (Change Advisory Board) besprochen.
Ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt
Die Kommunikation und der Informationsaustausch zur Durchführung des Change-Prozesses erfolgt aus Gründen der Flexibilität sowie aufgrund der individuellen Ausprägungsmöglichkeiten je Produkt-RfC bzw. Change-Durchlauf weitgehend per E-Mail, aber auch telefonisch, in Form von Telefonkonferenzen oder auch durch Besprechungen vor Ort. Die im Folgenden aufgeführten Anforderungen hinsichtlich der Übermittlung von Informationen der Anbieter an den SBV erfolgen dabei grundsätzlich per E-Mail, es sei denn, es werden nähere Angaben für das zu wählende Kommunikationsmedium gemacht.
Jeder übergreifende Produkt-RfC bzw. Produkt-Change wird in formaler Form in der ZID gespeichert. Speicherung und Statusänderungen des Produkt-RfCs bzw. des Produkt-Changes werden durch den SBV vorgenommen.
GS-A_5363 - Einrichten einer Benutzergruppe und eines Funktionspostfachs für Mitteilungen über die ZID im Change Management
Für die ZID-basierte Kommunikation zu übergreifenden Produkt-Changes wird je Anbieter eine spezifische Nutzergruppe eingerichtet, die über ein Funktionspostfach aus der ZID erreichbar ist. Die Anbieter MÜSSEN die Namen ihrer Mitarbeiter in der Nutzergruppe dem SBV mitteilen und die Daten dieser Nutzergruppe stets aktuell halten.Gesamtverantwortliche TI wird das Schema der TI-Konfigurationsdatenbank regelmäßig prüfen und ggf. Anpassungen vornehmen. Die TI-ITSM-Teilnehmer werden über diese Anpassungen mit angemessener Frist vorab informiert.
6.2.2 Konfigurationsdaten pflegen
TI-ITSM-Teilnehmer führen Änderungen nur unter Kontrolle des Change & Release Managements sowie des Request Fulfillments durch. Nach erfolgreicher Durchführung der Änderungsprozesse stehen die aktualisierten Daten den TI-ITSM-Teilnehmern bzw. dem Gesamtverantwortlichen TI zur Wahrnehmung der jeweiligen Rolle bedarfsgerecht im TI-ITSM-System zur Verfügung.
GS-A_4114 - Bereitstellung von TI-Konfigurationsdaten
TI-ITSM-Teilnehmer MÜSSEN entsprechend ihrer Rolle (vgl. [gemKPT_Betr#Tab_KPT_Betr_TI_002]) TI-Konfigurationsdaten mit dem Gesamtverantwortlichen TI zu Beginn der Serviceerbringung initial abstimmen und im TI-ITSM-System hinterlegen.
[<=]
GS-A_5594 - Identifikation von TI-Konfigurationsdaten
TI-ITSM-Teilnehmer MÜSSEN TI-Konfigurationsdaten gemäß Konfigurationsschema im TI-ITSM-System ermitteln und definieren.
[<=]
GS-A_4115 - Datenänderung für TI-Konfigurationsdaten
TI-ITSM-Teilnehmer MÜSSEN TI-Konfigurationsdaten über den gesamten Zeitraum der Serviceerbringung aktuell halten und im TI-ITSM-System hinterlegen.
[<=]
Mit dieser Regelung wird eine verlässliche Erreichbarkeit der Anbieter im übergreifenden Change Management erzielt. Benannte Mitarbeiter der bezeichneten Benutzergruppe sind berechtigt, für den jeweiligen Anbieter change-relevante Entscheidungen zu treffen, z.B. in der Abstimmung zur Autorisierung eines RfCs. Weitere Details zu CHG-Benutzergruppe und Funktionspostfach finden sich in der WDB.
Anbieter haben über das zur Verfügung gestellte Webportal der ZID die Möglichkeit, diejenigen Produkt-RfCs bzw. Changes einzusehen, an denen sie beteiligt sind. Ein Rollen- und Berechtigungskonzept der ZID regelt dabei die Einsichtnahme und den Zugriff auf die relevanten Datensätze. Des Weiteren wird den Anbietern im Webportal der ZID die Möglichkeit eröffnet, alle in diesen Richtlinien angegebenen formalen Informationen und Prozessschritte, welche die Kommunikation mit dem SBV berühren (z. B. Beantragung eines Produkt-RfCs, Autorisierung des Produkt-RfCs, Vorgangsdaten zu Produkt-Changes speichern), direkt über das Webportal der ZID vorzunehmen. Die Erläuterungen erfolgen in den jeweiligen Abschnitten.
Die im Folgenden definierten Dokumentations- und Übermittlungspflichten der am jeweiligen Produkt-RfC bzw. Produkt-Change beteiligten Anbieter obliegen weiterhin ausschließlich diesen selbst.
5.4.1 Eigeninitiierten Produktänderungsbedarf feststellen
Eigeninitiierte Produktänderungsbedarfe können durch verschiedene Einflussfaktoren bei den Anbietern festgestellt werden (bspw. Korrekturbedarfe aus dem lokalen/übergreifenden Incident Management oder Problem Management, oder auch Ergänzungsbedarfe des Produktes, die der Anbieter festgestellt hat).
An die Feststellung von Produktänderungsbedarfen innerhalb der lokalen Change-Prozesse des Anbieters werden keine Anforderungen gestellt.
5.4.2 Vorprüfung durchführen
GS-A_4398 - Vorprüfung von durch Anbietern festgestellten Produktänderungsbedarfen
Anbieter MÜSSEN jeden festgestellten Produktänderungsbedarf einer Vorprüfung gemäß der unten abgebildeten Tabelle unterziehen. Dabei ist - durch Feststellung der Wechselwirkungen mit anderen Produkten sowie der Abweichung von Produkttypvorgaben - zu prüfen, ob es sich um eine genehmigungspflichtige oder einen lokal autorisierte Produktänderung handelt.
Tabelle 15: Tab_Betr_TIP_024 CHG – Vorprüfung lokal./genehmig. Produktänderungsbedarf
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[<=]
Sofern es sich um einen genehmigungspflichtigen Produktänderungsantrag handelt, müssen Anbieter einen Produkt-RfC gemäß den Anforderungen in Kapitel 5.4.4 aufzeichnen.Spezifische Anforderungen an die Versionierung der Produkte und der logischen Produktinstanzen sind gemäß [gemSpec_OM] zu beachten.
6.2.2.1 Übermittlung von Konfigurationsdaten nach lokal autorisierten Produkt-Changes
Sofern es sich um einen lokal autorisierten Änderungsantrag handelt, erfolgt die weiterführende Bearbeitung - ohne weitere Genehmigung durch den SBV - im lokalen Change Management des Anbieters (siehe Kapitel 5.4.3).
5.4.3 lokalen Produkt-Change durchführen & abschließen
An das Management lokal autorisierter Produkt-Changes (s. Tabelle 15: Tab_Betr_TIP_024 CHG – Vorprüfung lokal./genehmig. Produktänderungsbedarf) werden keine Anforderungen gestellt. Der zuständige SBV ist nach Durchführung des lokal autorisierten Changes zu informierenein Change lokal autorisiert wurde, müssen die geänderten Produktdaten an das Configuration Management übermittelt werden.
GS-A_4399 - Übermittlung von Produktdaten nach Abschluss von lokal autorisierten Produkt-Changes
AnbieterAlle TI-ITSM-Teilnehmer MÜSSEN nach dem Abschluss (nach der Produktivsetzung des Produkt-Changes als Produkt) von lokal autorisierten Produkt-Changes den Änderungsdatensatz derdie geänderten Produktdaten an den SBVdas TI-ITSM-System übermitteln.
[<=]
5.4.4 Eigeninitiierten Produkt-RfC aufzeichnen
GS-A_4400 - Produkt-RfC aufzeichnen & an SBV übermitteln
Anbieter MÜSSEN für genehmigungspflichtige Produktänderungen über ein vom SBV zur Verfügung gestelltes RfC-Formular einen Produkt-RfC erstellen und an die vom SBV bereitgestellte Kommunikationsschnittstelle übermitteln oder den Produkt-RfC direkt über eine im Webportal der ZID eingerichtete, Erfassungsmaske manuell eingeben. Erfasst der Anbieter den Produkt-RfC direkt im Webportal der ZID, wird die formale Beantragung und Übermittlung an den SBV ebenfalls über das Webportal der ZID angestoßen.
(Zur Erstellung des Produkt-RfCs stellt der SBV den Anbietern ein RfC-Formular zur Verfügung.)
[<=]
Der SBV wird den Erhalt des vom Anbieter versendeten Produkt RfC quittieren, eine über alle Anbieter eindeutige ID vergeben, an den Antragsteller zurückmelden. Im Falle des per Formular (d. h. per E-Mail) übermittelten Produkt-RfC trägt der SBV diesen gemäß den Angaben des Anbieters vor der Quittierung in das Webportal der ZID ein. Der SBV wird dann den Produkt-RfC in angemessener Zeit formal und inhaltlich prüfen (insbesondere auf Vollständigkeit, Durchführbarkeit und Redundanz mit bereits angenommenen, aktuell zu prüfenden und abgelehnten Produkt RfCs).
Bei Zustimmung wird der SBV den Produkt-RfC zur Bewertung freigeben. Die Freigabe erfolgt durch den SBV im Webportal der ZID. Der SBV wird daraufhin dem Anbieter die Freigabe des Produkt-RfC zur Bewertung per E-Mail mitteilen.
Bei Ablehnung (Stornierung) (bspw. wegen Nichtdurchführbarkeit) des Produkt-RfCs wird der SBV dies dem Anbieter unter Angabe von Gründen mitteilen. Die Ablehnung wird formal vom SBV in der ZID dokumentiert.
5.4.5 Produkt-RfC registrieren
[<=]
7 Change & Release Management
Das Change & Release Management stellt sicher, dass alle Änderungen an Produkten und den darauf basierenden Services kontrolliert durchgeführt werden. Innerhalb des Change Management werden Änderungsanträge aufgezeichnet, bewertet sowie autorisiert und die daraus resultierenden Umsetzungen als Änderungsanforderungen koordiniert.
Im vorliegenden Dokument wird das übergreifende Change Management für Produkte und deren logische Produktinstanzen geregelt.
Es werden keine normativen Vorgaben zum lokalen Change Management der TI-ITSM-Teilnehmer gemacht.
7.1 Begriffsbestimmungen
7.1.1 Request for Change (RfC)
Unter einem Request for Change versteht man einen Antrag auf das Hinzufügen, Verändern oder Entfernen von autorisierten Services oder Servicekomponenten unter Bezug auf Configuration Items (Produkte, logische Produktinstanzen und deren Konfiguration sowie Produkttypen). Ein Request for Change wird zum Change nach dessen Autorisierung.
7.1.2 Produkt-Change
Ein Produktänderungsbedarf kann ebenso vom SBV festgestellt werden (bspw. durchProdukt-Change beinhaltet Änderungen an der Produkttypspezifikation). Der SBV registriert den Produkt-RfC in der ZID und übermittelt ihn per E-Mail an den bzw. die von ihm ausgewählten Anbieter , verbunden mit der Aufforderung zur inhaltlichen Prüfung. Der Produkt-RfC ist damit noch nicht zur Bewertung freigegeben. Erst nach positiver inhaltlicher Prüfung und Rückmeldung durch den Anbieter kann der Produkt-RfC durch den SBV zur Bewertung freigegeben werdeneinem Produkt bzw. einer logischen Produktinstanz, welches sich bereits im Betrieb befindet oder in den Betrieb eingeführt oder herausgeführt werden soll.
Bei Produkt-Changes gibt es zwei Durchführungsvarianten.
GS-A_4401 - Registrierung von durch den SBV übermittelten Produkt-RfCs
Anbieter SOLLEN durch den SBV übermittelte Produkt-RfCs vor der Bewertungsphase inhaltlich prüfen und das Ergebnis ihrer Prüfung – nach den mit der Registrierung und Anfrage zur Prüfung festgelegten zeitlichen Vorgaben des SBV – an ihn übermitteln.
(Die Registrierung dient insbesondere der Kenntnisnahme der anstehenden Produktänderung, der Prüfung auf Vollständigkeit, Kosten und Machbarkeit sowie der Vorbereitung der sich anschließenden gemeinsamen Bewertung des Produkt-RfC.)
[<=]
GS-A_5364 - Beachtung von Change Level, Dringlichkeit und Kritikalität
Anbieter und SBV MÜSSEN spätestens bis Registrierung des RfC eine Prüfung auf Change Level, Kritikalität und Dringlichkeit des Changes vorgenommen haben und ihr Prüfungsergebnis bei der Registrierung dokumentieren. Für diese Prüfung MÜSSEN Anbieter und SBV die Klassifikationen gemäß „Tab_Betr_TIP_044 CHG – Change Level“, „Tab_Betr_TIP_045 CHG – Change Dringlichkeit“ sowie gemäß „Tab_Betr_TIP_046 CHG – Festlegung von Change Kategorie und Auswirkung“ beachten.
[<=]
5.4.6 Produkt-RfC bewerten & autorisieren
Sowohl vom Anbieter aufgezeichnete, genehmigungspflichtige Produkt-RfCs (die vom SBV zur Bewertung freigegeben wurden), als auch vom SBV an Anbieter übermittelte Produkt-RfCs werden durch betroffene Anbieter sowie dem SBV bewertet werden. Die Autorisierung des genehmigungspflichtigen Produkt-RfC erfolgt im Konsens zwischen dem realisierenden Anbieter und dem zuständigen SBV. Der SBV hat sich die für die Autorisierung notwendigen Genehmigungen des SV und GTI vor der Autorisierung einzuholen.
Übergreifende Ziele der gemeinsamen Bewertung sind:
o finale Schärfung/Konkretisierung/Feststellung der Produkt-RfC-Inhalte, insbesondere zu Zeitraumplanung, Ressourcenaufwand & -planung, Kosten, Machbarkeit, Nutzen, Priorität, Risiken, Backout-/Fehlerkorrekturplan, Zulassungsrelevanz (inkl. relevanter Testverfahren, Testumgebungen & Testmanagement), Zuordnung zum Produktrelease bzw. TI-Service-Release
o sowie Festlegung der Verbindlichkeit von Termin- und Umsetzungszusagen.
Sollten Anbieter mit dem SBV keine Einigung bei der Bewertung erzielen können, besteht die Möglichkeit der Eskalation an den GTI (siehe Kapitel 5.8 Eskalationen).
Die Durchführung der Bewertung kann mittels der Einberufung eines CAB (Change Advisory Board) erfolgen. Die Form und die zeitlichen Intervalle des CAB werden durch den SBV festgelegt (bspw. Telefonkonferenz, E-Mail-Verteiler). Präsenztermine für Anbieter werden durch den SBV, soweit möglich, vermieden und nur einberufen, sofern eine Notwendigkeit hierfür besteht oder die Mehrheit der im CAB beteiligten Anbieter dieses wünschen.
GS-A_4402 - Mitwirkungspflicht bei Bewertung von Produkt-RfCs
Anbieter MÜSSEN bei der Bewertung von Produkt-RfCs mitwirken. Die Mitwirkung erfolgt innerhalb eines CAB oder bilateral zwischen Anbieter und SBV.
[<=]
Ist die Bewertung des Produkt-RfCs durch Anbieter und SBV inhaltlich abgeschlossen, müssen die am Produkt-RfC beteiligten Rollen (Anbieter und SBV) eine Autorisierung (Freizeichnung) des Produkt-RfCs vornehmen.
Die Autorisierung durch die Anbieter erfolgt per E-Mail an den SBV oder mittels eines im Webportal der ZID bereitgestellten Autorisierungsvorgangs. Erfolgt die Autorisierung per E-Mail an den SBV, nimmt der SBV - nach Erhalt der Autorisierung des betroffenen Anbieters - die Autorisierung für diesen formal im Webportal der ZID vor.
Vor der Change-Umsetzung muss der Produkt-RfC sowohl vom SBV als auch vom Anbieter formal autorisiert sein.
Ab diesem Zeitpunkt ist der Produkt-RfC als Produkt-Change freigegeben - die ID des Produkt-RfCs wird zur ID des Produkt-Changes. Der SBV informiert die Anbieter per E-Mail über die vollständig abgeschlossene Autorisierung.
5.4.7 Produkt-Change umsetzen
Die Umsetzung eines autorisierten Produkt-Changes wird bis zum erfolgten Abschluss (oder Abbruch der Umsetzung) übergreifend durch den SBV koordiniert.
GS-A_4415 - Aktualisierung des Vorgangsdatenreports
Anbieter MÜSSEN die interne Dokumentation des Vorgangsdatenreports für genehmigte Produkt-Changes stetig aktuell halten und auf Anfrage an den SBV übermitteln. Die Aktualisierung der Dokumentation erfolgt anlassbezogen, der Worklog ist spätestens zu jedem Statuswechsel des Produkt-Changes zu ergänzen.
[<=]
Die für den Vorgangsdatenreport erforderlichen Dokumentationspflichten (siehe Kap. 5.9 Prozessreporting (Vorgangsdaten) CHG) können vom Anbieter auch im Webportal der ZID vorgenommen werden. In diesem Fall kann die Übermittlungspflicht an den SBV - bei entsprechend vorgenommener Dokumentation - im Webportal der ZID ausgeführt werden.
GS-A_4418 - Übermittlung von Abweichungen vom Produkt-RfC
Anbieter, die während der Umsetzung des autorisierten Produkt-Changes Abweichungen zur Planung im Produkt-RfC feststellen, MÜSSEN diese unverzüglich dem SBV melden.
[<=]
Bei einer festgestellten Abweichung des dem aktuellen Produkt-Change zugrunde liegenden Produkt-RfCs wird der SBV entscheiden müssen, welche Konsequenzen die Feststellung bzw. Abweichung auf die weitere Durchführung des Produkt-Changes hat und welche Maßnahmen zu treffen sind. Dazu wird sich der SBV bei Bedarf mit den beteiligten Anbietern (und dem GTI) beraten. Die Ergebnisse werden vom SBV in der ZID dokumentiert, ebenso wie eine eventuelle Status-Änderung des Produkt-Changes (bspw. Stornierung). Die Anbieter werden vom SBV hierüber abschließend per E-Mail informiert.
Die Umsetzung des Produkt-Changes setzt sich im Wesentlichen aus den nachfolgenden vier Prozessschritten zusammen. Die einzelnen Prozessschritte entsprechen dabei dem jeweiligen Status, den ein Produkt-Change im Zuge der Umsetzungsphase annehmen kann.
Die formale Änderung des Status eines Produkt-Changes wird vom SBV in der ZID vorgenommen und von ihm entsprechend an die beteiligten Anbieter per E-Mail kommuniziert. Einem Statuswechsel geht dabei eine übereinstimmende Einschätzung des aktuellen Sachstandes der Beteiligten voraus. Eine formale Autorisierung des SBV zur Änderung eines Status (z. B. durch die beteiligten Anbieter ) erfolgt nicht.
Eine Übersicht der bei der Durchführung eines Produkt Changes zu durchlaufenden Phasen, Statusübergänge sowie der jeweiligen Bedingungen hierfür findet sich in Kapitel 5.4.9 „Produkt-Change: Phasen und Statusübergänge“.
1. Produkt-Change planen
GS-A_4416 - Planung von Produkt-Changes gemäß Produkt-RfC
Anbieter MÜSSEN die Produktentwicklung, den Produkttest, das Produkt-Deployment sowie den Abschluss des genehmigten Produkt-Changes planen und dabei die gemeinsam mit dem SBV festgelegten Termine und Inhalte des Produkt-RfCs zum Produkt-Change beachten.
[<=]
Zur Umsetzung von mehreren Changes an einem Produkt können Anbieter genehmigte Produkt Changes an einem Produkt zu einem Produkt-Release bündeln. Diese Produkt-Releases können auch lokal autorisierte Produkt Changes enthalten, die Anbieter eigenständig initiiert haben.
Weiterhin ist während der Bewertung des autorisierten Produkt-RfCs eine Grobplanung für die Umsetzung entwickelt worden. Diese ist durch den Anbieter innerhalb dieser Phase weiter zu konkretisieren, stetig zu aktualisieren und bei Bedarf dem SBV zur Verfügung zu stellen.
GS-A_4417 - Stetige Aktualisierung von Planungs- und Realisierungsdaten
Anbieter MÜSSEN die interne Dokumentation der Planungs- und Realisierungsdaten von autorisierten Produkt Changes stetig aktuell halten und auf Anfrage an den SBV übermitteln.
[<=]
1. Produkt-Change entwickeln
GS-A_4419 - Nutzung der Testumgebung
Anbieter MÜSSEN die Anforderungen an die Nutzung der Testumgebung sowie die geplante Belegung der Testumgebung für ihre Produkttests mit dem SBV abstimmen.
[<=]
Die Testumgebung wird hinsichtlich der Nutzung durch die testdurchführende Instanz (siehe Testkonzept) koordiniert. Der SBV stimmt sich mit der testdurchführenden Instanz ab.
GS-A_4420 - Übermittlung der lokalen Testergebnisse
Anbieter MÜSSEN - sofern mit dem SBV vereinbart - die finalen Ergebnisse der beim Anbieter lokal durchgeführten Tests von autorisierten Produkt-Changes an den SBV übermitteln.
[<=]
1. Produkt-Change testen
GS-A_4421 - Zulassung und Abnahme von entwickelten Produkt-Changes
Anbieter MÜSSEN für ihre entwickelten Produkt-Changes die vom SBV vorgegebenen Tests absolvieren und die gegebenenfalls notwendigen Zulassungen für den Produktivbetrieb erfolgreich erlangen.
[<=]
Der Abschluss des Tests ist erfolgt, wenn der Anbieter das Produkt (Produkt- Release) in den jeweiligen Umgebungen getestet hat und durch die testkoordinierende Instanz des SBV der Einsatz in der Produktivumgebung freigegeben wurde.
1. Produkt-Change einführen
Das Deployment eines Produkt-Changes wird durch den SBV zeitlich und verfahrenstechnisch koordiniert. Anbieter müssen das Deployment des Produkt-Changes gemäß den Vorgaben vom SBV durchführen und stetig deren Einhaltung prüfen.
Das Deployment zentraler Produkte ist die Inbetriebnahme in der Produktivumgebung.
GS-A_4422 - Überführung von Produkten durch Anbieter in den Wirkbetrieb
Anbieter MÜSSEN die von ihnen verantworteten Produkte zu den vereinbarten Test- und Releaseterminen in die Testumgebungen und die Wirkbetriebsumgebung überführen und dabei die Vorgaben der SBV erfüllen.
[<=]
Vom SBV genehmigte Wartungsfenster werden von der Verfügbarkeitsberechnung des betroffenen Produkts ausgenommen. Bei genehmigungspflichtigen Änderungen wird die Koordination der Wartungsfenster im Rahmen der Planung und Umsetzung des Changes durch den SBV vorgenommen.
GS-A_4423 - Abstimmung von Wartungsfenster für genehmigungspflichtige Änderungen
Anbieter MÜSSEN Wartungsfenster für genehmigungspflichtige Änderungen mit dem SBV abstimmen.
[<=] 7.1.2.1 Master-Change
Der Master-Change adressiert den Inhalt der Produktänderung fachlich. Er hat noch keinen konkreten Bezug zur Umsetzung in einer Umgebung (RU TU PU). Im Master-Change-Prozess werden grundsätzliche Entscheidungen (z.B.: Zulassungsrelevanz, Testumfang, oder dem zeitlichen Gesamtverlauf) vereinbart. Die mit dem Master-Change abgestimmten und freigegebenen Änderungen werden mit den sogenannten Sub-Changes in die Umgebungen eingebracht.
7.1.2.2 Sub-Change
Der Sub-Change ist einem Master-Change innerhalb eines Produkt-Changes zugeordnet. Er setzt die im Master-Change definierte(n) Änderung(en) in einer konkreten Umgebung und damit der logischen Produktinstanz um. Sub-Changes werden nur im Rahmen von Produkt-Changes verwendet.
7.1.3 Produkttyp-Change
Ein Produkttyp-Change umfasst die konzeptionellen Änderungen an einem Produkttypen der TI. Ergebnis des Prozesses ist eine geänderte Spezifikation des Produkttypen. Ein Produkttyp-Change kann von TI-ITSM-Teilnehmern oder vom Gesamtverantwortlichen TI gestellt werden.
7.1.4 Emergency-Change
Ein Emergency-Change ist eine Änderung, die aufgrund einer Notsituation durchgeführt werden muss, um so schnell wie möglich diese Notsituation zu lindern. Ein Emergency-Change kann in folgenden beispielhaften Situationen erforderlich werden:
- Nichtverfügbarkeit eines zentralen Plattformdienstes, der die höchste Auswirkung für die TI hat;
- Fehlgeschlagener Produkt-Change, der nicht durch ein Fallback zurückgenommen werden kann, da Auswirkungen auf andere Produkte bestehen;
- Entdeckte Sicherheitslücke, die umgehend behoben werden muss, um (weiteren) Schaden von der TI abzuwenden.
Die Dringlichkeit der Korrektur lässt unter Umständen kein Testen zu; die sofortige Heilung der Notsituation ist das primäre Ziel. Das damit einhergehende Risiko wird bewusst in Kauf genommen.
Für die kontrollierte Durchführung eines Emergency-Change wird ein Entscheidungsgremium, das Emergency Change Advisory Board (eCAB) implementiert, das den beteiligten TI-ITSM-Teilnehmern bei der Bewertung des auftretenden Emergency-Change wirksam unterstützt.
7.1.5 Betriebliches Change-Bewertungsgremium (BCB)
Das Betriebliche Change-Bewertungsgremium (BCB) ist das Board des Gesamtverantwortlichen TI, in dem RfCs bewertet und über deren weiteren Umsetzungsverlauf entschieden wird. Dabei werden die beteiligten TI-ITSM-Teilnehmer bei Bedarf in die Entscheidungsfindung und Umsetzungsplanung durch den Gesamtverantwortlichen TI einbezogen.
7.1.6 Change Advisory Board (CAB)
Das Change Advisory Board ist ein Gremium, das aus allen relevanten Vertretern der TI-ITSM-Teilnehmer, die von der Durchführung eines konkreten Changes betroffen sind, besteht. Wird eine vom BCB getroffene Entscheidung von den beteiligten TI-ITSM-Teilnehmern nicht mitgetragen, wird das CAB vom Gesamtverantwortlichen TI einberufen um das weitere Vorgehen abzustimmen oder zu eskalieren.
7.1.7 Emergency Change Advisory Board (eCAB)
Das Emergency Change Advisory Board (eCAB) ist eine besondere Organisationsform des CAB, organisiert durch den Gesamtverantwortlichen TI. Die Zusammensetzung wird fallbezogen festgelegt. Ziel und Aufgabe des eCAB ist es, bei auftretenden Anforderungen zur Durchführung eines Emergency Change eine möglichst zeitnahe Bewertung und Autorisierung bzw. Ablehnung herbeizuführen. Hierfür müssen die Teilnehmer mit entsprechenden Kompetenzen ausgestattet sein.
7.1.8 Post Implementation Review (PIR)
Beim Abschluss des Master-Changes führt der Gesamtverantwortliche TI das Post Implementation Review gemeinsam mit dem Durchführenden des Produkt-Changes durch. Ziel ist die Identifizierung von Optimierungspotenzialen und deren Umsetzung in den weiteren Change-Durchführungen.
7.1.9 Change- & Release-Kalender
Der Change- & Release-Kalender zeigt die laufenden Aktivitäten im Change & Release Management in einer Kalenderdarstellung übersichtlich für alle beteiligten TI-ITSM-Teilnehmer dar. Der Kalender dient allen am Betrieb der TI Beteiligten dazu, sich über anstehende und durchgeführte Änderungen informieren zu können. Er ist zugleich ein Organisations- und Planungsinstrument im Rahmen des Change Managements. Er ersetzt nicht die aktive Steuerung eines Change in der TI, sondern ermöglicht eine langfristige Vorschau auf geplante Änderungen und ist ein zusätzliches Hilfsmittel bei der Analyse von Störungsursachen bezüglich der Identifikation von Seiteneffekten bereits umgesetzter Änderungen.
7.2 Prozessdurchführung Change & Release Management
7.2.1 Produkt-Change: Request for Change (RfC) erstellen
Produktänderungsbedarfe können durch verschiedene Einflussfaktoren bei den TI-ITSM-Teilnehmern festgestellt werden. Diese können sich aus dem Incident Management, dem Problem Management oder auch durch Änderungsbedarfe eines Produktes ergeben.
A_13575 - Qualität von RfCs
Der RfC-stellende TI-ITSM-Teilnehmer MUSS die RfCs so formulieren, dass der Umfang und der Bedarf in sich vollständig ist, so dass der Gesamtverantwortliche TI den RfC ohne Hinzuziehung weiterer Dokumente bewerten kann. [<=]
Nicht vollständig erfasste RfCs werden vom TI-ITSM-System nur gespeichert, nicht an den Gesamtverantwortlichen TI zur Bewertung und Autorisierung weitergeleitet.
GS-A_4400 - Produkt-RfC (Master-Change) erstellen
Alle TI-ITSM-Teilnehmer MÜSSEN für genehmigungspflichtige Produktänderungen einen Produkt-RfC (Master-Change) im TI-ITSM-System erstellen.
[<=]
GS-A_4398 - Prüfung auf genehmigungspflichtige Produktänderung
Alle TI-ITSM-Teilnehmer MÜSSEN jeden festgestellten Produktänderungsbedarf einer Prüfung gemäß der unten abgebildeten Tab_Betr_TIP_024 CHG – Vorprüfung Produktänderungsbedarf unterziehen. Dabei ist - durch Feststellung der Wechselwirkungen mit anderen Produkten sowie der Abweichung von Produkttypvorgaben - zu prüfen, ob es sich um eine genehmigungspflichtige Produktänderung handelt.
Tabelle 8: Tab_Betr_TIP_024 CHG – Vorprüfung. Produktänderungsbedarf
Change Typ |
Wechselwirkungen mit anderen Produkten (an den Schnittstellen) |
Abweichung von Produkttypvorgaben |
lokal autorisiert |
Nein |
Nein |
genehmigungspflichtig |
Nein |
Ja |
genehmigungspflichtig |
Ja |
Nein |
genehmigungspflichtig |
Ja |
Ja |
[<=]
GS-A_4424 - Umsetzung des Fallbackplans5597 - Produkt-RfC (Sub-Changes) erstellen
Anbieter MÜSSEN einen Fallbackplan nach den Vorgaben des SBV erstellen und – bei erkannter Notwendigkeit während des Change Deployments – umsetzen.
(Die Notwendigkeit eines Fallbackplans wird i.d.R. gemeinsam mit dem SBV während der Bewertung des genehmigungspflichtigen Produkt-RfCs festgelegt. Sollten Abweichungen von dem dort definierten Vorgehen notwendig sein, wird der SBV dies an die Anbieter kommunizieren.)
[<=]
Produkt-Change-Umsetzung abbrechen
Ein genehmigungspflichtiger Produkt-Change kann ausschließlich durch den SBV abgebrochen werden (bspw. durch im Nachgang festgestellte Fehlannahmen im Produkt RfC).
Der SBV bricht dabei formal den Produkt-Change in der ZID ab, durch Setzen des Feldes „Status“ auf „Abgebrochen“. Die beteiligten Anbieter werden daraufhin durch den SBV in formalisierter Form über den Abbruch eines Produkt-Changes per E-Mail benachrichtigt.
5.4.8 Produkt-Change abschließen
GS-A_4425 - Übermittlung von Optimierungsmöglichkeiten zur Umsetzung von genehmigten Produkt-Changes an den SBV
Anbieter MÜSSEN mit erfolgtem Abschluss oder Abbruch des Produkt-Changes eine Bewertung durchführen und dabei gegebenenfalls erkannte Potenziale für mögliche Optimierungen zukünftiger Durchführungen von Produkt-Changes dem SBV mitteilen.
[<=] Der TI-ITSM-Teilnehmer MUSS zur Umsetzung der Änderungen des Master-Changes in den konkreten Betriebsumgebungen die abgeleiteten Sub-Changes auf Basis des autorisierten Master-Changes und der abgestimmten Rahmenbedingungen stellen.
[<=]
Lokal autorisierte Changes sind informationspflichtig im Rahmen des Configuration Managements (GS-A_4399).
Um die Wirksamkeit eines Produkt-Changes nachzuweisen, ist eine Verifikation notwendig. Hiermit wird nachgewiesen, dass der Produkt-Change wie geplant implementiert wurde und die TI-Fachanwendungen weiterhin verfügbar und funktional sind. Die Verifikationsbeschreibung ist Bestandteil des Master-Changes.
GS-A_5599 - Beschreibung der Verifikation des Produkt-Changes im RfC
Jeder TI-ITSM-Teilnehmer, der einen Produkt-RfC stellt, MUSS für diesen eine Verifikation beschreiben, welche die Wirksamkeit des Changes nachweist.
[<=]
GS-A_4404 - Übermittlung von Produktdaten nach Abschluss von genehmigungspflichtigen Produkt-Changes
Anbieter MÜSSEN nach dem Abschluss (nach der Produktivsetzung des Produkt-Changes als Produkt) von genehmigten Produkt-Changes den Änderungsdatensatz der Produktdaten an den SBV übermitteln.
[<=]
5.4.9 Produkt-Change: Phasen und Statusübergänge
Die Umsetzung eines Produkt-Changes findet in definierten Phasen statt. Jede Phase hat spezifische Inhalte, deren Umsetzung mit einem Status gekennzeichnet wird.
Dieser Status, die damit erreichten Ergebnisse sowie die verantwortliche Durchführung der Phasen sind in nachfolgender Tabelle dargestellt.
Der zutreffende Status wird formal vom SBV gesetzt, basierend auf den von den Anbietern gelieferten Informationen und den in der jeweiligen Phase erfolgten Abstimmungen zwischen allen Beteiligten der Change Umsetzung.5600 - Beschreibung der Verifikation des Produkt-Changes in Auswirkung auf andere TI-Fachanwendungen im RfC
Jeder TI-ITSM-Teilnehmer, der einen Produkt-RfC stellt, MUSS eine Verifikation beschreiben, welche die Ende-zu-Ende-Verfügbarkeit und -Funktionalität der entsprechenden Anwendungsfälle nach der vollständigen Implementierung des Changes in Auswirkung auf andere TI-Fachanwendungen nachweist.
[<=]
GS-A_5370 - Prüfung auf Emergency Change
Alle TI-ITSM-Teilnehmer MÜSSEN auf Grundlage der in Tabelle 12: Tab_Betr_TIP_048 CHG – Kriterien für Emergency Changes genannten Kriterien prüfen, ob die Notwendigkeit zur Durchführung eines Emergency Change besteht.
Tabelle 169: Tab_Betr_TIP_49048 CHG – Phasen im Produkt-Change und StatusübergängeKriterien für Emergency Changes
|
|
|
|
||||||
|
|
|
|
||||||
|
|
|
|
||||||
|
|
|
|
||||||
|
|
|
|
||||||
|
|
|
|
||||||
|
|
|
|
||||||
|
|
|
|
||||||
|
|
|
|
||||||
|
|
|
|
||||||
|
|
|
|
||||||
|
|
|
|
||||||
|
|
|
|
||||||
|
|
||||||||
Folgende Grafik bietet eine Übersicht zu den Phasen und Statusübergängen:
Abbildung 5: CHG – Bearbeitungsstatus: Phasen und Statusübergänge
5.4.10 Produkt-Change: Behandlung von Standard Changes
Um eine effiziente Durchführung von unkritischen, zeitlich gut planbaren und wiederholt durchzuführenden „Routine“ Produkt-Changes nicht durch unnötigen Aufwand zu behindern, können derartige Changes als „Standard Changes“ durchgeführt werden. Für diese Change Kategorie gelten die Klassifikationen gemäß „Tab_Betr_TIP_046 CHG – Festlegung von Change Kategorie und Auswirkung“
[<=]
7.2.2 Produkt-Change: RfC bewerten
Die Bewertung und Autorisierung eines RfC obliegt dem Gesamtverantwortlichen TI. Um diese Aufgabe wahrzunehmen ist er ggf. auf die Unterstützung weiterer TI-ITSM-Teilnehmer angewiesen.
GS-A_5365 - Deklarierung von Produkt-Changes als Standard Changes4402 - Mitwirkungspflicht bei der Bewertung vom Produkt-RfC
Der SBV MUSS prüfen, ob ein erfolgreich durchgeführter Produkt-Change in Zukunft als „Standard Change“ durchgeführt werden kann. Die Prüfung erfolgt auf Grundlage von Bewertungsinhalten, die der Anbieter übermittelt hat und auf Grundlage des durchgeführten Change-Reviews.
Der SBV MUSS bei positivem Prüfungsergebnis für die zukünftige Durchführung des geprüften Produkt-Changes die Kategorie „Standard Change“ setzen.
[<=]
GS-A_5380 - Publizierung von autorisierten Standard Produkt-Changes
Der SBV MUSS einen Katalog von autorisierten Standard Produkt-Changes einrichten und diesen aktuell halten.
Der SBV MUSS diesen Katalog den Anbietern in der WDB zu Verfügung stellen.
[<=]
GS-A_5366 - Mitwirkungspflicht der Anbieter bei der Festsetzung von Standard Produkt Changes
Die Anbieter MÜSSEN zur abschließenden Kategorisierung von Produkt-Changes als „Standard Change“ den SBV unterstützen, indem sie die zur Prüfung erforderlichen Inhalte auf Anforderung an den SBV liefern.
Die Anbieter MÜSSEN für die zukünftige Umsetzung des Produkt-Changes als „Standard Change“ die zum jeweiligen Produkt-Change dazugehörigen Umsetzungsaktivitäten dokumentieren und diese dem SBV übergeben. Alle betroffenen TI-ITSM-Teilnehmer MÜSSEN bei der Bewertung eines Produkt-RfC mitwirken. Die Mitwirkung erfolgt innerhalb der Bewertungsphase im BCB oder bilateral zwischen TI-ITSM-Teilnehmer und Gesamtverantwortlichen TI.
[<=]
Damit der Gesamtverantwortliche TI die Aufgabe der Bewertung und Autorisierung in angemessener Qualität durchführen kann sind Bearbeitungsfristen festgelegt.
GS-A_5610 - Bearbeitungsfristen in der Bewertung von Produkt-Changes
Alle betroffenen TI-ITSM-Teilnehmer MÜSSEN folgende Fristen bei der Erstellung eines RfCs beachten:
- Produkt-Change (Master): mindestens 10 Werktage (zwischen Beantragung und Umsetzung)
- Produkt-Change (Sub): mindestens 5 Werktage (zwischen Beantragung und Umsetzung)
[<=]
GS-A_5367 - Durchführung von Standard Produkt-Changes durch Anbieter
Die Anbieter MÜSSEN bei der Umsetzung von Standard Produkt-Changes den jeweiligen festgelegten, spezifischen Umsetzungsroutinen folgen und in der Dokumentation der Umsetzung auf diese verweisen.
Die Anbieter MÜSSEN bei Erkennen einer notwendigen größeren Abweichung von den festgelegten Umsetzungsroutinen den SBV darüber unterrichten und den Produkt-Change als „Non-Standard Change“ durchführen.
[<=]
GS-A_5368 - Steuerung von Standard Produkt-Changes durch den SBVWerden diese Fristen nicht eingehalten, so kann der Gesamtverantwortliche TI die Bewertung des Changes ablehnen. Dies führt zu einer Stornierung des RfC bzw. des gesamten Change-Vorgangs.
7.2.3 Produkt-Change: RfC genehmigen
Der SBV MUSS von den Anbietern beantragte Standard Produkt-Changes in einem beschleunigten Genehmigungsverfahren bearbeiten. Der SBV MUSS diese Produkt-Changes in maximal 5 AT (Mo-Fr) nach Beantragung zur Umsetzung freigeben.
[<=]
Beispiele für Produkt-Changes, die als „Standard Change“ einzustufen wären:
Zyklisches Wartungsfenster
o Wartungsfenster werden vom Anbieter angekündigt und in der Nebenzeit, mit Unterbrechung des Services ausgeführt. Der Inhalt der Arbeiten wird kommuniziert, z.B. Patchen, Upgrades etc., die Ausführungszeit wird festgelegt, der Change wird als Standard eingestuft.
Geplante Arbeiten von 3rd Parties, z.B. dem WAN Provider
o Arbeiten von Netzbetreibern werden in der Regel langfristig angekündigt. Diese Changes können als Standard Changes eingestuft und über den Change- und Release Kalender angekündigt werden.
5.4.11 Produkt-Change: Durchführung von Emergency Changes
Ein Emergency Change ist eine Änderung, die aufgrund einer Notsituation durchgeführt werden muss, um so schnell wie möglich diese Situation zu lindern. Emergency Changes können in folgenden beispielhaften Situationen erforderlich werden:
o Nichtverfügbarkeit eines zentralen Plattformdienstes, die höchste Auswirkung für die TI hat („Major Incident“).
o Fehlgeschlagener Produkt-Change, der nicht durch ein Fallback zurückgenommen werden kann, da Auswirkungen auf andere Produkte bestehen.
o Entdeckte Sicherheitslücke, die umgehend behoben werden muss, um (weiteren) Schaden von der TI abzuwenden („emergency security patch“).
Die Dringlichkeit der notwendigen Korrektur lässt unter Umständen kein üblicherweise erforderliches Testen zu; die sofortige Heilung der Notsituation ist das primäre Ziel. Das damit einhergehende Risiko wird bewusst in Kauf genommen.
Für die kontrollierte Durchführung von Emergency Changes wird ein Entscheidungsgremium, das Emergency Change Advisory Board (eCAB) implementiert, das den SBV bei der Bewertung von auftretenden Emergency Changes wirksam unterstützt.
GS-A_5369 - Steuerung von Emergency Changes
Der GTI und/oder das Emergency Change Advisory Board (eCAB) MÜSSEN den SBV bei Bewertung, Autorisierung und Freigabe von Emergency Changes unterstützen.Der GTI und/oder das Emergency Change Advisory Board (eCAB) MÜSSEN Emergency Changes so schnell wie möglich freigeben.[<=]
Bei der Bewältigung eines TI-Notfalls durch Emergency Changes sind die Anforderungen des Notfallmanagements zu beachtenrealisierende TI-ITSM-Teilnehmer hat sich die für die Autorisierung notwendigen Genehmigungen des GesamtverantwortIichen der TI einzuholen.
GS-A_5611 - Umsetzung von autorisierten RFC
TI-ITSM-Teilnehmer MÜSSEN vor der Umsetzung eines RfCs die Autorisierung des Gesamtverantwortlichen TI einholen. Ausnahmenregelungen beziehen sich einzig auf Emergency Changes.
[<=]
7.2.4 Produkt-Change umsetzen
Die Umsetzung des autorisierten Produkt-Changes obliegt dem zuständigen TI-ITSM-Teilnehmer. Die Umsetzung eines Master-Changes bedeutet, dass im nächsten Schritt die konkreten Sub-RfCs durch den TI-ITSM-Teilnehmer gestellt werden.
Die Umsetzung von Sub-RfCs bedeutet die konkrete Änderung eines Produktes und damit einer logischen Produktinstanz in der jeweiligen Betriebsumgebung. Grundsätzlich wird davon ausgegangen, dass jede Änderung eines Produktes von der RU über die TU bis zur PU sequenziell durchgeführt werden muss. Ausnahmen davon müssen im Rahmen des Master-Changes zwischen TI-ITSM-Teilnehmer und dem Gesamtverantwortlichen TI vereinbart werden.
Die Referenzumgebung (RU) und die Testumgebung (TU) werden vom Gesamtverantwortlichen TI koordiniert. Der realisierende TI-ITSM-Teilnehmer stimmt sich mit der testkoordinierenden Instanz ab und berücksichtigt diese Abstimmung in der Ausprägung der entsprechenden Sub-RfCs (RU und TU).
GS-A_5370 - Feststellen von Emergency Changes durch Anbieter4419 - Nutzung der Testumgebung (RU/TU)
Die Anbieter MÜSSEN auf Grundlage der in Tab_Betr_TIP_048 CHG – Kriterien für Emergency Changes genannten Kriterien die erkannte Notwendigkeit zur Durchführung eines Emergency Changes feststellen und diese auf schnellstem Weg an den SBV mitteilen. Die Anbieter MÜSSEN erforderliche Dokumentationen zur Bewertung der Notsituation liefern, soweit dies zeitlich möglich ist. Die Anbieter MÜSSEN bei Durchführung aller Aktivitäten beachten, dass die Notsituation durch Zeitverzug nicht noch weiter eskaliert wird.
[<=]
Die Meldung eines notwendigen Emergency Changes durch Anbieter kann telefonisch erfolgen. Die weitere Bewertung und Freigabe / Ablehnung durch den SBV kann ebenfalls auf diesem Wege stattfinden.
GS-A_5378 - Durchführung von Emergency Changes durch Anbieter
Die Anbieter MÜSSEN bei der Umsetzung eines Emergency Changes die zeitliche Kritikalität beachten, d.h. die eingetretene Notsituation schnellstmöglich beseitigen.
Die Anbieter MÜSSEN bei der Umsetzung eines Emergency Changes den Anweisungen (Freigabe, Ablehnung, Testanforderungen, Dokumentation) des SBV folgen.
Die Anbieter MÜSSEN die erforderliche Dokumentation des Emergency Changes in der ZID spätestens nach der Umsetzung erstellen.
[<=]
Sollte – bedingt durch Nichterreichbarkeit des SBV außerhalb der ITSM Service Zeit der gematik – keine Entscheidungsfindung zur Durchführung des Emergency Changes möglich sein, gilt folgende Regelung:
GS-A_5361 - Durchführung von Emergency Changes durch Anbieter bei Nichterreichbarkeit des SBVs außerhalb der ITSM Servicezeit der gematik
Die Anbieter MÜSSEN bei Nichterreichbarkeit des SBVs außerhalb der gematik ITSM Servicezeit - und daraus fehlender Freigabe durch den SBV - einen Emergency Change aus eigenem Ermessen durchführen.
Die Anbieter MÜSSEN dabei das Zutreffen aller drei folgenden Bedingungen beachten:
1. Es handelt sich nach fachlich-fundierter Bewertung des Anbieters um eine Notsituation, die nur durch einen Emergency Change gelöst werden kann.
2. Der Anbieter wird nach erfolgter Umsetzung des Emergency Changes unverzüglich eine Dokumentation hierzu erstellen und an den SBV übermitteln.
3. Soweit durch den Anbieter in dieser Situation erkennbar, entstehen durch die Umsetzung des Emergency Changes keine finanziellen Auswirkungen für die gematik.
[<=]
5.5 Service Level Requirements (SLR)TI-ITSM-Teilnehmer MÜSSEN die Anforderungen und die geplante Belegung an die Nutzung der Referenzumgebung (RU) und der Testumgebung (TU) für ihre Produkttests mit dem Gesamtverantwortlichen TI abstimmen.
[<=]
Das Deployment eines Produkt-Changes wird durch den Gesamtverantwortlichen TI zeitlich und verfahrenstechnisch überwacht. TI-ITSM-Teilnehmer müssen die Umsetzung des Produkt-Changes gemäß den Vorgaben vom Gesamtverantwortlichen TI durchführen und stetig deren Einhaltung prüfen und Abweichungen an den Gesamtverantwortlichen TI über das TI-ITSM-System kommunizieren.
GS-A_4417 - Stetige Aktualisierung des Change-Datensatzes im TI-ITSM-System
Realisierende TI-ITSM-Teilnehmer MÜSSEN die interne Dokumentation der Planungs- und Realisierungsdaten von autorisierten Produkt-Changes stetig im TI-ITSM-System aktuell halten.
[<=]
Ein Produkt-Change gilt als implementiert, wenn:
- bei zentralen Produkten die Integration der geänderten Produktversion in die jeweilige Betriebsumgebung abgeschlossen ist,
- bei dezentralen Produkten die geänderte Produktversion auf dem Konfigurations-Software-Repository (KSR) bereitgestellt ist.
7.2.5 Produkt-Change: Umsetzung verifizieren
GS-A_44055601 - Service Level Requirements für genehmigungspflichtige Produkt-Nachweis der Wirksamkeit eines Changes
Aufbauend auf die in den jeweiligen Verträgen geregelten Servicezeiten MÜSSEN Anbieter für genehmigte Produkt-Changes mindestens folgende Service Level messen:
Tabelle 17: Tab_Betr_TIP_005 CHG – Change Management – SLP "Prozess"
|
|
|
|
|
|
|
|
|
|
Service Level werden im Betriebskonzept [gemKPT_Betr] ausgeprägt. [<=]
Die SLR-Berichtsdaten können von Anbietern im Webportal der ZID generiert und zur Erstellung exportiert werden. Voraussetzung hierzu ist, dass die Rückmeldung der Anbieter auf Bewertungsanfragen des SBV durchgängig im Webportal der ZID erfolgen.
5.6 Informationspflichten
GS-A_4406 - Aktualität des Change- & Releasekalenders
Anbieter MÜSSEN den SBV bei Änderungen der Umsetzungsplanung und -durchführung sowie bei Abweichungen im Change-/Releasekalender zu einem Produkt-Change/-Release unverzüglich informieren, damit dieser den Change-/Releasekalender aktualisieren kann.
[<=]
5.7 Dokumentation
Die Dokumentation des Change Managements dient insbesondere der Steuerung und der Schaffung der Nachvollziehbarkeit von Produkt-Changes.
Für die ordnungsgemäße Umsetzung der Dokumentation ist ausschließlich der Anbieter verantwortlichJeder TI-ITSM-Teilnehmer, der einen Produkt-RfC stellt, SOLL eine Verifikation durchführen, welche die Wirksamkeit des Changes nachweist. Der TI-ITSM-Teilnehmer SOLL dem Gesamtverantwortlichen TI die entsprechenden Nachweise vorlegen.
[<=]
GS-A_5602 - Nachweis der Wirksamkeit eines Changes in Auswirkung auf andere TI-Fachanwendungen
Jeder TI-ITSM-Teilnehmer, der einen Produkt-RfC stellt, SOLL auf Anfrage des Gesamtverantwortlichen TI eine Verifikation durchführen, welche die Ende-zu-Ende-Verfügbarkeit und -Funktionalität eines entsprechenden Anwendungsfalls der veränderten Produktinstanz nachweist. Der TI-ITSM-Teilnehmer SOLL dem Gesamtverantwortlichen TI die entsprechenden Nachweise vorlegen.
[<=]
7.2.6 Produkt-Change abschließen
Sind die Umsetzungsarbeiten abgeschlossen, kann der Change nach erfolgreicher Verifikation und abschließender Dokumentation geschlossen werden.
GS-A_4407 - Bereitstellung der Dokumentation des Change Managements für genehmigungspflichtige Produkt-Changes
AnbieterTI-ITSM-Teilnehmer MÜSSEN für jeden genehmigungspflichtigen Produkt-Change eine Change-Dokumentation anlegen und an den SBV übermitteln. Die Change-Dokumentation setzt sich aus dem jeweils zu dem Produkt-Change dazugehörigen Produkt-RfC sowie der nachvollziehbaren Dokumentation der Change-Umsetzung zusammen.
[<=]
Die in der Umsetzungsphase des Produkt-Changes seitens der Anbieter bestehende Dokumentationspflicht kann, soweit sie die für den Vorgangsdatenreport erforderlichen Daten betrifft (siehe Kap. 5.9), vom Anbieter im Webportal der ZID vorgenommen werden. In diesem Fall kann die Übermittlungspflicht an den SBV – bei entsprechend vorgenommener Dokumentation – im Webportal der ZID ausgeführt werden.
Die darüber hinausgehende Dokumentation (Projektpläne, Entwicklungsdaten, Testergebnisse, Logfiles etc.) erfolgt weiterhin Anbieter- -intern, die Kommunikation dieser Daten oder Dokumente erfolgt in der Regel außerhalb der ZID.
Ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.
5.8 Eskalationen
GS-A_4408 - Eskalation für genehmigte Produkt-Changes während der Test- oder Deploymentdurchführung
Anbieter KÖNNEN bei schwerwiegenden Konflikten während der Test- oder Produktivsetzungsdurchführung von autorisierten Produkt-Changes eine hierarchische Eskalation an den SBV einleiten, wenn
o während der Tests oder der Produktivsetzung Fehler festgestellt werden, deren Ursache der Anbieter nicht ohne übergreifende Koordination durch den SBV beheben kann,
o die Auswirkung eines Fallbacks nicht ausschließlich auf den Produkt-Change beschränkt ist.
[<=]
GS-A_4409 - Eskalation für genehmigte Produkt-Changes während der Bewertung von Produkt-Changes
Die Autorisierung des genehmigungspflichtigen Produkt-RfC erfolgt im Konsens zwischen dem realisierenden Anbieter und dem zuständigen SBV. Anbieter KÖNNEN bei schwerwiegenden Konflikten während der Bewertung der notwendigen Anpassungen an Produkten, d.h. während der Bewertung von Produkt-Changes, eine hierarchische Eskalation an den GTI einleiten, wenn keine Einigung zwischen SBV und Anbieter des Produktes erzielt werden kann. [<=]
5.9 Prozessreporting (Vorgangsdaten) CHG
Das Prozessreporting dient voranging der Übermittlung des aktuellen Status zu einem Produkt-Change.
Ist der Status des Produkt-Changes innerhalb der Vorgangsdaten des Prozessreportings auf „abgeschlossen“ gesetzt worden, muss der Produkt-Change damit letztmalig innerhalb des konsolidierten Reports berichtet werden und wird nicht mehr in Folgereports erwähnt.
GS-A_4410 - Bereitstellung von Vorgangsdaten für autorisierte Produkt -Changes
Anbieter MÜSSEN für jeden Produkt-Change einen Datensatz für das Vorgangsdatenreporting anlegen.
(Die Anlage muss mit der Aufzeichnung oder dem Erhalt (eigeninitiiert oder durch den SBV übermittelt) für jeden genehmigungspflichtigen Produkt-RfC erfolgen.)
[<=]
GS-A_4411 - Reportinginhalte des Change-Management-Prozessreportings
Anbieter MÜSSEN Vorgangsdatenreports nach der folgenden, vorgegebenen Struktur erstellen:
Tabelle 18: Tab_Betr_TIP_006 CHG – Reportinginhalte des CHG-Prozessreportings
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[<=] der Aktivitäten und Nachweise im TI-ITSM-System ablegen. [<=]
Nach Abschluss des letzten Sub-RfCs ist der zugehörige Master-RfC ebenfalls vom TI-ITSM-Teilnehmer abzuschließen. Dabei kann der TI-ITSM-Teilnehmer Anforderungen an zukünftige Durchführungen ähnlicher Art, die zur Optimierung des Durchführungsprozesses dienen, an den Gesamtverantwortlichen TI übermitteln.
GS-A_4425 - Übermittlung von Optimierungsmöglichkeiten zur Umsetzung von genehmigten Produkt-Changes
TI-ITSM-Teilnehmer MÜSSEN mit erfolgtem Abschluss oder Abbruch des Produkt-Changes eine Bewertung des Master-Changes durchführen und dabei gegebenenfalls erkannte Potenziale für mögliche Optimierungen zukünftiger Durchführungen von Produkt-Changes dem Gesamtverantwortlichen TI mitteilen.
[<=]
Der Gesamtverantwortliche TI wird nach einem ggf. mit dem durchführenden TI-ITSM-Teilnehmer abschließenden PIR (Post Implementation Review) den Master-Change und damit den Gesamtvorgang schließen.
7.3 Abweichungen im Prozessablauf
Bei einer festgestellten Abweichung des dem aktuellen Produkt-Change zugrunde liegenden Produkt-RfCs wird der Gesamtverantwortliche TI entscheiden, welche Konsequenzen die Feststellung bzw. Abweichung auf die weitere Durchführung des Produkt-Changes hat und welche Maßnahmen zu treffen sind.
Dazu wird sich der Gesamtverantwortliche TI mit dem durchführenden TI-ITSM-Teilnehmer und bei Bedarf mit den beteiligten TI-ITSM-Teilnehmern beraten. Die Ergebnisse werden vom Gesamtverantwortlichen TI im TI-ITSM-System dokumentiert, ebenso wie eine eventuelle Status-Änderung des Produkt-Changes (bspw. Stornierung). Die beteiligten TI-ITSM-Teilnehmer werden vom Gesamtverantwortlichen TI hierüber abschließend per E-Mail informiert.
GS-A_4412 - Bereitstellung der Change Management Vorgangsdaten mittels Prozessreporting4418 - Übermittlung von Abweichungen vom Produkt-RfC
Anbieter MÜSSEN den an den SBV zu versendenden Change Management Report im CSV-Format übermitteln.
Anbieter MÜSSEN bei den an den SBV zu versendenden Change Management Reports die AFO GS-A_5248 beachten.
[<=]
Werden vom Anbieter die für das Prozessreporting erforderlichen Daten lückenlos im Webportal der ZID gepflegt, kann das Reporting vom Anbieter aus der ZID heraus erfolgen.
Ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.
6 Configuration Management (CM)
Um den Gesamtverantwortlichen der TI und den Serviceverantwortlichen Informationen über die für die Erbringung von TI-Services erforderlichen Konfigurationselemente (Configuration Items, CI) und deren Beziehungen untereinander bereitzustellen, ist ein Configuration Management (CM) zu etablieren. Über das Configuration Management stehen für die Prozesse und Aufgaben über den gesamten Lebenszyklus der Services konsistente Daten und Informationen zur Verfügung.
Die nachfolgende „Abbildung 6: CM – TI-Services: Beziehung der CMDB-TI “ veranschaulicht den allgemeinen Aufbau der TI- Konfigurationsdatenbank. Der jeweilige ITSM-TI-Teilnehmer übermittelt Informationen zu den von ihm verantworteten CI (Produkt) an den SBV. Der SBV konsolidiert die produktspezifischen Konfigurationsdaten und pflegt die TI Konfigurationsdatenbank sowie die CI Relationen (Erstellung und Aktualisierung). Das übergreifende Configuration Management wird durch den GTI etabliert. Der GTI stellt das Konfigurationsmodell inklusive der Relationen zur Verfügung. Dazu wird eine TI- Konfigurationsdatenbank als betriebsunterstützendes System implementiert. Die Dokumentation der spezifischen Konfiguration der IT-Architektur der Produkte obliegt dem ITSM-TI-Teilnehmer in seinem lokalen Konfigurationssystem. Dabei bilden die Produkte das Bindeglied zwischen der TI-Konfigurationsdatenbank und den lokalen Konfigurationssystemen der ITSM-TI-Teilnehmer.
Abbildung 6: CM – TI-Services: Beziehung der CMDB-TI zur lokalen CMDB der ITSM-TI-Teilnehmer
Im Fokus der nachfolgenden Regelungen stehen die Mindestanforderungen zum Informationsaustausch zwischen lokalem CM und TI-Konfigurationsdatenbank.
Die nachfolgende Abbildung veranschaulicht die Regelungen des Configuration Managements im für die ITSM-TI-Teilnehmer relevanten Prozessausschnitt mit Fokus auf deren Aufgaben.
Abbildung 7: CM – Gesamtüberblick "Configuration Management“
6.1 Betrachtungsgegenstand des übergreifenden CM
Fokus der nachfolgenden Configuration-Management-Regelungen im Betrieb ist die Bereitstellung der Konfigurationsdaten durch die ITSM-TI-Teilnehmer.
6.2 Begriffserläuterungen
6.2.1 Konfigurationselement (Configuration Item, CI)
Ein Konfigurationselement (Configuration Item, CI) ist eine formalisierte Beschreibung einer zum Betrieb erforderlichen Komponente, über deren gesamten Lebenszyklus hinweg. Konfigurationselemente werden durch das Configuration Management strukturiert, dokumentiert und in einer Datenbank zusammengefasst und gepflegt.
Beispiele für CIs sind Services, Produkte, Produkttypen, produktverantwortliche Organisationen und Prozess- und Betriebsdokumentationen.
6.2.2 Konfiguration
Die Konfiguration ist eine Bezeichnung für eine Gruppe von Konfigurationselementen, die miteinander verbunden für die Erbringung eines Service oder eines umfangreichen Teils eines Service eingesetzt werden.
6.2.3 TI-Konfigurationsdatenbank
Die TI-Konfigurationsdatenbank ist ein Werkzeug, welches die Konfigurationsdaten der TI-Services enthält, die der Gesamtverantwortliche der TI zur Entscheidungshilfe und zur Steuerung des übergreifenden IT-Service-Managements der TI benötigt.
6.2.4 Konfigurationsdaten
Konfigurationsdaten sind die Attribute zu einem CI. In dieser Richtlinie werden für ITSM-TI-Teilnehmer folgende Minimaldaten für CIs festgelegt:
o CI „Produktverantwortliche Organisation“: Allgemeine Informationen zu einem ITSM-TI-Teilnehmer, bspw. Anschrift und Ansprechpartner.
o CI „Produkt“: Produktspezifische Konfigurationsdaten der ITSM-TI-Teilnehmer, bspw. Produktname, -version, -beschreibung etc.
6.3 Prozessdurchführung zur Bereitstellung von Konfigurationsdaten
6.3.1 Prozessreporting (Konfigurationsdaten) CM
ITSM-TI-Teilnehmer führen Änderungen kontrolliert im Rahmen des Change & Release Managements durch. Nach erfolgter Änderung werden Konfigurationsdaten aktualisiert und dem SBV eine konsistente Informationsbasis bereitgestellt.
Die Beziehung zwischen lokalem CM und TI-Konfigurationsdatenbank (vgl. „Abbildung 6: CM – TI-Services: Beziehung der CMDB-TI “) werden für die von den ITSM-TI-Teilnehmern verantworteten CI weiter verdeutlicht: in „Abbildung 8: KM – Übersicht der Relationen“ werden die Relationen dieser CI dargestellt und die durch die ITSM-TI-Teilnehmer zu liefernden CI Daten tabellarisch aufgezeigt.
Abbildung 8: KM – Übersicht der Relationen
CI „Produktverantwortliche Organisation“
GS-A_4112 - Datenbereitstellung für CI „Produktverantwortliche Organisation“
ITSM-TI-Teilnehmer MÜSSEN folgende Daten für das CI „Produktverantwortliche Organisation“ an den SBV übermitteln:
Tabelle 19: Tab_Betr_TIP_007 CM – CI „Produktverantwortliche Organisation“
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[<=]
GS-A_4113 - Datenänderung für CI „Produktverantwortliche Organisation“
ITSM-TI-Teilnehmer MÜSSEN bei Datenänderung des CIs „Produktverantwortliche Organisation“ einen Report im CSV-Format an den SBV versenden.
[<=]
CI „Produkt“
GS-A_4114 - Datenbereitstellung für CI „Produkt“
ITSM-TI-Teilnehmer MÜSSEN bei jeder Datenänderung für das CI „Produkt“ einen Änderungsdatensatz an den SBV übermitteln. ITSM-TI-Teilnehmer MÜSSEN Daten des CIs „Produkt“ für jede neue Produktversion nach folgendem Schema übermitteln:
Tabelle 20: Tab_Betr_TIP_008 CM – „CI Produkt“
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[<=] TI-ITSM-Teilnehme, die während der Umsetzung des autorisierten Produkt-Changes Abweichungen zur Planung in Bezug auf zeitliche, inhaltliche und in der Auswirkung im Produkt-RfC feststellen, MÜSSEN diese unverzüglich dem Gesamtverantwortlichen TI melden.
[<=]
Festgestellte schwerwiegende Konflikte bei der Bewertung oder Durchführung eines Produkt-Changes sind gemäß GS-A_3920 an den Gesamtverantwortlichen TI zu eskalieren.
Stellen die an einem Produkt-Change beteiligten TI-ITSM-Teilnehmer negative Auswirkungen einer Änderung während der Umsetzung fest, so kann der Gesamtverantwortliche TI die Durchführung des im Produkt-Change hinterlegten Fallbackplans anweisen.
GS-A_4424 - Umsetzung des Fallbackplans
TI-ITSM-Teilnehmer MÜSSEN einen Fallbackplan nach den Vorgaben des Gesamtverantwortlichen TI erstellen und – bei erkannter Notwendigkeit während des Change Deployments – umsetzen.
[<=]
7.4 Verfahren für einen Standard-Change
Um eine effiziente Durchführung von unkritischen, zeitlich gut planbaren und wiederholt durchzuführenden „Routine“ Produkt-Changes zu gewährleisten, können Changes als „Standard-Changes“ durchgeführt werden.
Standard-Changes werden durch den Gesamtverantwortlichen TI im Rahmen des Change Managements definiert. Jeder Change durchläuft zunächst den Non-Standard Change-Prozess. Aus einem Non-Standard-Change wird ein Standard-Change, wenn folgende Kriterien erfüllt sind:
- Erstmalige, fehlerfreie Ausführung des Non-Standard-Changes und
- Minimales Risiko bei der Ausführung.
GS-A_5366 - Mitwirkungspflicht der TI-ITSM-Teilnehmer bei der Festsetzung von Standard-Produkt-Changes
TI-ITSM-Teilnehmer MÜSSEN zur abschließenden Kategorisierung von Produkt-Changes als „Standard-Change“ den Gesamtverantwortlichen TI unterstützen, indem sie die zur Prüfung erforderlichen Inhalte auf Anforderung an den Gesamtverantwortlichen TI liefern.
TI-ITSM-Teilnehmer MÜSSEN für die zukünftige Umsetzung des Produkt-Changes als „Standard-Change“ die zum jeweiligen Produkt-Change dazugehörigen Umsetzungsaktivitäten dokumentieren und diese dem Gesamtverantwortlichen TI übergeben.
[<=]
Die Abstimmung der Standard-Changes findet im Rahmen des Post Implementation Reviews statt.
7.5 Verfahren für einen Emergency-Change
GS-A_5378 - Durchführung von Emergency-Changes durch TI-ITSM-Teilnehmer
TI-ITSM-Teilnehmer MÜSSEN bei der Umsetzung eines Emergency-Changes die zeitliche Kritikalität beachten, d. h., die eingetretene Notsituation schnellstmöglich beseitigen und bei der Umsetzung den Anweisungen (Freigabe, Ablehnung, Testanforderungen, Dokumentation) des Gesamtverantwortlichen TI folgen.
[<=]
GS-A_4115 - Datenänderung für CI „Produkt“
ITSM-TI-Teilnehmer MÜSSEN bei Datenänderung des CIs „Produkt“ einen Report im CSV-Format an den SBV versenden.
[<=]
6.3.2 SPED Report
In diesem Report werden Daten der dezentralen Produkte / Anwenderkomponenten bereitgestellt. Es geht nicht um die detaillierte Konfiguration vor Ort bei Leistungserbringern, sondern die Menge der von den Anbietern und SPEDs implementierten Produkte / Anwenderkomponenten, differenziert nach Produktbezeichnung und Firmware Version
GS-A_5362 - Bereitstellung eines Reports durch SPEDs
SPEDs MÜSSEN dem GTI einen monatlichen Produkt Report, spätestens innerhalb der ersten Woche des Folgemonats bereitstellen. Folgende Informationen sind als Datensatz je eingesetzter Produktversion zu übermitteln:
Tabelle 21: Tab_Betr_TIP_047 CM – „ITSM-TI-Teilnehmer-Report“
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Folgende Konvention zum Dateinamen ist bei der Übermittlung einzuhalten:
o Jahr und dem Monat des Berichtzeitraumes (JJJJMM)
o Bezeichnung des Reports „TI“ für ITSM-TI-Teilnehmer-Report
o Teilnehmer-ID (TID) des SPEDs
o fortlaufenden Versionsnummer (VNR) (Hochzählung der Versionsnummer bei Veränderung der übermittelten Daten)
o <Dateiname>=<JJJJMM>-KR-SP-<TID>-<VNR>.csv
[<=]
6.3.3 Bereitstellung Ad-hoc Report
GS-A_4116 - Bereitstellung Ad-hoc Report
ITSM-TI-Teilnehmer MÜSSEN dem SBV auf Anfrage kurzfristig Konfigurationsdaten für Produkte und Produktinstanzen im Rahmen des Ad-hoc Reportings zur Verfügung stellen.
Inhalt und Format wird im Bedarfsfall mit den betroffenen ITSM-TI-Teilnehmern individuell abgestimmt.5361 - Durchführung von Emergency-Changes durch TI-ITSM-Teilnehmer bei Nichterreichbarkeit des Gesamtverantwortlichen TI
TI-ITSM-Teilnehmer MÜSSEN bei Nichterreichbarkeit des Gesamtverantwortlichen TI außerhalb der Servicezeit - und daraus resultierenden fehlenden Freigabe – einen Emergency Change in eigenem Ermessen durchführen.
TI-ITSM-Teilnehmer MÜSSEN dabei das Zutreffen aller drei folgenden Bedingungen beachten:
- Es handelt sich nach fachlich-fundierter Bewertung des TI-ITSM-Teilnehmers um eine Notsituation, die nur durch einen Emergency-Change gelöst werden kann.
- Der TI-ITSM-Teilnehmer wird nach erfolgter Umsetzung des Emergency-Changes unverzüglich die Dokumentation im TI-ITSM-System erstellen und an den Gesamtverantwortlichen TI übermitteln.
- Es entstehen – soweit durch den TI-ITSM-Teilnehmer in dieser Situation erkennbar – durch die Umsetzung des Emergency Changes keine finanziellen Auswirkungen für den Gesamtverantwortlichen TI.
[<=]
67.4 Obliegenheiten SBV/GTI6 Service Level Requirements
Obliegenheiten des SBV:
Der SBV ist verantwortlich für die Konsolidierung der von ITSM-TI-Teilnehmern erhaltenen Konfigurationsdaten und die Pflege der TI-Konfigurationsdatenbank.
Der SBV wird im Rahmen des Configuration Managements an ITSM-TI-Teilnehmer Mitteilungen bzgl. der Änderungsanforderungen zu Konfigurationsdaten versenden.
Obliegenheiten des GTI:
Der GTI veröffentlicht die Listen der Teilnehmer-IDs sowie der zugelassenen Produkte.
7 Knowledge Management (KM)Die Ermittlung des Service Level Reaktionszeit Produkt-RfC Bewertung erfolgt direkt im TI-ITSM-System. Die Ausgestaltung der Service Level erfolgt im Betriebskonzept [gemKPT_Betr].
GS-A_4405 - Service Level Requirements im Change und Release Management
Die TI-ITSM-Teilnehmer MÜSSEN die Servicezeiten gemäß TIP1-A_7265 [gemKPT_Betr] im Change- und Release Management einhalten. [<=]
8 Knowledge Management
Durch den Gesamtverantwortlichen der TI wird ein Knowledge Management (KM) etabliert, um den supportSupport-leistenden Organisationen die TI-Produktinformationen für die Ursachenanalyse und Lösungsfindung von Incidents und ProblemenProblems bereitzustellen. Diese Produktinformationen werden in der Wissensdatenbank des TI-ITSM-Systems bereitgestellt. Die Wissensdatenbank solldient dabei als erste Anlaufstelle für supportSupport-leistende Organisationen dienen.
Im Knowledge Management ToolIn der Wissensdatenbank abgelegte Produktinformationen sollen ITSM-TIunterstützen TI-ITSM-Teilnehmer sowie Anwender/DVO in der TI bei der Klärung im Betrieb bzw. bei der Nutzung auftretender Fragestellungen unterstützen. ITSM-TI. Alle TI-ITSM-Teilnehmer sindwerden verpflichtet, diese Informationen bereitzustellen.
Die nachfolgende Abbildung veranschaulicht die Regelungen des Knowledge Managements im ITSM-TI-Teilnehmer -relevanten Prozessausschnitt und mit Fokus auf die durch ITSM-TI-Teilnehmer zu unterstützenden Betriebsaufgaben in einem Schaubild.
Abbildung 9: KM – Gesamtüberblick "Knowledge Management“
7.1 Betrachtungsgegenstand des KM
Fokus der nachfolgenden Regelungen des Knowledge Managements ist die nicht-normative regelnde Informationsbereitstellung der ITSM-TI-Teilnehmer- bezogenen Produktinformationen, insbesondere zu Support-Schnittstellen und Ansprechpartnern.
7.2 Begriffserläuterungen
7.2.1 Wissensdatenbank (WDB)
Die Wissensdatenbank der TI wird durch den GTI bereitgestellt und unterstützt ITSM-TI-Teilnehmer sowie Anwender/DVO8.1 Begriffsbestimmungen
8.1.1 Wissensdatenbank (WDB) des TI-ITSM-Systems
Die Wissensdatenbank des TI-ITSM-Systems wird durch den Gesamtverantwortlichen TI bereitgestellt und unterstützt TI-ITSM-Teilnehmer im Falle einer Störung dabei, mehr Informationen über die möglichen Störungsursachen und möglichen Lösungen der Produkte zu erhalten und den für die Fehlerbehebung Verantwortlichen zu identifizieren und zu kontaktieren.
Die Wissensdatenbank soll in der initialen Ausbaustufe folgende Informationen bereitstellen:
Erläuterung zu Fehlercodes aus ProdukttypspezifikationAlle TI-ITSM-Teilnehmer erhalten über das TI-ITSM-System Zugang zur Wissensdatenbank.
Die Wissensdatenbank stellt mindestens folgende Informationen bereit:
- Produkt- und Serviceinformationen
- Erläuterungen zu Fehlercodes von Produkten (Knowledge Error Database (KEDB))
- Hinweise auf mögliche Ursachen sowie möglichen Lösungen des Fehlers
- Kontaktinformationen der lösungsverantwortlichen sowie problemlösungs-unterstützenden
ITSM-TI-ITSM-Teilnehmer.
78.32 Prozessdurchführung Bereitstellung der ProduktinformationKnowledge Management
78.32.1 Bereitstellung der ProduktinformationWissen identifizieren und übermitteln
GS-A_4117 - Bereitstellung der Produktinformation von AnbieternInformationsbereitstellung durch TI-ITSM-Teilnehmer
AnbieterTI-ITSM-Teilnehmer KÖNNEN für Nutzer ihrer Produkte (Anwender/DVOs sowie ITSM-TI-Teilnehmer) Produktinformationen über die möglichen Störungsursachen und Lösungen der Produkte an den SBV übermitteln.
[<=]
GS-A_5357 - Bereitstellung der Produktinformation von Herstellern
Hersteller MÜSSEN für Nutzer ihrer Produkte (Anwender/DVOs sowie ITSM-TI-Teilnehmer) allgemeine Produktinformationen sowie dokumentierte Fehlerbehandlungsroutinen (Error Codes, deren mögliche Ursachen sowie geeignete Maßnahmen zur Fehlerbeseitigung) einmalig im Zuge der Zulassung an den SBV übermitteln.
[<=]
GS-A_4413 - Aktualisierung der Produktinformation
ITSM-TI-Teilnehmer MÜSSEN bereitgestellte Informationen zu Produkten gemäß GS-A_4117 stets aktuell halten und bei Änderung den SBV informieren.
[<=]
GS-A_4118 - Bekanntmachung Support-Schnittstelle
ITSM-TI-Teilnehmer MÜSSEN dem SBV einen Link zur Support-Webseite mitteilen, der von ITSM-TI-Teilnehmern, Anwendern/DVOs zur Information bzgl. der Störungsursachen und möglicher Lösungen genutzt werden kann.
[<=]
GS-A_4119 - Benennung der Ansprechpartner
ITSM-TI-Teilnehmer MÜSSEN im Rahmen des Knowledge Managements einen für den SBV, den ITSM-TI-Teilnehmern und Anwendern/DVOs zugänglichen Ansprechpartner bekannt machen, mit dem alle evtl. entstehenden Fragen geklärt werden können.
[<=]
7.4 Obliegenheiten SBV/GTI
Obliegenheiten des SBV:
o Der SBV nimmt die Produktinformationen von ITSM-TI-Teilnehmern entgegen und wertet sie aus. Diese können um weitere Produktinformationen aus eigenen Recherchen, wie Analyse von Spezifikationen und anderer Dokumentationen z.B. Handbücher, ergänzt werden. Die konsolidierten Produktinformationen werden unter Angabe der Quelle in die Wissensdatenbank übernommen.
o Der SBV wird im Rahmen der Auswertung der Produktinformationen die Inhalte, bspw. durch Reviews oder Audits, regelmäßig überprüfen. Dies dient der Fehlersuche und -behebung bzw. kontinuierlichen Verbesserung der Inhalte der Wissensdatenbank.
Obliegenheiten des GTI:
o Durch den GTI wird ein übergreifendes Knowledge Management etabliert.
Der GTI stellt allen Beteiligten der TI (ITSM-TI-Teilnehmern, Anwendern, DVOs sowie nach Bedarf weiteren am ITSM zu Beteiligenden – z. B. Gesellschafter der gematik einschließlich deren Landesorganisationen) eine Wissensdatenbank als Informationsinstrument und Unterstützungswerkzeug im Betrieb zur Verfügung.Produkt- bzw. Serviceinformationen, mögliche Störungsursachen und Hinweise zu deren Behebung elektronisch an den Gesamtverantwortlichen TI übermitteln und stets aktuell halten. [<=]
Der Gesamtverantwortliche TI stellt dazu die Wissensdatenbank zur Verfügung. TI-ITSM-Teilnehmer können mit einem qualifizierten Link auf Inhalte ihrer eigenen (lokalen) Wissensdatenbank verweisen. In diesem Fall müssen sie mindestens sicherstellen, dass
- der Link auf den konkreten Sachverhalt verweist,
- der Link erreichbar ist und auf die jeweils aktuellen Informationen verweist,
- für die Wissensdatenbank eine Zusammenfassung der verlinkten Produkt- bzw. Serviceinformationen zur Verfügung gestellt wird,
- diese Zusammenfassung in der Wissensdatenbank aktuell gehalten wird.
Beispiele für Produkt- und Serviceinformationen sind:
- Gebrauchs- und Installationsanleitungen,
- FAQs,
- Fehlerbehandlungsroutinen (Error Codes, deren mögliche Ursachen sowie geeignete Maßnahmen zur Fehlerbeseitigung),
- Erkenntnisse von übergreifendem Interesse aus TI-ITSM-Prozessen.
GS-A_5603 - Eingangskanal für Informationen von TI-ITSM-Teilnehmern
TI-ITSM-Teilnehmer MÜSSEN den vom Gesamtverantwortlichen TI bereitgestellten Eingangskanal für die Einlieferung von Informationen nutzen.
[<=]
o Der GTI trägt die redaktionelle Verantwortung für die Wissensdatenbank. Für die produktbezogenen Inhalte zur Störung, Ursache und Lösung sind die ITSM-TI-Teilnehmer verantwortlich.
8 Incident Management (INC)
Um zwischen den verschiedenen ITSM-TI-Teilnehmern sicherzustellen, dass Servicestörungen bzw. vom erwarteten Betriebsverhalten abweichende Services des TI-Plattform-Service oder eines Anwendungsservice
o gemäß ihrer Auswirkungen eine konsistent gleiche Behandlung erfahren und
o im Rahmen des Supports, der Austausch bzw. die Übergabe von Incidents zwischen den Prozessbeteiligten problemlos und nachvollziehbar gewährleistet wird,
ist durch die ITSM-TI-Teilnehmer ein übergreifendes Incident Management (INC) zu etablieren.
Die nachfolgende Abbildung veranschaulicht die Regelungen des Incident Managements im ITSM-TI-Teilnehmer relevanten Prozessausschnitt und gibt eine Zuordnung der einzelnen Prozessinhalte zu den nachfolgenden Kapiteln.
Abbildung 10: INC – Gesamtüberblick "Incident Management"
8.1 Betrachtungsgegenstand des übergreifenden INC
Fokus der nachfolgenden Incident-Management-Regelungen im übergreifenden Betrieb sind ITSM-TI-Teilnehmerübergreifende Incidents. Sofern zur Durchführung des übergreifenden INC-Prozesses notwendig, werden Prozessinhalte sowie Regelungen für die Bearbeitung von Incident-Meldungen durch Anwender oder DVOs aufgezeigt.
8.2 Begriffserläuterungen
8.2.1 Lokaler Incident
Bei einem lokalen Incident handelt es sich um eine Servicestörung bzw. um einen vom erwarteten Betriebsverhalten abweichenden Betriebszustand innerhalb des SPED (Service Provider Endnutzernahe Dienste)/Anwendersupports sowie innerhalb des ITSM-TI-Teilnehmersupports, für dessen Behebung der support- und lösungsverantwortliche ITSM-TI-Teilnehmer keine anderen am Betrieb beteiligten ITSM-TI-Teilnehmer benötigt.
Ein lokaler Incident wird dabei innerhalb der lokalen INC-Prozesse des ITSM-TI-Teilnehmers verarbeitet und unterliegt nur insofern Regelungen durch diese Richtlinie, wie zur Gewährleistung der Performance, Sicherheit und Stabilität der zentralen und dezentralen Produkte bzw. TI-Services notwendig ist.
Ein lokaler Incident wird durch einen Anwender bzw. DVO gemeldet oder durch einen ITSM-TI-Teilnehmer im Rahmen seiner lokalen (ggf. systemischen) Störungsüberwachung festgestellt.
8.2.2 Übergreifender Incident
Um einen übergreifenden Incident handelt es sich, wenn zur Bewältigung mehrere der am Betriebsprozess beteiligten ITSM-TI-Teilnehmer involviert werden müssen, d. h. eine strukturierte Informationsübermittlung des Incidents an weitere ITSM-TI-Teilnehmer eingeleitet werden muss.
Zur Bearbeitung des übergreifenden Incidents steht es den ITSM-TI-Teilnehmern frei, die Inhalte des übergreifenden Incidents in den lokalen Incident- Management-Prozess zu überführen. Dabei muss sichergestellt sein, dass an den Schnittstellen zwischen den Prozessbeteiligten weiterhin eine einheitliche Kommunikation, mittels übergreifender Incident-Dokumentation, erfolgt.
Eine Einschätzung, ob mehrere am Betriebsprozess beteiligte ITSM-TI-Teilnehmer zur Behebung (Lösung, Verifizierung, Schließen) der Störung bzw. zur Wiederherstellung des erwarteten Betriebsverhaltens der zentralen oder dezentralen Produkte notwendig sind, können - qualifiziert - ausschließlich ITSM-TI-Teilnehmer treffen. Übergreifende Incidents können daher ausschließlich durch ITSM-TI-Teilnehmer erstellt werden, jedoch nicht durch einen Anwender bzw. einen DVO.
8.2.3 AnwendersupportGesamtverantwortliche TI wird die TI-ITSM-Teilnehmer über die etablierten Kommunikationsschnittstellen informieren, auf welchem Weg und in welcher Form Informationen für die Wissensdatenbank bereitgestellt werden müssen.
9 Service Level Management
Mit Hilfe des Service Level Management werden die Service Level für alle TI-ITSM-Teilnehmer definiert, kontrolliert und ggf. optimiert.
Die Ziele des übergreifenden Service Level Management sind:
- die vereinbarten Service Level zu messen, um die aktuell geforderten (technischen und prozessualen) Zielvorgaben zu überprüfen;
- die gemessenen Service Level zu analysieren und ggf. optimieren, um die IT-Service-Qualität und Performance - möglichst effizient – auch in der Zukunft zu gewährleisten.
9.1 Begriffsbestimmungen
9.1.1 Service Level
Service Level werden grundsätzlich in die Ausprägungen technisch und organisatorisch unterteilt.
Organisatorische Service Level werden für die zu betrachtenden TI-ITSM-Prozesse im Betriebskonzept inhaltlich definiert und durch Vorgaben für messbare Zielwerte konkretisiert. Die SL-ID eines organisatorischen Service Level beginnt immer mit dem Präfix „ITSM“.
Technische Service Level sind in der übergreifenden Spezifikation „Performance und Mengengerüst TI-Plattform“ [gemSpec_Perf] beschrieben. Die Tabelle Tab_gemSpec_Perf_Performance-Kenngroessen enthält die je Produkttyp definierten und zu reportenden Service Level. Die SL-ID eines technischen Service Level beginnt immer mit dem Präfix „PDT“.
Die in den Service-Level-Auswertungen dargestellten Werte sind Indikatoren für die Qualität der erbrachten Services. Service Level Verletzungen stellen eine Untererfüllung vereinbarter Service Level dar und weisen auf entsprechenden Verbesserungspotenziale hin.
9.1.2 Service Level Report
Der Anwendersupport hat im Gegensatz zum ITSM-TI-Teilnehmersupport eine Kommunikationsschnittstelle in Richtung Anwender bzw. DVO sowie zusätzlich eine in Richtung ITSM-TI-TeilnehmerService Level Report enthält für den jeweiligen Berichtszeitraum die tatsächlich gemessenen Service Level Werte und ggf. deren Kommentierung.
Incident-Meldungen innerhalb des Anwendersupports können ausschließlich durch Anwender oder DVOs erfolgen.
Der Anwendersupport umfasst primär Regelungen zur ordnungsgemäßen Durchführung des übergreifenden Incident Managements bei Meldung eines Incidents durch einen Anwender bzw. DVO.
8.2.4 ITSM-TI-Teilnehmersupport
Der ITSM-TI-Teilnehmersupport hat ausschließlich Kommunikationsschnittstellen in Richtung andere ITSM-TI-Teilnehmersupport, nicht jedoch gegenüber Anwendern oder DVOs.
Incident-Meldungen innerhalb des ITSM-TI-Teilnehmersupports können ausschließlich von ITSM-TI-Teilnehmern erfolgen (direkt oder im Rahmen einer Weiterleitung aus dem Anwendersupport heraus).
Der ITSM-TI-Teilnehmersupport umfasst primär Regelungen zur ordnungsgemäßen Durchführung des übergreifenden Incident Managements bei Meldung eines Incident durch einen ITSM-TI-Teilnehmer.
Anforderungen an die Dokumentation, die Information und das Reporting sind so ausgeprägt, dass sie mit Hilfe von Standard-Kommunikationswerkzeugen (bspw. E-Mail, Standard-Office-Produkte) durchgeführt werden können.
Der Einsatz bzw. die Anpassung bestehender Verfahren und Werkzeuge (bspw. der Ticketsysteme) kann die Effizienz der Incident-Bearbeitung erhöhen, ist jedoch keine Voraussetzung für das übergreifende INC.
8.2.5 Supportverantwortung
Unter dem Begriff Supportverantwortung wird die originäre Verantwortung zur Supportbereitstellung eines ITSM-TI-Teilnehmers gegenüber anderen ITSM-TI-Teilnehmern sowie Anwendern bzw. DVOs verstanden, der von ihm eine Dienstleistung bezieht. Die Ausgestaltung der Supportzuordnung und -inhalte ist nicht Bestandteil der Richtlinien und erfolgtim Betriebskonzept [gemKPT_Betr].
8.2.6 Lösungsverantwortung
Ein produktverantwortlicher ITSM-TI-Teilnehmer bzw. ein durch diesen beauftragter Betreiber trägt die Lösungsverantwortung, wenn dessen Produkt für die Störungsursache verantwortlich ist. Er muss die Wiederherstellung des erwarteten Betriebsverhaltens gewährleisten.
Eine detaillierte Darstellung der betrieblichen Rollen im ITSM-TI und ihrer Produkt-, Service- und Supportverantwortung findet sich im Betriebskonzept [gemKPT_Betr].
8.3 Grundsätze des übergreifenden INC
Die nachfolgenden Grundsätze bilden die übergeordneten Regelungen des übergreifenden Incident Managements für ITSM-TI-Teilnehmer.
8.3.1 Zentrale INC-Koordinierung durch den GTI
Ausschließlich bei Eskalationen eines schwerwiegenden Incidents mit (produkt-) übergreifender Auswirkung kann der Gesamtverantwortliche der TI - zur Gewährleistung der Performance, Sicherheit und Stabilität der zentralen und dezentralen Produkte - eine zentrale Koordinierung der Aktivitäten der anderen Beteiligten übernehmen.
8.3.2 Übergabe der Lösungsverantwortung
Sofern durch einen Supportverantwortlichen keine Herbeiführung einer Lösung möglich ist - bspw. weil der zu bearbeitende Incident durch eine andere Betriebsinstanz verursacht bzw. verantwortet wird - kann er die Lösungsverantwortung an andere ITSM-TI-Teilnehmer (deren Dienstleistungen er in Anspruch nimmt) mittels einer strukturierten Informationsübermittlung übergeben. D. h. innerhalb einer Supportkette (im klassischen Sinne wäre dies bspw. der 1st-, 2nd-, 3rd-Level Support) wechselt die Lösungsverantwortung jeweils zwischen den einzelnen supportleistenden Betriebsinstanzen.
8.3.3 Incident-Melder
Der Incident-Melder im übergreifenden ITSM ist immer derjenige, der eine Incident-Meldung beim nächsten aus seiner Sicht zuständigen ITSM-TI-Teilnehmer eröffnet. Anhand der Angabe ist es für den Incident-Empfänger vor allem im Falle von Ticketweiterleitungen möglich die strukturierte Kommunikation aufrecht zu erhalten.
Es gibt zwischen dem Incident-Melder und seinem Empfänger immer eine 1:1-Beziehung.
Ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.
8.3.4 Incident-Bearbeiter
Der Incident-Bearbeiter ist immer derjenige, der aktuell an der Incident-Lösung arbeitet. Wird die Lösungsverantwortung von dem Weiterleitungsempfänger angenommen, wechselt der ursprüngliche Incident-Bearbeiter in die Rolle des Incident-Melders und der Weiterleitungsempfänger in die Rolle des (neuen) Incident-Bearbeiters. Lehnt er die Lösungsverantwortung ab, so bleibt der Weiterleitende der Incident-Bearbeiter.
Ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.
8.3.5 Betroffener Anwender
Der betroffene Anwender ist der Nutzer der TI, bei dem ursprünglich eine Störung auftrat und der diese Störung an den für ihn zuständigen ITSM-TI-Teilnehmer gemeldet hat. Durch diesen erfolgt die Erfassung der Störung als Incident.
Ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.
8.4 Prozessdurchführung Anwendersupport INC
8.4.1 Incident-Erstmeldung im Anwendersupport
An die Incident Meldung eines Anwenders oder DVO werden keine Anforderungen gestellt.
8.4.2 Vorprüfung im Anwendersupport
Abbildung 11: INC – Vorprüfung im Anwendersupport Beispiele erforderliche Kommentierungen:
- Beschreibung der Ursache bei einer Service Level Verletzung mit entsprechenden Verbesserungsmaßnahmen
- Kommentare zu fehlenden Messwerten
Der Service Level Report dient damit der Kontrolle der Einhaltung der Service Level Vereinbarung durch den TI-ITSM-Teilnehmer und der inhaltlichen Auseinandersetzung mit der geleisteten Qualität.
9.2 Prozessdurchführung Service Level Management
9.2.1 Messung der Service Level
Das TI-ITSM-System ermittelt alle übergreifenden organisatorischen Service Level automatisch während der TI-ITSM-Prozessbearbeitung. Alle anderen Service Level, z.B. technische Service Level oder lokale organisatorische Service Level werden vom TI-ITSM-Teilnehmer gemessen und an das TI-ITSM-System übermittelt.
Damit wird sichergestellt, dass alle durch einen TI-ITSM-Teilnehmer zu erbringenden Service Level, übergreifend und lokal sowie technisch und organisatorisch, zentral dokumentiert werden.
GS-A_4100 - Messung der Service Level
TI-ITSM-Teilnehmer MÜSSEN alle nicht durch das TI-ITSM-System gemessenen Service Level gemäß [gemKPT_Betr] bzw. [gemSpec_Perf] messen. [<=]
9.2.2 Bereitstellung des Service Level Reports
Jeder TI-ITSM-Teilnehmer muss die von ihm zu verantwortenden Service Level prüfen, ggf. erfassen, kommentieren und für die weitere Verarbeitung im TI-ITSM-System freigeben.
Der Gesamtverantwortliche TI wird für die Erfassung der lokalen Messergebnisse eine Schnittstelle im TI-ITSM-System zur Verfügung stellen.
GS-A_5604 - Bewertung der Messergebnisse
TI-ITSM-Teilnehmer MÜSSEN in allen Fällen einer Untererfüllung der gemessenen Werte von den Zielwerten eine Begründung für die Untererfüllung sowie eine Information zu getroffenen und geplanten Maßnahmen angeben.
[<=]
GS-A_3876 - Vorprüfung im Anwendersupport4101 - Übermittlung der Service Level Messergebnisse
ITSM-TI-ITSM-Teilnehmer MÜSSEN jeden durch einen Anwender oder DVO gemeldeten Incident dahingehend prüfen, ob
1. der Incident in der eigenen Supportverantwortung liegt und angenommen werden muss,
2. der Incident nicht in der eigenen Supportverantwortung liegt und qualifiziert abgelehnt werden muss,
3. der Incident in der eigenen Support- und Lösungsverantwortung liegt und es sich somit um einen lokalen Incident zur internen Bearbeitung handelt,
4. der Incident in der eigenen Supportverantwortung liegt und angenommen werden muss, dabei jedoch nicht in der eigenen Lösungsverantwortung liegt und eine Weiterleitung/Zuweisung an verantwortliche, externe Supporteinheiten notwendig ist.
ITSM-TI-Teilnehmer MÜSSEN, wenn die Prüfung in Fall eins positiv ist, eine Prüfung auf die Fälle drei und vier durchführen.
ITSM-TI-Teilnehmer MÜSSEN in Fall zwei die Ablehnung im Rahmen ihrer lokalen INC-Prozesse vornehmen.
ITSM-TI-Teilnehmer MÜSSEN in Fall drei die Bearbeitung des Incidents innerhalb der lokalen INC-Prozesse fortsetzen, da es sich um einen lokalen Incident handelt.
ITSM-TI-Teilnehmer MÜSSEN ausschließlich in Fall vier den übergreifenden Incident-Bearbeitungsprozess einleiten und eine Erstqualifizierung (gemäß GS-A_3879, GS-A_3880 , GS-A_3881, GS-A_3882 , GS-A_3883, GS-A_3884) des dann übergreifenden Incidents vornehmendie Service Level Messergebnisse an die durch den Gesamtverantwortlichen TI benannte Kommunikationsschnittstelle übermitteln.
[<=]
9.2.3 Teilnahme am Service Review
Service Reviews werden zur Feststellung von notwendigen Optimierungsaktivitäten –sowohl auf Ebene der Vorgaben als auch auf Ebene der Umsetzung – durchgeführt. Service Reviews erfolgen bei Bedarf und werden durch den Gesamtverantwortlichen TI einberufen. Die Art der Durchführung des Service Reviews wird durch den Gesamtverantwortlichen TI festgelegt (bspw. Telefonkonferenz, E-Mail).
TI-ITSM-Teilnehmer, die Optimierungsaktivitäten eigenverantwortlich definiert haben, erfassen diese im Service Level Report.
GS-A_4397 - Teilnahme am Service Review
TI-ITSM-Teilnehmer MÜSSEN am Service Review teilnehmen und die bilateral vereinbarten Optimierungsaktivitäten umsetzen.
[<=]
Die Supportverantwortung gegenüber dem initial meldenden Anwender oder DVO im Rahmen des Anwendersupports verbleibt grundsätzlich bei dem ITSM-TI-Teilnehmer, welcher den Incident (im Rahmen seines Anwendersupports) entgegengenommen und eröffnet hat.
Bis zur internen Klärung, ob es sich bei dem gemeldeten Incident um einen übergreifenden Incident handelt, hat der derjenige ITSM-TI-Teilnehmer, der den Incident annimmt, zugleich die Lösungsverantwortung.
Sobald es sich um einen übergreifenden Incident handelt, muss die erstellte Dokumentation die Anforderungen an eine übergreifende Incident-Dokumentation - gemäß Kapiteln 8.4.5 „Interne Erfassung, Kategorisierung & Priorisierung übergreifender Incidents“ und 8.7 „Dokumentation“ - erfüllen und innerhalb der vorgegebenen Reaktionszeit an den zuständigen ITSM-TI-Teilnehmer strukturiert übermittelt werden. Die Supportverantwortung gegenüber dem meldenden Anwender oder DVO verbleibt weiterhin bei dem ITSM-TI-Teilnehmer, welcher die Incident-Meldung vom Anwender oder DVO entgegen genommen und die initiale Incident-Dokumentation erstellt hat.
8.4.3 Ablehnung im Anwendersupport
An die Ablehnung eines durch einen Anwender oder DVO gemeldeten Incidents werden keine Anforderungen gestellt. Es wird empfohlen, eine qualifizierte Ablehnung an den Meldenden zu versenden, der weiterführende Informationen (bspw. die Nennung des korrekten Ansprechpartners) zu entnehmen sind.
8.4.4 Lösung und Schließung im lokalen Incident Management
An das Verfahren zur Lösung und Schließung eines durch einen Anwender oder DVO gemeldeten Incidents werden nur insofern Anforderungen gestellt, wie es zur Gewährleistung der Performance, Sicherheit und Stabilität der zentralen und dezentralen Produkte bzw. TI-Services notwendig ist. Es wird empfohlen, stets eine qualifizierte Rückmeldung an den Meldenden zu versenden, wenn die Störung behoben ist.
Während der Bearbeitung eines lokalen Incidents kann durch den ITSM-TI-Teilnehmer festgestellt werden, dass ein TI-Service (bspw. für eine hohe Anzahl an Nutzern) gestört ist. Die Auswirkungsweite und die Dringlichkeit der produktspezifischen Ausprägung der Prioritäten (gemäß Kapitel 8.4.5 „Interne Erfassung, Kategorisierung & Priorisierung übergreifender Incidents“) sind - trotz der Bearbeitung im Rahmen der lokalen Incident-Prozesse - durch den ITSM-TI-Teilnehmer zu messen und bei Priorität 1 und 2 an den SBV zu berichten.
GS-A_3877 - Prüfung auf Erfüllung von Prioritätsanforderungen im lokalen Incident Management im Anwendersupport
ITSM-TI-Teilnehmer MÜSSEN bei der Bearbeitung von lokalen Incidents im Rahmen ihrer lokalen INC-Management-Prozesse prüfen, ob ein Incident mit der Priorität 1 oder 2 klassifiziert werden muss.
(Für lokale Incidents der Priorität 1 und 2 gelten die Informationspflichten gemäß GS-A_3913)
[<=]
GS-A_3878 - Nachträgliche strukturierte Informationsübermittlung von übergreifenden Incidents im Anwendersupport
ITSM-TI-Teilnehmer, bei denen sich während der Bearbeitung im lokalen Incident Management und trotz umfangreicher Vorprüfung des durch den Anwender bzw. DVO gemeldeten Incidents herausstellt, dass eine Lösung bzw. Behebung des Incidents nicht durch ihn selber möglich ist, MÜSSEN
• unverzüglich den support- und lösungsverantwortlichen ITSM-TI-Teilnehmer ermitteln,
• unverzüglich den übergreifenden Incident an den richtigen support- und lösungsverantwortlichen ITSM-TI-Teilnehmer strukturiert übermitteln bzw. für die Incident-Bearbeitung durch diesen, eine strukturierte Informationsübermittlung gemäß der Festlegungen für einen übergreifenden Incident durchführen.
(Zur Identifikation des richtigen support- und lösungsverantwortlichen ITSM-TI-Teilnehmers werden innerhalb des Betriebskonzepts die Leistungs- und Supportmodelle definiert. Zudem werden in der zentralen Wissensdatenbank Kontaktinformationen von Anbietern und anderen ITSM-TI-Teilnehmern bereitgestellt.) [<=]
GS-A_5086 - Bearbeitung und Lösung von lokalen Incidents bei Lösungsverantwortung
ITSM-TI-Teilnehmer , die bei der Vorprüfung feststellen, dass sie für den lokalen Incident support- und lösungsverantwortlich sind, MÜSSEN unverzüglich mit der Incident-Bearbeitung beginnen und gemäß der Priorität des Incidents und - innerhalb der vereinbarten Lösungszeiten - eine Lösung für den lokalen Incident herbeiführen und diesen beheben (lösen, verifizieren und schließen).
[<=]
8.4.5 Interne Erfassung, Kategorisierung & Priorisierung übergreifender Incidents
GS-A_3879 - Schriftliche Erfassung von übergreifenden Incidents
ITSM-TI-Teilnehmer MÜSSEN Incident-Meldungen von Anwendern bzw. DVOs - sobald erkennbar ist, dass es sich um einen übergreifenden Incident handelt (d. h. zur Bewältigung mehrere der am Betriebsprozess Beteiligten involviert werden müssen) - intern schriftlich erfassen, kategorisieren, priorisieren und innerhalb der vorgegebenen Qualifizierungszeit an den zuständigen Bearbeiter bzw. ITSM-TI-Teilnehmer strukturiert übermitteln.
[<=]
Die Erfassung und Bearbeitung von übergreifenden Incidents muss auch nach Austausch bzw. der strukturierter Übermittlung dieser zwischen den Prozessbeteiligten problemlos und nachvollziehbar gewährleistetet sein.
Dabei darf der interne ITSM-TI-Teilnehmerspezifische Bearbeitungsprozess zur Behebung (Lösung, Verifikation, Schließen) eines Incidents nicht behindert werden. Aus diesem Grund erstellt jeder ITSM-TI-Teilnehmer eine interne Dokumentation für den übergreifenden Incident in Form eines Tickets, eines Formulars (bspw. Excel) oder einer E-Mail. Diese wird insbesondere auch für die Pflichten der ITSM-TI-Teilnehmer im Rahmen des Reportings benötigt.
Zur Gewährleistung einer übergreifenden Nachvollziehbarkeit muss jeder im übergreifenden Incident Management bearbeitete bzw. an diesen Prozess übergebene Incident - bspw. zur Verweismöglichkeit - mit einer eineindeutigen Referenznummer (Incident-ID) versehen und ordnungsgemäß kategorisiert, priorisiert sowie dokumentiert werden.
Abbildung 12: INC – Strukturierte Informationsübermittlung im übergreifenden INC
Eineindeutige Referenznummer von übergreifenden Incidents
GS-A_3880 - eineindeutige Referenznummer von übergreifenden Incidents
ITSM-TI-Teilnehmer MÜSSEN bei der Erfassung eine eineindeutige Referenznummer für einen übergreifenden Incident nach folgendem Schema vergeben:
Die eineindeutige Referenznummer für übergreifende Incident-Dokumentation MUSS über die jeweilige Incident-ID gebildet werden, die sich aus dem aktuellem Jahr (JJJJ), der Teilnehmer-ID (TID) des ITSM-TI-Teilnehmers bzw. weitere Beteiligte im Betrieb der TI und einer laufenden Incident-Nummer (IN, String [5]) in dem Format „JJJJ-TID-IN“ (bspw. „JJJJ-ABCDE-12345“) zusammensetzt.
[<=]
GS-A_3881 - Eineindeutigkeit der Incident-ID
ITSM-TI-Teilnehmer MÜSSEN bei der Schnittstellenkommunikation mit anderen ITSM-TI-Teilnehmern beachten, dass sich die einmalig bei der Ersterfassung des übergreifenden Incidents aufgenommene, eindeutige Referenznummer (in Form der Incident-ID) innerhalb der gesamten Kommunikation nicht ändert, d. h. prozessdurchgängig konstant bleibt.
[<=]
Kategorisierung von übergreifenden Incidents
GS-A_3883 - Kategorisierung von übergreifenden Incidents
ITSM-TI-Teilnehmer MÜSSEN jeden im übergreifenden Incident Management bearbeiteten bzw. an diesen Prozess übergebenen Incident kategorisieren. Zur Kategorisierung MÜSSEN mindestens die im Rahmen der TI vorgegebenen Produkttypen genutzt werden.
[<=]
Priorisierung von Incidents
GS-A_3884 - Priorisierung von Incidents
ITSM-TI-Teilnehmer MÜSSEN jeden im übergreifenden Incident Management bearbeiteten bzw. an diesen Prozess übergebenen Incident gemäß nachfolgendem Schema priorisieren. Dabei ist die Anzahl der möglichen Prioritäten gemäß der Prioritätenmatrix wie folgt festgelegt:
Tabelle 22: Tab_Betr_TIP_009 INC – Prioritätenmatrix
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
• Jeder im übergreifenden Incident Management bearbeitete bzw. an diesen Prozess übergebene Incident MUSS entsprechend einer vierstufigen Einteilung - wobei 1 die höchste und 4 die niedrigste Priorität ist - eingestuft werden.
• Priorität 1- Kritisch,
• Priorität 2 - Hoch,
• Priorität 3 - Mittel,
• Priorität 4 - Niedrig.
Die für einen Incident anzuwendende Priorität wird abgeleitet aus den beiden Faktoren „Auswirkung“ und „Dringlichkeit“. Folgende Festlegungen sind für eine korrekte Anwendung der beiden Faktoren zu beachten:
Tabelle 23: Tab_Betr_TIP_026 INC – Festlegung von DringlichkeitSollten die im Service Review zwischen TI-ITSM-Teilnehmer und Gesamtverantwortlichen TI vereinbarten Optimierungen keinen belastbaren Erfolg zeigen, so steht dem Gesamtverantwortlichen TI als weitere Option die Durchführung von Audits gem. GS-A_4855 offen. Damit sollen erkannte prozessuale Defizite – insbesondere in den Prozessen Incident, Problem, Request Fulfillment und Change Management – sowie technische Defizite (Performance Zielwerte der von TI-ITSM-Teilnehmern verantworteten TI-Produkte) beseitigt werden.
10 Performance Management
Das Performance Management der TI umfasst die ITIL-Prozesse Capacity Management und Availability Management. Es verfolgt das Ziel, jederzeit adäquate Kapazitäten und ausreichende Verfügbarkeiten im Sinne eines angemessenen technischen Leistungsvermögens der TI unter Einhaltung der wirtschaftlichen Verhältnismäßigkeit zu gewährleisten. Letzteres beinhaltet beispielsweise den Abbau von festgestellten oder absehbaren Überkapazitäten und die Berücksichtigung des Ressourcenverbrauchs, der zur Leistungserbringung erforderlich ist.
Im Rahmen des Performance-Managements werden auch Entwicklungen aufgezeigt, Trends extrapoliert und Prognosen zu Verfügbarkeits- und Kapazitätsanforderungen erstellt. Letztlich sollen aus diesen Erkenntnissen Maßnahmen abgeleitet, geplant, durchgeführt und überwacht werden, welche die Sicherstellung des oben genannten Ziels gewährleisten sollen.
Zur Unterstützung dieses Ziels, müssen TI-ITSM-Teilnehmer zunächst Performance-Messungen auf den von ihnen verantworteten TI-relevanten Systemen durchführen und die Ergebnisse an den Gesamtverantwortlichen TI berichten. Im Weiteren sind die TI-ITSM-Teilnehmer auch zur Entwicklung und Definition von Maßnahmen zur Optimierung von Verfügbarkeit und Kapazität verpflichtet, wobei die TI-weiten Performance-Analysen und Service-Design-Optimierungen durch den Gesamtverantwortlichen TI vorgenommen bzw. initiiert werden. Interne Optimierungsmaßnahmen der TI-ITSM-Teilnehmer sind daher nicht Bestandteil der übergreifenden Richtlinien.
Im Folgenden werden ausschließlich Anforderungen an TI-ITSM-Teilnehmer definiert, die den Betrieb von zentralen Produkten oder Fachanwendungen in der TI verantworten. Für dezentrale Produkte werden hier keine Performance-Anforderungen definiert.
10.1 Begriffsbestimmungen
10.1.1 Performance
Der Begriff „Performance“ wird im Folgenden gemäß [gemSpec_Perf] verwendet. Die Performance wird dabei durch die in [gemSpec_Perf] definierten Kenngrößen repräsentiert, welche die Dimensionen Verfügbarkeit, Durchsatz und Bearbeitungszeit abdecken.
10.2 Prozessdurchführung Performance Management
10.2.1 Performance messen
Zur Zielerreichung des Performance-Managements der TI müssen TI-ITSM-Teilnehmer Performance-Messungen durchführen und die Ergebnisse berichten.
Die Messergebnisse dienen dabei im Wesentlichen
- zur Feststellung und Analyse des aktuellen Performance-Status der TI-Anwendungen und –Services und, darauf aufbauend, der Prognostizierung zukünftiger Performance-Anforderungen hinsichtlich Verfügbarkeit, Durchsatz und Bearbeitungszeit und
- zur Planung und Steuerung von Kapazitätsanpassungen, um bestehende bzw. drohende Engpässe kompensieren und ggf. vorhandene Überkapazitäten beseitigen zu können.
Die Messungen erfolgen durch den TI-ITSM-Teilnehmer innerhalb der von ihm verantworteten TI-relevanten Systeme und Prozesse basierend auf den Vorgaben der [gemSpec_Perf].
10.2.2 Performance reporten
Das TI-ITSM-System wird eine Möglichkeit zum Datenupload bereitstellen.
Geplant ist, dass das TI-ITSM-System eine Schnittstelle zum Datenupload bereitstellen wird. Sollte sich im Laufe des Projektes herausstellen, dass dies nicht möglich sein wird, gelten die Anforderungen zur CSV-Datenübermittlung gemäß Kapitel 13.
A_18236 - Übermittlung von Performance-Reports
TI-ITSM-Teilnehmer, die gemäß [gemSpec_Perf#Tab_gemSpec_Perf_Performance-Kenngroessen] technische Performance-Kenngrößen in Performance-Reports liefern, MÜSSEN den Performance-Report einmal im Monat an den vom Gesamtverantwortlichen der TI angegebenen Endpunkt übermitteln und dabei die GS-A_5248 beachten. Der Berichtszeitraum umfasst einen vollen Kalendermonat. [<=]
A_18237 - Lieferung von Performance-Rohdaten-Reports
TI-ITSM-Teilnehmer, die gemäß [gemSpec_Perf#2.5] technische Performance-Kenngrößen in Rohdaten-Performance-Berichten (Performance-Protokoll und Datei zur Selbstauskunft) liefern, MÜSSEN die für den Berichtszeitraum zu liefernden Berichte an den in [gemSpec_Perf] angegebenen Endpunkt liefern. Der Berichtszeitraum umfasst einen vollen Kalendermonat.
[<=]
Der Endpunkt wird vom GTI in der Wissensdatenbank bekannt gegeben. Bei Änderungen des Endpunktes bzw. bei Wechsel des Verfahrens (Ablösung von E-Mail) werden die TI-ITSM-Teilnehmer mit angemessenem zeitlichen Vorlauf informiert.
GS-A_4106 - Reportinhalte des Performance-Reports
TI-ITSM-Teilnehmer MÜSSEN die Ergebnisse ihrer Performance-Messungen nach folgendem Schema (die Reihenfolge ist verbindlich) an den Gesamtverantwortlichen TI übermitteln.
Tabelle 10: Tab_Betr_TIP_003 PERF – Reportinhalte von Performance Messungen
|
Spaltenname |
Beschreibung |
Typ |
Beispiel |
1 |
Teilnehmer ID |
ID des TI-ITSM-Teilnehmers bzw. weitere Beteiligte im Betrieb der TI |
[String]/ |
|
2 |
Produktkürzel |
Produktkürzel gemäß [gemSpec_OM] |
[String]/ |
|
3 |
Betriebsumgebung |
Gibt die Betriebsumgebung an, in welcher das Produkt im Messintervall gemessen wurde. Werden Messwerte für Produkte bzw. Produktbestandteile (z.B. SZZP) geliefert, so ist die Betriebsumgebung „Alle“ zu verwenden |
[Auswahlfeld], (RU), (TU), (PU), (Alle) |
Alle |
4 |
Performance Kenngroesse |
Ausgeprägter Bezeichner der Performance-Kenngröße gemäß Tab_gemSpec_Perf_Performance-Kenngroessen [gemSpec_Perf#Anh.C] |
[String] |
PDT03-S06-D1-G01-Z06 |
5 |
Messwert |
ermittelter Wert aus der Performance-Messung für das angegebene Messintervall [Auswertungsstart / -ende] bzw. Zeitstempel |
[Integer] oder |
|
|
Messgroesse |
Messgröße des Performance-Wertes gemäß [gemSpec_Perf] |
|
|
|
Auswertungsstart |
Zeitpunkt, ab dem die Messung für den Wert gestartet ist |
|
|
|
Auswertungsende |
Zeitpunkt, an dem die Messung für den Wert beendet wurde |
|
|
Tabelle 24: Tab_Betr_TIP_027 INC – Festlegung von Auswirkung
|
|
|
|
|
|
|
|
Für die Aspekte Informationssicherheit und Datenschutz gelten folgende Festlegungen:
• Jeder Incident MUSS auf die Sicherheitsrelevanz geprüft werden und bei Erfüllung der Sicherheitsrelevanz entsprechend gekennzeichnet werden (Feld 7: Sicherheitsrelevanz in „Tabelle 27: Tab_Betr_TIP_014 INC – Mindestinhalte Incident-Dokumentation“). Die Sicherheitsrelevanz ist gegeben, wenn die Vertraulichkeit bzw. Integrität eines schutzbedürftigen Informationsobjektes gefährdet ist.
• Jeder Incident MUSS auf die Datenschutzrelevanz geprüft werden und bei Erfüllung der Datenschutzrelevanz entsprechend gekennzeichnet werden (Feld 8: Datenschutzrelevanz in Tabelle 27: Tab_Betr_TIP_014 INC – Mindestinhalte Incident-Dokumentation). Datenschutzrelevanz ist gegeben, wenn personenbezogene Daten gemäß Art. 4 Nr. 1 DSGVO betroffen sind.
[<=]
8.4.6 Strukturierte Informationsübermittlung übergreifender Incidents
GS-A_3885 - strukturierte Informationsübermittlung von übergreifenden Incidents im Anwendersupport
ITSM-TI-Teilnehmer MÜSSEN einen übergreifenden Incident, nach der internen Erfassung, Priorisierung und Kategorisierung, schriftlich, innerhalb der vorgegebenen Qualifizierungszeit und auf elektronischem Weg an den zuständigen Support- bzw. Lösungsverantwortlichen strukturiert übermitteln.
[<=]
Es dürfen ausschließlich vorqualifizierte (inhaltsanforderungskonforme) Incident-Fälle - gemäß Kapitel 8.4.5 „Interne Erfassung, Kategorisierung & Priorisierung übergreifender Incidents“ - übermittelt werden. Die Lösungsverantwortung, also die Verantwortung zur Behebung der Störung bzw. zur Wiederherstellung des erwarteten Betriebsverhaltens, wird mit der strukturierten Informationsübermittlung an den ITSM-TI-Teilnehmer übergeben, der den übergreifenden Incident empfängt und annimmt.
GS-A_3886 - Nutzung der Kommunikationsschnittstelle bei strukturierter Informationsübermittlung von übergreifenden Incidents
ITSM-TI-Teilnehmer MÜSSEN zur strukturierten Informationsübermittlung von übergreifenden Incidents die ZID nutzen.
[<=]
Die den übergreifenden Incident empfangenden ITSM-TI-Teilnehmer müssen eine erneute interne Erfassung durchführen oder können mit der vorhandenen Incident-Dokumentation die Bearbeitung direkt fortführen.
Ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.
8.4.7 Schließung übergreifender Incidents
GS-A_3887 - Status eines übergreifenden Incidents während der Bearbeitung
ITSM-TI-Teilnehmer, die für einen übergreifenden Incident lösungsverantwortlich sind, MÜSSEN den Incident als „in Bearbeitung“ markieren bis die Incident-Lösung erfolgt ist.
ITSM-TI-Teilnehmer, die für einen übergreifenden Incident nicht lösungsverantwortlich jedoch supportverantwortlich sind, MÜSSEN den Incident als "weitergeleitet" markieren bis die strukturierte Informationsübermittlung zur Schließung eintrifft.
[<=]
GS-A_3888 - Verifikation vor Schließung eines übergreifenden Incidents
ITSM-TI-Teilnehmer MÜSSEN vor der Schließung einer übergreifenden Incident-Dokumentation verifizieren, dass der Incident behoben ist.
Bei negativer Verifikation des Incidents ist kein neuer übergreifender Incident zu eröffnen. Stattdessen ist der bestehende Incident weiterzubearbeiten. Es ist der Status auf „In Bearbeitung“ zu setzen. Es beginnt keine erneute Lösungszeit.
Tickets deren Verifikation länger als sieben Tage andauert, dürfen geschlossen werden.
[<=]
GS-A_3889 - Schließung der übergreifenden Incident-Dokumentation, mit abschließender Bearbeitung im Anwendersupport
ITSM-TI-Teilnehmer MÜSSEN nach der Behebung der Störung die übergreifende Incident-Dokumentation abschließend bearbeiten und schließen. Die abschließende Bearbeitung beinhaltet dabei mindestens folgende Inhalte/Schritte:
• Das Feld „Status“ MUSS auf geschlossen gesetzt werden.
• Das Feld „Kategorie verursachendes Produkt“ MUSS dem festgestellten, die Störung verursachenden, Produkttyp entsprechen.
• Das Feld „Kategorie betroffenes Produkt“ MUSS dem hauptsächlich betroffenen Produkttyp entsprechen.
• In das Feld „Incident Worklog“ MUSS die Schließung des Incidents als letzter Eintrag enthalten sein.
• Das Feld „Incident Lösung“ MUSS mindestens mit der eineindeutigen Beschreibung der Lösung und Ursache befüllt sein.
• Das Feld „Zeit Ende“ MUSS gefüllt sein.
[<=]
GS-A_3890 - Information bei Schließung der übergreifenden Incident-Dokumentation im Anwendersupport
ITSM-TI-Teilnehmer MÜSSEN an den Meldenden des übergreifenden Incidents eine Information über die Behebung des Incidents zusenden, damit dieser die Möglichkeit hat, seine - bis zur Lösung - „als weitergeleitet“ markierte Incident-Dokumentation ebenfalls zu schließen. Die strukturierte Information muss dabei mindestens die Inhalte haben, die in GS-A_3882 der „Schließung“ zugeordnet sind.
[<=]
Weitere ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.
8.4.8 Service Level Requirements (SLR)
GS-A_3891 - Service Requirements im Anwendersupport
Aufbauend auf die in den jeweiligen Verträgen geregelten Servicezeiten MÜSSEN ITSM-TI-Teilnehmer im Anwendersupport mindestens folgende Service Level messen und berichten:
Tabelle 25: Tab_Betr_TIP_011 INC – SLR Anwendersupport “Prozess”
|
|
|
|
|
||
|
|
|
|
|
||
|
|
|
|
|
||
|
|
|
|
|
||
|
|
|
|
|
||
Die Ausgestaltung der Service Level erfolgt im Betriebskonzept [gemKPT_Betr].
[<=]
8.5 Prozessdurchführung ITSM-TI-Teilnehmersupport INC
8.5.1 Feststellung, Lösung und Schließung im lokalen INC[<=]
A_17735 - Rohdatenreporting
Anbieter des ePA-Aktensystems (inkl. Schlüsselgenerierungsdienst), Schlüsselgenerierungsdienstes der zentralen Zone, Signaturdienstes, Verzeichnisdienstes, VPN-Zugangsdienstes, KOM-LE, X.509-TSP (HBA, SMC-B) sowie Fachdienstbetreiber VSDM MÜSSEN Rohdaten der Performancemessungen entsprechend [gemSpec_Perf] an die von dem Gesamtverantwortlichen TI benannte Schnittstelle (gemäß gemSpec_SST_LD_BD) senden. Damit entfällt für sie das konsolidierte Performance-Reporting. [<=]
10.2.3 Performance bewerten, planen und steuern
Die Ausgestaltung der Prozesse zur Bearbeitung und Lösung lokaler Incidents obliegt grundsätzlich dem ITSM-TI-Teilnehmer. Der Umgang mit lokalen Störungen, die durch das interne Monitoring eines ITSM-TI-Teilnehmers erkannt werden, wird durch die Produktverfügbarkeit dimensioniert. Folgende Anforderungen sind dabei zu beachten.
GS-A_3892 - Prüfung auf Erfüllung von Prioritätsanforderungen im lokalen Incident Management im ITSM-TI-Teilnehmersupport
ITSM-TI-Teilnehmer MÜSSEN, wenn die Anforderungen an die Priorität 1 oder 2 von lokalen Incidents erfüllt sind, innerhalb der vorgegebenen Service Level Requirements (vgl. GS-A_3891 ) eine Statusinformation an den SBV versenden. Darüber hinaus ist dann grundsätzlich bei jedem Statuswechsel von lokalen Incidents der Priorität 1 und 2 eine Statusinformation zu übermitteln.
[<=]
GS-A_3893 - nachträgliche strukturierte Informationsübermittlung von lokalen Incidents im ITSM-TI-Teilnehmersupport
ITSM-TI-Teilnehmer, bei denen sich während der Bearbeitung im lokalen Incident Management und trotz umfangreicher Vorprüfung des Incidents herausstellt, dass eine Lösung bzw. Behebung des Incidents nicht durch ihn selber möglich ist, MÜSSEN
• unverzüglich den richtigen support- und lösungsverantwortlichen ITSM-TI-Teilnehmer ermitteln ,
• unverzüglich den Incident an den richtigen support- und lösungsverantwortlichen ITSM-TI-Teilnehmer strukturiert übermitteln bzw. für die Incident-Bearbeitung durch diesen, eine strukturierte Informationsübermittlung gemäß der Festlegungen für einen übergreifenden Incident durchführen.
(Die Identifikation des richtigen support- und lösungsverantwortlichen ITSM-TI-Teilnehmers erfolgt auf Basis des Betriebskonzeptes [gemKPT_Betr]. Zudem werden in der zentralen Wissensdatenbank Kontaktinformationen von ITSM-TI-Teilnehmern bereitgestellt.)
[<=]
8.5.2 Qualifizierte Incident-Erstmeldung im ITSM-TI-Teilnehmersupport
Eine qualifizierte Erstmeldung ist eine Incident-Meldung durch einen ITSM-TI-Teilnehmer, bei welcher der ITSM-TI-Teilnehmer ohne Meldung durch einen Anwender oder DVO eine Störung bemerkt (bspw. durch geeignete Systeme) und diese an die support- bzw. lösungsverantwortlichen ITSM-TI-Teilnehmer melden möchte.
Durch das „ITSM-TI-Teilnehmer- ITSM-TI-Teilnehmer“-Verhältnis (B2B-Kommunikation) handelt es sich bei der qualifizierten Meldung immer um einen übergreifenden Incident.
Ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.
GS-A_3894 - qualifizierte Meldung einer Störung im ITSM-TI-Teilnehmersupport, ohne Meldung durch Anwender/DVO
ITSM-TI-Teilnehmer, die eine Störung ohne Meldung durch einen Anwender oder DVO feststellen und diese melden möchten, MÜSSEN dies mittels einer qualifizierten Erstmeldung des übergreifenden Incidents an den support- bzw. lösungsverantwortlichen ITSM-TI-Teilnehmer durchführen.
[<=]
GS-A_3895 - Erfassung und Übermittlung eines übergreifenden Incidents im Rahmen der qualifizierten Meldung im ITSM-TI-Teilnehmersupport
ITSM-TI-Teilnehmer MÜSSEN im Rahmen der qualifizierten Meldung für die Erfassung und strukturierte Informationsübermittlung des übergreifenden Incidents, die für die übergreifende Incident-Kommunikation bereitgestellte ZID nutzen.
ITSM-TI-Teilnehmer MÜSSEN dabei die Erfassung gemäß „GS-A_3879, GS-A_3880 ,GS-A_3881, GS-A_3882 , GS-A_3883, GS-A_3884“ vornehmen.
[<=]
GS-A_3896 - interne Erfassung des übergreifenden Incidents im Rahmen der qualifizierten Meldung im ITSM-TI-Teilnehmersupport
ITSM-TI-Teilnehmer, die einen Incident melden möchten, KÖNNEN (anders als im Anwendersupport, nicht Pflicht) im Rahmen der qualifizierten Erstmeldung eine interne Incident-Dokumentation erzeugen (bspw. um die interne Behebung der Störung, zu einem späteren Zeitpunkt weiter nach zu verfolgen).
[<=]
8.5.3 Vorprüfung im ITSM-TI-Teilnehmersupport
Abbildung 13: INC – Vorprüfung im ITSM-TI-Teilnehmersupport
GS-A_3902 - Vorprüfung im ITSM-TI-Teilnehmersupport
Die Meldung erhaltenden ITSM-TI-Teilnehmer MÜSSEN jeden durch einen anderen ITSM-TI-Teilnehmer gemeldeten, übergreifenden Incident dahingehend prüfen, ob
1. der Incident in der eigenen Supportverantwortung liegt und angenommen werden muss,
2. der Incident nicht in der eigenen Supportverantwortung liegt und dokumentiert abgelehnt werden muss,
3. der Incident in der eigenen Support- und Lösungsverantwortung liegt und es sich somit um einen Incident zur internen Bearbeitung handelt,
4. der Incident in der eigenen Supportverantwortung liegt und angenommen werden muss, dabei jedoch nicht in der eigenen Lösungsverantwortung liegt und eine strukturierte Informationsübermittlung an verantwortliche, externe Supporteinheiten notwendig ist.
Anbieter und ITSM-TI-Teilnehmer können, nach erfolgter Prüfung, einen übergreifenden Incident - gemäß GS-A_3906, GS-A_3907, GS-A_4120 - akzeptieren oder - gemäß GS-A_3905 - dokumentiert ablehnen.
[<=]
GS-A_3903 - Empfangsbestätigung von übergreifenden Incidents
Der Empfang eines an einen ITSM-TI-Teilnehmer übertragenen, übergreifenden Incidents MUSS dem Versender durch den Empfänger schriftlich und in elektronischer Form bestätigt werden, womit die Supportverantwortung als zutreffend bestätigt wird.
[<=]
GS-A_3904 - Incident-Annahme
ITSM-TI-Teilnehmer, die bei der Vorprüfung im ITSM-TI-Teilnehmersupport feststellen, dass Sie eine Supportverantwortung haben, MÜSSEN den übergreifenden Incident annehmen.
Mit der Incident-Annahme geht die Annahme der Supportverantwortung gegenüber dem meldenden ITSM-TI-Teilnehmer einher. Gleichzeitig geht die Zuständigkeit für die Lösungsverantwortung auf den ITSM-TI-Teilnehmer über, der den übergreifenden Incident annimmt.
[<=]
Ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.
8.5.4 Ablehnung im ITSM-TI-Teilnehmersupport
GS-A_3905 - Ablehnung von übergreifenden Incidents im ITSM-TI-Teilnehmersupport
ITSM-TI-Teilnehmer, die einen übergreifenden Incident ablehnen, MÜSSEN dieses mit einer qualifizierten Rückmeldung an den meldenden ITSM-TI-Teilnehmer des übergreifenden Incidents durchführen, aus der nachvollziehbar zu entnehmen ist, warum keine Bearbeitung erfolgen kann (bspw. dass die Bearbeitung des übergreifenden Incidents zwischen dem Meldenden und dem ITSM-TI-Teilnehmer keine bestehende Vereinbarung umfasst bzw. keine Supportverantwortung besteht).Eine Ablehnung der Supportverantwortung erfolgt über die Nutzung der ZID.Folgende Wege sind möglich:
1. Versand einer CSV-Datei mit den folgenden Eigenschaften:
o Der Betreff der E-Mail MUSS den CSV-Dateinamen beinhalten.
o Die CSV-Datei einschließlich der entsprechend angepassten Felder (z.B. Incident-Bearbeiter, Status, Worklog) MUSS angehängt werden.
o Die Begründung der Ablehnung MUSS im Worklog gepflegt sein.
o Eine qualifizierte Rückmeldung ist ein Eintrag in den Worklog, der mit der E-Mail erhaltenen CSV-Datei.
1. Die Ablehnung der Supportverantwortung kann über die Nutzung des Webservice erfolgen:
o Hier gelten die Vorgaben gemäß Anhang B.
o Die Begründung der Ablehnung MUSS im Worklog gepflegt sein.
1. Nutzung des Webportals
o Die Begründung der Ablehnung MUSS im Worklog gepflegt sein.
[<=]
Ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.
GS-A_5372 - Ablehnung eines übergreifenden Incidents nach bereits erfolgter Annahmebestätigung
Sollte sich nach erfolgter Annahme eines übergreifenden Incidents durch den ITSM-TI-Teilnehmer herausstellen, dass die Annahme irrtümlich erfolgt ist, MUSS der ITSM-TI-Teilnehmer den Incident an den Melder zurückgeben. Bei der Rückgabe MUSS der ITSM-TI-Teilnehmer eine Begründung für die Ablehnung an den Melder übermitteln.
[<=]
8.5.5 Lösung übergreifender Incidents
GS-A_3906 - Bearbeitung von übergreifenden Incidents bei Lösungsverantwortung
ITSM-TI-Teilnehmer, die bei der Vorprüfung feststellen, dass sie für den übergreifenden Incident support- und lösungsverantwortlich sind, MÜSSEN gemäß der Priorität (siehe auch GS-A_3884) den internen Incident-Bearbeitungs- und Lösungsprozess auslösen.
[<=]
GS-A_3907 - Lösung von übergreifenden Incidents
Der lösungsverantwortliche ITSM-TI-Teilnehmer MUSS nach erfolgter Annahme des übergreifenden Incidents unverzüglich mit der Incident-Bearbeitung beginnen und - innerhalb der vereinbarten Lösungszeiten - eine Lösung für den Incident herbeiführen und diesen beheben.
Der lösungsverantwortliche ITSM-TI-Teilnehmer MUSS bei der Incident-Bearbeitung konstant alle lösungsrelevanten Felder der übergreifenden Incident-Dokumentation weiterpflegen bzw. befüllen.
Kann eine Sofortlösung erfolgen, ist dies im Incident-Worklog so zu dokumentieren, dass nachvollziehbar ist, warum der Incident unmittelbar auf den Status „gelöst“ gesetzt wurde.
[<=]
GS-A_4120 - Nachträgliche strukturierte Informationsübermittlung von übergreifenden Incidents im ITSM-TI-Teilnehmersupport
ITSM-TI-Teilnehmer, bei denen sich während der Bearbeitung des übergreifenden Incidents und trotz umfangreicher Vorprüfung des Incidents herausstellt, dass eine Lösung bzw. Behebung des Incidents nicht durch ihn selber möglich ist, MÜSSEN
• unverzüglich den richtigen support- und lösungsverantwortlichen ITSM-TI-Teilnehmer ermitteln,
• unverzüglich den Incident an den richtigen support- und lösungsverantwortlichen ITSM-TI-Teilnehmer strukturiert übermitteln bzw. für die Incident Bearbeitung durch diesen, eine strukturierte Informationsübermittlung gemäß der Festlegungen für einen übergreifenden Incident durchführen.
(Zur Identifikation des richtigen support- und lösungsverantwortlichen ITSM-TI-Teilnehmers werden innerhalb des Betriebskonzepts die Leistungs- und Supportmodelle definiert. Zudem werden in der zentralen Wissensdatenbank Kontaktinformationen von ITSM-TI-Teilnehmern bereitgestellt.)
[<=]
8.5.6 Schließung übergreifender Incidents
GS-A_3908 - Schließung übergreifender Incident, mit abschließender Bearbeitung im ITSM-TI-Teilnehmersupport
ITSM-TI-Teilnehmer MÜSSEN die Schließung eines übergreifenden Incidents, mit abschließender Bearbeitung im ITSM-TI-Teilnehmersupport analog zu GS-A_3887, GS-A_3888, GS-A_3889 im Anwendersupport durchführen.
ITSM-TI-Teilnehmer MÜSSEN bei Schließung eines übergreifenden Incidents, mit abschließender Bearbeitung im ITSM-TI-Teilnehmersupport analog zu GS-A_3890 im Anwendersupport an den Meldenden des übergreifenden Incidents eine Information versenden.
[<=]
GS-A_5250 - Lösungsverifikation vor Schließung
ITSM-TI-Teilnehmer MÜSSEN vor der Schließung eines übergreifenden Incidents die Bestätigung des Incident-Melders über die Behebung der Störung einholen und den Incidentstatus auf „gelöst“ setzen. Die Lösungsverantwortung bleibt bis zur Schließung des Tickets die ganze Zeit beim Lösungsverantwortlichen. Mit Ablehnung der Incident-Lösung durch den Melder des übergreifenden Incidents MUSS die Messung der Lösungszeit fortgesetzt und der Status auf „in Bearbeitung“ gesetzt werden.
[<=]
Ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.
8.5.7 interne Dokumentation übergreifender Incidents
GS-A_3909 - interne Dokumentation einer übergreifenden Incident-Meldung, bei nicht vorhandener Lösungsverantwortung
Supportverantwortliche ITSM-TI-Teilnehmer, die bei der Vorprüfung eines übergreifenden Incidents feststellen, dass sie nicht lösungsverantwortlich sind, MÜSSEN bevor sie die Incident-Dokumentation an den lösungsverantwortlichen ITSM-TI-Teilnehmer übermitteln, eine interne Dokumentation des ihnen gemeldeten Incidents vornehmen.
ITSM-TI-Teilnehmer MÜSSEN dabei eine Erfassung, Kategorisierung und Priorisierung des übergreifenden Incidents analog zu GS-A_3879, GS-A_3880 , GS-A_3881,GS-A_3882 , GS-A_3883, GS-A_3884 durchführen.
[<=]
8.5.8 strukturierte Informationsübermittlung übergreifender Incidents
GS-A_3910 - strukturierte Informationsübermittlung von übergreifender Incidents im ITSM-TI-Teilnehmersupport
ITSM-TI-Teilnehmer, die eine übergreifende Incident-Dokumentation eröffnen, MÜSSEN diese - innerhalb der vorgegebenen Reaktionszeit - nach Weiterbearbeitung, an den zuständigen Support- bzw. Lösungsverantwortlichen strukturiert übermitteln.
[<=]
Ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.
8.5.9 Service Level Requirements (SLR)
GS-A_3911 - Service Level Requirements im ITSM-TI-Teilnehmersupport
Aufbauend auf die in den jeweiligen Verträgen geregelten Servicezeiten MÜSSEN ITSM-TI-Teilnehmer innerhalb des ITSM-TI-Teilnehmersupports mindestens folgende Service Level messen und berichten:
Tabelle 26: Tab_Betr_TIP_013 INC – SLR ITSM-TI-Teilnehmersupport „Prozess“
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Die Ausgestaltung der Service Level erfolgt im Betriebskonzept [gemKPT_Betr].
[<=]
Die Gesamtlösungszeit für einen übergreifenden Incident wird vorerst durch diese Richtlinie nicht weiter geregelt. Diese ergibt sich aus der Lösungszeit des übergreifenden Incidents beim Lösungsverantwortlichen sowie den Qualifizierungs- und Reaktionszeiten der zuvor am übergreifenden Incident beteiligten ITSM-TI-Teilnehmern.
Beim Wechsel der Priorität eines Incidents ergeben sich im Regelfall Änderungen der Lösungszeiten. Diese Änderungen sollen gemäß den nachfolgenden Beschreibungen und Beispielen behandelt werden:
• Bei einem Prioritätenwechsel eines Incidents von 3/4 auf 1/2 beginnt die Lösungszeit von neuem (Anpassung der Service Level). Dabei darf die Restlaufzeit des „alten“ Incidents nicht überschritten werden. Die Incident-ID bleibt gleich.
Beispiel: Ein Incident der Priorität 3 hat den Service Level von 10 Stunden. Der Incident läuft bereits 8 Stunden. Der Incident wird jetzt auf Stufe 1 umpriorisiert und hat einen Service Level von 3 Stunden. Die Service Level -Zeit wird neu gesetzt, endet allerdings nach 2 Stunden, da die Restlaufzeit des alten Incidents nicht überschritten werden darf.
• Bei einem Prioritätswechsel von 1/2 auf 3/4 gilt als Restlaufzeit die Laufzeit der niedrigeren Priorität abzüglich der bereits abgelaufenen Zeit des "alten" Incidents.
Beispiel: Ein Incident der Priorität 1 hat einen Service Level von 3 Stunden. Der Incident läuft bereits 2 Stunden. Der Incident wird jetzt auf Stufe 3 umpriorisiert und hat einen Service Level von 10 Stunden. Die Service Level Zeit wird neu gesetzt, endet allerdings nach 8 Stunden, da zwei Stunden der zulässigen Laufzeit in Priorität 3 bereits in der höheren Priorität "verbraucht" wurden.
GS-A_3912 - Messung der Gesamtlösungszeit
ITSM-TI-Teilnehmer MÜSSEN, sofern durch den SBV ein Optimierungsbedarf der Gesamtlösungszeiten festgestellt wird, die Reaktions- und Qualifizierungszeit (prioritätsabhängig) gemäß den Vorgaben des SBV anpassen.
[<=]
8.6 Informationspflichten
GS-A_3913 - prioritätsabhängige Meldungen im lokalen Incident Management
ITSM-TI-Teilnehmer MÜSSEN bei lokalen Incidents, welche den Anforderungen an die Prioritäten 1 oder 2 des übergreifenden Incident Managements entsprechen, innerhalb ihres lokalen Incident Managements eine Meldung an den SBV versenden. Mindestinhalte sind dabei die unter genannten Inhalte bei Erfassung eines übergreifenden Incidents.
[<=]
GS-A_3914 - Statusinformation bei übergreifenden Incidents
ITSM-TI-Teilnehmer MÜSSEN bei jeder Statusänderung des Incidents eine Meldung über den aktuellen Status des übergreifenden Incidents an den SBV versenden. Bei übergreifenden Incidents erfolgt die Kommunikation über die ZID. Mindestinhalte sind dabei die unter „GS-A_3882 “ genannten Inhalte bei Erfassung eines übergreifenden Incidents.
[<=]
GS-A_3915 - Information bei Annahme von übergreifenden Incidents
ITSM-TI-Teilnehmer, denen bereits bei Annahme des übergreifenden Incidents ersichtlich ist, dass eine Lösung nicht innerhalb der vereinbarten Lösungszeiten herbeigeführt werden kann, MÜSSEN den SBV hierüber informieren. Bei übergreifenden Incidents erfolgt die Kommunikation über die ZID.
[<=]
GS-A_3916 - Informationen bei Bearbeitung von übergreifenden Incidents
Der lösungsverantwortliche ITSM-TI-Teilnehmer MUSS den SBV informieren, sobald ¾ der vereinbarten Lösungszeit für einen übergreifenden Incident verstrichen sind und nicht sichergestellt werden kann, dass in der verbleibenden Zeit eine Behebung des Incidents gewährleistet ist.
Der lösungsverantwortliche ITSM-TI-Teilnehmer MUSS den SBV über alle SLR-Verletzungen, die bei der Bearbeitung bzw. Behebung von übergreifenden Incidents entstehen, schriftlich (per E-Mail) informieren. Bei übergreifenden Incidents erfolgt die Kommunikation über die ZID.
[<=]
GS-A_3917 - Bereitstellung der Incident-Dokumentation bei Audits
ITSM-TI-Teilnehmer MÜSSEN bei der Durchführung von Audits der betrieblichen Vorgaben dem SBV auf Verlangen die Incident-Dokumentationen bereitstellen.
[<=]
8.7 Dokumentation
GS-A_3918 - Integrität der Dokumentation von übergreifenden Incidents
ITSM-TI-Teilnehmer MÜSSEN Datensätze der Incident-Dokumentationen vor nachträglicher Veränderung mittels Zeitstempeln sichern.
[<=]
Inhalte und Dokumentation von übergreifenden Incidents
GS-A_3882 - Mindestinhalte von übergreifenden Incidents
ITSM-TI-Teilnehmer MÜSSEN jede im übergreifenden Incident Management bearbeitete bzw. an diesen Prozess übergebene Incident-Dokumentation gemäß Tabelle 27: Tab_Betr_TIP_014 INC – Mindestinhalte Incident-Dokumentation erstellen.Die an die Webservice-Schnittstelle der ZID zu sendenden Daten entsprechen dieser Beschreibung. Die Felder sind im Anhang B beschrieben.Zeichenerklärung in der Spalte Befüllungszeitpunkt/BefüllungsstatusX entspricht muss befüllt bzw. geändert werden O entspricht kann befüllt bzw. geändert werden- entspricht darf nicht geändert werden
Tabelle 27: Tab_Betr_TIP_014 INC – Mindestinhalte Incident-Dokumentation
|
|
|
|
|
|
||||||
|
|
|
|
|
|
|
|||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[<=]
8.8 Eskalationen
GS-A_3919 - Bereitstellung Eskalationsschnittstelle
ITSM-TI-Teilnehmer MÜSSEN eine Kommunikationsschnittstelle (bspw. E-Mail, Telefon) für den Eskalationsfall bereitstellen und den SBV über die Inhalte (bspw. E-Mail-Adresse, Telefonnummer) in Kenntnis setzen.
ITSM-TI-Teilnehmer MÜSSEN dem SBV mitteilen, wenn die Inhalte (bspw. E-Mail-Adresse, Telefonnummer) der Kommunikationsschnittstelle für Eskalationen verändert werden.
[<=]
GS-A_3920 - Eskalationseinleitung durch den ITSM-TI-Teilnehmer im INC
ITSM-TI-Teilnehmer KÖNNEN bei (produkt-) übergreifenden Incidents eine hierarchische Eskalation an den SBV einleiten, wenn
• keine Einigung über die Support- bzw. Lösungsverantwortung für den übergreifenden Incident mit anderen ITSM-TI-Teilnehmern erzielt werden kann (bspw. wenn ein übergreifender Incident undokumentiert oder unausreichend dokumentiert abgelehnt wurde und kein Lösungsverantwortlicher benannt werden kann),
• nach seinem Verständnis zur Bewältigung bei Vorfällen - zur Gewährleistung der Performance, Sicherheit und Stabilität der zentralen und dezentralen Produkte - eine übergeordnete Koordination notwendig ist,
• er keinen support- bzw. lösungsverantwortlichen ITSM-TI-Teilnehmer ermitteln kann,
• die Bearbeitung durch einen anderen ITSM-TI-Teilnehmer zu lange dauert oder sich als schwierig erweist.
[<=]
GS-A_3921 - Eskalationsinhalte im INC
ITSM-TI-Teilnehmer MÜSSEN bei jeder Eskalationsmeldung an einen SBV im übergreifenden Incident Management folgende Inhalte übermitteln:
• aktuelle Incident-Dokumentation gemäß GS-A_3882
• Das Worklog der Incident-Dokumentation muss um folgende Informationen ergänzt werden:
o Eskalationsbeschreibung: qualifizierte Beschreibung aller bislang erfolgten Prüfungen, Aktionen/Eskalationen und Schritte, Eskalationsgrund und Dringlichkeit sowie konkret angefragter Unterstützungsbedarf.
o Eskalationsmelder sowie Kontaktdaten, inklusive Telefonnummer und E-Mail-Adresse für eventuelle Rückfragen.
Die Eskalationsmeldung muss strukturiert über die ZID erfolgen.
[<=]
Ergänzende Erläuterungen zum konkreten Vorgehen und der Austausch der festgelegten Kommunikationsschnittstellen (z.B. Kontaktinformationen, E-Mail-Adressen) werden im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.
Bei Incidents mit (produkt-)übergreifender Auswirkung kann der Gesamtverantwortliche der TI - zur Gewährleistung der Performance, Sicherheit und Stabilität der zentralen und dezentralen Produkte – eine Taskforce zur Behebung der Störung bilden. Diese wird aus mehreren der am Betriebsprozess beteiligten ITSM-TI-Teilnehmer zusammengesetzt.
GS-A_3922 - Mitwirkung bei serviceübergreifenden Taskforces im Eskalationsfall
ITSM-TI--Teilnehmer MÜSSEN, wenn sie zur Teilnahme bei einer Taskforce zur Behebung von übergreifenden Incidents mit der Priorität 1 oder 2 aufgefordert werden, der Taskforce beitreten und die Lösungsfindung unterstützen.
ITSM-TI-Teilnehmer MÜSSEN nach der Lösung des übergreifenden Incidents mit der Priorität 1 oder 2 innerhalb einer Taskforce im Anschluss die Erstellung des Abschlussberichtes bzw. die Durchführung des Audits unterstützen.
[<=]
8.9 Prozessreporting (Vorgangsdaten) INC
GS-A_3923 - Zusendung von Reports an den Servicebetriebsverantwortlichen
ITSM-TI-Teilnehmer MÜSSEN, zur Sicherstellung und Optimierung der Prozessqualität, Reports - gemäß den produkttypabhängigen Frequenzen (siehe Betriebskonzept) - an den SBV versenden.
[<=]
GS-A_3924 - Bereitstellung von Vorgangsdaten aus dem übergreifenden Incident Management
ITSM-TI-Teilnehmer MÜSSEN die an den SBV zu versendenden Reports im .CSV-Format übermitteln.
ITSM-TI-Teilnehmer MÜSSEN bei den an den SBV zu versendenden Reports die AFO GS-A_5248 beachten.
[<=]
GS-A_3925 - Reportinhalte von Vorgangsdaten aus dem übergreifenden Incident Management
ITSM-TI-Teilnehmer MÜSSEN Vorgangsdatenreports nach der in „GS-A_3882 “ genannten Struktur (die Reihenfolge ist ebenfalls verbindlich) erstellen. Alle Felder der Tabelle 27: Tab_Betr_TIP_014 INC – Mindestinhalte Incident-Dokumentation sind für Reports relevant.
[<=]
Ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.
8.10 Obliegenheiten SBV/GTI
Obliegenheiten des SBV:
• Der jeweilige SBV nimmt Eskalationsmeldungen entgegen und entscheidet, ob eine Meldung an den GTI durchzuführen ist.
• Der jeweilige SBV nimmt übergreifende Incidents mit der Priorität 1 und 2 entgegen und entscheidet, ob eine Meldung an den GTI durchzuführen ist.
• Der jeweilige SBV wird sich bei übergreifenden Incidents der Priorität 1 oder 2 selbständig über den jeweils aktuellen Stand der Bearbeitung durch den betreffenden ITSM-TI-Teilnehmer informieren, so dass er gegenüber dem GTI jederzeit auskunftsfähig ist.
Obliegenheiten der GBV TI:
• Bei Incidents mit (produkt-)übergreifender Auswirkung kann der Gesamtverantwortliche der TI - zur Gewährleistung der Performance, Sicherheit und Stabilität der zentralen und dezentralen Produkte - eine zentrale Koordinierung der Aktivitäten der anderen Prozessbeteiligten übernehmen.
Bei Incidents mit (produkt-)übergreifender Auswirkung kann der Gesamtverantwortliche der TI - zur Gewährleistung der Performance, Sicherheit und Stabilität der zentralen und dezentralen Produkte - eine Taskforce zur Behebung der Störung bilden. Diese wird aus mehreren der am Betriebsprozess beteiligten ITSM-TI-Teilnehmern durch den GTI zusammengesetztPerformance-Bewertung beinhaltet die Feststellung, Überwachung und Analyse der definierten Kenngrößen und Parameter. Des Weiteren bildet sie die Grundlage für die Planung einer rechtzeitigen Bereitstellung der notwendigen Kapazitäten und Verfügbarkeiten in der TI-Infrastruktur. Hierbei werden sowohl zukünftige Leistungsanforderungen und -angebote als auch Änderung im Nutzungsverhalten und von technischen Rahmenbedingungen berücksichtigt.
GS-A_5606 - Unterstützung bei Definition von Kapazitätsanforderungen
TI-ITSM-Teilnehmer MÜSSEN auf Anforderung des Gesamtverantwortlichen TI an Gesprächen zur Bewertung der aktuellen Kapazitätssituation teilnehmen. Sie MÜSSEN den Gesamtverantwortlichen TI bei der Entwicklung und Definition von zukünftigen Kapazitätsanforderungen unterstützen.
[<=]
Die eigentliche Entwicklung von Maßnahmen bei festgestellten und diagnostizierten Anforderungsbedarfen und deren Nachverfolgung erfolgt in den jeweils zutreffenden ITSM-Prozessen und werden dort dokumentiert (z. B. Problem-Management, Change-Management).
10.2.4 Service Monitoring (finale Lösung)
Mit Einführung der finalen Lösung des Service Monitoring der TI wird die Neuausrichtung der TI-Betriebssteuerung auch systemtechnisch sichtbar. Mit Hilfe des neuen Systems werden einerseits Verfügbarkeit und Antwortzeit von TI-Systemen und Services bzw. Dienste gemessen und überwacht, andererseits berichten die TI-ITSM-Teilnehmer ihre Performancedaten ebenfalls zukünftig ausschließlich an dieses System. Neben der physikalischen Erreichbarkeit werden vom System selbst auch qualifizierte Anfragen an die Dienste gestellt und aus den Antworten dieser wird (automatisiert) auf den Servicezustand geschlossen.
Die gematik wird auf Basis dieser Auswertungen jederzeit zum aktuellen Status der TI aussagefähig sein und kann auf Basis der Kenntnis um den äußeren Gesamtstatus der TI ggf. notwendige Maßnahmen einleiten. Das Service Monitoring beinhaltet damit sämtliche Themen des hier definierten Performance Managements. Eine Überwachung der Systeme und Services, die sich in der Eigenverantwortlichkeit der TI-ITSM-Teilnehmer befinden, findet allerdings nicht statt.
Nutzer des Service Monitoring Systems sind alle am Betrieb der TI Beteiligten (gemäß Definition dieser Richtlinien [gemRL_Betr_TI]). Anwender (Versicherte/Leistungserbringer) haben keinen direkten Zugriff. Die Regelung des Zugriffs auf die Darstellungseinheit des Service Monitoring Systems (Live-Dashboard) erfolgt über ein Rollen- und Berechtigungskonzept. Auf der Darstellungseinheit werden z. B. die Auswirkungen eines festgestellten Servicedefizites angezeigt. Weiterhin besteht die Möglichkeit zur Anbindung von Drittsystemen bei den TI-ITSM-Teilnehmern mittels Schnittstelle gemäß den definierten Berechtigungen. Auf diese Weise können Meldungen über aktuelle Systemzustände bzw. Systemdefizite der betroffenen Dienste automatisiert auch auf Drittsysteme übertragen werden.
• Nach Bildung einer Taskforce und Lösung des Incidents kann der GTI ein Abschlussbericht oder ein Audit durchführen.
9 Problem Management (PRO)
Um zwischen den verschiedenen ITSM-TI-Teilnehmern der TI sicherzustellen, dass
• Probleme gemäß ihrer Auswirkungen eine konsistent gleiche Behandlung erfahren,
• im Rahmen der Unterstützung der Problembearbeitung, sofern mehrere ITSM-TI-Teilnehmer involviert werden müssen, die Übergabe von Problemen untereinander reibungslos und nachvollziehbar gewährleistet wird,
• eine zuverlässige Lösung von aufgetretenen Problemen anbieterübergreifend gewährleistet ist,
ist durch ITSM-TI-Teilnehmer ein übergreifendes Problem Management (PRO) zu etablieren.
Die nachfolgende Abbildung veranschaulicht die Regelungen des übergreifenden Problem Managements im ITSM-TI-Teilnehmer-relevante Prozessausschnitt und gibt eine Zuordnung der einzelnen Prozessinhalte zu den nachfolgenden Kapiteln.
Abbildung 14: PRO – Gesamtüberblick "Problem Management“
9.1 Betrachtungsgegenstand des übergreifenden PRO
Im Fokus der nachfolgenden Problem-Management-Grundsätze im übergreifenden Betrieb stehen ITSM-TI-Teilnehmerübergreifende Probleme.
Eine Anfrage zur übergreifenden Lösungsunterstützung und Klärung der Problemlösungsverantwortlichkeit zwischen ITSM-TI-Teilnehmern erfolgt nach dem any-to-any-Prinzip, d. h. jeder ITSM-TI-Teilnehmer bietet prinzipiell jedem anderen ITSM-TI-Teilnehmer Problemlösungssupport in zumutbaren Umfang an.
Anforderungen an die Dokumentation, die Information und das Reporting sind so ausgeprägt, dass sie mit Hilfe von Standard-Kommunikationswerkzeugen (bspw. E-Mail, Standard-Office-Produkte) durchgeführt werden können.
Der Einsatz bzw. die Anpassung bestehender Verfahren und Werkzeuge (bspw. der Ticketsysteme) kann die Effizienz der Problembearbeitung erhöhen, ist jedoch keine Voraussetzung für das übergreifende PRO.
9.2 Begriffserläuterungen
9.2.1 Problem
Bei einem Problem handelt es sich um die unbekannte Ursache einer eingetretenen oder einer möglichen Störung (Incident). Die Problemlösung vollzieht sich in 2 Phasen:
1. Durchführen einer Ursachenanalyse und
2. Entwickeln und implementieren einer Lösung. Diese wirkt nachhaltig und verhindert das erneute Auftreten von wiederkehrenden Störungen, die durch das Problem bedingt verursacht wurden.
9.2.2 Lokales Problem
Ein lokales Problem liegt vor, wenn zu seiner Ursachenanalyse und Lösung der problemlösungsverantwortliche ITSM-TI-Teilnehmer keine anderen am Betrieb beteiligten ITSM-TI-Teilnehmer benötigt.
Ein lokales Problem wird dabei innerhalb der lokalen Problem-Management-Prozesse des ITSM-TI-Teilnehmers verarbeitet und unterliegt nur insofern Regelungen durch diese Richtlinie, wie sie zur Wahrnehmung der Gesamtverantwortung, insbesondere zur Gewährleistung der Performance, Sicherheit und Stabilität der TI-Services und der zentralen und dezentralen Produkte notwendig ist.
9.2.3 Übergreifendes Problem
Ein übergreifendes Problem liegt vor, wenn zu seiner Ursachenanalyse und Lösung mehrere der am Betriebsprozess beteiligten ITSM-TI-Teilnehmer involviert werden müssen.
9.2.4 Problemerkennender
Ein ITSM-TI-Teilnehmer, der ein Problem identifiziert hat, jedoch für die Problembehebung nicht zuständig ist, ist als Problemerkennender zu bezeichnen. Die gematik in ihrer Rolle als GTI darf ein identifiziertes Problem an den aus ihrer Sicht verantwortlichen ITSM-TI-Teilnehmer als Problemverantwortlichen übergeben. Im Rahmen der übergreifenden Problemursachenanalyse kann ein Problemerkennender die Rolle eines Problemlösungsverantwortlichen übernehmen. In diesem Fall muss er beide Rollen (Problemerkennender und Problemlösungsverantwortlicher) einnehmen.
9.2.5 Problemlösungsverantwortlicher
Ein Problemlösungsverantwortlicher ist ein ITSM-TI-Teilnehmer, dessen Produkt für die Störung verantwortlich ist. Der Problemlösungsverantwortliche hat nach erfolgter Ursachenanalyse die Lösungsverantwortung bis zur Problembehebung.
9.2.6 Lösungsunterstützender
Ein von einem ITSM-TI-Teilnehmer zur Problemlösungsunterstützung angefragter anderer ITSM-TI-Teilnehmer ist als lösungsunterstützender ITSM-TI-Teilnehmer zu bezeichnen. Der lösungsunterstützende ITSM-TI-Teilnehmer hat den Problemlösungsverantwortlichen in seiner Problemlösung zu unterstützen.
9.3 Grundsätze des übergreifenden Problem Managements
An die bestehenden lokalen Problemlösungsverfahren der ITSM-TI-Teilnehmer werden keine Anforderungen gestellt, eine Regelung der Verfahren erfolgt ausschließlich im Rahmen der übergreifenden Problembearbeitung.
Die nachfolgenden Grundsätze bilden die übergeordneten Regelungen des übergreifenden Problem Managements für ITSM-TI-Teilnehmer.
9.3.1 Zentrale PRO Koordinierung durch den SBV TI
Bei Eskalationen eines Problems mit (produkt-)übergreifender Auswirkung kann der jeweils zuständige SBV - zur Gewährleistung der Performance, Sicherheit und Stabilität der zentralen und dezentralen Produkte - eine zentrale Koordinierung der Aktivitäten der anderen Beteiligten übernehmen.
Die Koordination der Problemlösung erfolgt durch die betroffenen ITSM-TI-Teilnehmer in Eigenverantwortung. Falls eine wirksame Kooperation zur Problemlösung nicht zustande kommt, hat der jeweils zuständige SBV koordinierend einzugreifen.
Der jeweils zuständige SBV kann innerhalb des übergreifenden Problem Managements für eine Koordination im Rahmen der Nachstellung von Fehlerzuständen in TI-Testumgebungen einbezogen werden.
9.4 Prozessdurchführung problemerkennende ITSM-TI-Teilnehmer
9.4.1 Problemerkennung
GS-A_3958 - Problemerkennung durch ITSM-TI-Teilnehmer
ITSM-TI-Teilnehmer MÜSSEN geeignete Maßnahmen implementieren, um proaktiv und reaktiv eine Problemerkennung zu ermöglichen.
(Bei einer Problemerkennung handelt es sich um eine Problemfeststellung im Betrieb der ITSM-TI-Teilnehmer.)
[<=]
9.4.2 Vorprüfung
Ziel der Vorprüfung ist die Identifizierung von Problemen mit produktübergreifender Ursache oder Auswirkung.
Abbildung 15: PRO – Vorprüfung problemerkennende ITSM-TI-Teilnehmer
GS-A_3959 - Vorprüfung als Problemerkennender
Die problemerkennenden ITSM-TI-Teilnehmer MÜSSEN jedes identifizierte Problem dahingehend prüfen, ob
1. es sich um ein Problem zur lokalen Bearbeitung handelt,
2. es sich um ein übergreifendes Problem handelt, für welches zur Problemlösung die problemlösungsverantwortlichen und lösungsunterstützenden ITSM-TI-Teilnehmer sowie der SV oder der SBV herangezogen werden sollen.
Problemerkennende ITSM-TI-Teilnehmer MÜSSEN in Fall eins die Ursachenanalyse und Lösungsentwicklung des Problems eigenverantwortlich innerhalb der lokalen PRO-Prozesse fortsetzen, da es sich um ein lokales Problem handelt.
Problemerkennende ITSM-TI-Teilnehmer MÜSSEN in Fall zwei den übergreifenden Problem-Bearbeitungsprozess einleiten und zur Ursachenanalyse und Lösungsentwicklung des Problems die problemlösungsverantwortlichen und lösungsunterstützenden ITSM-TI-Teilnehmer sowie den SV oder den SBV anfragen.
[<=]
9.4.3 Lösung und Schließung im lokalen Problem Management
Die Ausgestaltung des Prozesses zur Lösung und Schließung lokaler Problem obliegt dem jeweiligen ITSM-TI-Teilnehmer. Folgende Anforderungen sind dabei zu berücksichtigen:
GS-A_3960 - Statusinformation an SBV für lokale Problems
ITSM-TI-Teilnehmer MÜSSEN den SBV über den Status lokaler Probleme informieren, wenn das lokale Problem die Schwellwerte für die Priorität 1 oder 2 erfüllt. Es gelten die Service Level Requirements für Statusinformation an den SBV gemäß GS-A_3972.
[<=]
9.4.4 Erfassung, Kategorisierung & Priorisierung übergreifender Probleme
Das Ziel der Erfassung, Kategorisierung & Priorisierung ist die Festlegung einer einheitlich gestalteten, an den lösungsunterstützenden ITSM-TI-Teilnehmer gestellten Anfrage zur Unterstützung des übergreifenden Problems sowie die Nutzung einer einheitlichen Dokumentation für die Kommunikation mit allen beteiligten ITSM-TI-Teilnehmern sowie SV oder SBV, insbesondere für das Reporting.
eineindeutige Referenznummer von übergreifenden Problemen
GS-A_3961 - eineindeutige Referenznummer von übergreifenden Problemen
Problemerkennende ITSM-TI-Teilnehmer MÜSSEN bei der Erfassung eine eineindeutige Referenznummer für ein übergreifendes Problemen nach folgendem Schema vergeben:
Die eineindeutige Referenznummer für übergreifende Problemdokumentation MUSS über die jeweilige Problem-ID gebildet werden, die sich aus dem aktuellem Jahr (JJJJ), der Teilnehmer-ID (TID) und einer laufenden Problemnummer (PN, Integer [5]) in dem Format „JJJJ-TID-PN“ (bspw. „JJJJ-K234A-12345“) zusammensetzt.
[<=]
GS-A_3962 - Eineindeutigkeit der Problem ID
ITSM-TI-Teilnehmer MÜSSEN bei der Schnittstellenkommunikation mit anderen ITSM-TI-Teilnehmern beachten, dass sich die einmalig bei der Ersterfassung des übergreifenden Problems aufgenommene, eindeutige Referenznummer (in Form der Problem-ID) innerhalb der gesamten Kommunikation nicht ändert, d.h. prozessdurchgängig konstant bleibt.
[<=]
Kategorisierung von übergreifenden Problemen
GS-A_3963 - Kategorisierung von übergreifenden Problemen
Problemerkennender ITSM-TI-Teilnehmer MÜSSEN jedes identifizierte übergreifende Problem kategorisieren. Zur Kategorisierung MÜSSEN mindestens die im Rahmen der TI vorgegebenen Produkttypen genutzt werden.
[<=]
Priorisierung von übergreifenden Problemen
GS-A_3964 - Priorisierung von übergreifenden Problemen
ITSM-TI-Teilnehmer MÜSSEN jedes identifizierte übergreifende Problem gemäß nachfolgendem Schema priorisieren. Dabei ist die Anzahl der möglichen Prioritäten gemäß der in GS-A_3884 aufgeführten Prioritätenmatrix wie folgt festgelegt: Jedes im übergreifenden Problem Management identifizierte bzw. an diesen Prozess übergebene Problem MUSS entsprechend einer vierstufigen Einteilung - wobei 1 die höchste und 4 die niedrigste Priorität ist - eingestuft werden.
• Priorität 1- Kritisch,
• Priorität 2 - Hoch,
• Priorität 3 - Mittel,
• Priorität 4 - Niedrig.
(Anhand der Priorisierung müssen die in Service Level Requirements genannte Qualitätsdimensionen (siehe GS-A_3972) eingehalten werden, wobei die Festlegung von Service Level Requirements für Prioritäten im Betriebskonzept stattfindet.) [<=]
9.4.5 Anfrage zur Unterstützung übergreifender Probleme
GS-A_3965 - Anfrage zur Unterstützung von übergreifenden Problemen bei lösungsunterstützenden ITSM-TI-Teilnehmern
Problemerkennende ITSM-TI-Teilnehmer MÜSSEN in der Anfrage an die lösungsunterstützenden ITSM-TI-Teilnehmer eine qualifizierte Beschreibung der benötigten Unterstützungsleistung vornehmen.
[<=]
GS-A_3966 - Zusendung der Anfrage zur Unterstützung von übergreifenden Problemen
ITSM-TI-Teilnehmer MÜSSEN eine übergreifende Problemanfrage zur Unterstützung mit Informationen gemäß GS-A_3961, GS-A_3962 , GS-A_3963, GS-A_3964 und GS-A_4000, schriftlich, innerhalb der vorgegebenen Qualifizierungszeit „Start Problembearbeitung durch Problemerkennenden“ (gemäß GS-A_3972) und auf elektronischem Weg an den lösungsunterstützenden ITSM-TI-Teilnehmer senden.
[<=]
GS-A_3967 - Nutzung der Kommunikationsschnittstelle bei Anfrage zur Unterstützung von übergreifenden Problemen
ITSM-TI-Teilnehmer MÜSSEN bei einer Anfrage zur Lösungsunterstützung von übergreifenden Problemen die ZID nutzen.
[<=]
9.4.6 Ermittlung der Problemlösungsverantwortung bei übergreifenden Problemen
Der problemerkennende ITSM-TI-Teilnehmer kann zur Ermittlung der Problemlösungsverantwortung die Wissensdatenbank als Informationsquelle nutzen.
GS-A_3968 - Anfrage zur Ermittlung der Problemlösungsverantwortung von übergreifenden Problemen
Problemerkennende ITSM-TI-Teilnehmer MÜSSEN in der Anfrage zur Ermittlung der Problemlösungsverantwortung von übergreifenden Problemen an den (aus ihrer Sicht) problemlösungsverantwortlichen ITSM-TI-Teilnehmer eine qualifizierte Beschreibung zur Klärung der Problemlösungsverantwortung vornehmen.
[<=]
GS-A_5373 - Vollständiger Statusdurchlauf nach Übernahme der Lösungsverantwortung
Der PLV MUSS nach Übernahme der Lösungsverantwortung sämtliche Status nacheinander durchlaufen, bis das Ticket in den Status „Lösung implementiert“ überführt wurde (d.h. von „PLV ermittelt“ -> „In Bearbeitung“ -> „Ursache erkannt“ -> „Lösung bekannt“ -> „Lösung implementiert“).
Der vollständige Statusdurchlauf MUSS auch dann erfolgen, wenn die implementierte Lösung nicht das Problem erledigt. In diesem Fall MUSS das Ticket im Status „PLV ermittelt“ an den PLV weitergeleitet werden. Der PLV MUSS das Ticket in den Status „In Bearbeitung“ setzen und die nachfolgenden Status sukzessive durchlaufen.
[<=]
GS-A_5381 - Statusdurchlauf von CSV-angebundenen Anbietern und SPEDs
Die CSV-angebundenen Anbieter und SPEDs MÜSSEN den Statuswechsel („In Bearbeitung“, „Ursache erkannt“, „Lösung bekannt“) durch entsprechende Statusmeldungen (Meldungstyp „SI“) nachweisen
[<=]
GS-A_3969 - Zusendung der Anfrage zur Ermittlung der Problemlösungsverantwortung von übergreifenden Problemen
ITSM-TI-Teilnehmer MÜSSEN eine Anfrage zur Ermittlung der Problemlösungsverantwortung mit Informationen gemäß GS-A_3961, GS-A_3962 , GS-A_3963, GS-A_3964, GS-A_4000 und GS-A_5200 schriftlich, innerhalb der vorgegebenen Qualifizierungszeit „Start Problembearbeitung durch Problemerkennenden“ (GS-A_3972) und auf elektronischem Weg an den problemlösungsverantwortlichen ITSM-TI-Teilnehmer senden.
[<=]
GS-A_3970 - Nutzung der Kommunikationsschnittstelle bei Anfrage zur Ermittlung der Problemlösungsverantwortung von übergreifenden Problemen
ITSM-TI-Teilnehmer MÜSSEN bei einer Anfrage zur Ermittlung der Problemlösungsverantwortung von übergreifenden Problemen die ZID nutzen.
[<=]
Ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.
9.4.7 Problemschließung
GS-A_3971 - Problem nach Verifizierung schließen
Problemerkennende ITSM-TI-Teilnehmer MÜSSEN die Problemschließung des problemlösungsverantwortlichen ITSM-TI-Teilnehmers verifizieren sowie bei vollständiger Problemlösungsentwicklung lokal schließen. Problemerkennende ITSM-TI-Teilnehmer MÜSSEN bei nicht vollständiger Problemlösungsentwicklung den problemlösungsverantwortlichen ITSM-TI-Teilnehmer solange mit der Nacharbeit beauftragen, bis die Problemlösung erfolgt ist und anschließend das Problem lokal schließen.
[<=]
Weitere ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.
9.4.8 Service Level Requirements (SLR)
GS-A_3972 - Service Level Requirements problemerkennende ITSM-TI-Teilnehmer
Aufbauend auf die in den jeweiligen Verträgen geregelten Servicezeiten MÜSSEN problemerkennende ITSM-TI-Teilnehmer mindestens folgende Service Level messen und berichten:
Tabelle 28: Tab_Betr_TIP_016 PRO – SLR Problemerkennende ITSM-TI TN „Prozess”
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Die Ausgestaltung der Service Level erfolgt im Betriebskonzept [gemKPT_Betr]. [<=]
9.5 Prozessdurchführung lösungsunterstützende ITSM-TI-Teilnehmer
9.5.1 Vorprüfung
Das Ziel der Vorprüfung ist die Feststellung der Lösungsunterstützung der ITSM-TI-Teilnehmer im Rahmen des übergreifenden PRO.
Abbildung 16: PRO – Vorprüfung lösungsunterstützende ITSM-TI-Teilnehmer
GS-A_3975 - Vorprüfung lösungsunterstützende ITSM-TI-Teilnehmer
ITSM-TI-Teilnehmer MÜSSEN jedes von dem problemerkennenden oder problemverantwortlichen ITSM-TI-Teilnehmer zur Lösungsunterstützung angefragte übergreifende Problem dahingehend prüfen, ob
1. das übergreifende Problem in der eigenen Lösungsunterstützung liegt und angenommen werden muss,
2. das übergreifende Problem nicht in der eigenen Lösungsunterstützung liegt und dokumentiert abgelehnt werden muss.
[<=]
9.5.2 Ablehnung
GS-A_3976 - Ablehnung von übergreifenden Problemen bei lösungsunterstützenden ITSM-TI-Teilnehmern
ITSM-TI-Teilnehmer, die ein übergreifendes Problem ablehnen, MÜSSEN dieses mit einer qualifizierten Rückmeldung an den anfragenden ITSM-TI-Teilnehmer des übergreifenden Problems durchführen, aus der nachvollziehbar zu entnehmen ist, warum keine Lösungsunterstützung erfolgen kann.
[<=]
Ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.
9.5.3 Unterstützung Problembearbeitung
Bei Unterstützung Problembearbeitung handelt es sich um die unterstützenden Leistungen der ITSM-TI-Teilnehmer bei der Analyse bzw. Lösung der übergreifenden Probleme der problemerkennenden oder problemlösungsverantwortlichen ITSM-TI-Teilnehmer.
GS-A_3977 - Unterstützung bei übergreifenden Problemen
Lösungsunterstützende ITSM-TI-Teilnehmer, die ein übergreifendes Problem angenommen haben, MÜSSEN bei der Bearbeitung von übergreifenden Problemen im erforderlichen Umfang Unterstützung leisten.
[<=]
9.5.4 Service Level Requirements (SLR)
GS-A_3978 - Service Level Requirements für lösungsunterstützende ITSM-TI-Teilnehmer
Aufbauend auf die in den jeweiligen Verträgen geregelten Servicezeiten MÜSSEN lösungsunterstützende ITSM-TI-Teilnehmer mindestens folgende Service Level messen und berichten:
Tabelle 29: Tab_Betr_TIP_018 PRO – SLR Lösungsunterstützende ITSM-TI Tln „Prozess”
|
|
|
|
|
|
|
|
|
|
Die Ausgestaltung der Service Level erfolgt im Betriebskonzept [gemKPT_Betr]
[<=]
9.6 Prozessdurchführung problemlösungsverantwortlicher ITSM-TI-Teilnehmer
9.6.1 Vorprüfung
Ziel der Vorprüfung ist die Feststellung der Problemlösungsverantwortlichkeit bei Problemen mit produktübergreifender Ursache oder Auswirkung.
Abbildung 17: PRO – Vorprüfung problemlösungsverantwortlicher ITSM-TI-Teilnehmer
GS-A_3981 - Problembearbeitung von übergreifenden Problemen
Problemlösungsverantwortliche ITSM-TI-Teilnehmer, welche das übergreifende Problem identifiziert sowie dokumentiert haben, MÜSSEN unverzüglich den Problem-Bearbeitungsprozess entsprechend der festgestellten Problempriorität auslösen.
[<=]
9.6.2 Ablehnung
GS-A_3982 - Ablehnung von übergreifenden Problemen durch problemlösungsverantwortliche ITSM-TI-Teilnehmer
ITSM-TI-Teilnehmer, die ein übergreifendes Problem ablehnen, MÜSSEN dieses mit einer qualifizierten Rückmeldung an den anfragenden ITSM-TI-Teilnehmer des übergreifenden Problems durchführen, aus der nachvollziehbar zu entnehmen ist, warum keine Problemlösungsverantwortung übernommen werden kann.
[<=]
Ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.
9.6.3 Problem Ursachenanalyse
GS-A_3983 - Ursachenanalyse von übergreifenden Problemen durch Problemlösungsverantwortlichen
Die Ursachenanalyse der Problemlösung MUSS durch den problemlösungsverantwortlichen ITSM-TI-Teilnehmer erfolgen.
[<=]
Der problemlösungsverantwortliche ITSM-TI-Teilnehmer kann während der Bearbeitung die Wissensdatenbank zur Ursachenanalyse als Informationsquelle nutzen.
9.6.4 Anfrage zur Bereitstellung der Testumgebung bei SBV
GS-A_3984 - Anfrage zur Bereitstellung der TI-Testumgebung
ITSM-TI-Teilnehmer, die für die Lösung des übergreifenden Problems eine TI-Testumgebung benötigen, MÜSSEN die Nutzung vorab beim SBV anfragen.
ITSM-TI Teilnehmer MÜSSEN in der an einen SBV zu meldenden Anfrage beschreiben, welche Art der Unterstützung, zu welchem Zeitpunkt und im welchen Umfang benötigt wird.
[<=]
Problemlösungsverantwortliche ITSM-TI-Teilnehmer müssen die von dem SV oder SBV zur Verfügung gestellte Kommunikationsschnittstelle nutzen.
9.6.5 Anfrage zu Produkttypvorgaben
GS-A_3985 - Anfrage Produkttypvorgaben
Problemlösungsverantwortliche ITSM-TI-Teilnehmer KÖNNEN bei Fragen zu den spezifischen Produkttypvorgaben, mittels der vom SV bereitgestellten Kommunikationsschnittstelle, beim zuständigen SV Unterstützung und Klärungen anfordern.
[<=]
GS-A_5355 - Anfrage einer Lösungsunterstützung durch Problemlösungsverantwortlichen
Ein Problemlösungsverantwortlicher KANN eine Anfrage zur Lösungsunterstützung ohne Übergang der Lösungsverantwortung stellen.
Dabei KANN pro Anfrage nur ein ITSM-TI-Teilnehmer zur Lösungsunterstützung adressiert werden.
Der angefragte ITSM-TI-Teilnehmer erhält Zugriff auf das Ticket.
Dieser Zugriff endet mit Ablehnung der Lösungsunterstützung.
[<=]
Eine weitere Detailierung hierzu findet sich in der Wissensdatenbank.
9.6.6 Problem Lösungsentwicklung und -implementierung
Die Lösungsentwicklung erfolgt durch den problemlösungsverantwortlichen ITSM-TI-Teilnehmer. Dabei wird er von anderen am Prozess beteiligten ITSM-TI-Teilnehmer sowie von SBV und SV unterstützt.
GS-A_3986 - Problemlösungsverantwortliche Koordination von übergreifenden Problems
Die Koordination zwischen allen erforderlichen Lösungsbeteiligten im Rahmen der Problemlösungsentwicklung MUSS durch den problemlösungsverantwortlichen ITSM-TI-Teilnehmer erfolgen.
[<=]
GS-A_3987 - Lösung von übergreifenden Problemen
Der problemlösungsverantwortliche ITSM-TI-Teilnehmer MUSS unverzüglich mit der Problembearbeitung beginnen und innerhalb der vorgegebenen Problemlösungszeit eine Lösungsentwicklung für das Problem herbeiführen und dieses beheben.
Der problemlösungsverantwortliche ITSM-TI-Teilnehmer MUSS eine Dokumentation der Problemlösungsentwicklung vornehmen. Diese MUSS im qualifizierten Umfang bereitgestellt werden, aus dem hervorgeht, welche Problembehebungsmaßnahmen für das übergreifende Problem getroffen wurden.
Der problemlösungsverantwortliche ITSM-TI-Teilnehmer MUSS während der Problemlösungsentwicklung einen Change initiieren, in dem die Durchführung von Autorisierung, Entwicklung, Test und Implementierung der Lösung dokumentiert wird.
Der problemlösungsverantwortliche ITSM-TI-Teilnehmer MUSS im Rahmen der Problembehebung mit daraus hervorgehender Änderung an dem Produkt einen Verweis auf die RfC-ID (Request for Change ID) in die Dokumentation gemäß „GS-A_4000“ aufnehmen. Die Eintragung MUSS spätestens ab der Weiterleitung „WE“ mit „Lösung implementiert“ vorgenommen werden.
ITSM-TI-Teilnehmer MÜSSEN im Change-Management-Verweis der Dokumentation die zur Problemlösung notwendigen Maßnahmen und die durchgeführten Produkttypänderungen inkludieren.
[<=]
GS-A_5375 - Befüllung des Feldes Lösungsbeschreibung
Der Problemlösungsverantwortliche MUSS das Feld Lösungsbeschreibung in dem Problem Ticket ab dem Status „Lösung bekannt“ befüllen.
[<=]
GS-A_5376 - Befüllung des Feldes Zeitpunkt Lösung
Der Problemlösungsverantwortliche MUSS das Feld „Zeitpunkt Lösung“ im Problem Ticket frühestens zum Status „Lösung bekannt“ füllen und der Problemlösungsveranwortliche MUSS dieses Feld spätestens zum Status „Lösung implementiert“ gefüllt haben.
[<=]
9.6.7 Schließung übergreifendes Problem
Nach der Problemlösung wird die Lösung dem problemerkennenden ITSM-TI-Teilnehmer zur Verifizierung vorgelegt. Nach erfolgreicher Verifizierung erfolgt die vollständige Problemschließung durch den problemlösungsverantwortlichen ITSM-TI-Teilnehmer. Anschließend erfasst er die notwendige Dokumentation über die Problembehebung in der Wissensdatenbank.
Eine Problemlösung kann auch sein, dass die Problembearbeitung nicht weiterverfolgt wird, wobei das Problem in diesem Fall den abschließenden Status „Storniert“ erhält. Über dieses Vorgehen entscheidet der Problemerkennende bzw. Problemlösungsverantwortliche aber grundsätzlich niemals selbst, sondern darf den Status „Storniert“ immer nur mit Zustimmung des SBV oder GTI setzen. Die entsprechende Abstimmung und Begründung der Entscheidung ist vom Bearbeiter im Problem zu dokumentieren.
Ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt
GS-A_3988 - Versendung Verifizierung vor Schließung eines übergreifenden Problems
Problemlösungsverantwortliche ITSM-TI-Teilnehmer MÜSSEN vor Schließung eines übergreifenden Problems die Lösung des Problems durch den problemerkennenden ITSM-TI-Teilnehmer verifizieren lassen. Bei negativer Verifikation des Problems ist kein neues übergreifendes Problem zu eröffnen. Stattdessen ist das bestehende Problem weiterzubearbeiten. Es ist erneut der Status auf „In Bearbeitung“ zu setzen, außerdem wird die Lösungszeit fortgeschrieben. Dabei bestimmt der entsprechend im Problem gesetzte problemerkennende ITSM-TI-Teilnehmer den Zeitpunkt der Verifikation. Dies gilt sinngemäß auch für den Zeitpunkt der Bestätigung und Schließung.
[<=]
GS-A_3989 - Nacharbeitung vor Schließung eines übergreifenden Problems
Problemlösungsverantwortliche ITSM-TI-Teilnehmer MÜSSEN die von problemerkennenden ITSM-TI-Teilnehmer beauftragte Nacharbeit überprüfen und bei nicht vollständiger Lösungsentwicklung die Mängel beseitigen.
[<=]
GS-A_3990 - Schließung nach Verifizierung des Problemerkennenden
Problemlösungsverantwortliche ITSM-TI-Teilnehmer MÜSSEN nach der erfolgreichen Verifizierung eines übergreifenden Problems durch problemerkennende ITSM-TI-Teilnehmer dieses abschließend dokumentieren und schließen.
[<=]
GS-A_5377 - Durchführung einer Problemstornierung oder Problemannullierung
Der Problemlösungsverantwortliche MUSS ein Problem stornieren, wenn sich im Laufe der Lösungsbearbeitung herausstellt, dass die ursächliche Störung, der bekannte Fehler oder die bekannte Ursache zwischenzeitlich durch einen anderen Change oder auch einer lokalen Konfigurationsänderung gelöst wurde oder sich erledigt hat.
Der Problemlösungsverantwortliche MUSS auch dann ein Problem stornieren, wenn Auswirkungen des Problems und der Aufwand zur Behebung in keinem wirtschaftlichen oder sicherheitsrelevanten Verhältnis zueinander stehen oder das Ticket irrtümlich angelegt wurde und alle beteiligten Anbieter und SPEDs der Annullierung zustimmen.
[<=]
GS-A_5374 - Zustimmung zur Problemstornierung
Der GTI MUSS zur Stornierung eines Problems zustimmen. Die Stornierung des zentralen Tickets in der ZID erfolgt durch einen administrativen Eingriff durch den GTI. Alle Beteiligten werden telefonisch oder per E-Mail außerhalb der ZID über die Stornierung informiert. Stornierte Tickets sind in den entsprechenden Reports zu berichten. [<=]
GS-A_3991 - WDB Aktualisierung nach Schließung der übergreifenden Problemmeldungen
Problemlösungsverantwortliche ITSM-TI-Teilnehmer MÜSSEN nach der Behebung eines übergreifenden Problems die Wissensdatenbank um die relevanten Problemlösungsinformationen aktualisieren.
[<=]
9.6.8 Service Level Requirements (SLR)
GS-A_3992 - Service Level Requirements problemlösungsverantwortliche ITSM-TI-Teilnehmer
Aufbauend auf die in den jeweiligen Verträgen geregelten Servicezeiten MÜSSEN problemlösungsverantwortliche ITSM-TI-Teilnehmer mindestens folgende Service Level messen und berichten:
Tabelle 30: Tab_Betr_TIP_020 PRO – SLR PLVe A/H „Prozess“
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Die Ausgestaltung der Service Level erfolgt im Betriebskonzept [gemKPT_Betr]. [<=]
9.7 Informationspflichten
Für die ordnungsgemäße Wahrnehmung und Umsetzung der Informationspflichten sind problemerkennende sowie problemlösungsverantwortliche ITSM-TI-Teilnehmer verantwortlich.
GS-A_3993 - Information bei Feststellung von Problemen im lokalen und übergreifenden Problem Management
Problemerkennende sowie problemlösungsverantwortliche ITSM-TI-Teilnehmer MÜSSEN bei der Feststellung eines produkttypspezifischen Problems (siehe GS-A_3972 für Problemerkennende und GS-A_3992 Problemlösungsverantwortliche) mit hoher Kritikalität, d.h. Prioritäten „1. Kritisch“ und „2. Hoch“ unter Beachtung der Mindestinhalte bei Erfassung eines Problems (siehe GS-A_4000), den SBV informieren. Im übergreifenden Problem Management erfolgt die Kommunikation über die ZID.
[<=]
GS-A_3994 - Statusinformation bei lokalen und übergreifenden Problemen
Problemerkennende sowie problemlösungsverantwortliche ITSM-TI-Teilnehmer MÜSSEN gemäß den zeitlichen Vorgaben der Service Level Requirements (siehe GS-A_3972 für Problemerkennende und GS-A_3992 Problemlösungsverantwortliche) eine Meldung über den aktuellen Status des produkttypspezifischen Problems mit hoher Kritikalität, d.h. Prioritäten „1. Kritisch“ und „2. Hoch“ unter Beachtung der Mindestinhalte bei Erfassung eines Problems (siehe GS-A_4000), an den SBV versenden. Darüber hinaus ist grundsätzlich, unabhängig von der Priorität, bei jedem Statuswechsel eines Problems eine Statusinformation zu übermitteln.
Im übergreifenden Problem Management erfolgt die Kommunikation über die ZID.
[<=]
9.8 Dokumentation
Die Dokumentation der Problembearbeitung erfolgt durch die problemerkennenden und problemlösungsverantwortlichen ITSM-TI-Teilnehmer und ist durch diese zu unterschiedlichen Zeitpunkten zu befüllen.
GS-A_4000 - Mindestinhalte Dokumentation von übergreifenden Problemen
ITSM-TI-Teilnehmer MÜSSEN jedes im übergreifenden PRO zu erfassende Problem nach folgendem Schema dokumentieren, wobei die Felder durch die problemerkennenden (PE) und problemlösungsverantwortlichen (PLV) ITSM-TI-Teilnehmer zu unterschiedlichen Zeitpunkten zu befüllen sind:Die an die Webservice-Schnittstelle der ZID zu sendenden Daten entsprechen dieser Beschreibung und sind im Anhang B beschrieben.Zeichenerklärung in der Spalte Befüllungszeitpunkt / BefüllungsstatusX entspricht muss befüllt bzw. geändert werden O entspricht kann befüllt bzw. geändert werden- entspricht darf nicht geändert werden
Tabelle 31: Tab_Betr_TIP_021 PRO – Mindestinhalte Problemdokumentation
|
|
|
|
|
|
||||||||
|
|
|
|
|
|
|
|
|
|||||
|
|
|
|
|
|
|
|
|
|||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[<=]
9.9 Eskalationen
GS-A_3995 - Eskalationseinleitung durch den ITSM-TI-Teilnehmer im PRO
ITSM-TI-Teilnehmer KÖNNEN bei übergreifenden Problemen mit Prioritäten „1. Kritisch“ und „2. Hoch“ oder bei sicherheitsrelevanten Problemen eine hierarchische Eskalation an den SBV einleiten, wenn:
• er keinen lösungsunterstützenden ITSM-TI-Teilnehmer ermitteln kann,
• er keine Einigung über die Lösungsunterstützung für das übergreifende Problem mit anderen ITSM-TI-Teilnehmern erreicht werden kann,
• nach seinem Verständnis zur Bewältigung der Probleme mit Prioritäten „1. Kritisch“ und „2. Hoch“ eine übergeordnete Koordination notwendig ist,
• die Bearbeitungsdauer eines anderen ITSM-TI-Teilnehmers die Service Level Requirements für die Bearbeitung des Problems (mit der gegebenen Priorität) zu verletzen droht bzw. die eigene Serviceerbringung gefährdet.
[<=]
GS-A_3996 - Eskalationsinhalte im PRO
ITSM-TI-Teilnehmer MÜSSEN bei jeder Eskalationsmeldung an einen SBV im übergreifenden Problem Management folgende Inhalte erfassen:
• aktuelle Problemdokumentation gemäß GS-A_4000.
• Das Worklog der Problem-Dokumentation muss um folgende Informationen ergänzt werden:
o Eskalationsbeschreibung: qualifizierte Beschreibung aller bislang erfolgten Prüfungen, Aktionen/Eskalationen und Schritte, Eskalationsgrund und Dringlichkeit sowie konkret angefragter Unterstützungsbedarf.
o Eskalationsmelder ID, sowie Kontaktdaten, inklusive Telefonnummer und E-Mail-Adresse für eventuelle Rückfragen.
Die Eskalationsmeldung muss strukturiert über die ZID erfolgen. [<=]
Bei Problemen mit Prioritäten „1. Kritisch“ und „2. Hoch“ sowie bei sicherheitsrelevanten Problemen kann der SBV der TI - zur Gewährleistung der Performance, Sicherheit und Stabilität der zentralen und dezentralen Produkte - eine Taskforce zur Problembehebung bilden. Diese wird aus mehreren der am Betriebsprozess beteiligten ITSM-TI-Teilnehmer durch den SBV TI zusammengesetzt.
GS-A_3997 - Mitwirkung bei Taskforces im Eskalationsfall
ITSM-TI-Teilnehmer MÜSSEN bei Aufforderung durch den SBV an einer Taskforce zur Behebung von übergreifenden Problemen mit der Priorität 1 oder 2 teilzunehmen, der Taskforce beitreten und die Lösungsfindung unterstützen.
ITSM-TI-Teilnehmer MÜSSEN nach der Lösung des übergreifenden Problems mit der Priorität 1 oder 2 innerhalb einer Taskforce im Anschluss die Erstellung des Abschlussberichtes bzw. die Durchführung des Audits unterstützen.
[<=]
9.10 Obliegenheiten SBV/GTI
Obliegenheiten des SBV:
• Der jeweilige SBV nimmt Eskalationsmeldungen entgegen und entscheidet, ob eine Meldung an den GTI durchzuführen ist.
Der jeweilige SBV nimmt übergreifende Problems mit der Priorität 1 und 2 entgegen und entscheidet, ob eine Meldung an den GTI durchzuführen ist. Einführung des Service Monitorings wird das monatliche Reporting von Performance-Daten (Verfügbarkeit, Durchsatz, Bearbeitungszeit) der TI-ITSM-Teilnehmer an den Gesamtverantwortlichen der TI angepasst mit dem Ziel einer teilweisen oder vollständigen Ersetzung. Bis zu diesem Zeitpunkt behalten die bestehenden Anforderungen und Vorgehensweisen Gültigkeit. Auch wird mit der Einführung dieses Systems die Störungsampel abgelöst. Welche betrieblichen Anforderungen mit der Einführung des Service Monitorings der TI stattdessen im Rahmen dieser Richtlinien bzgl. Performance-Management zukünftig definiert werden, ist zum jetzigen Zeitpunkt noch nicht geklärt.
11 Servicekatalog Management
Der Servicekatalog Management der TI regelt, wie Servicekataloge der TI-ITSM-Teilnehmer mit dem Gesamtverantwortlichen TI vereinbart und für andere TI-ITSM-Teilnehmer bereitgestellt werden. Ziel ist es, die notwendige Transparenz für alle TI-ITSM-Teilnehmer über in der TI angebotene Services und die Beschaffungskonditionen zu schaffen.
11.1 Begriffsbestimmungen
11.1.1 Servicekatalog
Der Servicekatalog enthält alle von einem TI-ITSM-Teilnehmer angebotenen TI Services mit Angabe der dazugehörenden Servicekomponenten. Es wird dargestellt, zu welchen Konditionen der jeweilige Service geliefert wird. Der Servicekatalog wird im Rahmen des Servicekatalog-Managements vereinbart und anderen TI-ITSM-Teilnehmern über das TI-ITSM-System bereitgestellt.
11.1.2 Serviceverzeichnis
Alle Servicekataloge aller TI-ITSM-Teilnehmer werden zentral im Service-Verzeichnis des TI-ITSM-Systems aufgeführt.
11.2 Prozessdurchführung Servicekatalog Management
11.2.1 Definition der angebotenen Services
Der TI-ITSM-Teilnehmer erfasst seine angebotenen Services im TI-ITSM-System. Die Gesamtheit der angebotenen Services ergibt den Servicekatalog des TI-ITSM-Teilnehmers.
GS-A_5607 - Inhalte eines Servicekataloges der angebotenen TI-Services
TI-ITSM-Teilnehmer MÜSSEN alle von ihnen angebotenen TI-Services und -qualitäten gegenüber anderen TI-ITSM-Teilnehmern in einem Servicekatalog im TI-ITSM-System dokumentieren und dabei mindestens folgende Angaben beifügen:
- Vertraglich zugesicherte Leistung:
- Prozess des Abrufs und der Freigabe des Services
- Kosten des Serviceabrufs
- Reaktions-, Lösungs- und Verifikationsfrist
- Prozess der Verifikation der Servicelieferung
- Notwendige Daten zum Abruf des Service Requests:
- Benötigte Input Informationen
- Betriebsumgebung
[<=]
Zusätzlich muss der TI-ITSM-Teilnehmer über Vereinbarungen mit anderen TI-ITSM-Teilnehmern sicherstellen, dass alle Voraussetzungen für die Erbringung seiner eigenen Services gegeben sind.
11.2.2 Servicekatalog freigeben
• Der jeweilige SBVGesamtverantwortliche TI wird sich bei übergreifenden Problems der Priorität 1 oder 2 selbständig über den jeweils aktuellen Stand der Bearbeitung durch den betreffenden ITSM-TI-Teilnehmer informieren, so dass er ggü. dem GTI jederzeit auskunftsfähig ist.
Obliegenheiten der GTI:
• Bei Problems mit (produkt-)übergreifender Auswirkung kann der GTI - zur Gewährleistung der Performance, Sicherheit und Stabilität der zentralen und dezentralen Produkte - eine zentrale Koordinierung der Aktivitäten der anderen Prozessbeteiligten übernehmen.
9.11 Prozessreporting (Vorgangsdaten) PRO
Das Prozessreporting der Problemursache und -lösung dient der geordneten Aufbewahrung von bereits behobenen Problemen. Durch diese ist es zu einem späteren Zeitpunkt möglich, ein möglicherweise ähnliches Problem so früh wie möglich zu identifizieren oder mit Hilfe von einer Problem- oder Lösungsbeschreibung anhand der übergreifenden Zusammenhänge zu analysieren.
Für die ordnungsgemäße Wahrnehmung und Umsetzung des Prozessreportings ist ausschließlich der problemlösungsverantwortliche ITSM-TI-Teilnehmer verantwortlich.
GS-A_3998 - Bereitstellung von Problemdokumentationen aus dem übergreifenden Problem Management
Problemlösungsverantwortliche ITSM-TI-Teilnehmer MÜSSEN die an den SBV zu versendenden Reports im .CSV-Format übermitteln.
ITSM-TI-Teilnehmer MÜSSEN bei den an den SBV zu versendenden Reports die AFO GS-A_5248 beachten.
[<=]
GS-A_3999 - Reportinhalte von Vorgangsdaten aus dem übergreifenden Problem Management
Problemlösungsverantwortliche ITSM-TI-Teilnehmer MÜSSEN Vorgangsdatenreports nach der in GS-A_3961, GS-A_3962 , GS-A_3963, GS-A_3964 und GS-A_4000 vorgegebenen Struktur erstellen.
[<=]
Im Rahmen der Fehleranalyse und zu Auswertungszwecken sind durch ITSM-TI-Teilnehmer Systemprotokolle und Fehlerlogs, sowie Incidentdokumentationen an den SBV zu übermitteln, welche nicht Bestandteil des regelmäßigen Reportings sind.
GS-A_5251 - Übermittlung von Fehlerlogs, Systemprotokollen der Produktinstanzen und lokalen Incidents
ITSM-TI-Teilnehmer MÜSSEN die vom SBV bei Bedarf angeforderten Systemprotokolle und Fehlerlogs der Produktinstanzen sowie Dokumentationen der lokalen Incidents, unverzüglich in elektronischer Form und in einem weiter bearbeitbaren und auswertbaren Format an den SBV oder den durch den SBV benannten Empfänger übermitteln.
[<=]
9.12 Obliegenheiten lösungsunterstützende SV/SBV
Lösungsunterstützende SV und SBV unterstützen, koordinieren und stellen sicher, dass die am spezifischen Service beteiligten ITSM-TI-Teilnehmer aufgetretene Probleme lösen und dass sie die Service Qualität und Performance nicht nachhaltig beeinträchtigen. Dies wird durch strikte Befolgung der Service Level Requirements, wie z.B. Reaktionszeiten in Abhängigkeit von Problem-Prioritäten, erreicht.
9.12.1 Vorprüfung
Die die Meldung erhaltenden lösungsunterstützenden SV oder SBV werden die von ITSM-TI-Teilnehmer gemeldeten, übergreifenden Problemen innerhalb einer angemessenen Zeitspanne beantworten.
9.12.2 Ablehnung
SV oder SBV, die ein übergreifendes Problem ablehnen, werden dieses mit einer Rückmeldung an den meldenden ITSM-TI-Teilnehmer des übergreifenden Problems durchführen.
9.12.3 Unterstützung Problembearbeitung
Problemlösungsverantwortliche ITSM-TI-Teilnehmer, die ein übergreifendes Problem gemeldet haben, werden entsprechende Unterstützung bei der Problemanalyse von SV oder SBV erhalten. Problemlösungsverantwortliche ITSM-TI-Teilnehmer werden entsprechende Unterstützung bei der Koordinierung der Aktivitäten für die relevante Testumgebung und bei der Klärung der wesentlichen Produkttypvorgaben vom SV oder SBV erhalten.
Der SBV unterstützt und koordiniert bei Bedarf die Kooperation zwischen problemlösungsverantwortlichen und lösungsunterstützenden ITSM-TI-Teilnehmern.
10 Notfallmanagement (NM)
Um zwischen den verschiedenen ITSM-TI-Teilnehmern sicherzustellendie Servicedefinition und -konditionen prüfen und den Servicekatalog in Abstimmung mit dem TI-ITSM-Teilnehmer im TI-ITSM-System hinterlegen.
GS-A_5609 - Abnahme des Servicekataloges
TI-ITSM-Teilnehmer MÜSSEN alle von ihnen angebotenen Services in einem Business-Servicekatalog mit dem Gesamtverantwortlichen TI vereinbaren.
[<=]
Durch die Abnahme werden sie berechtigten TI-ITSM-Teilnehmern zum Abruf über das TI-ITSM-System zur Verfügung gestellt.
12 Notfall Management
Das Notfall Management der TI stellt sicher, dass
- die entsprechenden Vorkehrungen zur Bewältigung von TI-Notfällen getroffen werden bzw. die Umsetzung der in der TI-Notfallvorsorge geplanten Maßnahmen erfolgt ist
,sowie
• dass eine zuverlässige Notfallkoordination bzw. -unterstützung von aufgetretenen Schadensereignissen produkt- sowie serviceübergreifend gewährleistet ist,
ist durch ITSM-TI-Teilnehmer ein Notfallmanagement zu etablieren.
Die nachfolgende Abbildung veranschaulicht hierzu die Regelungen von TI-Notfällen im ITSM-TI-Teilnehmer-relevanten Prozessausschnitt und gibt eine Zuordnung der einzelnen Prozessinhalte zu den nachfolgenden Kapiteln.
Abbildung 18: Notfallmanagement – Gesamtprozessschaubild "Notfallmanagement“
10.1 Betrachtungsgegenstand des übergreifenden Notfallmanagement
Der primäre Fokus der Richtlinie.
Der primäre Fokus des Notfall Managements in den Übergreifenden Richtlinien zum Betrieb der TI liegt in Ausprägung der Vorsorge und Bewältigung von TI-Notfällen durch TI-ITSM-TI-Teilnehmer.
Art und Umfang der Notfallvorsorge und -bewältigung von lokalen Notfällen der ITSM-TIdurch die TI-ITSM-Teilnehmer sind nicht Gegenstand dieser RichtlinieRichtlinien. Ein lokales Notfallmanagement wird vorausgesetzt. Anforderungen an das lokale Notfallmanagement sind [gemSpec_DS_Anbieter] zu entnehmen.
Die operative Behebung von TI-Notfällen obliegt grundsätzlich den ITSM-TI-ITSM-Teilnehmern, wobei der SBV Gesamtverantwortliche TI eine zentrale koordinierende Rolle im Rahmen der Bewältigung einnehmen kann. Dazu etabliert er ein Lösungsteam und das EMC, welches die ITSM-TI-Teilnehmer unterstützt.
1012.2 Begriffserläuterungen1 Begriffsbestimmungen
1012.21.1 Notfall
Gemäß dem [BSI 100-4] wird unter Notfall ein länger andauernder Ausfall von Prozessen oder Ressourcen mit hohem oder sehr hohem Schaden verstanden. Die Verfügbarkeit der entsprechenden Prozesse oder Ressourcen kann innerhalb einer geforderten Zeit nicht wieder hergestellt werden. Notfälle können nicht mehr im allgemeinen Tagesgeschäft abgewickelt werden, sondern erfordern eine gesonderte Notfallbewältigungsorganisation.
1012.21.2 lokalerLokaler Notfall
Ein lokaler Notfall beschreibt ein Schadensereignis der Produkte mit lokal ausgeprägten Auswirkungen. Lokale Notfälle werden durch ITSM-TI-ITSM-Teilnehmer bewältigt und erfordern i.d.R. keine Koordination durch SBVden Gesamtverantwortlichen TI. TI-ITSM-Teilnehmer müssen den Gesamtverantwortlichen TI über das Schadenereignis unverzüglich gemäß den Vorgaben der [gemSpec_DS_Anbieter] informieren.
1012.21.3 TI-Notfall
Ein TI-Notfall beschreibt ein übergreifendes Schadensereignis, welches nicht allein durch die lokale Notfallorganisation von betroffenen ITSM-TI-ITSM-Teilnehmern zu bewältigen ist (also der Koordination durch SBV bedarf) undoder welches schwerwiegende Auswirkungen auf Services bzw. Produkte von anderen TI-ITSM-Teilnehmern hat. Ein TI-Notfall hebt sich insbesondere dadurch hervorhebthervor, dass die TI bzw. ein TI-Service in ihrer ganzheitlichen Funktion (auch im Kontext der Sicherheit) gestört oder gefährdet ist.
10.2Der TI-Notfall besitzt die höchste Eskalationsstufe und deckt auch das Verhalten in Krisen und Katastrophensituationen ab. Der Gesamtverantwortliche TI nimmt in TI-Notfällen eine koordinierende Rolle wahr.
12.1.4 TI-Notfallvorsorge
Gemäß dem [BSI 100-4] zählen zur TI-Notfallvorsorge alle organisatorischen und konzeptionellen Aspekte sowie alle proaktiven Maßnahmen und Tätigkeiten des Notfallmanagements. Dazu zählen:
- vorbeugende Maßnahmen, die den Schaden oder die Eintrittswahrscheinlichkeit von Risiken reduzieren und die Widerstandsfähigkeit der Institution durch Anheben der Krisenschwelle erhöhen, wie auch
- proaktive Maßnahmen, um ein schnelles und sinnvolles Reagieren auf einen Vorfall zu ermöglichen.
Die Ausgestaltung der Vorsorgemaßnahmen sollte sich an der Kritikalität des Dienstes orientieren.
1012.21.5 TI-Notfallmaßnahme
Als TI-Notfallmaßnahme gilt jede Handlung, welche die Auswirkung eines TI-Notfalls eindämmen, schmälern oder aufheben kann. Die Maßnahme bietet in der Regel keine nachhaltige Beseitigung der Ursache des TI-Notfalls, kann aber einen Notbetrieb ermöglichen bzw. in Art und Ausprägung die TI-Notfallbewältigung erleichtern oder ermöglichen.
1012.21.6 Notbetrieb
Als Notbetrieb wird der Betriebszustand bezeichnet, welcher durch eine erfolgreiche Maßnahme innerhalb der TI-Notfallbewältigung die Grundfunktionen des Dienstes zwar aufrechterhält, diese jedoch entweder noch nicht nachhaltig stabilisiert sind und/oder noch nicht in der gewünschten Güte geleistet werden können (bspw. längere Antwortzeiten, Fehlen einer Redundanz, Verzicht auf einzelne Features etc.). Wichtigstes Merkmal des Notbetriebes ist dabei, dass betroffene Produkte keine schädigenden Wechselwirkungen mit anderen TI-Produkten mehr verursachen. Mit der erfolgreichen Aufnahme des Notbetriebs beginnt die Wiederherstellung.
1012.21.7 TI-Notfallbewältigung
Bei der der TI-Notfallbewältigung handelt es sich um das operative Agieren innerhalb des in der TI-Notfallvorsorge festgelegten Rahmens. Das Ziel der TI-Notfallbewältigung ist das Fortführen des vom TI-Notfall betroffenen Services, gegebenenfalls auch mit Einschränkungen sowie die vollständige Wiederherstellung des Services im vorgegebenen Leistungsumfang und Sicherheitsmerkmalen.
1012.21.8 Emergency Management Committee (EMC)
Das Emergency Management Committee (EMC) ist das Führungsinstrument im TI-Notfall. Es wirdist zeitlich befristet eingesetztaktiv und ist für die Koordination der TI-Notfallbewältigung verantwortlich.
Das EMC ist im Rahmen der geltenden betrieblichen und rechtlichen Regelungen gegenüber allen Rollen der Notfallorganisation im Rahmen der TI-Notfallbewältigung weisungsbefugt. Es befasst sich ausschließlich mit dem vorliegenden TI-Notfall und den davon betroffenen Bereichen.
Das EMC umfasst:
• einen Vertreter der Leitungsebene des GTI,
• einen Vertreter der Leitungsebene der SBVs der TI-Services,
• den Koordinator Informationssicherheit- und Datenschutz TI (GTI).
Diese Zusammensetzung kann fallspezifisch um die Vertreter der relevanten Experten sowie weiteren ITSM-TI-Teilnehmern erweitert werden.
10.212.1.9 Lösungsteam
Das Lösungsteam ist ein durch das EMC einberufenes Team von Fachexperten der durch den TI-Notfall unmittelbar betroffenen oder gefährdeten Dienste der TI. Aufgabe des Lösungsteams ist das Identifizieren und Bewerten, sowie (nach erfolgter Freigabe durch das EMC) das Durchführen von Maßnahmen der TI-Notfallbewältigung. Das Lösungsteam kann jederzeit während der TI-Notfallbewältigung hinsichtlich der Anforderungen umbesetzt werden und wird spätestens mit der Deeskalation des TI-Notfalls aufgelöst.
1012.3 Grundsätze des übergreifenden Notfallmanagements2 Prozessdurchführung Notfallvorsorge
Die nachfolgenden Grundsätze bilden die Regelungen des übergreifenden Notfallmanagements für ITSM-TI-Teilnehmer sowie SBV.
10.3.1 Kommunikation des übergreifenden Notfallmanagements
Die Kommunikation zwischen den Prozessbeteiligten hat auf Basis der Kommunikationsschnittstellen für Incident Management zu erfolgen und wird im Notfallmanagement nicht weiter ausgeprägt. Ein TI-Notfall wird insofern als höchste Eskalationsstufe einer Störung bezeichnet.
Die Kommunikation innerhalb der Notfallorganisation hat in allen Informations- und Eskalationsrichtungen (funktional, hierarchisch) sachlich, ruhig und umgehend zu erfolgen.
Die Kommunikation während des TI-Notfalls mit außenstehenden Dritten (Öffentlichkeit; nicht betroffene oder unbeteiligte ITSM-TI-Teilnehmer) muss ausschließlich in vorheriger Abstimmung mit, oder durch das EMC erfolgen.
10.3.2 zentrale Koordination von TI-Notfällen durch das EMC
Notfälle mit Auswirkung auf die TI-Services werden durch das EMC koordiniert. Das EMC wird durch den SBV einberufen.
10.4 Prozessdurchführung Notfallvorsorge
10.4Einhaltung der Anforderungen zur Notfallvorsorge wird regelmäßig im Rahmen der Auditierung geprüft und nachgewiesen.
12.2.1 Analyse der Auswirkungen möglicher Notfälle der Produktinstanzen
Der SVServiceverantwortliche wird ein Notfallvorsorgekonzept erstellen. Das Ziel des Notfallvorsorgekonzepts ist, die TI-Notfälle in ihrer Auswirkung auf die Erbringung der TI-Services zu analysieren und vorbeugend proaktive Maßnahmen zu entwickeln. Im Rahmen der Analyse von möglichen (lokalen) Schadensereignissen und im Rahmen der Bereitstellung bzw. dem Betrieb von Produkten wird der SV durch die jeweiligen ITSM-TI-Teilnehmer unterstützt.
GS-A_4121 - Analyse Auswirkungen möglicher Schadensereignisse auf Sicherheit und Funktion der TI-Services
ITSM-TI-ITSM-Teilnehmer MÜSSEN die Auswirkungen möglicher Schadensereignisse der Produkte auf Sicherheit und Funktion dervon ihnen verantworteten TI-Services analysieren und bewerten. Die Auswirkungsanalyse MUSS mit mindestens folgenden Vorgaben erstellt werden:
- angenommener Ausfall einer tatsächlichen Funktionalität bzw. Eigenschaft des Produkts (Notfallszenario),
- Beschreibung der Auswirkung möglicher Wechselwirkung mit anderen Produkten bzw. auf den TI-Service,
- Risikobewertung des Notfallszenarios.
[<=]
GS-A_4122 - Unterstützung TI-Notfallvorsorge
ITSM-TI-Teilnehmer MÜSSEN, zur Gewährleistung der Sicherheit und Funktionalitäten der TI-Services, andere ITSM-TI-Teilnehmer bei der Auswirkungsanalyse der TI-Notfallvorsorgemaßnahmen im Rahmen der TI-Notfallvorsorge unterstützen.
[<=]
10.412.2.2 Entwicklung und Pflege der Notfallvorsorgedokumentation
GS-A_4123 - Entwicklung und Pflege der TI-Notfallvorsorgedokumentation
ITSM-TI-ITSM-Teilnehmer MÜSSEN eine TI-Notfallvorsorgedokumentation, welche die Ergebnisse der Auswirkungsanalyse sowie Vorkehrungen zur TI-Notfallvorsorge des SVServiceverantwortlichen enthält, entwickeln und pflegen. In der TI-Notfallvorsorgedokumentation sind die Aktivitäten festgelegt, die bei Eintritt eines TI-Notfalls durchführendurchzuführen sind.
[<=]
10.4
[<=]
12.2.3 Umsetzung Vorkehrungen zur Notfallvorsorge
GS-A_4124 - Umsetzung Vorkehrungen zur TI-Notfallvorsorge
ITSM-TI-ITSM-Teilnehmer MÜSSEN die erarbeiteten Vorkehrungen zur TI-Notfallvorsorge umsetzen.
[<=]
1012.53 Prozessdurchführung TI-Notfallbewältigung
Die nachfolgende Abbildung zeigt einen generischen, idealtypischen Ablauf der TI-Notfallbewältigung, an dessen Beispiel die einzelnen Aktivitäten im Folgenden beschrieben werden.
Diese Abbildung stellt keinen Prozessablauf dar und erhebt keinen Anspruch auf vollständige Abdeckung sämtlicher Szenarien. Sie soll mit Hilfe der nachfolgend textuell beschriebenen Arbeitsschritte einen Rahmen für die Mitwirkungsverpflichtungen der ITSM-TI-Teilnehmer bei der Bewältigung von TI-Notfällen definieren.
Abbildung 19: Notfallmanagement – Idealtypischer Ablauf TI-Notfallbewältigung
12.3.1 TI-Notfallerkennung
Die TI-Notfallerkennung ist eine operative Aufgabe des Incident Managements. Sie stellt sicher, dass Vorfälle erkannt werden und eine schnelle und angemessene Reaktion erfolgen kann.
GS-A_4125 - TI-Notfallerkennung
ITSM-TI-Teilnehmer MÜSSEN TI-Notfälle im operativen Betrieb im Rahmen des Incident Managements feststellen. TI-Notfälle werden als Incidents der Priorität 1 mit Kennzeichnung „TI-Notfall“ klassifiziert.
[<=]
Im Folgenden werden weitergehende Regelungen für Eskalation, Koordination sowie Informations- und Dokumentationspflichten für die Bewältigung von TI-Notfällen festgelegt.
10.5.1Ein Vorfall wird gemäß GS-A_4125 als TI-Notfall klassifiziert und an das Notfall Management übergeben. Außerdem wird das TI-Notfall-Logbuch gemäß GS-A_4137 angelegt und fortgeschrieben.
12.3.2 Eskalation TI-Notfälle
GS-A_4126 - Eskalation TI-Notfälle
ITSM-TI-ITSM-Teilnehmer MÜSSEN erkannte TI-Notfälle, unverzüglich an den für sie zuständigen SBVGesamtverantwortlichen TI eskalieren. Eine Meldung an den SBVGesamtverantwortlichen TI MUSS im Sinne einer umgehenden und persönlichen Benachrichtigung erfolgen.
[<=]
[<=]
10.5.2Konkrete Handlungsanweisungen zur TI-Notfall-Meldung werden in der Wissensdatenbank zur Verfügung gestellt und aktuell gehalten.
12.3.3 Sofortmaßnahmen TI-Notfälle
GS-A_4127 - Sofortmaßnahmen TI-Notfälle
ITSM-TI-ITSM-Teilnehmer, diederen Dienste von einem TI-Notfall betroffen sind, MÜSSEN entsprechende Maßnahmen einleiten, mit dem Ziel die Auswirkungen der TI-Notfälle eigenständig zu reduzieren oder einzuschränken.
[<=]
10.5.3
[<=]
12.3.4 Bewältigung TI-Notfälle
GS-A_4128 - Bewältigung der TI-Notfälle
ITSM-TI-ITSM-Teilnehmer MÜSSEN vom EMC autorisierte TI-Notfallmaßnahmen zur Bewältigung von TI-Notfällen im eigenen Verantwortungsbereich umsetzen.
[<=]
GS-A_4129 - Unterstützung bei TI-Notfällen
ITSM-TI-ITSM-Teilnehmer MÜSSEN bei der Bewältigung sowie Koordination der TI-Notfälle den SBVGesamtverantwortlichen TI oder andere ITSM-TI-ITSM-Teilnehmer im erforderlichen Umfang unterstützen.
[<=]
10.5.4
[<=]
12.3.5 Koordination der TI-Notfallbewältigung durch SBVden Gesamtverantwortlichen TI
12.3.5.1 Notfallbeurteilung/-alarmierung
Nach demNachdem die ITSM-TI-ITSM-Teilnehmer einen möglichen TI-Notfall erkannt und an den SBVGesamtverantwortlichen TI gemeldet haben, wird der SBV die durch das Incident Management vorgenommene Beurteilung undGesamtverantwortliche TI die zu erwartende Auswirkung des TI-Notfalls anhand des Schadenbeurteilungsplans überprüfen.
Im Falle einer negativen Notfallbewertung (keine zu erwartende Auswirkung, Notfallkriterien sind zwischenzeitlich nicht mehr erfüllt etc.) wird die Zurückweisung des TI-Notfalls entsprechend dem regulären Betriebsprozess in der Incident-Dokumentation festgehalten.
Im Falle einer positiven Notfallbewertung wird der GTI durch den SBV über die Art und Ausprägung sowie zu erwartende Auswirkungen des vorliegenden TI-Notfalls alarmiert.
Im Falle einer negativen Notfallbewertung (keine zu erwartende Auswirkung, Notfallkriterien sind zwischenzeitlich nicht mehr erfüllt etc.) erfolgt die Zurückweisung des TI-Notfalls. Der Vorfall wird als Incident im regulären Betriebsprozess behandelt.
12.3.5.2 Notfallfeststellung
Der SBV wird ggf. in Abstimmung mit dem GTIGesamtverantwortliche TI wird im Falle eines TI-Notfalls die vorgenommene Notfallbewertung bestätigen und einen formellen Ausruf des TI-Notfalls durchführen.
12.3.5.3 Einberufung des EMCEmergency Management Committee (EMC)
Nach der Notfallbestätigung beruft der SBVGesamtverantwortliche TI das EMC ein. Die Zusammensetzung des EMC wirdbasiert auf BasisArt und Umfang des vorliegenden TI-Notfalls beschlossen und wird entsprechend des Schwierigkeitsgrades der eingetretenen oder zu erwartenden Auswirkungenkann ggf. fallspezifisch erweitert.
Im Laufe der TI-Notfallbewältigung kann das EMC seine Zusammensetzung erweitern. werden.
GS-A_4130 - Festlegung der Räumlichkeiten fürSchnittstellen des EMC
Prozessbeteiligte ITSM-TI-ITSM-Teilnehmer MÜSSEN die von SBVvom Gesamtverantwortlichen TI bereitgestellten RäumlichkeitenSchnittstellen im Rahmen der Einberufung des EMC wahrnehmen.
[<=]
GS-A_4131 - Bereitstellung der Ansprechpartner und Teilnehmer für EMC
ITSM-TI-Teilnehmer MÜSSEN entsprechend den Anforderungen des SBV Ansprechpartner und Teilnehmer für das EMC mit entsprechenden Fach- und/oder Entscheidungskompetenzen bereitstellen.
[<=]
GS-A_4893 - Kommunikationsschnittstellen im Rahmen von TI-Notfällen
ITSM-TI-Teilnehmer MÜSSEN für die Kommunikation im Rahmen von TI-Notfällen Kommunikationsschnittstellen per E-Mail und Telefon bereithalten.
[<=]
nutzen.
[<=]
Damit wird eine sofortige Reaktion auf Anfragen sichergestellt. Die Dokumentation erfolgt außerhalb des TI-ITSM-Systems.
Konkrete Informationen zum EMC werden in der Wissensdatenbank zur Verfügung gestellt und aktuell gehalten.
12.3.5.4 Zusammenstellung des Lösungsteams
Das Lösungsteam wird durch das EMC eingesetzt. Die Zusammensetzung des Lösungsteams kann im Laufe der TI-Notfallbewältigung durch das EMC verändert werden.
12.3.5.5 Durchführung der Notfallmaßnahmen
Das Lösungsteam wird die geeignetennach Verifikation der Ursachen und des Umfangs des TI-Notfalls geeignete TI-Notfallmaßnahmen identifizieren, diese zusammen mit dem. Diese werden im EMC hinsichtlich Aufwand, Durchführbarkeit und Wirkung bewerten und sie dem EMC zur Freigabe vorlegen. Die Freigabe erfolgt durch die Mitglieder des EMCbewertet und freigegeben.
Die freigegebenen Maßnahmen werden durchgeführt und deren Erfolg geprüft.
12.3.5.6 Notfalldeeskalation
Nach erfolgreich durchgeführten TI-Notfallmaßnahmen wird der SBVGesamtverantwortliche TI die Beseitigung des TI-Notfalls bzw. die Erreichung des Notbetriebs bestätigen und den TI-Notfall formell deeskalieren.
Auflösung des EMC
Nach der Deeskalation des TI-Notfalls wird der SBV das EMC auflösen. Mit der Auflösung des EMC, also den TI-Notfall als beendet erklären. Damit ist auch das EMC aufgelöst und es endet die Dokumentation in Form des TI-Notfall-Logbuchs. Das TI-Notfall-Logbuch wird direkt im Anschluss an die Auflösung in elektronischer Form an die Teilnehmer des EMC und des Lösungsteams verteilt.
1012.53.56 Wiederherstellung
Der SBVGesamtverantwortliche TI wird im Anschluss der EMC Auflösung,Notfalldeeskalation die Wiederherstellung veranlassen. Die Wiederherstellung hat zum Ziel, den Betriebszustand zu erreichen, welcher vor Eintreten des TI-Notfalls bestand. Ggf. ergriffene Sofortmaßnahmen im Sinne von Interimslösungen werden in diesem Zusammenhang geplant zurückgenommen.
Die erfolgreiche Wiederherstellung wird in Form eines Wiederherstellungsberichtes an die Teilnehmer des EMC und des Lösungsteams gemeldet.
GS-A_4132 - Durchführung der Wiederherstellung und TI-Notfällen
ITSM-TI-ITSM-Teilnehmer MÜSSEN alle Aktivitäten, welche der ErreichungWiedererreichung und Stabilisierung des Leistungsumfangs im eigenen Verantwortungsbereich dienen, durchführen und dokumentieren.
[<=]
10.5.6 Rollback-Verfahren
Der SBV wird kurz darauf das Rollback-Verfahren veranlassen. Das erfolgreiche Rollback-Verfahren wird in Form eines Rollback-Berichtes an die Teilnehmer des EMC und des Lösungsteams gemeldet.
GS-A_4133 - Rollback-Verfahren nach TI-Notfällen
ITSM-TI-Teilnehmer MÜSSEN die interimistischen und im Zuge der Sofortmaßnahmen installierten Notfallhandlungen zurücknehmen und dokumentieren.
[<=]
10.5
[<=]
12.3.7 Nachbearbeitung/Notfallauswertung
GS-A_4134 - Auswertungen von TI-Notfällen
ITSM-TI-ITSM-Teilnehmer MÜSSEN nach Abschluss der TI-Notfallbewältigung den TI-Notfall hinsichtlich seiner Ursache, Auswirkung, Dauer, Wahrscheinlichkeit eines erneuten Eintritts und der Angemessenheit der ergriffenen Maßnahmen zur TI-Notfallbewältigung auswerten. Die Auswertungsergebnisse sind zusammen mit TI-Notfall-Logbuch, Widerherstellungsbericht, Rollback-Bericht an den zuständigen SBV zu übergeben.
[<=]
Notfallauswertung
Der SBV wird nach Bewältigung der in seinem Verantwortungsbereich eingetretenen TI-Notfälle eine Auswertung vornehmen. Der SBV und Wiederherstellungsbericht, an den Gesamtverantwortlichen TI zu übergeben.
[<=]
Der Gesamtverantwortliche TI wird nach Bewältigung des eingetretenen TI-Notfalls eine Auswertung vornehmen. Der Gesamtverantwortliche TI wird dabei untersuchen, ob die im Rahmen der Notfallplanung festgelegten Abläufe und Maßnahmen für die Bewältigung des TI-Notfalls geeignet und ausreichend und ob weitere von ihm getroffenen Entscheidungen und Maßnahmen angemessen für eine effiziente TI-Notfallbewältigung waren. Mit erfolgter Notfallauswertung sind die Notfallvorsorgemaßnahmen/Notfallplan zu validieren und bei erkanntem Bedarf zu optimieren.
10.5.8 Service Level Requirements (SLR)
GS-A_4135 - Service Level Requirements ITSM-TI-Teilnehmer
ITSM-TI-Teilnehmer MÜSSEN mindestens folgende Service Level messen und berichten:
Tabelle 32: Tab_Betr_TIP_022 Notfallmanagement – SLR ITSM-TI-Teilnehmer „Serviceerbringung”
|
|
|
|
|
|
|
|
|
|
Die Ausgestaltung der Service Level erfolgt im Betriebskonzept [gemKPT_Betr]. [<=]
10.6Die daraus gewonnenen Erkenntnisse werden für die Validierung der Notfallvorsorgemaßnahmen bzw. der Notfallpläne herangezogen. Bei Bedarf werden Verbesserungsmaßnahmen durchgeführt.
12.4 Informationspflichten
GS-A_4136 - Statusinformation bei TI-Notfällen
ITSM-TI-ITSM-Teilnehmer, die von einem TI-Notfall betroffen sind, MÜSSEN im Rahmen der TI-Notfallbewältigung den SBVGesamtverantwortlichen TI ständig über den aktuellen Status der Durchführung der TI-Notfallmaßnahmen informieren. Sie haben gegenüber SBV eine ständige Informationspflicht.
[<=]
ITSM-TI
[<=]
TI-ITSM-Teilnehmer werden im Rahmen der Teilnahme am EMC mit den notwendigen Informationen zur TI-Notfallbewältigung versorgt.
1012.75 Dokumentation
12.5.1 TI-Notfall-Logbuch
GS-A_4137 - Dokumentation im TI-Notfall-Logbuch
ITSM-TI-ITSM-Teilnehmer MÜSSEN zu jedem TI-Notfall ein TI-Notfall-Logbuch erstellen.
ITSM-TI-ITSM-Teilnehmer MÜSSEN im Rahmen der TI-Notfallbewältigung im eigenen Verantwortungsbereich folgende Angaben im TI-Notfall-Logbuch dokumentieren:
- Zeit (Wann?)
, - Verantwortung (Wer?)
, - Durchführung (Was, Wie?)
und - Ergebnis einer Maßnahme
.
ITSM-TI-ITSM-Teilnehmer MÜSSEN dabei das TI-Notfall-Logbuch in den Phasen von Notfallbekanntwerden bis -deeskalationvom Bekanntwerden des Notfalls bis zur Notfalldeeskalation ständig aktualisieren.
[<=]
12.5.2 Wiederherstellungsbericht
GS-A_4138 - Erstellung des Wiederherstellungsberichts nach TI-Notfällen
ITSM-TI-ITSM-Teilnehmer MÜSSEN zu jeder Wiederherstellung in der TI-Notfallbewältigung einen Wiederherstellungsbericht erstellen.
ITSM-TI-ITSM-Teilnehmer MÜSSEN einen Wiederherstellungsbericht mit allen durchgeführten Aktionen und Änderungen sowie Angaben zu Erfolg und Misserfolg jeder einzelnen Aktivität im eigenen Verantwortungsbereich, welche im Rahmen der Wiederherstellung durchgeführt wurden, erstellen.
[<=]
Rollback-Bericht13 Vorschriften für CSV-Reporting
GS-A_4139 - Rollback-Bericht nach TI-Notfällen5608 - Übermittlung von CSV-Dateien
ITSM-TI-Teilnehmer MÜSSEN zu jedem Rollback in der TI-Notfallbewältigung einen Wiederherstellungsbericht erstellen.
ITSM-TI-Teilnehmer MÜSSEN einen Rollback-Bericht mit allen durchgeführten Aktionen und Änderungen sowie Angaben zu Erfolg und Misserfolg jeder einzelnen Aktivität im eigenen Verantwortungsbereich, welche im Verlauf des Rollback-Verfahrens durchgeführt wurden, erstellen.
[<=]
11 Request Fulfillment (RF)
Ziel des Prozesses Request Fulfillment ist, alle regulären betrieblichen Leistungsanfragen der TI-Akteure zu erfassen und in standardisierten Verfahren zu bearbeiten. Damit soll eine kontrollierte, bedarfsgerechte und aufwandsminimierte Erledigung der Service Requests sichergestellt werden.
Um für die verschiedenen Anbieter in der TI sicherzustellen, dass
• ein kontrollierter Zugang der Zertifikatsherausgeber in die Vertrauensräume der RU/TU und PU vorhanden ist,
• eine kontrollierte Netzkonfiguration des zentralen Netzes gewährleistet ist
• und allgemeine Beschwerden die TI betreffend entsprechend bearbeitet werden,
ist durch den GTI ein Request Fulfillment zu etablieren. Im Folgenden werden daher für die Etablierung des Prozesses ausschließlich Pflichten der gematik beschrieben. Nutzer des Prozesses sind berechtige ITSM-TI-Teilnehmer.
Die nachfolgende Abbildung veranschaulicht hierzu die Regelungen des Request Fulfillments im ITSM-TI relevanten Prozessausschnitt und gibt eine Zuordnung der einzelnen Prozessinhalte zu den nachfolgenden Kapiteln.
Abbildung 20: RF – Gesamtüberblick "Request Fulfillment"
11.1 Betrachtungsgegenstand des Request Fulfillment
Im Fokus des Request Fulfillment Prozesses liegt die Etablierung eines standardisierten Verfahrens zur erfolgreichen Bearbeitung wiederkehrender betrieblicher Anfragen von ITSM-TI-Teilnehmern.
Beispielhafte Inhalte von Service Requests sind aktuell:
• TSL-Eintragsverwaltung
• Freigabe User TMS (Trust Management System der arvato)
• Freigabe Netzkonfigurationen TI
• Freigabe Zertifikatsabholung für TSP CVC bei SP CVC Root
• Complaint Management: Hinweise und Beschwerden von Anbietern, SPEDs und weiteren ITSM-TI-Teilnehmern
11.2 Begriffserläuterungen
11.2.1 Service Request
Bei einem Service Request handelt es sich um eine Anfrage oder einen Serviceantrag, der auch als kleinerer Change mit einem niedrigen Risiko bezeichnet werden kann. Requests können mit einem oder mehreren Incident oder Problem Tickets verknüpft sein und diese lösen.
Auf Requests müssen die folgenden Merkmale zutreffen:
• wiederkehrende Vorgänge
• Durchführung ist vorab bereits genehmigt
• Standardverfahren ist definiert
• geringes Risiko bei Umsetzung
Umfassendere Changes mit größerem Risiko und unregelmäßiger Durchführung müssen den in dieser Richtlinie beschriebenen formalen Change Management Prozess durchlaufen.
11.2.2 Complaint Management
Complaint Management, oder auch Beschwerdemanagement, bezeichnet Maßnahmen bei Kundenunzufriedenheiten mit Services und hat zum Ziel, die Zufriedenheit des Beschwerdemelders wiederherzustellen. Per Request können Hinweise oder Reklamationen eines ITSM-TI-Teilnehmers zu TI-Services eingehen. Diese werden vom GTI bearbeitet bzw. angenommen und weitergeleitet.
11.3 Grundsätze des Request Fulfillment
Die nachfolgenden Grundsätze bilden die übergeordneten Regelungen des Request Fulfillment für ITSM-TI-Teilnehmer.
11.3.1 Zentrale RF Koordinierung durch den GTI
Der Request Fulfillment Prozess für Service Requests wird zentral von dem GTI gesteuert. Requests von ITSM-TI-Teilnehmern zu Themen wie
• Registrierung von Anbietern TSP CVC oder TSP X.509
• Durchführung von TSL Regelupdates
• Zertifikatsausstellung aus der gematik-Root
• Freigabe von Netzkonfigurationen
• Root-User Beantragungen
• Aufnahme und Weiterleitung von Beschwerden
werden entsprechend bearbeitet.
Eingangskanal für Service Requests, den ITSM-TI-Teilnehmer nutzen können, ist das Kommunikationspostfach Request_Fulfillment@gematik.de und für PKI-Serviceanfragen PKI-Registrierung@gematik.de.
Service Requests können aus einem Change Prozess (z.B. Onboarding Anbieter TSP) entstehen, aus dem Zulassungsprozess (Zulassung für Anbieter TSP) oder Vertragsmanagement (z.B. Business Servicekatalog).
11.3.2 Service Request-Melder
Der Service Request-Melder im ITSM-TI ist immer derjenige, der einen Service Request beim GTI eröffnet. Entsprechende Antragsformulare für ITSM-TI-Teilnehmer sind in der Wissensdatenbank hinterlegt und können abgerufen werden.
Service Request-Melder kann ebenfalls z.B. ein zukünftiger ITSM-TI-Teilnehmer sein, der sich als Anbieter TSP qualifizieren möchte. In diesem Fall wird der Service Request-Melder eine E-Mail senden und das Antragsformular wird ihm vom GTI via E-Mail zur Verfügung gestellt.
Ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.
11.3.3 Service Request-Bearbeiter
Der Service Request-Bearbeiter ist immer der GTI. Die Koordination zur Lösung des Service Requests wird intern organisiert.
Ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.
11.4 Prozessdurchführung Request Fulfillment
11.4.1 Qualifizierte Service Request -Meldung im ITSM-TI-Teilnehmersupport
Eine qualifizierte Service Request Meldung wird durch einen ITSM-TI-Teilnehmer oder zukünftigen ITSM-TI-Teilnehmer initiiert. Es existiert hierbei für den Melder eine berechtigte Anfrage betreffend der TI. Dieser Service Request richtet sich an den GTI. Dieser besitzt die Lösungsverantwortung für sämtliche TI Service Requests.
Ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.
GS-A_5349 - Eingangskanal für qualifizierte Meldung eines Service Requests durch ITSM-TI-Teilnehmer
ITSM-TI-Teilnehmer, die einen Service Request betreffend der TI stellen möchten, MÜSSEN dies mittels einer qualifizierten Meldung an die beiden folgend genannten Funktionspostfächer durchführen:
alle Anfragen: Request_Fulfilment@gematik.de
PKI-Anfragen: PKI-Registrierung@gematik.de.Bei der Übermittlung von CSV-Dateien an den Gesamtverantwortlichen TI sind folgende Regelungen zu beachten:
- Der Betreff einer E-Mail ist immer der Dateiname der in der E-Mail angehängten CSV-Datei. (Ausnahme: konsolidiertes Reporting entsprechend A_18236)
- Bei der Anwendung von E-Mail-Komprimierung gelten folgende Vorgaben:
- CSV-Dateien sind von Komprimierungsmaßnahmen ausgeschlossen
- Komprimierung der Dateianhänge im zip-Datei-Format
- mit „normaler“ Kompression/Kompressionsstärke
- mit Kompressionsmethode/-verfahren „Deflate“ (#4.4.5 - compression method 8)
- unverschlüsselt, d. h. ohne Passwort
- nicht selbst-entpackend (d. h. zip als exe)
[<=]
GS-A_5248 - Konventionen zur Struktur von Prozessdaten
- Für CSV-Dateien gilt :
TI-ITSM-Teilnehmer MÜSSEN die Struktur der CSV-Dateien für Statusinformationen und Eskalationen sowie der Prozesskommunikation nach den Vorgaben aus [RFC4180] und den nachfolgenden Konkretisierungen bauen:
- In der ersten Zeile sind die Feldnamen (Header) und ab der zweiten Zeile sind die zu übermittelnden Werte enthalten (Datensatz). Diese sind durch Semikolon (ASCII-59) zu trennen.
- Zeichensatzkodierung UTF-8 ohne ByteOrderMark liefern.
- Sämtliche Feldinhalte innerhalb der CSV-Datei (d.h. die Inhalte der Datensätze UND die Inhalte des Headers) sind in ASCII-34-Zeichen zu setzen (Quoting).
- Leere Felder müssen quotiert werden.
- Innerhalb der Feldinhalte ist jedes ASCII-34-Zeichen durch ASCII-39-Zeichen zu ersetzen.
- Zeilendelimiter ist die Zeichenfolge ASCII-13-Zeichen (Carriage return), ASCII-10-Zeichen (Line feed).
- Comments sind nicht zugelassen.
- Leere Zeilen sind nicht zugelassen.
- Leerzeichen am Rand von Feldinhalten werden nicht ignoriert, d. h., sie sind vom Sender zu entfernen, wenn sie nicht intendiert sind.
- Ist in einem Feldinhalt kein Zeichen enthalten, wird das als NULL-Wert, d. h. nicht gefüllter Feldwert interpretiert.
- Tausendertrennzeichen DÜRFEN NICHT verwendet werden.
- Der auf Grundlage von Basisfeldtypen (Tabelle 16: Tab_Betr_TIP_030 Basisfeldtypen von CSV-Dateien) festgelegte Wertebereich in Spalte „Typ“ muss erfüllt werden.
- Als Basis für Datums- und Zeitformate dient die ISO-Norm 8601.
- Folgende Formate sind zu benutzen:
- für Werte innerhalb der CSV-Datei: YYYY-MM-DDThh:mm:ss±hh
- als Bestandteil eines Dateinamens: YYYYMMDDThhmmss±hh
- Jede Datei darf im Rahmen der Prozesskommunikation nur einen Datensatz enthalten. Reports dürfen mehrere Datensätze enthalten.
- Für die Erfassung der Prozessdaten im Webportal werden die Konventionen im entsprechenden Formular dargestellt.
[<=]
GS-A_5350 - Nutzung von Antragsunterlagen zur qualifizierten Meldung eines Service Requests5249 - Reservierte Zeichen in den Prozessdaten
ITSM-TI-ITSM-Teilnehmer, die einen Service Request betreffend der TI stellen möchten, MÜSSEN hierfür die Antragsformulare aus der Wissensdatenbank nutzen und diese vollständig ausfüllen.
[<=]
GS-A_5379 - Zusendung von Antragsunterlagen eines Service Requests für zukünftige Anbieter und SPEDs
Der GTI sendet zukünftigen Anbietern und SPEDs per E-Mail die entsprechenden Antragsunterlagen zu.[<=]
11.4.2 Prüfung Service Request
Eine qualifizierte Service Request Meldung wird vom GTI auf Vollständigkeit und Plausibilität geprüft (z.B. Vorliegen der Beantragung zur Zulassung).
GS-A_5351 - Prüfung Service Request Antragsunterlagen
Der GTI MUSS die Service Request Antragsunterlagen vom ITSM-TI-Teilnehmer auf Vollständigkeit und Plausibilität prüfen.[<=]
11.4.3 Bearbeitung des Service Requests
Für die Bearbeitung des Service Requests ist der GTI verantwortlich. Er organisiert intern die Weiterleitung des Service Requests und stellt dem Melder die Lösung zur Verfügung.
GS-A_5352 - Lösung bzw. Bearbeitung des Service Requests
Der GTI MUSS sicherstellen, dass jeder Service Request bearbeitet und gelöst wird.[<=]
11.4.4 Schließung des Service Requests und Bestätigung an Melder
Die Lösung wird an den Melder des Service Requests übermittelt und somit der Service Request geschlossen. Per E-Mail wird der Melder über den Abschluss und die Lösung informiert.
GS-A_5353 - Abschlussbestätigung an den Service Request Melder
Der GTI MUSS: - den Melder eines Service Requests über die Lösung informieren und - dem Melder den Abschluss des Service Requests per E-Mail bestätigen (Abschlussbestätigung).[<=]
12 Anhang – Verzeichnisse
12.1 Abkürzungen MÜSSEN die in Tab_Betr_TIP_049 reservierte Zeichen Ersetzungstabelle benannten Zeichenketten in den [String] Basisfeldtypen der zu übermittelnden Prozessdaten der Incident- und Problemdokumentationen vermeiden und entsprechend ersetzen.
[<=]
Tabelle 11: Tab_Betr_TIP_049 reservierte Zeichen Ersetzungstabelle
|
|
Begründung |
||
|
<Hash> |
|
||
|
<br> |
|
||
|
|
Reserviertes Zeichen, für die Markierung der Inhalte von Feldern. Sie müssen ersetzt werden durch ein „Einfaches Anführungszeichen“. |
||
|
löschen |
|
||
|
löschen |
|
||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
1213.1 Basisfeldtypen von Prozessdaten
Tabelle 10 definiert Basisfeldtypen, die in konkreten Definitionen fachlicher Tabellen referenziert werden. In der Definition der fachlichen Tabellen können diese Basisfeldtypen weiter durch Constraints konkretisiert werden, z. B. durch Einschränkung auf eine fachlich definierte Wertemenge.
Tabelle 12: Tab_Betr_TIP_030 Basisfeldtypen von CSV-Dateien
Basisfeldtyp |
Definition |
Beispiel |
[String] |
Beliebige Zeichenkette mit den Anforderungen aus GS-A_5249 |
Hello World |
[Date] |
Gemäß [ISO-Norm 8601] folgendes Format auf Grundlage der lokalen Zeit gegenüber UTC: |
2015-02-23T01:47:36+01 |
[Date] |
als Bestandteil eines Dateinamens: YYYYMMDDThhmmss±hh |
20150223T014736+01 |
[Integer] |
+-nnnnnnnnn |
88888888 |
[Double] |
+-nnnnn,nnn |
2,456 |
[Auswahlfeld], (Auswahl1), (Auswahl2), (Auswahln) |
Es ist immer nur ein Wert von Auswahl n gültig. |
ja |
[Telefonnummer] |
[String] DIN 5008 |
+49 30 40041-999 |
[hh.mm] |
Uhrzeit: zwei Stellen für Stunde, zwei Stellen für Minuten gemäß [ISO-Norm 8601] |
12:30 |
[hhhh:mm:ss] |
Dauer in Stunden, zwei Stellen für Minuten, zwei Stellen für Sekunden |
0012:04:10 |
14 Anhang A – Verzeichnisse
14.1 Abkürzungen
Kürzel |
Erläuterung |
AZPD |
Anbieter Zentraler Plattformdienste |
CAB |
Change Advisory Board |
eCAB |
Emergency Change Advisory Board |
CHG |
Change Management |
CI |
Configuration Item |
CM |
Configuration Management |
CSV |
Comma-Separated Values |
DVO |
Dienstleister-vor-Ort |
EMC |
Emergency Management Committee |
FSC |
Forward Schedule of Change |
GTI |
Gesamtverantwortlicher der Telematikinfrastruktur |
ID |
Identifikationsnummer |
INC |
Incident Management |
ITIL |
IT Infrastructure Library |
ITSM |
IT-Service-Management |
PE |
Problemerkennender |
PED |
Professionelle Endnutzernahe Dienstleister |
PERF |
Performance Management |
PKI |
public key infrastucture |
PLV |
Problemlösungsverantwortlicher |
PRO |
Problem Management |
PU |
Produktivumgebung |
RF |
Request Fulfillment |
RFC |
Request for Change |
RLM |
Release Management |
RU |
Referenzumgebung |
SBV |
Servicebetriebsverantwortlicher |
SLK |
Service Level Katalog |
SLM |
Service Level Management |
SLR |
Service Level Requirements |
SPED |
Service Provider Endnutzernahe Dienste |
SPOC |
Single Point of Contact |
STD |
Standard |
SV |
Serviceverantwortlicher |
SZZP |
Sicherer Zentraler Zugangspunkt |
TI |
Telematikinfrastruktur |
TMS |
Trust Management System |
TU |
Testumgebung |
UML |
Unified Modeling Language |
VPN-ZugD |
VPN-Zugangsdienst |
WDB |
Wissensdatenbank |
ZID |
Zentrale Informationsdrehscheibe |
14.2 Glossar
Das Glossar wird als eigenständiges Dokument, vgl. [gemGlossar] zur Verfügung gestellt.
1214.3 Abbildungsverzeichnis
Abbildung 1: SLM – Prozessausschnitt „Service Level Management“Abbildung 1: CM – TI-Services: Beziehung und CIs (Auszug) der CMDB-TI zur lokalen CMDB der TI-ITSM-Teilnehmer
14.4 Tabellenverzeichnis
Abbildung 2: PERF – Gesamtüberblick „Performance Management“Tabelle 1: Tab_Betr_TIP_026 INC – Festlegung der Dringlichkeit
Abbildung 3: CHG & RM – Gesamtkontext "Change & Release Management"Tabelle 2: Tab_Betr_TIP_027 INC – Festlegung von Auswirkung
Abbildung 4: CHG – Gesamtüberblick „Change Management der Produkte“Tabelle 3: Tab_Betr_TIP_009 INC – Prioritätenmatrix
Abbildung 5: CHG – Bearbeitungsstatus: Phasen und StatusübergängeTabelle 4: Tab_Betr_TIP_102 PRO – Festlegung von Dringlichkeit
Abbildung 6: CM – TI-Services: Beziehung der CMDB-TI zur lokalen CMDB der ITSM-TI-TeilnehmerTabelle 5: Tab_Betr_TIP_103 PRO – Festlegung von Auswirkung
Abbildung 7: CM – Gesamtüberblick "Configuration Management“Tabelle 6: Tab_Betr_TIP_100 CM – TI-Stammdaten Datenpflege Gesamtverantwortlicher TI
Abbildung 8: KM – Übersicht der RelationenTabelle 7: Tab_Betr_TIP_101 CM – TI-Konfigurationsdaten
Abbildung 9: KM – Gesamtüberblick "Knowledge Management“Tabelle 8: Tab_Betr_TIP_024 CHG – Vorprüfung. Produktänderungsbedarf
Abbildung 10: INC – Gesamtüberblick "Incident Management"Tabelle 9: Tab_Betr_TIP_048 CHG – Kriterien für Emergency Changes
Abbildung 11: INC – Vorprüfung im AnwendersupportTabelle 10: Tab_Betr_TIP_003 PERF – Reportinhalte von Performance Messungen
Abbildung 12: INC – Strukturierte Informationsübermittlung im übergreifenden INCTabelle 11: Tab_Betr_TIP_049 reservierte Zeichen Ersetzungstabelle
Abbildung 13: INC – Vorprüfung im ITSM-TI-TeilnehmersupportTabelle 12: Tab_Betr_TIP_030 Basisfeldtypen von CSV-Dateien
Abbildung 14: PRO – Gesamtüberblick "Problem Management“
Abbildung 15: PRO – Vorprüfung problemerkennende ITSM-TI-Teilnehmer
Abbildung 16: PRO – Vorprüfung lösungsunterstützende ITSM-TI-Teilnehmer
Abbildung 17: PRO – Vorprüfung problemlösungsverantwortlicher ITSM-TI-Teilnehmer
Abbildung 18: Notfallmanagement – Gesamtprozessschaubild "Notfallmanagement“
Abbildung 19: Notfallmanagement – Idealtypischer Ablauf TI-Notfallbewältigung
Abbildung 20: RF – Gesamtüberblick "Request Fulfillment"
12.4 Tabellenverzeichnis
Tabelle 1: Tab_Betr_TIP_050 zeigt Anforderungen, die bei einer Prüfung nach § 274 Abs. 1 SGB V, der gematik nicht nachgewiesen werden müssen.
Tabelle 2: Tab_Betr_TIP_025 Bestandteile des konsolidierten Reportings
Tabelle 3: Tab_Betr_TIP_028 Übersicht Meldungstypen – Incident Management
Tabelle 4: Tab_Betr_TIP_029 Übersicht Meldungstypen – Problem Management
Tabelle 5: Tab_Betr_TIP_049 reservierte Zeichen Ersetzungstabelle
Tabelle 6: Tab_Betr_TIP_030 Basisfeldtypen von CSV-Dateien
Tabelle 7: Tab_Betr_TIP_023 SLM – Service Level "Performance"
Tabelle 8: Tab_Betr_TIP_002 SLM – Reportinhalte Service Level Report
Tabelle 9: Tab_Betr_TIP_003 PERF – Reportinhalte von Performance Messungen
Tabelle 10: Tab_Betr_TIP_004 PERF-Performance-Messungen Anb. „Serviceerbringung”
Tabelle 11: Tab_Betr_TIP_044 CHG – Change Level
Tabelle 12: Tab_Betr_TIP_045 CHG – Change Dringlichkeit
Tabelle 13: Tab_Betr_TIP_046 CHG – Festlegung von Change Kategorie und Auswirkung
Tabelle 14: Tab_Betr_TIP_048 CHG – Kriterien für Emergency Changes
Tabelle 15: Tab_Betr_TIP_024 CHG – Vorprüfung lokal./genehmig. Produktänderungsbedarf
Tabelle 16: Tab_Betr_TIP_49 CHG – Phasen im Produkt-Change und Statusübergänge
Tabelle 17: Tab_Betr_TIP_005 CHG – Change Management – SLP "Prozess"
Tabelle 18: Tab_Betr_TIP_006 CHG – Reportinginhalte des CHG-Prozessreportings
Tabelle 19: Tab_Betr_TIP_007 CM – CI „Produktverantwortliche Organisation“
Tabelle 20: Tab_Betr_TIP_008 CM – „CI Produkt“
Tabelle 21: Tab_Betr_TIP_047 CM – „ITSM-TI-Teilnehmer-Report“
Tabelle 22: Tab_Betr_TIP_009 INC – Prioritätenmatrix
Tabelle 23: Tab_Betr_TIP_026 INC – Festlegung von Dringlichkeit
Tabelle 24: Tab_Betr_TIP_027 INC – Festlegung von Auswirkung
Tabelle 25: Tab_Betr_TIP_011 INC – SLR Anwendersupport “Prozess”
Tabelle 26: Tab_Betr_TIP_013 INC – SLR ITSM-TI-Teilnehmersupport „Prozess“
Tabelle 27: Tab_Betr_TIP_014 INC – Mindestinhalte Incident-Dokumentation
Tabelle 28: Tab_Betr_TIP_016 PRO – SLR Problemerkennende ITSM-TI TN „Prozess”
Tabelle 29: Tab_Betr_TIP_018 PRO – SLR Lösungsunterstützende ITSM-TI Tln „Prozess”
Tabelle 30: Tab_Betr_TIP_020 PRO – SLR PLVe A/H „Prozess“
Tabelle 31: Tab_Betr_TIP_021 PRO – Mindestinhalte Problemdokumentation
Tabelle 32: Tab_Betr_TIP_022 Notfallmanagement – SLR ITSM-TI-Teilnehmer „Serviceerbringung”
Tabelle 33: Tab_Betr_TIP_041 – Allgemeine Festlegungen zur WebService Schnittstelle
Tabelle 34: Tab_Betr_TIP_042 – Operation AddObject
Tabelle 35: Tab_Betr_TIP_043 – Operation GetObjectList
Tabelle 36: Tab_Betr_TIP_040 – Attribute der Objekttypen Incident und Problem
Tabelle 37: Tab_Betr_TIP_001 Referenz Service Level IDs aus ORS1 zu Service Level IDs in OPB
1214.5 Referenzierte Dokumente
1214.5.1 Dokumente der gematik
Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert,; Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument passende jeweils gültige VersionsnummerVersionsnummern sind in der aktuellstenaktuellen, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.
[Quelle] |
Herausgeber: Titel |
||
|
|
||
[gemGlossar] |
gematik: Glossar der Telematikinfrastruktur |
||
|
|
||
[ |
gematik: |
||
[gemSpec_ |
gematik: |
||
|
|
||
[gemSpec_Perf] |
gematik: Übergreifende Spezifikation Performance und Mengengerüst TI-Plattform |
||
|
|
||
12.5.2 Weitere Dokumente
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
13 Anhang B – Webservice-Schnittstelle
Im Folgenden wird die Webservice-Schnittstelle zum Webservice-basierten Austausch von Incidents und Problems definiert.
Die Definition erfolgt in drei Stufen:
1. Allgemeine Festlegungen für die einzelnen Ebenen der Schnittstelle mittels Tabelle Tab_Betr_TIP_041.
2. Festlegungen zu den verwendeten Operationen
1. AddObject mittels Tabelle Tab_Betr_TIP_042
2. GetObjectList mittels Tabelle Tab_Betr_TIP_043
3. Mapping der in den Operationen verwendeten Feldnamen auf die Schnittstellenübergreifend definierten Feldnamen in Kapitel 8 und 9 mittels Tabelle Tab_Betr_TIP_040.
Tabelle 33: Tab_Betr_TIP_041 – Allgemeine Festlegungen zur WebService Schnittstelle
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Die Webservice-Schnittstelle des Produkts OMNITRACKER wird im Produkthandbuch [OMNI MANUAL] beschrieben.
Tabelle 34: Tab_Betr_TIP_042 – Operation AddObject
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
Tabelle 35: Tab_Betr_TIP_043 – Operation GetObjectList
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
Tabelle 36: Tab_Betr_TIP_040 – Attribute der Objekttypen Incident und Problem
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Bei jeder Informationsübermittlung per Webservice-Schnittstelle sind unabhängig vom Meldungstyp die in der GS-A_5200 definierten Daten sowie die TID des Empfängers des Kommunikationsvorganges zu übermitteln.
Die Übermittlung eines neuen Incidents oder Problems (d. h. die Referenz-ID ist neu und der ZID bisher noch nicht mitgeteilt worden) kann nur mit dem Meldungstyp „WE“ (Weiterleitung) erfolgen.
Bei den in der obigen Tabelle aufgeführten Zeitfeldern handelt es sich durchgängig um Zeitpunkte und nicht um Zeiträume.
Zur Erreichbarkeit der Webservice-Schnittstelle werden die benötigten Adressen (URLs) in der Wissensdatenbank bekannt gegeben (getrennt nach SOAP 1.1 und SOAP 1.2 und getrennt nach Test- und Produktivumgebung).
14 Anhang C – Mapping Tabelle Service Level ORS1 – OPB
Nachfolgend die Referenzdarstellung der in ORS1 verwendeten Service Level IDs zu den eineindeutigen IDs in OPB. Die spezifischen SL Zielwerte werden im Betriebskonzept [gemKPT_Betr] dargestellt.
Tabelle 37: Tab_Betr_TIP_001 Referenz Service Level IDs aus ORS1 zu Service Level IDs in OPB 14.5.2 Weitere Dokumente
|
|
|
|
|||||||||||||
|
||||||||||||||||
|
|
|
|
|
||||||||||||
|
|
|
|
|
||||||||||||
|
||||||||||||||||
|
|
|
|
|
||||||||||||
|
|
|
|
|
||||||||||||
|
||||||||||||||||
|
|
|
|
|
||||||||||||
|
|
|
|
|
||||||||||||
|
|
|
|
|
||||||||||||
|
|
|
|
|
||||||||||||
|
|
|
|
|
||||||||||||
|
||||||||||||||||
|
|
|
|
|
||||||||||||
|
|
|
|
|
||||||||||||
|
|
|
|
|
||||||||||||
|
|
|||||||||||||||
|
|
|||||||||||||||
|
|
|||||||||||||||
|
|
|
||||||||||||||
|
|
|||||||||||||||
|
|
|||||||||||||||
|
|
|||||||||||||||
|
|
|
|
|
||||||||||||
|
|
|||||||||||||||
|
|
|||||||||||||||
|
|
|||||||||||||||
[Quelle] |
|
|||||||||||||||
|
|
|
|
|
||||||||||||
|
|
|||||||||||||||
|
|
|||||||||||||||
|
|
|||||||||||||||
|
|
|
|
|
||||||||||||
|
|
|||||||||||||||
|
|
|||||||||||||||
|
|
|||||||||||||||
|
|
|
|
|
||||||||||||
|
|
|||||||||||||||
|
|
|||||||||||||||
|
|
|||||||||||||||
|
|
|
|
|
||||||||||||
|
|
|||||||||||||||
|
|
|||||||||||||||
|
|
|||||||||||||||
|
|
|
||||||||||||||
|
|
|||||||||||||||
|
|
|||||||||||||||
|
|
|||||||||||||||
|
||||||||||||||||
|
|
|
|
|
||||||||||||
|
|
|
|
|
||||||||||||
|
|
|||||||||||||||
|
|
|
||||||||||||||
|
|
|||||||||||||||
|
|
|
|
|
||||||||||||
|
|
|||||||||||||||
|
|
|||||||||||||||
|
|
|||||||||||||||
|
|
|
|
|
||||||||||||
|
|
|||||||||||||||
|
|
|
||||||||||||||
|
|
|||||||||||||||
|
|
|
|
|
||||||||||||
|
|
|||||||||||||||
|
|
|||||||||||||||
|
|
|||||||||||||||
|
|
|
|
|
||||||||||||
[RFC2119] |
RFC 2119 (März 1997): Key words for use in RFCs to Indicate Requirement Levels S. Bradner, |
|
|
|
||||||||||||
[BDSG] |
Der Bundesbeauftragte für Datenschutz und Informationsfreiheit (20.12.1990 (neugefasst durch Bek. 14.01.2003, Letzte Änderung vom 14.08.2009): Bundesdatenschutzgesetz |
|
|
|
||||||||||||
[ISO 8601] |
ISO 8601:2000: Data elements and interchange formats – Information interchange – Representation of dates and times |
|
|
|
||||||||||||
|
omnitracker.wsdl |
|||||||||||||||
|
|
|
|
|
||||||||||||
|
RFC 2617 (Juni 1999): HTTP Authentication: Basic and Digest Access Authentication |
|||||||||||||||
|
|
|
|
|
||||||||||||
|
|
|
|
|
||||||||||||