latest

Elektronische Gesundheitskarte und Telematikinfrastruktur

Übergreifende Richtlinien zum Betrieb der TI

    

     

      
Version
      
2.13.0
     
     

      
Revision
      
907771
     
     

      
Stand
      
19.03.2024
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemRL_Betr_TI
     
    

Dokumentinformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Die vorliegenden „Übergreifenden Richtlinien zum Betrieb der TI“ definieren die betrieblichen Mitwirkungspflichten und Schnittstellen zur übergreifenden Zusammenarbeit der Teilnehmer der Telematikinfrastruktur (TI) im IT-Servicemanagement (TI-ITSM) auf prozessualer Ebene. Die übergreifenden Richtlinien gelten für den Betrieb aller Betriebsumgebungen (Referenzumgebung (RU), Testumgebung (TU), Produktivumgebung (PU)). TI-ITSM-Teilnehmer sind Anbieter. Die zur Erbringung der TI-Services benötigten Produkte müssen zugelassen sein.

Eine abschließende Übersicht der TI-ITSM-Teilnehmer findet sich im Betriebskonzept [gemKPT_Betr#Tab_KPT_Betr_TI_001 TI-ITSM-Teilnehmer].

Hinweis

Anforderungen, die im vorliegenden Dokument definiert sind und sich an eine Teilmenge der TI-ITSM-Teilnehmer richten, bspw. an die Anbieter zentraler Produkte, sind deutlich an diese adressiert.

Die Mitwirkung der gematik am TI-ITSM erfolgt über die Rolle „Gesamtverantwortlicher TI“.

In 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 TI-ITSM-Teilnehmer (z. B. Koordination einer Taskforce im Problem Management (PRO))
• Eskalation von Vorgängen bei erkanntem Eskalationsbedarf oder nach erfolgter Eskalation durch TI-ITSM-Teilnehmer (z. B. ein Problem wurde im Problem Management an den Gesamtverantwortlichen TI eskaliert)
• Steuerung der 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 im Service Level Management (SLM) zur Einleitung von Optimierungsmaßnahmen bei den TI-ITSM-Teilnehmern).

Die Richtlinien treffen keine Vorgaben zu internen ITSM-Prozessen der einzelnen Teilnehmer der TI.

Folgende Prozesse werden im 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,
• Servicekatalog-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 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 Abgrenzungen 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 TI-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 Afo-ID und der Textmarke angeführten Inhalte.

2 Prozessübergreifende Regelungen

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 technischen und organisatorischen 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.

Das TI-ITSM-System vergibt für jeden Vorgang automatisch eine eindeutige Referenznummer. Die Referenznummer des lokalen ITSM-Systems des TI-ITSM-Teilnehmers kann mitgeführt werden.

Im TI-ITSM-System können zur Gewährleistung der besseren Erreichbarkeit der jeweiligen Ansprechpartner(gruppen) der TI-ITSM-Teilnehmer auch Funktionspostfächer hinterlegt werden.

Mehrfachnennungen und/oder Nennung eines Ansprechpartners/Funktionspostfachs für mehrere Bereiche sind möglich.

Die Kommunikation im Rahmen des TI-ITSM unter den TI-ITSM-Teilnehmer erfolgt immer verschlüsselt.

Die Abstimmung erfolgt zwischen den Kommunikationspartnern und die Realisierung kann beispielsweise über S/MIME, PGP oder TLS erfolgen. Ist keine Einigung zwischen den Kommunikationspartnern möglich, sind die Kommunikationspartner gehalten die Lösung mittels S/MIME zu realisieren. 

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.

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

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

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.

Umfang und Zeitpunkt des Audits stimmt der Gesamtverantwortliche TI mit dem zuständigen Serviceverantwortlichen ab.

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.

2.4.2 Taskforce als Instrument der Deeskalation im übergreifenden TI-ITSM

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.

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.

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

Gemeldete TI-Notfälle werden zuerst als potenziell aufgenommen, und es gilt Kapitel 12.3.5.1 und 12.3.5.2.

Die unter „Beschreibung“ genannten Punkte sind durch ein logisches ODER verknüpft und sollen als nicht abschließende Beispiele zur Einschätzung dienen.

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

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:

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.

Die für die Root Cause Analyse (RCA) relevanten organisatorischen Service Level (Reaktionszeit, Umsetzungszeit) für finale RCA und der ersten Draft-Version befinden sich in [gemKPT_Betr].

Die für die RCA zu erstellenden notwendigen Informationen werden in einem Formular in der Wissensdatenbank hinterlegt.

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.

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.

3.2.6 Übergreifenden Incident schließen

Nach erfolgreicher Verifikation erfolgt die vollständige Schließung des Incidents durch den serviceverantwortlichen TI-ITSM-Teilnehmer.

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.

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

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

Die unter „Beschreibung“ genannten Punkte sind durch ein logisches ODER verknüpft und sollen als nicht abschließende Beispiele zur Einschätzung dienen.

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.

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.

Benötigen serviceverantwortliche TI-ITSM-Teilnehmer eine TI-Testumgebung, muss dies vorab angefragt werden. Dazu stellen sie einen Service Request im TI-ITSM-System.

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.

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.

4.2.3.3 Stornierung oder Abbruch der Bearbeitung eines Problem-Tickets

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.

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.

4.2.6 Übergreifendes Problem schließen

4.2.6.1 Problem - Kennzeichnung von Zeiträumen als "Pending"

Während der Lösung eines übergreifenden Problems kann die Situation eintreten, dass ein serviceverantwortlicher TI-ITSM-Teilnehmer unverschuldet auf das Ergebnis anderer Aktivitäten warten muss. In der Regel sind dies administrative oder organisatorische Aktivitäten., die in Verantwortung anderer beteiligter Organisationen liegt.
Ein Beispiel hierfür ist die Wartezeit auf einen Eskalationstermin.

Die während der Lösungsbearbeitung mit dem als "Pending" gekennzeichneten  Zeiträume werden bei Berechnung der organisatorischen Service Level exkludiert (siehe auch [gemKPT_Betr#5.2.1.3]).

4.3 Abweichungen im Prozessablauf

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

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.

5.2.2 Service Request prüfen

Ein Service Request wird vom Serviceverantwortlichen auf Vollständigkeit und Plausibilität geprüft.

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.

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.

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.

6 Configuration Management

Das Configuration Management stellt 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.

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

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 1: 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 6: Tab_Betr_TIP_100 CM – TI-Stammdaten Datenpflege Gesamtverantwortlicher TI

6.1.4 TI-Konfigurationsdaten

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 7: Tab_Betr_TIP_101 CM – TI-Konfigurationsdaten

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

Die Instance-IDs sind gemäß [gemSpec_OM#GS-A_3856-02] ebenfalls als TI-Konfigurationsdaten mit dem Gesamtverantwortlichen TI initial und bei Änderung abzustimmen. Neu vergebene Instance-IDs entsprechen der in Kapitel 6.1.1 beschriebenen CI-ID.

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 ein Change lokal autorisiert wurde, müssen die geänderten Produktdaten an das Configuration Management übermittelt werden.

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-Change beinhaltet Änderungen an einem Produkt bzw. einer logischen Produktinstanz, welches sich bereits im Betrieb befindet oder in den Betrieb eingeführt oder herausgeführt werden soll.

Ein Produkt-Change ist immer eine Wartung und es gibt zwei Durchführungsvarianten.

7.1.2.1 Master-Change

Der Master-Change adressiert den Inhalt der Wartung 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.1.10 Wartung

Die Wartung eines IT-Systems ist ein Teil der primären Lebenszyklus-Prozesse gemäß [ISO/IEC/IEEE 12207:2017]. Sie umfasst alle getroffenen Maßnahmen, welche sich korrigierend oder verbessernd auf das IT-System auswirken. Eine Wartung kann nach [ISO/IEC/IEEE 14764:2022] verschiedenen Zwecken dienen und wird im Rahmen des Change & Release Managements festgelegt und durchgeführt. 

7.1.11 Wartungsfenster

Ein Wartungsfenster ist der definierte Zeitraum mit Start- und Endzeit, in dem eine Wartung durchgeführt wird. Wartungsfenster werden im Rahmen des Change & Release Managements vom TI-ITSM-Teilnehmer angekündigt und vor der Durchführung vom Gesamtverantwortlichen TI genehmigt. 

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.

Nicht vollständig erfasste RfCs werden vom TI-ITSM-System nur gespeichert, nicht an den Gesamtverantwortlichen TI zur Bewertung und Autorisierung weitergeleitet.

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.

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.

Damit der Gesamtverantwortliche TI die Aufgabe der Bewertung und Autorisierung in angemessener Qualität durchführen kann sind Bearbeitungsfristen festgelegt.

Werden 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 realisierende TI-ITSM-Teilnehmer hat sich die für die Autorisierung notwendigen Genehmigungen des GesamtverantwortIichen der TI einzuholen.

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

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.

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

Der Gesamtverantwortliche der TI legt den Teilnehmerkreis zur Verifikation im Rahmen der Produkt-Change-Freigabe fest.

7.2.6 Produkt-Change abschließen

Sind die Umsetzungsarbeiten abgeschlossen, kann der Change nach erfolgreicher Verifikation und abschließender Dokumentation geschlossen werden.

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.

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.

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.

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.

Die Abstimmung der Standard-Changes findet im Rahmen des Post Implementation Reviews statt.

7.5 Verfahren für einen Emergency-Change

8 Knowledge Management

Durch den Gesamtverantwortlichen TI wird ein Knowledge Management etabliert, um den Support-leistenden Organisationen die TI-Produktinformationen für die Ursachenanalyse und Lösungsfindung von Incidents und Problems bereitzustellen. Diese Produktinformationen werden in der Wissensdatenbank bereitgestellt. Die Wissensdatenbank dient dabei als erste Anlaufstelle für Support-leistende Organisationen.

In der Wissensdatenbank abgelegte Produktinformationen unterstützen TI-ITSM-Teilnehmer bei der Klärung im Betrieb bzw. bei der Nutzung auftretender Fragestellungen. Alle TI-ITSM-Teilnehmer werden verpflichtet, diese Informationen bereitzustellen.

8.1 Begriffsbestimmungen

8.1.1 Wissensdatenbank (WDB) des TI-ITSM-Systems

Die Wissensdatenbank 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.

Alle TI-ITSM-Teilnehmer erhalten im Rahmen des TI-ITSM Onboardings 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 TI-ITSM-Teilnehmer.

8.2 Prozessdurchführung Knowledge Management

8.2.1 Wissen identifizieren und übermitteln

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.

Der Gesamtverantwortliche 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_gemKPT_Betr_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 Service Level Report enthält für den jeweiligen Berichtszeitraum die tatsächlich gemessenen Service Level Werte und ggf. deren Kommentierung.

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.

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.

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.

Sollten 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-02 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 [gemKPT_Betr] 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].

Festlegung und Abstimmung müssen rechtzeitig vor Aufnahme des Betriebs eines Produktes in einer Betriebsumgebung des TI-ITSM-Teilnehmers im Rahmen des Anbieterzulassungsverfahrens erfolgen, damit die Bereitstellung der Werte der definierten Performance-Kenngrößen für die Betriebsüberwachung und im Service Level Reporting vor Aufnahme des Wirkbetriebes erfolgen kann.

10.2.2 Performance reporten

Die Übermittlung der Ergebnisse der Performance-Messung erfolgt entweder durch die Lieferung von Performance-Reports (das Verfahren befindet sich in der schrittweisen Ablösung) oder durch die Lieferung von Rohdaten in Form von Rohdaten-Performance-Berichten. Welche der beiden möglichen Lieferarten für ein Produkt / einen Anbieter relevant ist, ist durch die Zuweisung der entsprechenden Anforderungen geregelt - eine Wahlfreiheit besteht im Allgemeinen nicht.

Die umfangreichen Details der Rohdaten-Lieferung sind in [gemSpec_Perf] geregelt.

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.

10.2.3 Performance bewerten, planen und steuern

Die Performance-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.

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

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 Gesamtverantwortliche TI wird die Servicedefinition und -konditionen prüfen und den Servicekatalog in Abstimmung mit dem TI-ITSM-Teilnehmer im TI-ITSM-System hinterlegen.

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
• eine zuverlässige Notfallkoordination bzw. -unterstützung von aufgetretenen Schadensereignissen produkt- sowie serviceübergreifend gewährleistet ist.

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

Art und Umfang der Notfallvorsorge und -bewältigung von lokalen Notfällen durch die TI-ITSM-Teilnehmer sind nicht Gegenstand dieser Richtlinien. 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 TI-ITSM-Teilnehmern, wobei der Gesamtverantwortliche TI eine zentrale koordinierende Rolle im Rahmen der Bewältigung einnehmen kann.

12.1 Begriffsbestimmungen

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

12.1.2 Lokaler Notfall

Ein lokaler Notfall beschreibt ein Schadensereignis der Produkte mit lokal ausgeprägten Auswirkungen. Lokale Notfälle werden durch TI-ITSM-Teilnehmer bewältigt und erfordern keine Koordination durch den Gesamtverantwortlichen TI. TI-ITSM-Teilnehmer müssen den Gesamtverantwortlichen TI über das Schadenereignis unverzüglich gemäß den Vorgaben der [gemSpec_DS_Anbieter] informieren.

12.1.3 TI-Notfall

Ein TI-Notfall beschreibt ein übergreifendes Schadensereignis, welches nicht allein durch die lokale Notfallorganisation von betroffenen TI-ITSM-Teilnehmern zu bewältigen ist oder welches schwerwiegende Auswirkungen auf Services bzw. Produkte von anderen TI-ITSM-Teilnehmern hat. Ein TI-Notfall hebt sich insbesondere dadurch hervor, dass die TI bzw. ein TI-Service in ihrer ganzheitlichen Funktion (auch im Kontext der Sicherheit) gestört oder gefährdet ist.

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

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

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

12.1.7 TI-Notfallbewältigung

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

12.1.8 Emergency Management Committee (EMC)

Das Emergency Management Committee (EMC) ist das Führungsinstrument im TI-Notfall. Es ist zeitlich befristet aktiv 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.

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

12.2 Prozessdurchführung Notfallvorsorge

Die Einhaltung 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 Serviceverantwortliche 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.

12.2.2 Entwicklung und Pflege der Notfallvorsorgedokumentation

12.2.3 Umsetzung Vorkehrungen zur Notfallvorsorge

12.3 Prozessdurchführung TI-Notfallbewältigung

12.3.1 TI-Notfallerkennung

Die TI-Notfallerkennung ist eine operative Aufgabe des Incident Managements. Ein 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

Konkrete Handlungsanweisungen zur TI-Notfall-Meldung werden in der Wissensdatenbank zur Verfügung gestellt und aktuell gehalten.

12.3.3 Sofortmaßnahmen TI-Notfälle

12.3.4 Bewältigung TI-Notfälle

12.3.5 Koordination der TI-Notfallbewältigung durch den Gesamtverantwortlichen TI

12.3.5.1 Notfallbeurteilung

Nachdem die TI-ITSM-Teilnehmer einen möglichen TI-Notfall erkannt und an den Gesamtverantwortlichen TI gemeldet haben, wird der Gesamtverantwortliche TI die zu erwartende Auswirkung des TI-Notfalls überprüfen. 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 Gesamtverantwortliche TI wird im Falle eines TI-Notfalls einen formellen Ausruf des TI-Notfalls durchführen.

12.3.5.3 Einberufung des Emergency Management Committee (EMC)

Nach der Notfallbestätigung beruft der Gesamtverantwortliche TI das EMC ein. Die Zusammensetzung des EMC basiert auf Art und Umfang des vorliegenden TI-Notfalls und kann ggf. fallspezifisch erweitert werden.

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 nach Verifikation der Ursachen und des Umfangs des TI-Notfalls geeignete TI-Notfallmaßnahmen identifizieren. Diese werden im EMC hinsichtlich Aufwand, Durchführbarkeit und Wirkung bewertet 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 Gesamtverantwortliche TI die Beseitigung des TI-Notfalls bzw. die Erreichung des Notbetriebs bestätigen und den TI-Notfall formell deeskalieren, 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.

12.3.6 Wiederherstellung

Der Gesamtverantwortliche TI wird im Anschluss der 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.

12.3.7 Nachbearbeitung/Notfallauswertung

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

TI-ITSM-Teilnehmer werden im Rahmen der Teilnahme am EMC mit den notwendigen Informationen zur TI-Notfallbewältigung versorgt.

12.5 Dokumentation

12.5.1 TI-Notfall-Logbuch

12.5.2 Wiederherstellungsbericht

13 Vorschriften für CSV-Reporting

Tabelle 11: Tab_Betr_TIP_049 reservierte Zeichen Ersetzungstabelle

13.1 Basisfeldtypen von Prozessdaten

Tabelle Tab_Betr_TIP_030 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

14 Anhang A – Verzeichnisse

14.1 Abkürzungen

14.2 Glossar

Das Glossar wird als eigenständiges Dokument, vgl. [gemGlossar] zur Verfügung gestellt.

14.3 Abbildungsverzeichnis

14.4 Tabellenverzeichnis

14.5 Referenzierte Dokumente

14.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 jeweils gültige Versionsnummern sind in der aktuellen, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.

14.5.2 Weitere Dokumente