gemRL_Betr_TI_V2.14.0





Elektronische Gesundheitskarte und Telematikinfrastruktur




Übergreifende Richtlinien zum Betrieb der TI



    
Version 2.14.0
Revision 964687
Stand 26.07.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

Version
Stand
Kap./ Seite
Grund der Änderung, besondere Hinweise
Bearbeiter
Vollständige Überarbeitung gemäß C_6410 und C_6411
2.0.0 14.05.2018 freigegeben gematik
2.0.1 24.08.2018 Korrektur der Übertragung der bekannten Änderung (redaktionell) gematik
2.1.0 15.05.2019 Einarbeitung Änderungsliste P18.1 gematik
2.2.0 28.06.2019 Einarbeitung Änderungsliste P19.1 gematik
2.3.0 02.10.2020 Einarbeitung Änderungsliste P20.1/2 gematik
2.4.0 02.03.2020 Einarbeitung Änderungsliste P20.1  gematik
2.5.0 30.06.2020 Anpassungen gemäß Änderungsliste P22.1 und Scope-Themen aus Systemdesign R4.0.0 gematik
2.5.1 19.02.2020 Einarbeitung Änderungsliste P22.5 gematik
2.6.0 14.02.2022 Einarbeitung Änderungsliste Betr_Maintenance_21.3 gematik
2.7.0 03.02.2023 Einarbeitung Änderungsliste Betr_Maintenance_22.3 gematik
2.8.0 23.05.2023 7.1.10ff Einarbeitung Änderungsliste Betr_Maintenance_23.2 gematik
2.9.0 01.08.2023 Einarbeitung Änderungsliste Betr_Maintenance_23.3 gematik
2.10.0 19.09.2023 Einarbeitung Änderungsliste NCPeH_23.1 gematik
2.11.0 30.01.2024 Einarbeitung der Anpassungen der ePA für alle, Berücksichtigung Hersteller Versicherten Frontend in TI-ITSM-Anforderungen (Hinweis Zuordnung verschiedener Anforderungen an den "Hersteller Versicherten Gateway" ), neue Afo A_24799 zur Sicherstellung der Funktionsfähigkeit nach Changes gematik
2.12.0 20.02.2024 Einarbeitung Betr_Maintenance_23.4 und Änderungsliste CI_Maintenance_24.1 gematik
2.13.0 19.03.2024 Einarbeitung Änderungsliste Smartcards_23.3 gematik
2.14.0 26.07.2024 Einarbeitung Änderungsliste Betr_24.2 (C_11850, C_11812) gematik

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.

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.
[<=]

A_24021 - Erweiterung zur Sprache der Betriebsdokumentation

Der TI-ITSM-Teilnehmer SOLL in Abweichung der geltenden Anforderung GS-A_4090 seine anzufertigenden Dokumentationen (z.B. Betriebshandbuch) in mindestens einer der folgenden Sprachen konsistent führen:

  • Deutsch
  • Englisch
Hinweis:
Eine zweisprachige Führung der anzufertigenden Dokumentationen ist zulässig, jedoch nicht erforderlich.
[<=]

GS-A_3886-01 - Nutzung des TI-ITSM-Systems bei der Übermittlung eines übergreifenden Vorgangs

Alle TI-ITSM-Teilnehmer MÜSSEN alle übergreifenden Vorgänge, zwecks Informationsübermittlung, im TI-ITSM-System erfassen.
[<=]

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.

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_4088-01 - Benennung von Ansprechpartnern

TI-ITSM-Teilnehmer MÜSSEN Kontaktdaten von Ansprechpartnern im TI-ITSM-System eintragen und aktuell halten für

  • die Rolle Service Delivery Manager (agiert auch als 1. Eskalationsstufe),
  • die 2. Eskalationsstufe,
  • für alle für den TI-ITSM-Teilnehmer relevanten Prozesse gemäß Tabelle gemKPT_Betr#Tab_KPT_Betr_TI_003 Mitwirkungsverpflichtung im TI-ITSM
  • das Notfall-Management,
  • die Unternehmenskommunikation (u.a. Krisenkommunikation).
  • die Informationssicherheit,
  • den Datenschutz, 
  • vertragliche und kaufmännische Fragestellungen.
Die benannten Ansprechpartner MÜSSEN mit der entsprechenden Fach- und Entscheidungskompetenz ausgestattet sein.
[<=]

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.

GS-A_4086 - Erreichbarkeit der Kommunikationsschnittstellen

Alle TI-ITSM-Teilnehmer MÜSSEN die Kommunikationsschnittstellen während der festgelegten Servicezeiten erreichbar halten und einer regelmäßigen Eingangsprüfung und Bearbeitung unterziehen.
[<=]

GS-A_5402 - Eigenverantwortliches Handeln bei Ausfall von Kommunikationsschnittstellen

Bei 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.
[<=]

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

GS-A_5401-01 - Verschlüsselte E-Mail-Kommunikation

Der Informationsaustausch per E-Mail zwischen allen TI-ITSM-Teilnehmern MUSS verschlüsselt nach dem Stand der Technik erfolgen. [<=]

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.

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 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
  • Betriebliche Rolle und Identifikation
  • Version
  • Freigabe- und Prüfungsverantwortung
  • Ergänzende Dokumente soweit vorhanden
  • Dokumentenstand-Basis
  1. Systemüberblick
  • Architektur
  • System
  • Komponenten
  1. Aufnahme, Unterbrechung und Beendigung des Betriebes
  • 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)
  1. Darstellung des lokalen ITSM (vor- und nachgelagerte Prozesse im Verhältnis zu den übergreifenden ITSM-Prozessen)
  • 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.
  1. 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.
  1. Relevanter Teil des Servicekataloges
  2. 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-02 - Auditierung von TI-ITSM-Teilnehmern

TI-ITSM-Teilnehmer MÜSSEN Auditierungen durch Gesamtverantwortlichen TI zur Überprüfung der Einhaltung von Betriebs- und 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 und KTR-Consumer 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 alle relevanten Informationen (z.B. TI-ITSM relevante Tickets im ITSM-System) im Rahmen der Umsetzung bzw. Erfüllung der betrieblichen Anforderungen 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.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.

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 oder
  • für einen Service eine Redundanzlösung gefordert und umgesetzt ist, und diese Lösung durch eine Störung an den beteiligten Komponenten in der Art beeinträchtigt ist, dass bei einer weiteren Beeinträchtigung es zu einer Verletzung der vereinbarten Service Level kommen kann. 

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

Dringlichkeit
Beschreibung
Hoch
  • Durch die Störung stehen die bereitgestellten Leistungen (und/oder Funktionen) nicht zur Verfügung bzw. nur so eingeschränkt, dass die Nutzung des Services nicht zumutbar ist.
  • Die Sicherheit der TI ist nicht mehr gewährleistet.
  • Die Störung der bereitgestellten Leistungen (und/oder Funktionen) lässt sich nicht durch eine Umgehungslösung unmittelbar beseitigen.
Mittel
  • Durch die Störung stehen bereitgestellte Leistungen (und/oder Funktionen) erheblich eingeschränkt zur Verfügung. Die Nutzung des Services ist jedoch mit Einschränkungen möglich.
  • Es ist absehbar, dass sich die Störung ausweitet, wenn keine Gegenmaßnahmen ergriffen werden.
Niedrig
  • Durch die Störung stehen die bereitgestellten Leistungen (und/oder Funktionen) mit leichten Einschränkungen zur Verfügung.
  • Der von dem Incident verursachte Schaden nimmt im Verlauf der Zeit nicht oder nur unwesentlich zu.

Tabelle 2: Tab_Betr_TIP_027 INC – Festlegung von Auswirkung

Auswirkung
Beschreibung
Hoch
  • Es liegt ein Ausfall gemäß [gemSpec_Perf#2.3] vor.
  • Der durch die Störung verursachte Schaden weitet sich schnell aus, falls nicht unmittelbar eine Lösung bereitgestellt werden kann.
  • Die Störung führt zu Verletzung gesetzlicher Vorschriften, wie z.B. aus Datenschutz und Informationssicherheit.
  • Die Störung hat eine hohe Auswirkung in der öffentlichen Wahrnehmung und führt zu einem erheblichen Imageverlust der TI.
Mittel
  • Der vom TI-ITSM-Teilnehmer verantwortete Service ist nur mit sehr starken Einschränkungen nutzbar.
  • Die Störung kann zu Verletzung gesetzlicher Vorschriften führen, wie z.B. aus Datenschutz und Informationssicherheit.
Niedrig
  • Der vom TI-ITSM-Teilnehmer verantwortete Service ist nur mit Einschränkungen nutzbar.
  • Eine Verletzung gesetzlicher Vorschriften ist nicht gegeben.

[<=]

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

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.
[<=]

A_24983 - Erstellung einer Root Cause Analysis im Incident - Prio 1 bis 2

Lösungsverantwortliche TI-ITSM-Teilnehmer MÜSSEN bei Incidents der Priorität 1 oder 2 unaufgefordert im Rahmen der vereinbarten organisatorischen Service Level eine Root Cause Analysis erstellen und an den Gesamtverantwortlichen TI fristgerecht übermitteln.
Die notwendigen Informationen werden vom Gesamtverantwortlichen TI bereitgestellt.

Hierbei kann eine erste Draft-Version durch den Gesamtverantwortlichen TI vorab eingefordert werden.
[<=]

A_24984 - Erstellung einer Root Cause Analysis im Incident - Prio 3 bis 4

Lösungsverantwortliche TI-ITSM-Teilnehmer MÜSSEN bei Incidents der Priorität 3 oder 4 auf Anfrage des Gesamtverantwortlichen TI im Rahmen der vereinbarten organisatorischen Service Level eine Root Cause Analysis erstellen und an den Gesamtverantwortlichen TI fristgerecht übermitteln.
Die notwendigen Informationen werden vom Gesamtverantwortlichen TI bereitgestellt.

Hierbei kann eine erste Draft-Version durch den Gesamtverantwortlichen TI vorab eingefordert 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.

A_18405 - Erstellung einer Root Cause Analysis durch am Incident beteiligte TI-ITSM-Teilnehmer

Am Incident beteiligte TI-ITSM-Teilnehmer MÜSSEN auf Anfrage des Gesamtverantwortlichen der TI mit der Erstellung einer Root Cause Analysis beginnen, dafür das vom Gesamtverantwortlichen der TI bereitgestellte Formular nutzen und anschließend ausgefüllt an ihn übermitteln. [<=]

A_18406 - Nachlieferung zu einer Root Cause Analysis

Lösungsverantwortliche TI-ITSM-Teilnehmer MÜSSEN auf Rückfrage des Gesamtverantwortlichen der TI Informationen zur Root Cause Analysis nachreichen. [<=]

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-03]) ü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-03]) 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.

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_3959 - Prüfung auf übergreifendes Problem

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

Dringlichkeit Beschreibung
Hoch Das Problem muss schnellstmöglich gelöst werden, eine maximale negative Auswirkung liegt vor; ein Workaround ist nicht oder nur nach viel Aufwand vorhanden
Mittel Das Problem sollte so schnell wie möglich gelöst werden; eine Ausweitung ist absehbar
Niedrig Das Problem besteht, ist aber durch geeignete Maßnahmen unter Kontrolle. Es sollte in absehbarer Zeit gelöst werden.

Tabelle 5: Tab_Betr_TIP_103 PRO – Festlegung von Auswirkung

Auswirkung Beschreibung
Hoch
  • Es liegt ein Ausfall gemäß [gemSpec_Perf#2.3] vor.
  • Das Incident Management konnte keinen Workaround zur Verfügung stellen
Mittel
  • Der TI-Service ist durch das Problem negativ beeinflusst und wird nicht wie vereinbart zur Verfügung gestellt.
  • Es existiert ein Workaround, der aufwändig und nur schwer umzusetzen ist
Niedrig
  • Der TI-Service wird durch das Problem negativ beeinflusst
  • Es existiert ein Workaround, der einfach und ohne viel Aufwand umzusetzen ist
 
[<=]

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.

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-03]) ü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_3971 - Verifikation vor Schließung eines übergreifenden Problems

Serviceverantwortliche TI-ITSM-Teilnehmer MÜSSEN 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-03]) keine Rückmeldung durch den problemerkennenden TI-ITSM-Teilnehmer vor, KANN das übergreifende Problem geschlossen werden.
[<=]

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_3991 - WDB-Aktualisierung nach Schließung eines übergreifenden Problems

Serviceverantwortliche TI-ITSM-Teilnehmer MÜSSEN nach der Behebung eines übergreifenden Problems die Wissensdatenbank der TI um die relevanten Problemlösungsinformationen aktualisieren.
[<=]


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.

A_24968 - Probleme während Lösungsphase als "Pending" kennzeichnen

Der serviceverantwortliche TI-ITSM-Teilnehmer KANN für begründete administrativen oder organisatorische Aktivitäten, welche nicht durch ihn verschuldet und auch nicht planbar sind, beim Gesamtverantwortlichen TI veranlassen, dass ein spezifischer Zeitraum während der Lösungsphase eines Problems als "Pending" markiert wird. Die Entscheidung bzgl. der Markierung des Zeitraums liegt ausschließlich bei dem Gesamtverantwortlichen TI (Realisierung, Dauer, Zeitpunkt). [<=]

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.

GS-A_5590 - Nutzung Business-Servicekatalog bei der Erfassung von Service Requests

TI-ITSM-Teilnehmer MÜSSEN 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.
[<=]

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-03]) ohne Rückmeldung überschritten ist.
[<=]

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.

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

Configuration Item
Beschreibung
Beispiel
TI-Services
Alle Services, die durch die TI selbst bereitgestellt werden. Diese Services werden durch den Gesamtverantwortlichen TI definiert.
VSDM, KOM-LE, EPA/EPF
Produkttypen
Um einen TI-Service bereitzustellen, werden Produkttypen spezifiziert. Mehrere Produkttypen bilden einen generischen TI-Service.
VPN-Zugangsdienst, Namensdienst
Betriebliche Rollen
Betriebliche Rolle, die ein TI-ITSM-Teilnehmer im Rahmen des Betriebsmodells der TI einnehmen darf.
AZPD, Anbieter VPN-Zugangsdienst, Hersteller Konnektor
TI-ITSM-Teilnehmer
Juristische Person des TI-ITSM-Teilnehmers mit Zuweisung der betrieblichen Rolle und Zulassungsstatus
Firma x / Anbieter X.509 TSPs für eGK

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

Configuration Item
Beschreibung
Beispiel
Organisation
Angabe der für den Betrieb relevanten Kommunikationsschnittstellen
gem. GS-A_4088-01
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 Betriebsumgebung PU
Konfigurationsdaten Produktinstanz
Detaillierte Daten zu der logischen Produktinstanz
Produktversion; Produkttypversion, Status

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.

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.
[<=]

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.

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.

[<=]

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.

GS-A_4399 - Übermittlung von Produktdaten nach Abschluss von lokal autorisierten Produkt-Changes

Alle TI-ITSM-Teilnehmer MÜSSEN nach dem Abschluss (nach der Produktivsetzung des Produkt-Changes) von lokal autorisierten Produkt-Changes die geänderten Produktdaten an das TI-ITSM-System übermitteln.
[<=]

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.

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_5597 - Produkt-RfC (Sub-Changes) erstellen

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_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 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 9: Tab_Betr_TIP_048 CHG – Kriterien für Emergency Changes

Definition Kriterien
EMERGENCY
CHANGE

  • kritische Situation, Incident klassifiziert mit „Priorität 1“, gemäß Tab_Betr_TIP_009 INC – Prioritätenmatrix und eingeschränkte Testmöglichkeiten für die hier einsetzbare Lösung
  • Incident, kategorisiert als „TI-Notfall“
  • vom Gesamtverantwortlichen TI und/oder EMC bestätigter TI-Notfall
  • Fehlgeschlagener Produkt-Change; der nicht mit üblichen Mitteln zurückgenommen werden kann, d. h. unzureichende Fallback-Möglichkeiten und/oder mögliche Auswirkungen auf andere TI-Services
  • Unmittelbare Notwendigkeit, einen kritischen Sicherheitsvorfall durch Einsatz eines „Emergency Security Patches“ zu beseitigen

[<=]

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_4402 - Mitwirkungspflicht bei der Bewertung vom Produkt-RfC

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-02 - Bearbeitungsfristen in der Bewertung von Produkt-Changes

Alle betroffenen TI-ITSM-Teilnehmer MÜSSEN mindestens folgende Change-Bewertungszeiten des GTI bei der Erstellung und Umsetzungsplanung (im Sinne Vorlaufzeiten vor Implementierungsbeginn) eines RfCs berücksichtigen:

  • Produkt-Change (Master): mindestens 5 Werktage (zwischen Beantragung und Umsetzung)
  • Produkt-Change (Sub): mindestens 3 Werktage (zwischen Beantragung und Umsetzung)
[<=]

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.

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_4419 - Nutzung der Testumgebung (RU/TU)

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

A_24799 - ChangeManagement - e2e-Funktionsprüpfung nach Change

Der TI-ITSM-Teilnehmer MUSS nach der Durchführung eines jeden Changes durch geeignete Maßnahmen überprüfen, dass die Funktionalität beim Client wie erwartet wieder hergestellt ist bzw. noch immer/weiterhin besteht. [<=]

GS-A_5601 - Nachweis der Wirksamkeit eines Changes

Jeder 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.
[<=]

A_18407 - Unterstützung bei Change-Verifikation

TI-ITSM-Teilnehmer, deren Service von einem Produkt-Change betroffen ist, MÜSSEN nach der Change-Implementierung bei der Ende-zu-Ende-Verifikation unterstützen.
[<=]

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.

GS-A_4407 - Bereitstellung der Dokumentation des Change Managements für genehmigungspflichtige Produkt-Changes

TI-ITSM-Teilnehmer MÜSSEN für jeden genehmigungspflichtigen Produkt-Change eine Dokumentation 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_4418 - Übermittlung von Abweichungen vom Produkt-RfC

TI-ITSM-Teilnehmer, 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_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:

  1. Es handelt sich nach fachlich-fundierter Bewertung des TI-ITSM-Teilnehmers um eine Notsituation, die nur durch einen Emergency-Change gelöst werden kann.
  2. 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.
  3. 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.
[<=]

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

GS-A_4117 - Informationsbereitstellung durch TI-ITSM-Teilnehmer

TI-ITSM-Teilnehmer KÖNNEN 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.
[<=]

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.

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_4101 - Übermittlung der Service Level Messergebnisse

TI-ITSM-Teilnehmer MÜSSEN die 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.

[<=]

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

Um die Verfügbarkeit und Stabilität der eingesetzten Dienste und Komponenten zu gewährleisten, ist die genauere Betrachtung von geeigneten Redundanzlösungen notwendig. Die hier betrachtete Redundanz ist die Vervielfältigung von Wegen zum Übertragen, Speichern und Verarbeiten von Daten im Kontext des betrieblichen Capacity-Managements.

Gemäß [ISO/IEC 22237-1:2021] ist das primäre Ziel von operativen Betriebsumgebungen die Reduktion von ungeplanten Einschränkungen im laufenden Betrieb. Die Abhängigkeit der Erbringung von Betriebsleistungen von betriebs-kritischer Infrastruktur wie z.B. Speichersystemen, Netzwerkhardware, Energieversorgung oder Kühlung wird bei einem Ausfall durch geeignete Redundanzmaßnahmen in ihrer negativen Auswirkung abgemildert oder gänzlich unterbunden.

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

A_18363 - Berechnung von Performance-Kenngrößen aus Rohdaten

Zur Berechnung der in [gemKPT_Betr] definierten Performance-Kenngrößen aus den Performance-Rohdaten auf Service-Ebene MUSS der TI-ITSM-Teilnehmer den Gesamtverantwortlichen TI  bei der Festlegung der Bildungsregeln unterstützen und mit dem Gesamtverantwortlichen TI vereinbaren. [<=]

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 von Ergebnissen der Performance-Messung in Form von Performance-Reports befindet sich in der schrittweisen Ablösung und wird vollständig durch die Lieferung in Form von Rohdaten ersetzt.

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.

A_18236-01 - Übermittlung von Performance-Reports

TI-ITSM-Teilnehmer, die gemäß Tab_gemKPT_Betr_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.

A_19869 - Performance - Rohdaten-Performance-Berichte - zu liefernde Berichte der TI-ITSM-Teilnehmer

TI-ITSM-Teilnehmer, die Rohdaten-Performance-Berichte übermitteln, MÜSSEN jeweils zu jedem separat konfigurierbaren Berichtsintervall zwei Dateien senden:
- einen "Rohdaten-Performance-Bericht" mit den zu liefernden Rohdaten [gemSpec_Perf#A_17755, A_17671, A_17668-*, A_19733-*]
und
- eine Datei zur "Selbstauskunft" gemäß [gemSpec_OM#GS-A_4543] im XML-Format [ProductInformation.xsd].

Beide Dateien MÜSSEN separat an die Betriebsdatenerfassung gemäß gemSpec_SST_LD_BD an die Schnittstelle I_OpsData_Update gesandt werden. [<=]

GS-A_4106-02 - 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_gemKPT_Betr_Performance-Kenngroessen [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
[Date]

6 Messgroesse Messgröße des Performance-Wertes gemäß Tab_ gemKPT_Betr_Performance-Groessen [String]
7 Auswertungsstart Zeitpunkt, ab dem die Messung für den Wert gestartet ist [Date]/
8 Auswertungsende Zeitpunkt, an dem die Messung für den Wert beendet wurde [Date]/
[<=]

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

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

10.3 Redundanzkonzept

Das Redundanzkonzept stellt auf Basis einer Business Impact Analyse (siehe [ISO/TS 22317:2021]) zum eingesetzten Dienst oder der Komponente betriebliche Risiken dar, welche in Abhängigkeit des eingesetzten Dienstes oder der Komponente, organisatorische und/oder betriebliche Einschränkungen zur Folge haben. Auf dieser Basis leiten sich dann konkrete Maßnahmen ab, die zur Erfüllung des festgelegten Anforderungsprofils der Spezifikation umgesetzt werden müssen, um einen kontinuierlichen und sicheren Betrieb zu gewährleisten und die Einschränkungen durch Ausfälle zu verringern oder komplett abzumildern.

Folgende Anforderungen können vom TI-ITSM Teilnehmer auch durch die Vorlage von bereits zertifiziert erstellten Konzepten z.B. im Rahmen einer Akkreditierung zur ISO/IEC 22237, DIN EN 50600 oder ähnlichen unterstützt werden. Eine erfolgreiche Akkreditierung nach einem Industriestandard für Rechenzentren kann jedoch nicht die Vorlage eines zugelassenen Redundanzkonzeptes ersetzen. Vielmehr vereinfacht eine vorhandene Akkreditierung den Zulassungsprozess, aufgrund der bereits einheitlichen Dokumentenlage und einer ggf. bereits durchgeführten Business Impact-Analyse mit eingesetzten Maßnahmen.

A_25903 - Redundanz - Definition inhaltlicher Auszüge aus dem Redundanzkonzept

Der TI-ITSM Teilnehmer MUSS in dem Redundanzkonzept die nachfolgenden Themen betrachten.

1. Einleitung

1.1.             Zielstellung
2. Standorte der Rechenzentren
3. Risikoanalyse
3.1.             Identifizierung potentieller Ausfallpunkte
3.2.             Gefährdungsübersicht
         3.2.1. Physische Gefährdungen (z.B. Feuer, Überschwemmung)
         3.2.2. Technische Gefährdungen (z.B. Hardwareausfälle, Netzwerkausfälle)
         3.2.3. Menschliche Gefährdungen (z.B. Bedienfehler, Sabotage)
         3.2.4. Umweltbezogene Gefährdungen (z.B. Stromausfall, Naturkatastrophen)
3.3.             Bewertung der Auswirkungen von Ausfällen (Auswirkung auf TI)
3.4.             Maßnahmen Risikominimierung
3.5.             Kontinuierliche Überwachung und Überprüfung
4. Redundanzstrategien
4.1.             Physische Redundanz (z.B. N+1,2N,2N+1)
4.2.             Logische-Redundanz (z.B. Failover, Load Balancing)
4.3.             Geografische-Redundanz
4.4.             Kombination und Integration verschiedener Redundanzstrategien
5. Implementierung
5.1.             Auswahl der geeigneten Redundanzlösung
5.2.             Planung und Umsetzung der Redundanzlösung
6. Überwachung und Wartung
6.1.             Monitoring-Systeme und Tools
6.2.             Wartungsstrategien und –plänen
6.3.             Regelmäßige Überprüfung und Aktualisierung des Redundanzkonzepts
7. Schulung und Sensibilisierung
7.1.             Schulungsprogramme für Mitarbeiter       
7.2.             Sensibilisierung für Redundanz und Risikomanagement       
7.3.             Dokumentation und Nachweise       
8. Dokumentation und Berichterstattung
8.1.             Anforderungen an die Dokumentation
8.2.             Berichterstattung über Redundanz und Risikomanagementmaßnahmen
8.3.             Audit- und Zertifizierungsergebnisse
9. Zusammenfassung und Ausblick
10. Anhang
10.1.           Detaillierte technische Spezifikationen der Redundanzlösungen
10.2.           Weitere relevante Dokumentationen und Ressourcen
 

[<=]

A_25902 - Redundanz - Bereitstellung Redundanzkonzept

Der TI-ITSM Teilnehmer MUSS auf Basis der definierten Performancevorgaben und der durchgeführten Business Impact Analyse (siehe [ISO/TS 22317:2021])

  • ein Redundanzkonzept erstellen, das sich an den Leitlinien von Industriestandards für Planung, Aufbau und dem kontinuierlichen Betrieb von Rechenzentren orientiert,
    • in dem eine Identifizierung von Redundanzstrategien,
    • eine risikobasierte Bewertung insbesondere in Bezug auch auf mögliche Gefährdungen erfolgt
Bereits bestehende Zertifizierungen können nachgenutzt werden, wenn sie Bereiche der Business Impact Analyse bereits abdecken.
Das Redundanzkonzept ist der gematik im Rahmen der Zulassung oder auf Anfrage in aktualisierter Form unverzüglich vorzulegen.
[<=]

A_26014 - Redundanz - Umsetzung Redundanzkonzept

Der TI-ITSM Teilnehmer MUSS die aus dem Konzept abgeleiteten Maßnahmen und die dafür geeignete Redundanzstrategie umsetzen. Die Umsetzung kann in Abstimmung mit dem Gesamtverantwortlichen TI in Ausbaustufen erfolgen. [<=]

A_25917 - Redundanz - Kontrollierte Validierung des Redundanzkonzept

Der TI-ITSM Teilnehmer MUSS in Abstimmung mit dem Gesamtverantwortlichen TI mindestens einmal jährlich eine praktische Validierung des vorliegenden Redundanzkonzeptes durchführen.
Die Validierung des Redundanzkonzeptes ist möglichst in allen angebotenen Betriebsumgebungen durchzuführen. Dabei sollen unterschiedliche Ausfallszenarien praktisch überprüft und die zur Wiederherstellung erforderlichen Tätigkeiten erfasst und mit dem Konzept abgeglichen werden. Es ist maßgeblich darauf zu achten, dass die im Redundanzkonzept angegebenen Wiederherstellungszeiten eingehalten werden. Werden bei dieser Durchführung Abweichungen vom Konzept oder den erwarteten Zeiten festgestellt, so sind vom Anbieter in Abstimmung mit dem Gesamtverantwortlichen TI entsprechende Folgemaßnahmen zu planen und priorisiert umzusetzen.
[<=]

Hinweis: Die Durchführung der jährlichen Validierung des eingesetzten Redundanzkonzeptes kann in Absprache mit dem Gesamtverantwortlichen TI dann als erfolgt gelten, wenn im laufenden Kalenderjahr bereits ein Ausfall oder die Störung einer Komponente zur erfolgreichen Validierung der Redundanzmaßnahmen geführt hat und diese nachvollziehbar im TI-ITSM System z.B. im Rahmen einer RCA (Root Cause Analyse) oder eines PIR (Post Incident Reviews) dokumentiert wurde.

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:

  1. Vertraglich zugesicherte Leistung:
    • Prozess des Abrufs und der Freigabe des Services
    • Kosten des Serviceabrufs
    • Reaktions-, Lösungs- und Verifikationsfrist
    • Prozess der Verifikation der Servicelieferung
  2. 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 Gesamtverantwortliche TI wird die 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
  • 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.

GS-A_4121 - Analyse Auswirkungen möglicher Schadensereignisse auf Sicherheit und Funktion der TI-Services

TI-ITSM-Teilnehmer MÜSSEN die Auswirkungen möglicher Schadensereignisse auf von 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.
[<=]

12.2.2 Entwicklung und Pflege der Notfallvorsorgedokumentation

GS-A_4123 - Entwicklung und Pflege der TI-Notfallvorsorgedokumentation

TI-ITSM-Teilnehmer MÜSSEN eine TI-Notfallvorsorgedokumentation, welche die Ergebnisse der Auswirkungsanalyse sowie Vorkehrungen zur TI-Notfallvorsorge des Serviceverantwortlichen enthält, entwickeln und pflegen. In der TI-Notfallvorsorgedokumentation sind die Aktivitäten festgelegt, die bei Eintritt eines TI-Notfalls durchzuführen sind.
[<=]

12.2.3 Umsetzung Vorkehrungen zur Notfallvorsorge

GS-A_4124 - Umsetzung Vorkehrungen zur TI-Notfallvorsorge

TI-ITSM-Teilnehmer MÜSSEN die erarbeiteten Vorkehrungen zur TI-Notfallvorsorge umsetzen.

[<=]

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

GS-A_4126 - Eskalation TI-Notfälle

TI-ITSM-Teilnehmer MÜSSEN erkannte TI-Notfälle unverzüglich an den Gesamtverantwortlichen TI eskalieren. Eine Meldung an den Gesamtverantwortlichen TI MUSS im Sinne einer umgehenden und persönlichen Benachrichtigung erfolgen.
[<=]

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

GS-A_4127 - Sofortmaßnahmen TI-Notfälle

TI-ITSM-Teilnehmer, deren 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.
[<=]

12.3.4 Bewältigung TI-Notfälle

GS-A_4128 - Bewältigung der TI-Notfälle

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

TI-ITSM-Teilnehmer MÜSSEN bei der Bewältigung sowie Koordination der TI-Notfälle den Gesamtverantwortlichen TI oder andere TI-ITSM-Teilnehmer im erforderlichen Umfang unterstützen.
[<=]

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.

GS-A_4130 - Festlegung der Schnittstellen des EMC

Prozessbeteiligte TI-ITSM-Teilnehmer MÜSSEN die vom Gesamtverantwortlichen TI bereitgestellten Schnittstellen im Rahmen der Einberufung des EMC 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 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.

GS-A_4132 - Durchführung der Wiederherstellung und TI-Notfällen

TI-ITSM-Teilnehmer MÜSSEN alle Aktivitäten, welche der Wiedererreichung und Stabilisierung des Leistungsumfangs im eigenen Verantwortungsbereich dienen, durchführen und dokumentieren.
[<=]

12.3.7 Nachbearbeitung/Notfallauswertung

GS-A_4134 - Auswertungen von TI-Notfällen

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

GS-A_4136 - Statusinformation bei TI-Notfällen

TI-ITSM-Teilnehmer, die von einem TI-Notfall betroffen sind, MÜSSEN im Rahmen der TI-Notfallbewältigung den Gesamtverantwortlichen TI ständig über den aktuellen Status der Durchführung der TI-Notfallmaßnahmen informieren.
[<=]

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

GS-A_4137 - Dokumentation im TI-Notfall-Logbuch

TI-ITSM-Teilnehmer MÜSSEN zu jedem TI-Notfall ein TI-Notfall-Logbuch erstellen.

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

  • Ergebnis einer Maßnahme

TI-ITSM-Teilnehmer MÜSSEN dabei das TI-Notfall-Logbuch in den Phasen vom Bekanntwerden des Notfalls bis zur Notfalldeeskalation ständig aktualisieren.

[<=]

12.5.2 Wiederherstellungsbericht

GS-A_4138 - Erstellung des Wiederherstellungsberichts nach TI-Notfällen

TI-ITSM-Teilnehmer MÜSSEN zu jeder Wiederherstellung in der TI-Notfallbewältigung einen Wiederherstellungsbericht erstellen.

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.

[<=]

13 Vorschriften für CSV-Reporting

GS-A_5608 - Übermittlung von CSV-Dateien

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-01)
  • 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

  1. 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 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.
  1. Für die Erfassung der Prozessdaten im Webportal werden die Konventionen im entsprechenden Formular dargestellt.
[<=]

GS-A_5249 - Reservierte Zeichen in den Prozessdaten

TI-ITSM-Teilnehmer 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

reservierte Zeichen
Muss ersetzt werden durch
Begründung
#
<Hash>
Reserviertes Zeichen, für die Feldtrennung. Sie müssen ersetzt werden durch den Text <Hash>.
Zeilenumbruch
<br>
Zeilenumbrüche in Inhaltsfeldern erhöhen die Fehlerwahrscheinlichkeit beim Einlesen der CSV-Datei durch das Zielsystem. Sie müssen ersetzt werden durch den Text <br>
Doppeltes Anführungszeichen (ASCII 34)

(ASCII 39)
Reserviertes Zeichen, für die Markierung der Inhalte von Feldern. Sie müssen ersetzt werden durch ein „Einfaches Anführungszeichen“.
<tr>
löschen
Reservierte Zeichen, für eine Datensatztrennung im Inhaltsfeld. Die Zeichen müssen gelöscht werden.
</tr>
löschen
Reservierte Zeichen, für eine Datensatztrennung im Inhaltsfeld. Die Zeichen müssen gelöscht werden.

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

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:

YYYY-MM-DDThh:mm:ss±hh
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.
Beispiel :[Auswahlfeld], (ja), (nein)
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
SLK Service Level Katalog
SLM Service Level Management
SLR Service Level Requirements
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.

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.

[Quelle] Herausgeber: Titel
[gemGlossar] gematik: Glossar der Telematikinfrastruktur
[gemKPT_Betr] gematik: Betriebskonzept Online-Produktivbetrieb
[gemSpec_DS_Anbieter] gematik: Spezifikation Datenschutz- und Sicherheitsanforderungen der TI an Anbieter
[gemSpec_Perf] gematik: Übergreifende Spezifikation Performance und Mengengerüst TI-Plattform

14.5.2 Weitere Dokumente

[Quelle]
Herausgeber (Erscheinungsdatum): Titel
[BSI 100-4]
BSI-Standardreihe zur Informationssicherheit: 100-4 Notfallmanagement,  Version 1.0 (2008)
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/ITGrundschutzstandards/standard_1004_pdf
[RFC2119] RFC 2119 (März 1997): Key words for use in RFCs to Indicate Requirement Levels S. Bradner,
http://tools.ietf.org/html/rfc2109
[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
[OMNI WSDL] omnitracker.wsdl, Version 10.3.200 (build 6408)
Namespace http://www.omninet.de/OtWebSvc/v1
[OMNI MANUAL] OMNITRACKER Web Service Manual, The OMNINET Problem and Request Tracking System
Version 10.3 (build 6408)
[RFC2617] RFC 2617 (Juni 1999): HTTP Authentication: Basic and Digest Access Authentication
http://tools.ietf.org/html/rfc2617
[RFC2616] RFC 2616 (Juni 1999): Hypertext Transfer Protocol -- HTTP/1.1
http://tools.ietf.org/html/rfc2616
[BSI TR-02102] BSI TR-02102-2 "Kryptographische Verfahren: Empfehlungen und Schlüssellängen, Teil 2 – Verwendung von Transport Layer Security (TLS)"
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2_pdf.html