Elektronische Gesundheitskarte und Telematikinfrastruktur

Übergreifende Richtlinien zum Betrieb der TI

    

     

      
Version
      
1.11.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
14.05.2018
     
     

      
Status
      
in Bearbeitung
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemRL_Betr_TI
     
    

Dokumentinformationen

Änderungen zur Vorversion

Änderungen zur Vorversion beruhen auf P 15.2

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

1.1 Zielsetzung

Die vorliegenden „Übergreifenden Richtlinien zum Betrieb der TI“ definieren die betrieblichen Mitwirkungspflichten und Schnittstellen zur übergreifenden Zusammenarbeit der Teilnehmer der TI im IT-Servicemanagement (ITSM-TI) auf prozessualer Ebene. Die übergreifende Richtlinie zum Betrieb der gilt sinngemäß auch für den Betrieb der Referenz- und Testumgebung. Als ITSM-TI-Teilnehmer sind Anbieter und Service Provider Endnutzernahe Dienste (SPED), verantwortlich für Anwendungsservices, Basisservices, TI-nahe Anwendungen und Anwenderkomponenten. Die zur Erbringung der TI-Services benötigten Produkte müssen zugelassen sein.

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

Hinweis

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

Die Mitwirkung der gematik am ITSM-TI erfolgt über explizit benannte Rollen (z. B. Servicebetriebsverantwortlicher - SBV).

Die gematik Rollen (SBV, SV, GBV TI) haben in den ITSM-TI Betriebsprozessen gegenüber den Anbietern und SPEDs einen anderen Fokus: diese verantworten die Umsetzung ihrer Service-, Support- und Produktverantwortung gegenüber ihren Servicenehmern. Die gematik Rollen hingegen haben Ergebnisverantwortung für die ITSM-TI Betriebsprozesse und nehmen dort folgende Funktionen ein:

• Koordination von Vorgängen nach erfolgter Anfrage durch Anbieter und SPEDs (z.B. Koordination einer Taskforce im PRO)
• Eskalation von Vorgängen bei erkanntem Eskalationsbedarf oder nach erfolgter Eskalation durch Anbieter / SPEDs (z.B. ein Problem wurde im PRO an den GBV-TI eskaliert; Eskalationsstufe 2)
• Steuerung der ITSM-TI-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 SLM zur Einleitung von Optimierungsmaßnahmen bei den Anbietern / SPEDs).

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

Folgende Prozesse werden im ITSM-TI betrachtet:

• 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,
• Change & Release Management: Regelungen für das Management von Änderungen der TI-Basis-Services und Anwendungsservices sowie Regelungen für das Management zur Überführung von Releases in den Wirkbetrieb,
• Configuration Management: Regelungen für das Management der für die TI-Basis-Services und Anwendungsservices erforderlichen Beschreibungsdaten,
• Knowledge Management: Regelungen für das Management von Informationen aus dem und für den Wirkbetrieb der TI-Basis-Services und Anwendungsservices,
• Incident Management: Regelungen für den Umgang mit Störungen, die zu einer Qualitätsminderung der TI-Basis-Services oder der Anwendungsservices führen können,
• Problem Management: Regelungen für das Management von unbekannten Ursachen einer eingetretenen/möglichen Störung und nachhaltiger Beseitigung der identifizierten Störungsursachen,
• Notfallmanagement: Regelungen für die Notfallvorsorge und die Notfallbewältigung der TI-Basis-Services und der Anwendungsservices.
• Request Fulfillment: Regelungen für das Bearbeiten von Service-Requests. Dabei handelt es sich um Nachfrage nach vordefinierten Dienstleistungen bzw. Stellung allgemeiner Anfragen und/oder Beschwerden, die von berechtigten TI-Akteuren oder zukünftigen ITSM-TI-Teilnehmern durchgeführt werden.

In Kapitel 2 werden die prozessübergreifenden Begriffe und Grundsätze, die Regelungen zum Reporting und die Zuordnung der ITSM-Prozesse zu den ITIL-Lebenszyklusphasen eingeführt. Es werden die betrieblichen Rollen definiert und deren Verantwortungsteilung beschrieben. Zugleich werden den Rollen Teilaufgaben zugeordnet, die sich aus den Aufgabenbereichen des Betriebs der TI ergeben.

Die Aufgabenbereiche sind an ITIL® V3 angelehnt. Alle Aufgabenfelder werden in Form von übergreifenden IT-Service-Management-Prozessen mit den jeweiligen Aufgaben und Zielen vorgestellt. Sie orientieren sich an den ITIL-Lebenszyklusphasen des „Service Design“ zur Erstellung, Weiterentwicklung und Pflege von Vorgaben, der „Service Transition“ zur Überführung der Vorgaben in den Wirkbetrieb und der „Service Operation“ in der Unterstützung des Wirkbetriebs der TI-Services.

1.2 Zielgruppe

Das Dokument richtet sich an die bezeichneten ITSM-TI-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, 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 Abgrenzung des Dokuments

Nicht alle ITSM-Prozesse gemäß ITIL® V3 sind im Rahmen dieses Richtliniendokumentes geregelt. Dies ergibt sich insbesondere

• durch die Fokussierung auf die Mitwirkungspflichten durch Anbieter und SPEDs im Wirkbetrieb der TI,
• 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 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 Textmarken angeführten Inhalte.

2 Prozessübergreifende Regelungen

In diesem Kapitel werden Begriffe und Regelungen eingeführt, die für alle nachfolgend beschriebenen ITSM-Prozesse Gültigkeit haben.

Begriffe, die im Kontext des übergreifenden Betriebes einer Konkretisierung bedürfen, werden in diesem Dokument in den Kapiteln „Begriffserläuterungen“ definiert. Dabei wird zwischen prozessübergreifenden und prozessspezifischen Begriffserläuterungen unterschieden.

Prozessübergreifende Begriffserläuterungen werden zentral in diesem Dokument eingeführt und sind über alle in diesem Dokument beschriebenen ITSM-Prozesse hinweg gültig.

Prozessspezifische Begriffserläuterungen werden prozessspezifisch eingeführt und sind nur im Kontext des jeweiligen ITSM Prozesses gültig.

Ergänzende Informationen mit nicht normativem Inhalt, die zum Fördern des gemeinsamen Verständnisses der ITSM-TI-Teilnehmer (siehe Kapitel 2.2.2) beitragen (z.B. Prozessablaufdiagramme, ergänzende Beschreibungen oder Kontaktinformationen), werden bei Bedarf im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank (siehe Kapitel 7.2.1) bereitgestellt.

2.1 Organisationen in § 274 Abs. 1 SGB V in der Rolle eines Anbieters

Sofern eine im § 274 Abs. 1 SGB V genannte Organisation, die gemäß § 274 Abs. 1 SGB V regelmäßig durch eine im § 274 Abs. 1 SGB V benannte Stelle geprüft wird, in der Rolle eines Anbieters auftritt, muss sie - unabhängig vom angebotenen Produkt bzw. der angebotenen Anwendung – die Anforderungen aus Tabelle xy nicht nachweisen.

Tabelle 1: Tab_Betr_TIP_050 zeigt Anforderungen, die bei einer Prüfung nach § 274 Abs. 1 SGB V, der gematik nicht nachgewiesen werden müssen.

2.2 Prozessübergreifende Begriffserläuterungen

Nachfolgend werden die wesentlichen prozessübergreifenden Begriffe erläutert, die Anforderungen zur prozessübergreifenden Kommunikation der ITSM-TI-Teilnehmer auf Grundlage der ZID sowie die Mindestinhalte des vorzulegenden Betriebshandbuchs dargestellt.

2.2.1 Information, Eskalation, Report

• Information: Bei einer Information handelt es sich um eine für den jeweiligen Empfänger strukturierte und aufbereitete Sammlung von Daten, die - zu festgelegten Prozesszeitpunkten - durch den Versender an definierte Adressaten verschickt werden.
• Eskalation: Eine Eskalation wird angestoßen, um die gefährdete Zielerreichung dennoch sicherzustellen. In den Richtlinien wird unter dem Begriff „Eskalation“ prinzipiell eine hierarchische Eskalation verstanden. Eine Eskalation beinhaltet ähnliche Merkmale wie eine strukturierte Information.
• Funktionale „Eskalationen“ sind im Umfang der definierten ITSM-Prozesse Zuweisungen bzw. Weiterleitungen von speziellen Aufgaben an andere Prozessbeteiligte.
• Report: Bei einem Report handelt es sich um eine für den jeweiligen Empfänger strukturierte und aufbereitete Sammlung von Daten, die nach der originären Prozessdurchführung - zu festgelegten Zeitpunkten oder ad-hoc - durch den Versender an definierte Adressaten verschickt werden.

2.2.2 Teilnehmer-ID (TID)

Die Teilnehmer-ID identifiziert die Teilnehmer im Betrieb der TI (Beteiligte am IT-Servicemanagement gemäß dieser Richtlinie) eineindeutig. Sie ist vom Typ „String [5]“ und wird von gematik vergeben. Die ID über alle Teilnehmer wird in Listenform von der gematik im Rahmen des Knowledge Managements veröffentlicht. Ist eine Hersteller-ID/Anbieter-ID gemäß [gemSpec_OM] vorhanden, wird sie verwendet.

2.2.3 Prozessübergreifende Kommunikation

Hinweis zur Weiterentwicklung der Betriebsdokumente und des TI-ITSM-Tools

Die Richtlinie Betrieb wird im Zuge neuerer Erkenntnisse und Anpassungen an aktuelle Standards überarbeitet und die zentrale Anwendung zum Informationsaustausch der Akteure im ITSM der TI - Zentrale Informationsdrehscheibe (ZID) - wird durch eine Nachfolgeanwendung (TI-ITSM-Tool) geplant zum 30.09.2017 abgelöst. Die Nachfolgeanwendung (TI-ITSM-Tool) bietet neben der bereits etablierten Webportal-Schnittstelle eine standardisierte Webservice-Schnittstelle an. Der strukturierte Datenaustausch per CSV-Datei wird abgelöst.

Zukünftigen Teilnehmern wird empfohlen, über das Webportal der ZID teilzunehmen und strukturierte Reports via CSV zu senden.

Es steht den Teilnehmern frei, die automatisierte CSV-Schnittstelle der ZID zu nutzen. Diese steht jedoch nur noch bis zur Ablösung durch die Nachfolgeanwendung (TI-ITSM-Tool) zeitlich begrenzt zur Verfügung und wird nach der Migration der ZID auf die Nachfolgeanwendung abgeschaltet. Im Anschluss kann der Teilnehmer ausschließlich über das Webportal oder per Webservice am ITSM der TI teilnehmen.

Um eine möglichst reibungslose Prozesskommunikation und effiziente Prozessdurchführung zwischen den ITSM-TI-Teilnehmern und den zuständigen Serviceverantwortlichen (SV) bzw. Servicebetriebsverantwortlichen (SBV) sicherzustellen, werden nachfolgend die übergreifenden Anforderungen für die Bereitstellung von Kommunikationsschnittstellen und Ansprechpartnern definiert. Die Kommunikationsschnittstelle und die Ansprechpartner bilden den SPOC (Single Point of Contact) des jeweiligen ITSM-TI-Teilnehmers im Rahmen der Prozesskommunikation.

Die zuständigen SV/SBV errichten ihrerseits Kommunikationsschnittstellen und stellen Ansprechpartner im Rahmen der Prozesskommunikation zur Verfügung. Die Übersicht der im übergreifenden ITSM zu verwendenden Kontaktdaten (E-Mail-Adressen, Telefonnummern) wird im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank hinterlegt.

Die nachfolgenden Anforderungen an die Kommunikation zwischen den Prozessbeteiligten basieren auf einer ursprünglich vorgesehenen bilateralen Kommunikation via E-Mail und dem Austausch strukturierter CSV-Dateien. Um jedoch für alle Beteiligten eine einheitliche und transparente Daten- und Prozesskonsistenz für die übergreifenden ITSM-Prozessabläufe im Incident-, Problem- und Change-Management zu erreichen, wird mit der Zentralen Informationsdrehscheibe (ZID) ein zentrales ITSM-System zur Verfügung gestellt. Dieses bildet die zentrale Kommunikationsschnittstelle für alle Prozessbeteiligten. Wichtig ist, dass die ZID nur die übergreifenden Kommunikationsprozesse unterstützt (keine lokalen Prozesse) und hier auch nur die Kommunikationsvorgänge im Incident-, Problem- und Change-Management. Für Teilnehmer, die sich in den übergreifenden INC- und PRO-Prozessen für die Benutzung des Webportals entscheiden, kann hingegen die ZID zum führenden ITSM-System werden. Auch diese Teilnehmer müssen den INC „lokal“ dokumentieren, d. h. in diesem Fall in der ZID. Die Dokumentation sollte allerdings bereits vollständig in der ZID vorliegen.

Die ZID stellt für den gesicherten Austausch und die Generierung von Prozessinformationen mehrere Schnittstellen zur Verfügung. Ein Prozessbeteiligter kann im Incident- und Problem-Management über die ZID dabei entweder (weiterhin) seine Kommunikationsschnittstelle durch die Versendung von E-Mails mit angehängten CSV-Dateien einrichten, oder er realisiert den Austausch mit der ZID über eine Webservice-Schnittstelle oder er entscheidet sich für die manuelle Bedienung im Webportal. Grundsätzlich besteht die Möglichkeit, Incidents, Problems und Changes im Webportal der ZID einzusehen.

Die ZID stellt im Incident- und Problem-Management sicher, dass über die vom Prozessbeteiligten einmalig vorab getroffene Entscheidung des Kommunikationsweges (E-Mail mit CSV oder Webservice oder Webportal) sämtliche der im Folgenden beschriebenen Kommunikationsschritte abgebildet werden.

Bei der Kommunikation im Change Management wird im Wesentlichen davon ausgegangen, dass die Informationsübermittlung zwischen den Prozessbeteiligten per E-Mail ohne CSV-Dateien erfolgt. Daher bietet die ZID für diesen Prozess keine Webservice-Schnittstelle an, sondern es steht ausschließlich das Webportal der ZID zur Verfügung. Die Benutzung des Webportals für übergreifende Produkt-RfCs bzw. Produkt-Changes steht jedoch jedem ITSM-TI-Teilnehmer frei. Falls sich ein ITSM-TI-Teilnehmer im Rahmen des Change Managements für die Nutzung des Webportals entscheidet, sind die für diesen Prozess definierten Übermittlungs- und Dokumentationspflichten auch möglichst durchgehend in der ZID zu erfüllen.

Der Zugriff auf die Webservice-Schnittstelle und das Webportal der ZID durch die ITSM-TI-Teilnehmer wird durch Eingabe von Melder-individuellen Anmeldeinformationen (Anmeldenamen und Passwort) abgesichert. Zusätzlich wird der Zugriff auf definierte IP-Adress-Bereiche beschränkt, wobei der IP-Adress-Bereich nachvollziehbar dem entsprechenden ITSM-TI-Teilnehmer zuzuordnen sein muss. Weiterhin wird die Datenübertragung durch ein Server-Zertifikat abgesichert.

Bei Ausfall der ZID oder anderen vom GTI/SBV zur Verfügung gestellten Kommunikationsschnittstellen bzw. Informationssystemen, hat die Absicherung der Kommunikation durch die ITSM-TI-Teilnehmer zu erfolgen.

Die Service Level Requirements zu den Servicezeiten werden in den jeweiligen ITSM Prozessen dieses Dokumentes definiert.

2.2.4 Betriebshandbuch-Auszug

Um eine gesicherte Verbindung der ITSM-TI-Teilnehmer Prozesse mit den übergreifenden ITSM-TI Prozessen zu ermöglichen, müssen die implementierten Prozesse der ITSM-TI-Teilnehmer mindestens an den Schnittstellen nachvollziehbar sein. Des Weiteren müssen die vor- und nachgelagerten Prozesse hinsichtlich der Sicherstellung der Qualität dargestellt werden.

Die relevanten Auszüge aus dem Betriebshandbuch der ITSM-TI-Teilnehmer sollen hier die geeigneten Steuerungs- und Kontrollmöglichkeit bieten: initial im Zuge der Anbieterzulassung und im Bedarfsfall als Grundlage von anlassbezogenen Prozessprüfungen.

Um für die ITSM-TI-Teilnehmer Mehraufwand und die Offenbarung von möglichen Betriebsgeheimnissen zu vermeiden, können daher Auszüge aus den bestehenden Betriebshand-büchern bzw. providerspezifischen Betriebskonzepten nachgenutzt werden.

2.3 Reporting

Zur Unterstützung der strategischen und operativen Betriebsführung sowie zur Überwachung der Einhaltung von Vorgaben ist durch die ITSM-TI-Teilnehmer ein Reporting zu etablieren. In diesem Kapitel werden hierzu die übergreifenden Anforderungen sowie der inhaltliche Aufbau an das regelmäßige, konsolidierte Reporting sowie an das unregelmäßige Ad-hoc-Reporting beschrieben.

2.3.1 Konsolidiertes Reporting

Ziel des konsolidierten Reportings ist die Bereitstellung der relevanten Reporting-Inhalte in einem einheitlichen Verfahren sowie deren strukturierte Übermittlung an den SBV.

Der konsolidierte Report setzt sich aus insgesamt acht Einzelreports zusammen. Die Inhalte des Reports werden durch die in der folgenden Tabelle referenzierten Kapitel bzw. Dokumente definiert. Werden für einen Einzelreport keine Inhalte definiert, bzw. sind diese für den jeweiligen Produkttyp nicht relevant, muss der entsprechende Einzelreport nicht übermittelt werden.

Tabelle 2: Tab_Betr_TIP_025 Bestandteile des konsolidierten Reportings

Neben den inhaltlichen Aspekten, die primär in den jeweiligen ITSM-Prozessen bzw. -Prozesskapiteln geregelt werden, gelten für das konsolidierte Reporting, übergreifende Regelungen, die insbesondere die Struktur, die Reportingfrequenz, als auch die Übermittlung des konsolidierten Reports an den SBV regeln:

2.3.2 Ad-hoc Reporting

Neben der regelmäßigen Zusendung des konsolidierten Reportings kann der SBV Ad-hoc, also außerplanmäßige, Reports anfordern. Dabei kann der Servicebetriebsverantwortliche (SBV) oder der Gesamtverantwortliche der TI (GTI) auf den vorhandenen Vorgangsdaten-/Kennzahlenpool aus den Einzelreports des konsolidierten Reportings zurückgreifen oder andere Kennzahlen (innerhalb eines zumutbaren Umfangs für den ITSM-TI-Teilnehmer) abfragen. Entsteht die Notwendigkeit zur Erhebung weiterer Messgrößen, werden diese gemeinsam mit den betroffenen ITSM-TI-Teilnehmern individuell abgestimmt.

2.3.3 Service Level Requirements (SLR)

2.4 Auditierung von ITSM-TI-Teilnehmern

Es besteht die Notwendigkeit anlassbezogene Audits durchzuführen. Audits werden durchgeführt, wenn die Prozesskommunikation zwischen den am Betrieb beteiligten ITSM-TI-Teilnehmern nachhaltig gestört bzw. die Serviceerbringung gegenüber dem Anwender bzw. Versicherten gefährdet ist.

Die Audits dienen der Prüfung der korrekten Umsetzung der Richtlinien insbesondere mit dem Ziel Schnittstellen-/Prozessprobleme zwischen ITSM-TI-Teilnehmern zu identifizieren. Die Erkenntnisse der anlassbezogenen Audits können zur Optimierung der Richtlinien führen, um die Reibungsverluste im Zusammenspiel der ITSM-TI-Teilnehmer untereinander zu minimieren.

2.5 Konvention zur Übermittlung von Prozessdaten

Um doppelte Einträge im Worklog zu verhindern und damit die Entwicklung eines Ticketverlaufes möglichst einfach nachzuvollziehen, ist grundsätzlich zu empfehlen, ausschließlich die letzte Änderung des Worklogs aus dem lokalen ITSM-System in das übergreifende ITSM zu übermitteln.

Incident Management:

Tabelle 3: Tab_Betr_TIP_028 Übersicht Meldungstypen – Incident Management

Problem Management:

Tabelle 4: Tab_Betr_TIP_029 Übersicht Meldungstypen – Problem Management

Tabelle 5: Tab_Betr_TIP_049 reservierte Zeichen Ersetzungstabelle

2.5.1 Basisfeldtypen von Prozessdaten

Tabelle 6 definiert Basisfeldtypen, die in konkreten Definitionen fachlicher Tabellen referenziert werden. In der Definition der fachlichen Tabellen können diese Basisfeldtypen weiter durch Constraints konkretisiert werden, z. B. durch Einschränkung auf eine fachlich definierten Wertemenge.

Tabelle 6: Tab_Betr_TIP_030 Basisfeldtypen von CSV-Dateien

3 Service Level Management (SLM)

Mit Hilfe des Service Level Management (SLM) werden die Service Level über alle Betriebseinheiten definiert, kontrolliert und optimiert.

Ziele des übergreifenden SLM sind:

• die vereinbarten Service Level zu messen, um die Sicherstellung der aktuell vereinbarten (technischen und prozessualen) Qualität zu gewährleisten.
• die gemessenen Service Level zu analysieren und zu optimieren, um zukünftig die Sicherstellung der IT-Service-Qualität und Performance - möglichst effizient - zu gewährleisten.

Abbildung 1: SLM – Prozessausschnitt „Service Level Management“ veranschaulicht den für die ITSM-TI-Teilnehmer relevanten Prozessausschnitt.

Abbildung 1: SLM – Prozessausschnitt „Service Level Management“

3.1 Betrachtungsgegenstand des übergreifenden SLM

Grundlage und Arbeitsmittel für die Aufgabenwahrnehmung des Service Level Managements durch den SBV und den GTI sowie der damit verknüpften Zielerreichung ist der Service Level Report des konsolidierten Reportings (siehe Kapitel 2.3.1 „Konsolidiertes Reporting“).

Betrachtungsgegenstand des übergreifenden SLM sind daher die Regelungen, welche zum Reporting der Service Level im Rahmen des Service Level Reportings festzulegen sind.

3.2 Begriffserläuterungen

3.2.1 Service Level Requirements

Service Level Requirements enthalten die inhaltlichen, als auch schematischen Anforderungen (Qualitätsdimension, Beschreibung der Qualitätsdimension, Ausprägungstyp) für die durch ITSM-TI-Teilnehmer zu messenden Service Level.

Die in der Richtlinie definierten, durch ITSM-TI-Teilnehmer zu messenden Service Level Requirements werden im Betriebskonzept [gemKPT_Betr] ausgeprägt, mit Werten hinterlegt und bilden damit die vollständigen, durch ITSM-TI-Teilnehmer zu erreichenden Service Level ab.

Hinweis:

Die Service Level IDs wurden im Zuge der Weiterentwicklung der Betriebsdokumentation von ORS1 auf OPB optimiert: Eineindeutige Service Level IDs, die die prioritätsbestimmte Ausprägung der SL IDs berücksichtigen und die Tool Implementierung vereinfachen. Eine Referenztabelle der „ORS1 Service Level IDs“ zu den in OPB geltenden findet sich in Anhang C.

3.3 Grundsätze des übergreifenden SLM

Die nachfolgenden Grundsätze bilden die übergeordneten Regelungen des übergreifenden Service Level Managements für ITSM-TI-Teilnehmer.

3.3.1 Gliederung des SLM in Service Level Cluster

Innerhalb des Service Level Managements wird in drei verschiedene Service Level Cluster unterschieden:

• Service Level Performance - hierunter werden alle zu messenden technischen Kennzahlen (bspw. hinsichtlich Bearbeitungszeit, Durchsatz und Verfügbarkeit) zusammengefasst.

Dabei wird die Service Level Performance im Betriebskonzept [gemKPT_Betr] nach folgendem Schema gebildet:

Tabelle 7: Tab_Betr_TIP_023 SLM – Service Level "Performance"

• Service Level Prozess - hierunter werden alle prozessbezogen zu messenden Service Level Requirements der übergreifenden ITSM-Prozesse mit Fokus auf die Prozessqualität (bspw. Reaktionszeit) zusammengefasst.

In dem vorliegenden Dokument sind diese mit „Prozess“ gekennzeichneten SLRs

• für das Incident Management den Kapiteln 8.4.8 „Service Level Requirements (SLR)“ und 8.5.9 „Service Level Requirements (SLR)“ zu entnehmen,
• für das Problem Management den Kapiteln 9.4.8 „Service Level Requirements (SLR)“, 9.5.4 „Service Level Requirements (SLR)“ und 9.6.8 „Service Level Requirements (SLR)“ zu entnehmen,
• für das Change Management dem Kapitel 5.5 „Service Level Requirements (SLR)“ zu entnehmen.
• Service Level Serviceerbringung - hierunter werden alle qualitativen, servicebezogen zu messenden Service Level Requirements der übergreifenden ITSM-TI-Prozesse mit dem Schwerpunkt auf die Serviceerbringung (bspw. Rufbereitschaft) zusammengefasst.

In dem vorliegenden Dokument sind diese mit „Serviceerbringung“ gekennzeichneten SLRs

• für das konsolidierte Reporting dem Kapitel 2.3.3 „Service Level Requirements (SLR)“ zu entnehmen,
• für das Incident Management den Kapiteln 8.4.8 „Service Level Requirements (SLR)“ und 8.5.9 „Service Level Requirements (SLR)“ zu entnehmen,
• für das Problem Management den Kapiteln 9.4.8 „Service Level Requirements (SLR)“, 9.5.4 „Service Level Requirements (SLR)“ und 9.6.8 „Service Level Requirements (SLR)“ zu entnehmen,
• für das Performance Management dem Kapitel 4.3.4 „Service Level Requirements (SLR)“ zu entnehmen,
• für das Notfallmanagement dem Kapitel 10.5.8 „Service Level Requirements (SLR)“ zu entnehmen.

3.4 Prozessdurchführung übergreifendes SLM

Innerhalb der jeweiligen ITSM-Prozessbeschreibungen dieses Dokumentes sind, abhängig vom Prozess, verschiedene Service Level Requirements beschrieben, die durch den ITSM-TI-Teilnehmer zu messen, zu berichten und zu optimieren sind. Da die Service Level Requirements in diesem Dokument ausschließlich die schematischen Inhalte, als Grundlage der Service Level darstellen, werden diese im Betriebskonzept [gemKPT_Betr] mit Werten hinterlegt und bilden erst damit die vollständige Anforderung als Service Level.

Während des Wirkbetriebs werden diese spezifischen, durch ITSM-TI-Teilnehmer zu messenden und zu berichtenden Requirements durch den SV fortgeschrieben und gepflegt sowie deren Einhaltung durch den SBV überwacht.

3.4.1 Messung der Service Level

3.4.2 Bereitstellung des Service Level Reports

Für die Webportal-nutzenden Teilnehmer wird der Service Level Report (Prozess und Serviceerbringung) über die ZID zur Verfügung gestellt.

3.4.3 Service Review

Service Reviews werden zur Feststellung von notwendigen Optimierungsaktivitäten -sowohl auf Ebene der Vorgaben als auch auf Ebene der Umsetzung - durchgeführt. Service Reviews erfolgen bei Bedarf und werden durch den SBV einberufen. Die Art der Durchführung des Service Reviews wird durch den SBV festgelegt (bspw. Telefonkonferenz, E-Mail). Präsenztermine für ITSM-TI-Teilnehmer werden durch den SBV, soweit möglich, vermieden und nur einberufen, sofern eine Notwendigkeit hierfür besteht.

ITSM-TI-Teilnehmer, die Optimierungsaktivitäten eigenverantwortlich definiert haben, erfassen diese im Service Level Report.

Sollten die im Service Review zwischen ITSM-TI-Teilnehmer und SBV vereinbarten Optimierungen keinen belastbaren Erfolg zeigen, so steht dem SBV als weitere Option die Durchführung von Audits (außer Anbieter Fachdienste VSDM und Anbieter TSP eGK) offen. Damit sollen erkannte prozessuale Defizite – insbesondere in den Prozessen INC, PRO und CHG – sowie technische Defizite (Performance Zielwerte der von Anbietern verantworteten TI-Produkte) beseitigt werden.

4 Performance Management (PERF)

Das Performance Management fasst die ITIL-Prozesse „Capacity Management“ und „Availability Management“ zusammen. Dabei hat das Performance Management zum Ziel, adäquate Kapazitäten und die geforderten Verfügbarkeiten für die TI zu gewährleisten.

Um dieses Ziel zu unterstützen, müssen ITSM-TI-Teilnehmer Performance-Messungen durchführen und diese an die zuständige servicebetriebsverantwortliche Instanz berichten. Die entsprechenden Analysen und Optimierungen im Design werden durch den SBV initiiert bzw. vorgenommen. Interne Optimierungsmaßnahmen der ITSM-TI-Teilnehmer sind nicht Bestandteil der Richtlinie und werden vorausgesetzt.

Dieses Kapitel enthält ausschließlich Anforderungen an Anbieter von zentralen Produkten der TI.

Abbildung 2: PERF – Gesamtüberblick „Performance Management“ veranschaulicht den ITSM-TI-Teilnehmer- relevanten Prozessausschnitt und gibt eine Zuordnung der einzelnen Prozessinhalte zu den nachfolgenden Kapiteln.

Abbildung 2: PERF – Gesamtüberblick „Performance Management“

4.1 Betrachtungsgegenstand des übergreifenden PERF

Fokus der nachfolgenden Performance-Management-Regelungen im übergreifenden Betrieb sind die durch die Anbieter durchzuführenden Performance-Messungen und das dazugehörige Reporting an die servicebetriebsverantwortliche Instanz. Die Performance-Messungen der dezentralen Produkte werden nicht betrachtet.

4.2 Begriffserläuterungen

4.2.1 Performance

Die Performance umfasst gemäß [gemSpec_Perf] die Dimensionen Bearbeitungszeit, Durchsatz und Verfügbarkeit.

4.3 Prozessdurchführung des übergreifenden PERF

Zur Sicherung der notwendigen Leistungen und Kapazitäten in der geforderten Verfügbarkeit, zur rechtzeitigen Einleitung von notwendigen Schritten zur Leistungsanpassung sowie zur Vermeidung von Überkapazitäten in der TI müssen Anbieter Performance-Messungen durchführen und die Ergebnisse berichten.

Die Messergebnisse dienen dabei

• im ersten Schritt der Analyse der aktuellen Performance sowie der Prognoseerstellung für zukünftige Performance-Anforderungen der Anwendungsservices und des TI-Plattform Services und
• im zweiten Schritt der - falls erforderlich - Anpassung der Kapazität, um Überkapazitäten oder bestehende bzw. drohende Engpässe zu kompensieren und die vereinbarten Service Level aufrechterhalten zu können.

4.3.1 Messung der Performance

Die Messungen erfolgen innerhalb der lokalen Systeme und Prozesse des Anbieters und müssen die Vorgaben (bspw. Messvorschriften) gemäß [gemSpec_Perf] für die Messung der Performance einhalten.

4.3.2 Bereitstellung des Performance Reports

4.3.3 Bereitstellung von Ad-hoc Performance Reports

4.3.4 Service Level Requirements (SLR)

5 Change & Release Management (CHG & RLM)

Der Changeprozess gilt unter dem Vorbehalt notwendiger Anpassungen aus Erkenntnissen der Erprobung ORS1.

Das Release Management hat die Überführung von Releases in den Wirkbetrieb zur Aufgabe. Es koordiniert die Entwicklung, den Test, die Verifikation sowie das Deployment der durch das Service Design definierten und geplanten Funktionen. Das Release Management stellt sicher, dass ein Release ausschließlich aus zugelassenen sowie aus einem Satz zu einander kompatibler Konfigurationseinheiten besteht.

Das Change Management hat die Aufgabe sicherzustellen, dass alle Änderungen an Produkten und den darauf basierenden Services kontrolliert durchgeführt werden. Innerhalb des Change Managements werden Änderungsanträge (Requests for Change) aufgezeichnet, bewertet sowie autorisiert und die daraus resultierenden Umsetzungen als Änderungsanforderungen (Change) koordiniert.

Da ein Release im Kontext der TI aus einer Vielzahl von Changes besteht, sind beide ITSM-Prozesse eng miteinander verzahnt und werden innerhalb dieses Dokumentes integrativ beschrieben. Die nachfolgende Abbildung veranschaulicht hierzu Regelungen des übergreifenden Change & Release Managements und verdeutlicht den für Anbieter relevanten Prozessausschnitt.

Abbildung 3: CHG & RM – Gesamtkontext "Change & Release Management"

5.1 Betrachtungsgegenstand des übergreifenden CHG & RLM

In diesem Abschnitt wird das übergreifende Change Management für Produkte sowie die im Change Management Prozess enthaltenen Übergabepunkte zum und vom Release Management der Produkte geregelt.

Das Change & Release Management der anderen Level (TI, Service, Produkttyp) wird innerhalb dieser Richtlinie nur insoweit dargestellt, wie es zur Einordnung des Produkt-Levels in den Gesamtkontext notwendig ist.

Das „lokale“ Release Management der Produkte in Verantwortung der Anbieter wird in dieser Richtlinie nur insofern geregelt, wie es zur Sicherstellung der ordnungsgemäßen Umsetzung des Change & Release Managements notwendig ist.

Nicht weiter betrachtet wird das Release Management der TI in Verantwortung des GTI.

5.2 Begriffserläuterungen

Die Begriffe RfC (Request for Change), Change Request und Änderungsantrag werden synonym verwendet.

Die Begriffe Change und Änderungsanforderung werden synonym verwendet.

Korrigierender Change: Bei einem korrigierenden Change handelt es sich um Korrekturänderungen der TI bzw. des Services bzw. des Produkttyps bzw. des Produktes.

Erweiterungs-Change: Bei einem Erweiterungs-Change handelt es sich um ergänzende Änderungen der TI bzw. des Services bzw. des Produkttyps bzw. des Produktes.

Übergreifender Change- und Releasekalender: Der Change- und Releasekalender ist Bestandteil der betriebsunterstützenden Verfahren und Systeme der Telematikinfrastruktur.

Der Change- und Releasekalender dient allen am Betrieb der TI Beteiligten dazu, sich über anstehende und durchgeführte Änderungen und Releasewechsel informieren zu können. Er ist zugleich ein Organisations- und Planungsinstrument im Rahmen des Change & Release Managements. Er ersetzt nicht die aktive Steuerung von Changes und Releasewechseln in der TI, sondern ermöglicht eine langfristige Vorschau auf geplante Änderungen und ist ein zusätzliches Hilfsmittel bei der Analyse von Störungsursachen bezüglich der Identifikation von Seiteneffekten bereits umgesetzter Änderungen.

Anbieter können bspw. zur erneuten Verifikation von Change- und Releaseplanungen oder zur Analyse von Störungsursachen den Change- und Releasekalender nutzen.

Change Advisory Board (CAB): Gremium, bestehend allen relevanten Interessensvertretern, die von der Durchführung eines konkreten Changes betroffen sind (RfC Ersteller, Change Durchführer, vom Change betroffene andere produktverantwortliche Anbieter, gematik Rollen). Aufgabe des CAB ist die gemeinsame Bewertung durch die „change stakeholder“ und die folgende Autorisierung oder Ablehnung eines Changes durch den SBV.

Emergency Change Advisory Board (eCAB): Stand-by Organisationsform des CAB, organisiert durch die Rollen GTI und SBV. Ziel und Aufgabe des eCAB besteht darin, bei auftretenden Anforderungen zur Durchführung eines Notfall Changes (Emergency Change) eine Bewertung und Autorisierung / Ablehnung herbeizuführen.

Change Level: Differenzierung des Changes nach Objekt und Umfang des Changes. Folgende Change Level sind festgelegt:

Tabelle 11: Tab_Betr_TIP_044 CHG – Change Level

Im Kapitel „5.4 Prozessdurchführung übergreifendes CHG“ erfolgt eine Darstellung zur Durchführung von Produkt Changes (Change Level 1). Eine Präzisierung zur Behandlung der weiteren Change Level (2, 3 und 4) sowie zum Release Management erfolgt in einer späteren Version dieses Dokuments.

Lokaler Change: Änderung, die nach erfolgter Vorprüfung durch den Anbieter keine erwarteten Wechselwirkungen mit anderen Produkten der TI hat und im lokalen Change Management des Anbieters durchgeführt werden kann. Eine Autorisierung durch den SBV ist für die Change Durchführung nicht erforderlich.

Ein Change kann als lokaler Change durchgeführt werden, wenn:

1. Vereinbarte Service Level durch den Change nicht verletzt werden
2. Geltende Produkttypspezifikationen durch den Change nicht berührt werden
3. Der Change lokal auf das Produkt oder eine Produktinstanz begrenzt ist.

Weitere Ausführungen zur Durchführung von lokalen Produkt Changes finden sich im Kap. 5.4.2 und Kap. 5.4.3.

Übergreifender Change: Änderung, die nach erfolgter Vorprüfung durch den Anbieter oder durch den SBV mögliche Auswirkungen auf die Produkttypspezifikation und/oder erwartete Wechselwirkungen mit anderen Produkten der TI haben kann und unter Kontrolle des übergreifenden Change Managements der TI durchgeführt werden muss. Übergreifende Changes sind genehmigungspflichtig, d.h. eine Autorisierung durch den SBV ist für die Change-Durchführung erforderlich.

Weitere Ausführungen zur Durchführung von übergreifenden Produkt Changes finden sich im Kap. 5.4.4 ff.

Change Dringlichkeit (Urgency): Bewertung der erforderlichen Dringlichkeit bei Umsetzung eines Changes. Dies ist insbesondere bei fehlerkorrigierenden Changes notwendig.

Tabelle 12: Tab_Betr_TIP_045 CHG – Change Dringlichkeit

Change Kategorie: Die Beschreibung der möglichen Auswirkungen und des daher erforderlichen Risikomanagements erfolgt durch den Begriff „Kategorie“; diese betrachtet Umfang, Komplexität und Schwere eines Changes.

„Kategorie“ bestimmt damit die möglichen Auswirkungen, die die Durchführung eines Changes auf die Geschäftsprozesse der TI-Anwender haben kann, betrachtet also das damit verbundene Risiko.

Tabelle 13: Tab_Betr_TIP_046 CHG – Festlegung von Change Kategorie und Auswirkung

Emergency Change (Notfall Change): Ein Change, der so bald wie möglich umgesetzt werden muss, um auf eine Notsituation angemessen reagieren zu können. Übergeordnetes Ziel ist, größeren Schaden zu vermeiden oder zu beheben, beispielsweise um einen Major Incident zu lösen oder um eine kritische Sicherheitslücke durch ein Sicherheits-Patch zu schließen.

Tabelle 14: Tab_Betr_TIP_048 CHG – Kriterien für Emergency Changes

Die Anwendung der hier beschriebenen Change Parameter (lokal, übergreifend, Dringlichkeit, Change Kategorie, Emergency Change) für die Durchführung von Produkt- Changes wird im Kapitel „5.4 Prozessdurchführung übergreifendes CHG“ beschrieben.

5.3 Prozessdurchführung übergreifendes RLM

In einem Release werden unterschiedliche Services zu einem TI-Release bzw. unterschiedliche Produkttypen und Produkte zu einem Service-Release zusammengefasst, die zum gleichen Releasetermin im Rahmen eines einheitlichen Releaseprozesses produktiv gesetzt werden.

Der Begriff Release ist in diesem Zusammenhang im Sinne eines Containers zu verstehen, der die einzelnen Service-, Produkttyp- oder Produktversionen enthält. Das übergreifende Release Management erfolgt auf den Ebenen:

• Release Management der TI,
• Release Management der TI-Services,
• Release Management der Produkttypen,
• Release Management der Produkte.

Auf der Ebene der Services und Produkttypen wird ein Release in der Regel mehrere Änderungen beinhalten. Auf Ebene der Produkte kann ein Release bereits aus einer Änderung bestehen.

Jede dieser Ebenen prägt ihr eigenes Release Management aus, so dass Umfang, Aufgaben, Stakeholder und Betroffene je nach Gegenstand der Releases variieren.

Release Management der TI:

Das Release Management der TI verantwortet die strategische Releaseplanung für die TI. Auf dieser Ebene steht der Planungsaspekt im Vordergrund, der Funktionsumfang eines TI-Releases wird vereinbart und die Bereitstellung sowie Implementierung wird mit den Stakeholdern abgestimmt. Die Planung der TI-Releases legt den zeitlichen Rahmen und die Termine für die Ebene Release Management der TI-Services fest. Diese Termine werden im Change- und Releasekalender dokumentiert. Der Test und die Überführung der TI-Releases in den Wirkbetrieb werden in enger Kooperation mit der Ebene Release Management der TI-Services durchgeführt. Verantwortlich für das Release Management der TI ist der GTI.

Beispiel für TI-Release: Das ORS1-Release als Gesamtmenge aller bereitzustellenden Anwendungs- und Basisservices auf Basis der Produkttyp-Spezifikationen und den realisierten, implementierten und zugelassenen Produkten im Wirkbetrieb, mit dem dazugehörigen und freigegebenen Dokumentenset. Ein Release Label zu diesem TI-Release ist derzeit noch nicht festgelegt.

Da das Release Management der TI ausschließlich durch den GTI durchgeführt wird, wird es in dieser Richtlinie nicht weiter betrachtet.

Release Management der TI-Services:

Auf der Ebene des Release Managements der TI-Services planen und koordinieren die serviceverantwortlichen Instanzen (Rolle SV) die Bereitstellung, den Test und die Überführung von Service Releases und Produkttyp-Changes in den Wirkbetrieb.

Der SV wird während der Anpassung der Produkttypen - bei Bedarf - bei Anbietern und Herstellern eine Befragung zum geplanten Produkttyp-Change durchführen. Die Befragung wird sich insbesondere auf die Kriterien Machbarkeit (inkl. Kompatibilität) und Kostenwirkung (inkl. Migrationsaufwand) fokussieren.

Beispiel für TI-Service-Release: Das Release des Anwendungsservices VSDM als Gesamtmenge aller auf Basis der Produkttyp-Spezifikationen zugelassenen Produkte, die genau den Anwendungsservice VSDM bilden. Die zugelassenen Produkte sind als Produktinstanzen im Wirkbetrieb implementiert, mit dem dazugehörigen und freigegebenen Dokumentenset. Das Release Label zu diesem TI-Service-Release ist derzeit noch nicht festgelegt.

Release Management der Produkte:

Das operative Release Management der Produkte verantworten die ITSM-TI-Teilnehmer auf Grundlage ihrer Produktverantwortung. Die Entwicklung der Produkte, ihr Test und die Überführung der Produktinstanzen in den Wirkbetrieb müssen die Produkttyp-Spezifikationen, die Vorgaben aus dem übergeordneten TI-Service Release sowie die Änderungsaufträge aus dem Change Management beachten.

Beispiel für Produkt-Release: Die fertige, veröffentlichte und zugelassene Version eines Produktes eines Anbieters wird als Produkt-Release bezeichnet. Beispiele für zugelassene Produkt-Releases finden sich auf der Homepage der Zulassungsstelle der gematik.

5.4 Prozessdurchführung übergreifendes CHG

Abbildung 4: CHG – Gesamtüberblick „Change Management der Produkte“

Im Rahmen des übergreifenden Change Managements verantworten die Anbieter auf Grundlage ihrer Produktverantwortung (in Abstimmung mit dem SBV) das Change Management der Produkte.

Alle Produktänderungen werden

• durch das lokale Change Management des Anbieters koordiniert und
• innerhalb des lokalen Change Managements des Anbieters umgesetzt.

Innerhalb des übergreifenden Change Managements wird dabei grundsätzlich in zwei Produkt-Change-Typen unterschieden:

• in lokal autorisierte Changes (informationspflichtig im Rahmen des Configuration Managements)
• und in genehmigungspflichtige Changes.

Die Entscheidung, um welchen Change Typ es sich handelt, muss innerhalb der Vorprüfung des Produktänderungsbedarfs (siehe Kapitel 5.4.2) erfolgen.

Sofern nicht anders ausgewiesen, werden nachfolgend die für Anbieter relevanten Regelungen zur Identifikation des Change Typs sowie des Prozessablaufs für genehmigungspflichtige Produkt Changes dargelegt. Im vorliegenden Dokument werden Changes zentraler Produkte, verantwortet von Anbietern, behandelt. Eine Präzisierung der Changes dezentraler Produkte erfolgt in einer späteren Version.

Eine Übersicht aller RfCs und deren Status wird in einem FSC (Forward Schedule of Change) über die Wissensdatenbank zur Verfügung gestellt. Weiterhin werden RfCs abhängig von ihrem Status im CAB (Change Advisory Board) besprochen.

Ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt

Die Kommunikation und der Informationsaustausch zur Durchführung des Change-Prozesses erfolgt aus Gründen der Flexibilität sowie aufgrund der individuellen Ausprägungsmöglichkeiten je Produkt-RfC bzw. Change-Durchlauf weitgehend per E-Mail, aber auch telefonisch, in Form von Telefonkonferenzen oder auch durch Besprechungen vor Ort. Die im Folgenden aufgeführten Anforderungen hinsichtlich der Übermittlung von Informationen der Anbieter an den SBV erfolgen dabei grundsätzlich per E-Mail, es sei denn, es werden nähere Angaben für das zu wählende Kommunikationsmedium gemacht.

Jeder übergreifende Produkt-RfC bzw. Produkt-Change wird in formaler Form in der ZID gespeichert. Speicherung und Statusänderungen des Produkt-RfCs bzw. des Produkt-Changes werden durch den SBV vorgenommen.

Mit dieser Regelung wird eine verlässliche Erreichbarkeit der Anbieter im übergreifenden Change Management erzielt. Benannte Mitarbeiter der bezeichneten Benutzergruppe sind berechtigt, für den jeweiligen Anbieter change-relevante Entscheidungen zu treffen, z.B. in der Abstimmung zur Autorisierung eines RfCs. Weitere Details zu CHG-Benutzergruppe und Funktionspostfach finden sich in der WDB.

Anbieter haben über das zur Verfügung gestellte Webportal der ZID die Möglichkeit, diejenigen Produkt-RfCs bzw. Changes einzusehen, an denen sie beteiligt sind. Ein Rollen- und Berechtigungskonzept der ZID regelt dabei die Einsichtnahme und den Zugriff auf die relevanten Datensätze. Des Weiteren wird den Anbietern im Webportal der ZID die Möglichkeit eröffnet, alle in diesen Richtlinien angegebenen formalen Informationen und Prozessschritte, welche die Kommunikation mit dem SBV berühren (z. B. Beantragung eines Produkt-RfCs, Autorisierung des Produkt-RfCs, Vorgangsdaten zu Produkt-Changes speichern), direkt über das Webportal der ZID vorzunehmen. Die Erläuterungen erfolgen in den jeweiligen Abschnitten.

Die im Folgenden definierten Dokumentations- und Übermittlungspflichten der am jeweiligen Produkt-RfC bzw. Produkt-Change beteiligten Anbieter obliegen weiterhin ausschließlich diesen selbst.

5.4.1 Eigeninitiierten Produktänderungsbedarf feststellen

Eigeninitiierte Produktänderungsbedarfe können durch verschiedene Einflussfaktoren bei den Anbietern festgestellt werden (bspw. Korrekturbedarfe aus dem lokalen/übergreifenden Incident Management oder Problem Management, oder auch Ergänzungsbedarfe des Produktes, die der Anbieter festgestellt hat).

An die Feststellung von Produktänderungsbedarfen innerhalb der lokalen Change-Prozesse des Anbieters werden keine Anforderungen gestellt.

5.4.2 Vorprüfung durchführen

Sofern es sich um einen genehmigungspflichtigen Produktänderungsantrag handelt, müssen Anbieter einen Produkt-RfC gemäß den Anforderungen in Kapitel 5.4.4 aufzeichnen.

Sofern es sich um einen lokal autorisierten Änderungsantrag handelt, erfolgt die weiterführende Bearbeitung - ohne weitere Genehmigung durch den SBV - im lokalen Change Management des Anbieters (siehe Kapitel 5.4.3).

5.4.3 lokalen Produkt-Change durchführen & abschließen

An das Management lokal autorisierter Produkt-Changes (s. Tabelle 15: Tab_Betr_TIP_024 CHG – Vorprüfung lokal./genehmig. Produktänderungsbedarf) werden keine Anforderungen gestellt. Der zuständige SBV ist nach Durchführung des lokal autorisierten Changes zu informieren.

5.4.4 Eigeninitiierten Produkt-RfC aufzeichnen

Der SBV wird den Erhalt des vom Anbieter versendeten Produkt RfC quittieren, eine über alle Anbieter eindeutige ID vergeben, an den Antragsteller zurückmelden. Im Falle des per Formular (d. h. per E-Mail) übermittelten Produkt-RfC trägt der SBV diesen gemäß den Angaben des Anbieters vor der Quittierung in das Webportal der ZID ein. Der SBV wird dann den Produkt-RfC in angemessener Zeit formal und inhaltlich prüfen (insbesondere auf Vollständigkeit, Durchführbarkeit und Redundanz mit bereits angenommenen, aktuell zu prüfenden und abgelehnten Produkt RfCs).

Bei Zustimmung wird der SBV den Produkt-RfC zur Bewertung freigeben. Die Freigabe erfolgt durch den SBV im Webportal der ZID. Der SBV wird daraufhin dem Anbieter die Freigabe des Produkt-RfC zur Bewertung per E-Mail mitteilen.

Bei Ablehnung (Stornierung) (bspw. wegen Nichtdurchführbarkeit) des Produkt-RfCs wird der SBV dies dem Anbieter unter Angabe von Gründen mitteilen. Die Ablehnung wird formal vom SBV in der ZID dokumentiert.

5.4.5 Produkt-RfC registrieren

Ein Produktänderungsbedarf kann ebenso vom SBV festgestellt werden (bspw. durch Änderungen an der Produkttypspezifikation). Der SBV registriert den Produkt-RfC in der ZID und übermittelt ihn per E-Mail an den bzw. die von ihm ausgewählten Anbieter , verbunden mit der Aufforderung zur inhaltlichen Prüfung. Der Produkt-RfC ist damit noch nicht zur Bewertung freigegeben. Erst nach positiver inhaltlicher Prüfung und Rückmeldung durch den Anbieter kann der Produkt-RfC durch den SBV zur Bewertung freigegeben werden.

5.4.6 Produkt-RfC bewerten & autorisieren

Sowohl vom Anbieter aufgezeichnete, genehmigungspflichtige Produkt-RfCs (die vom SBV zur Bewertung freigegeben wurden), als auch vom SBV an Anbieter übermittelte Produkt-RfCs werden durch betroffene Anbieter sowie dem SBV bewertet werden. Die Autorisierung des genehmigungspflichtigen Produkt-RfC erfolgt im Konsens zwischen dem realisierenden Anbieter und dem zuständigen SBV. Der SBV hat sich die für die Autorisierung notwendigen Genehmigungen des SV und GTI vor der Autorisierung einzuholen.

Übergreifende Ziele der gemeinsamen Bewertung sind:

• finale Schärfung/Konkretisierung/Feststellung der Produkt-RfC-Inhalte, insbesondere zu Zeitraumplanung, Ressourcenaufwand & -planung, Kosten, Machbarkeit, Nutzen, Priorität, Risiken, Backout-/Fehlerkorrekturplan, Zulassungsrelevanz (inkl. relevanter Testverfahren, Testumgebungen & Testmanagement), Zuordnung zum Produktrelease bzw. TI-Service-Release
• sowie Festlegung der Verbindlichkeit von Termin- und Umsetzungszusagen.

Sollten Anbieter mit dem SBV keine Einigung bei der Bewertung erzielen können, besteht die Möglichkeit der Eskalation an den GTI (siehe Kapitel 5.8 Eskalationen).

Die Durchführung der Bewertung kann mittels der Einberufung eines CAB (Change Advisory Board) erfolgen. Die Form und die zeitlichen Intervalle des CAB werden durch den SBV festgelegt (bspw. Telefonkonferenz, E-Mail-Verteiler). Präsenztermine für Anbieter werden durch den SBV, soweit möglich, vermieden und nur einberufen, sofern eine Notwendigkeit hierfür besteht oder die Mehrheit der im CAB beteiligten Anbieter dieses wünschen.

Ist die Bewertung des Produkt-RfCs durch Anbieter und SBV inhaltlich abgeschlossen, müssen die am Produkt-RfC beteiligten Rollen (Anbieter und SBV) eine Autorisierung (Freizeichnung) des Produkt-RfCs vornehmen.

Die Autorisierung durch die Anbieter erfolgt per E-Mail an den SBV oder mittels eines im Webportal der ZID bereitgestellten Autorisierungsvorgangs. Erfolgt die Autorisierung per E-Mail an den SBV, nimmt der SBV - nach Erhalt der Autorisierung des betroffenen Anbieters - die Autorisierung für diesen formal im Webportal der ZID vor.

Vor der Change-Umsetzung muss der Produkt-RfC sowohl vom SBV als auch vom Anbieter formal autorisiert sein.

Ab diesem Zeitpunkt ist der Produkt-RfC als Produkt-Change freigegeben - die ID des Produkt-RfCs wird zur ID des Produkt-Changes. Der SBV informiert die Anbieter per E-Mail über die vollständig abgeschlossene Autorisierung.

5.4.7 Produkt-Change umsetzen

Die Umsetzung eines autorisierten Produkt-Changes wird bis zum erfolgten Abschluss (oder Abbruch der Umsetzung) übergreifend durch den SBV koordiniert.

Die für den Vorgangsdatenreport erforderlichen Dokumentationspflichten (siehe Kap. 5.9 Prozessreporting (Vorgangsdaten) CHG) können vom Anbieter auch im Webportal der ZID vorgenommen werden. In diesem Fall kann die Übermittlungspflicht an den SBV - bei entsprechend vorgenommener Dokumentation - im Webportal der ZID ausgeführt werden.

Bei einer festgestellten Abweichung des dem aktuellen Produkt-Change zugrunde liegenden Produkt-RfCs wird der SBV entscheiden müssen, welche Konsequenzen die Feststellung bzw. Abweichung auf die weitere Durchführung des Produkt-Changes hat und welche Maßnahmen zu treffen sind. Dazu wird sich der SBV bei Bedarf mit den beteiligten Anbietern (und dem GTI) beraten. Die Ergebnisse werden vom SBV in der ZID dokumentiert, ebenso wie eine eventuelle Status-Änderung des Produkt-Changes (bspw. Stornierung). Die Anbieter werden vom SBV hierüber abschließend per E-Mail informiert.

Die Umsetzung des Produkt-Changes setzt sich im Wesentlichen aus den nachfolgenden vier Prozessschritten zusammen. Die einzelnen Prozessschritte entsprechen dabei dem jeweiligen Status, den ein Produkt-Change im Zuge der Umsetzungsphase annehmen kann.

Die formale Änderung des Status eines Produkt-Changes wird vom SBV in der ZID vorgenommen und von ihm entsprechend an die beteiligten Anbieter per E-Mail kommuniziert. Einem Statuswechsel geht dabei eine übereinstimmende Einschätzung des aktuellen Sachstandes der Beteiligten voraus. Eine formale Autorisierung des SBV zur Änderung eines Status (z. B. durch die beteiligten Anbieter ) erfolgt nicht.

Eine Übersicht der bei der Durchführung eines Produkt Changes zu durchlaufenden Phasen, Statusübergänge sowie der jeweiligen Bedingungen hierfür findet sich in Kapitel 5.4.9 „Produkt-Change: Phasen und Statusübergänge“.

1. Produkt-Change planen

Zur Umsetzung von mehreren Changes an einem Produkt können Anbieter genehmigte Produkt Changes an einem Produkt zu einem Produkt-Release bündeln. Diese Produkt-Releases können auch lokal autorisierte Produkt Changes enthalten, die Anbieter eigenständig initiiert haben.

Weiterhin ist während der Bewertung des autorisierten Produkt-RfCs eine Grobplanung für die Umsetzung entwickelt worden. Diese ist durch den Anbieter innerhalb dieser Phase weiter zu konkretisieren, stetig zu aktualisieren und bei Bedarf dem SBV zur Verfügung zu stellen.

1. Produkt-Change entwickeln

Die Testumgebung wird hinsichtlich der Nutzung durch die testdurchführende Instanz (siehe Testkonzept) koordiniert. Der SBV stimmt sich mit der testdurchführenden Instanz ab.

1. Produkt-Change testen

Der Abschluss des Tests ist erfolgt, wenn der Anbieter das Produkt (Produkt- Release) in den jeweiligen Umgebungen getestet hat und durch die testkoordinierende Instanz des SBV der Einsatz in der Produktivumgebung freigegeben wurde.

1. Produkt-Change einführen

Das Deployment eines Produkt-Changes wird durch den SBV zeitlich und verfahrenstechnisch koordiniert. Anbieter müssen das Deployment des Produkt-Changes gemäß den Vorgaben vom SBV durchführen und stetig deren Einhaltung prüfen.

Das Deployment zentraler Produkte ist die Inbetriebnahme in der Produktivumgebung.

Vom SBV genehmigte Wartungsfenster werden von der Verfügbarkeitsberechnung des betroffenen Produkts ausgenommen. Bei genehmigungspflichtigen Änderungen wird die Koordination der Wartungsfenster im Rahmen der Planung und Umsetzung des Changes durch den SBV vorgenommen.

Produkt-Change-Umsetzung abbrechen

Ein genehmigungspflichtiger Produkt-Change kann ausschließlich durch den SBV abgebrochen werden (bspw. durch im Nachgang festgestellte Fehlannahmen im Produkt RfC).

Der SBV bricht dabei formal den Produkt-Change in der ZID ab, durch Setzen des Feldes „Status“ auf „Abgebrochen“. Die beteiligten Anbieter werden daraufhin durch den SBV in formalisierter Form über den Abbruch eines Produkt-Changes per E-Mail benachrichtigt.

5.4.8 Produkt-Change abschließen

5.4.9 Produkt-Change: Phasen und Statusübergänge

Die Umsetzung eines Produkt-Changes findet in definierten Phasen statt. Jede Phase hat spezifische Inhalte, deren Umsetzung mit einem Status gekennzeichnet wird.

Dieser Status, die damit erreichten Ergebnisse sowie die verantwortliche Durchführung der Phasen sind in nachfolgender Tabelle dargestellt.

Der zutreffende Status wird formal vom SBV gesetzt, basierend auf den von den Anbietern gelieferten Informationen und den in der jeweiligen Phase erfolgten Abstimmungen zwischen allen Beteiligten der Change Umsetzung.

Tabelle 16: Tab_Betr_TIP_49 CHG – Phasen im Produkt-Change und Statusübergänge

Folgende Grafik bietet eine Übersicht zu den Phasen und Statusübergängen:

Abbildung 5: CHG – Bearbeitungsstatus: Phasen und Statusübergänge

5.4.10 Produkt-Change: Behandlung von Standard Changes

Um eine effiziente Durchführung von unkritischen, zeitlich gut planbaren und wiederholt durchzuführenden „Routine“ Produkt-Changes nicht durch unnötigen Aufwand zu behindern, können derartige Changes als „Standard Changes“ durchgeführt werden. Für diese Change Kategorie gelten die Klassifikationen gemäß „Tab_Betr_TIP_046 CHG – Festlegung von Change Kategorie und Auswirkung“.

Beispiele für Produkt-Changes, die als „Standard Change“ einzustufen wären:

Zyklisches Wartungsfenster

• Wartungsfenster werden vom Anbieter angekündigt und in der Nebenzeit, mit Unterbrechung des Services ausgeführt. Der Inhalt der Arbeiten wird kommuniziert, z.B. Patchen, Upgrades etc., die Ausführungszeit wird festgelegt, der Change wird als Standard eingestuft.

Geplante Arbeiten von 3rd Parties, z.B. dem WAN Provider

• Arbeiten von Netzbetreibern werden in der Regel langfristig angekündigt. Diese Changes können als Standard Changes eingestuft und über den Change- und Release Kalender angekündigt werden.

5.4.11 Produkt-Change: Durchführung von Emergency Changes

Ein Emergency Change ist eine Änderung, die aufgrund einer Notsituation durchgeführt werden muss, um so schnell wie möglich diese Situation zu lindern. Emergency Changes können in folgenden beispielhaften Situationen erforderlich werden:

• Nichtverfügbarkeit eines zentralen Plattformdienstes, die höchste Auswirkung für die TI hat („Major Incident“).
• 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 („emergency security patch“).

Die Dringlichkeit der notwendigen Korrektur lässt unter Umständen kein üblicherweise erforderliches Testen zu; die sofortige Heilung der Notsituation ist das primäre Ziel. Das damit einhergehende Risiko wird bewusst in Kauf genommen.

Für die kontrollierte Durchführung von Emergency Changes wird ein Entscheidungsgremium, das Emergency Change Advisory Board (eCAB) implementiert, das den SBV bei der Bewertung von auftretenden Emergency Changes wirksam unterstützt.

Bei der Bewältigung eines TI-Notfalls durch Emergency Changes sind die Anforderungen des Notfallmanagements zu beachten.

Die Meldung eines notwendigen Emergency Changes durch Anbieter kann telefonisch erfolgen. Die weitere Bewertung und Freigabe / Ablehnung durch den SBV kann ebenfalls auf diesem Wege stattfinden.

Sollte – bedingt durch Nichterreichbarkeit des SBV außerhalb der ITSM Service Zeit der gematik – keine Entscheidungsfindung zur Durchführung des Emergency Changes möglich sein, gilt folgende Regelung:

5.5 Service Level Requirements (SLR)

Die SLR-Berichtsdaten können von Anbietern im Webportal der ZID generiert und zur Erstellung exportiert werden. Voraussetzung hierzu ist, dass die Rückmeldung der Anbieter auf Bewertungsanfragen des SBV durchgängig im Webportal der ZID erfolgen.

5.6 Informationspflichten

5.7 Dokumentation

Die Dokumentation des Change Managements dient insbesondere der Steuerung und der Schaffung der Nachvollziehbarkeit von Produkt-Changes.

Für die ordnungsgemäße Umsetzung der Dokumentation ist ausschließlich der Anbieter verantwortlich.

Die in der Umsetzungsphase des Produkt-Changes seitens der Anbieter bestehende Dokumentationspflicht kann, soweit sie die für den Vorgangsdatenreport erforderlichen Daten betrifft (siehe Kap. 5.9), vom Anbieter im Webportal der ZID vorgenommen werden. In diesem Fall kann die Übermittlungspflicht an den SBV – bei entsprechend vorgenommener Dokumentation – im Webportal der ZID ausgeführt werden.

Die darüber hinausgehende Dokumentation (Projektpläne, Entwicklungsdaten, Testergebnisse, Logfiles etc.) erfolgt weiterhin Anbieter- -intern, die Kommunikation dieser Daten oder Dokumente erfolgt in der Regel außerhalb der ZID.

Ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.

5.8 Eskalationen

5.9 Prozessreporting (Vorgangsdaten) CHG

Das Prozessreporting dient voranging der Übermittlung des aktuellen Status zu einem Produkt-Change.

Ist der Status des Produkt-Changes innerhalb der Vorgangsdaten des Prozessreportings auf „abgeschlossen“ gesetzt worden, muss der Produkt-Change damit letztmalig innerhalb des konsolidierten Reports berichtet werden und wird nicht mehr in Folgereports erwähnt.

Werden vom Anbieter die für das Prozessreporting erforderlichen Daten lückenlos im Webportal der ZID gepflegt, kann das Reporting vom Anbieter aus der ZID heraus erfolgen.

Ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.

6 Configuration Management (CM)

Um den Gesamtverantwortlichen der TI und den Serviceverantwortlichen Informationen über die für die Erbringung von TI-Services erforderlichen Konfigurationselemente (Configuration Items, CI) und deren Beziehungen untereinander bereitzustellen, ist ein Configuration Management (CM) zu etablieren. Über das Configuration Management stehen für die Prozesse und Aufgaben über den gesamten Lebenszyklus der Services konsistente Daten und Informationen zur Verfügung.

Die nachfolgende „Abbildung 6: CM – TI-Services: Beziehung der CMDB-TI “ veranschaulicht den allgemeinen Aufbau der TI- Konfigurationsdatenbank. Der jeweilige ITSM-TI-Teilnehmer übermittelt Informationen zu den von ihm verantworteten CI (Produkt) an den SBV. Der SBV konsolidiert die produktspezifischen Konfigurationsdaten und pflegt die TI Konfigurationsdatenbank sowie die CI Relationen (Erstellung und Aktualisierung). Das übergreifende Configuration Management wird durch den GTI etabliert. Der GTI stellt das Konfigurationsmodell inklusive der Relationen zur Verfügung. Dazu wird eine TI- Konfigurationsdatenbank als betriebsunterstützendes System implementiert. Die Dokumentation der spezifischen Konfiguration der IT-Architektur der Produkte obliegt dem ITSM-TI-Teilnehmer in seinem lokalen Konfigurationssystem. Dabei bilden die Produkte das Bindeglied zwischen der TI-Konfigurationsdatenbank und den lokalen Konfigurationssystemen der ITSM-TI-Teilnehmer.

Abbildung 6: CM – TI-Services: Beziehung der CMDB-TI zur lokalen CMDB der ITSM-TI-Teilnehmer

Im Fokus der nachfolgenden Regelungen stehen die Mindestanforderungen zum Informationsaustausch zwischen lokalem CM und TI-Konfigurationsdatenbank.

Die nachfolgende Abbildung veranschaulicht die Regelungen des Configuration Managements im für die ITSM-TI-Teilnehmer relevanten Prozessausschnitt mit Fokus auf deren Aufgaben.

Abbildung 7: CM – Gesamtüberblick "Configuration Management“

6.1 Betrachtungsgegenstand des übergreifenden CM

Fokus der nachfolgenden Configuration-Management-Regelungen im Betrieb ist die Bereitstellung der Konfigurationsdaten durch die ITSM-TI-Teilnehmer.

6.2 Begriffserläuterungen

6.2.1 Konfigurationselement (Configuration Item, CI)

Ein Konfigurationselement (Configuration Item, CI) ist eine formalisierte Beschreibung einer zum Betrieb erforderlichen Komponente, über deren gesamten Lebenszyklus hinweg. Konfigurationselemente werden durch das Configuration Management strukturiert, dokumentiert und in einer Datenbank zusammengefasst und gepflegt.

Beispiele für CIs sind Services, Produkte, Produkttypen, produktverantwortliche Organisationen und Prozess- und Betriebsdokumentationen.

6.2.2 Konfiguration

Die Konfiguration ist eine Bezeichnung für eine Gruppe von Konfigurationselementen, die miteinander verbunden für die Erbringung eines Service oder eines umfangreichen Teils eines Service eingesetzt werden.

6.2.3 TI-Konfigurationsdatenbank

Die TI-Konfigurationsdatenbank ist ein Werkzeug, welches die Konfigurationsdaten der TI-Services enthält, die der Gesamtverantwortliche der TI zur Entscheidungshilfe und zur Steuerung des übergreifenden IT-Service-Managements der TI benötigt.

6.2.4 Konfigurationsdaten

Konfigurationsdaten sind die Attribute zu einem CI. In dieser Richtlinie werden für ITSM-TI-Teilnehmer folgende Minimaldaten für CIs festgelegt:

• CI „Produktverantwortliche Organisation“: Allgemeine Informationen zu einem ITSM-TI-Teilnehmer, bspw. Anschrift und Ansprechpartner.
• CI „Produkt“: Produktspezifische Konfigurationsdaten der ITSM-TI-Teilnehmer, bspw. Produktname, -version, -beschreibung etc.

6.3 Prozessdurchführung zur Bereitstellung von Konfigurationsdaten

6.3.1 Prozessreporting (Konfigurationsdaten) CM

ITSM-TI-Teilnehmer führen Änderungen kontrolliert im Rahmen des Change & Release Managements durch. Nach erfolgter Änderung werden Konfigurationsdaten aktualisiert und dem SBV eine konsistente Informationsbasis bereitgestellt.

Die Beziehung zwischen lokalem CM und TI-Konfigurationsdatenbank (vgl. „Abbildung 6: CM – TI-Services: Beziehung der CMDB-TI “) werden für die von den ITSM-TI-Teilnehmern verantworteten CI weiter verdeutlicht: in „Abbildung 8: KM – Übersicht der Relationen“ werden die Relationen dieser CI dargestellt und die durch die ITSM-TI-Teilnehmer zu liefernden CI Daten tabellarisch aufgezeigt.

Abbildung 8: KM – Übersicht der Relationen

CI „Produktverantwortliche Organisation“

CI „Produkt“

6.3.2 SPED Report

In diesem Report werden Daten der dezentralen Produkte / Anwenderkomponenten bereitgestellt. Es geht nicht um die detaillierte Konfiguration vor Ort bei Leistungserbringern, sondern die Menge der von den Anbietern und SPEDs implementierten Produkte / Anwenderkomponenten, differenziert nach Produktbezeichnung und Firmware Version

6.3.3 Bereitstellung Ad-hoc Report

6.4 Obliegenheiten SBV/GTI

Obliegenheiten des SBV:

• Der SBV ist verantwortlich für die Konsolidierung der von ITSM-TI-Teilnehmern erhaltenen Konfigurationsdaten und die Pflege der TI-Konfigurationsdatenbank.
• Der SBV wird im Rahmen des Configuration Managements an ITSM-TI-Teilnehmer Mitteilungen bzgl. der Änderungsanforderungen zu Konfigurationsdaten versenden.

Obliegenheiten des GTI:

• Der GTI veröffentlicht die Listen der Teilnehmer-IDs sowie der zugelassenen Produkte.

7 Knowledge Management (KM)

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

Im Knowledge Management Tool abgelegte Produktinformationen sollen ITSM-TI-Teilnehmer sowie Anwender/DVO in der TI bei der Klärung im Betrieb bzw. bei der Nutzung auftretender Fragestellungen unterstützen. ITSM-TI-Teilnehmer sind verpflichtet, diese Informationen bereitzustellen.

Die nachfolgende Abbildung veranschaulicht die Regelungen des Knowledge Managements im ITSM-TI-Teilnehmer -relevanten Prozessausschnitt und mit Fokus auf die durch ITSM-TI-Teilnehmer zu unterstützenden Betriebsaufgaben in einem Schaubild.

Abbildung 9: KM – Gesamtüberblick "Knowledge Management“

7.1 Betrachtungsgegenstand des KM

Fokus der nachfolgenden Regelungen des Knowledge Managements ist die nicht-normative regelnde Informationsbereitstellung der ITSM-TI-Teilnehmer- bezogenen Produktinformationen, insbesondere zu Support-Schnittstellen und Ansprechpartnern.

7.2 Begriffserläuterungen

7.2.1 Wissensdatenbank (WDB)

Die Wissensdatenbank der TI wird durch den GTI bereitgestellt und unterstützt ITSM-TI-Teilnehmer sowie Anwender/DVO im Falle einer Störung dabei, mehr Informationen über die möglichen Störungsursachen und möglichen Lösungen der Produkte zu erhalten und den für die Fehlerbehebung Verantwortlichen zu identifizieren und zu kontaktieren.

Die Wissensdatenbank soll in der initialen Ausbaustufe folgende Informationen bereitstellen:

• Erläuterung zu Fehlercodes aus Produkttypspezifikation
• Hinweise auf mögliche Ursachen sowie möglichen Lösungen des Fehlers
• Kontaktinformationen der lösungsverantwortlichen sowie problemlösungs-unterstützenden ITSM-TI-Teilnehmer

7.3 Prozessdurchführung Bereitstellung der Produktinformation

7.3.1 Bereitstellung der Produktinformation

7.4 Obliegenheiten SBV/GTI

Obliegenheiten des SBV:

• Der SBV nimmt die Produktinformationen von ITSM-TI-Teilnehmern entgegen und wertet sie aus. Diese können um weitere Produktinformationen aus eigenen Recherchen, wie Analyse von Spezifikationen und anderer Dokumentationen z.B. Handbücher, ergänzt werden. Die konsolidierten Produktinformationen werden unter Angabe der Quelle in die Wissensdatenbank übernommen.
• Der SBV wird im Rahmen der Auswertung der Produktinformationen die Inhalte, bspw. durch Reviews oder Audits, regelmäßig überprüfen. Dies dient der Fehlersuche und -behebung bzw. kontinuierlichen Verbesserung der Inhalte der Wissensdatenbank.

Obliegenheiten des GTI:

• Durch den GTI wird ein übergreifendes Knowledge Management etabliert.
• Der GTI stellt allen Beteiligten der TI (ITSM-TI-Teilnehmern, Anwendern, DVOs sowie nach Bedarf weiteren am ITSM zu Beteiligenden – z. B. Gesellschafter der gematik einschließlich deren Landesorganisationen) eine Wissensdatenbank als Informationsinstrument und Unterstützungswerkzeug im Betrieb zur Verfügung.
• Der GTI trägt die redaktionelle Verantwortung für die Wissensdatenbank. Für die produktbezogenen Inhalte zur Störung, Ursache und Lösung sind die ITSM-TI-Teilnehmer verantwortlich.

8 Incident Management (INC)

Um zwischen den verschiedenen ITSM-TI-Teilnehmern sicherzustellen, dass Servicestörungen bzw. vom erwarteten Betriebsverhalten abweichende Services des TI-Plattform-Service oder eines Anwendungsservice

• gemäß ihrer Auswirkungen eine konsistent gleiche Behandlung erfahren und
• im Rahmen des Supports, der Austausch bzw. die Übergabe von Incidents zwischen den Prozessbeteiligten problemlos und nachvollziehbar gewährleistet wird,

ist durch die ITSM-TI-Teilnehmer ein übergreifendes Incident Management (INC) zu etablieren.

Die nachfolgende Abbildung veranschaulicht die Regelungen des Incident Managements im ITSM-TI-Teilnehmer relevanten Prozessausschnitt und gibt eine Zuordnung der einzelnen Prozessinhalte zu den nachfolgenden Kapiteln.

Abbildung 10: INC – Gesamtüberblick "Incident Management"

8.1 Betrachtungsgegenstand des übergreifenden INC

Fokus der nachfolgenden Incident-Management-Regelungen im übergreifenden Betrieb sind ITSM-TI-Teilnehmerübergreifende Incidents. Sofern zur Durchführung des übergreifenden INC-Prozesses notwendig, werden Prozessinhalte sowie Regelungen für die Bearbeitung von Incident-Meldungen durch Anwender oder DVOs aufgezeigt.

8.2 Begriffserläuterungen

8.2.1 Lokaler Incident

Bei einem lokalen Incident handelt es sich um eine Servicestörung bzw. um einen vom erwarteten Betriebsverhalten abweichenden Betriebszustand innerhalb des SPED (Service Provider Endnutzernahe Dienste)/Anwendersupports sowie innerhalb des ITSM-TI-Teilnehmersupports, für dessen Behebung der support- und lösungsverantwortliche ITSM-TI-Teilnehmer keine anderen am Betrieb beteiligten ITSM-TI-Teilnehmer benötigt.

Ein lokaler Incident wird dabei innerhalb der lokalen INC-Prozesse des ITSM-TI-Teilnehmers verarbeitet und unterliegt nur insofern Regelungen durch diese Richtlinie, wie zur Gewährleistung der Performance, Sicherheit und Stabilität der zentralen und dezentralen Produkte bzw. TI-Services notwendig ist.

Ein lokaler Incident wird durch einen Anwender bzw. DVO gemeldet oder durch einen ITSM-TI-Teilnehmer im Rahmen seiner lokalen (ggf. systemischen) Störungsüberwachung festgestellt.

8.2.2 Übergreifender Incident

Um einen übergreifenden Incident handelt es sich, wenn zur Bewältigung mehrere der am Betriebsprozess beteiligten ITSM-TI-Teilnehmer involviert werden müssen, d. h. eine strukturierte Informationsübermittlung des Incidents an weitere ITSM-TI-Teilnehmer eingeleitet werden muss.

Zur Bearbeitung des übergreifenden Incidents steht es den ITSM-TI-Teilnehmern frei, die Inhalte des übergreifenden Incidents in den lokalen Incident- Management-Prozess zu überführen. Dabei muss sichergestellt sein, dass an den Schnittstellen zwischen den Prozessbeteiligten weiterhin eine einheitliche Kommunikation, mittels übergreifender Incident-Dokumentation, erfolgt.

Eine Einschätzung, ob mehrere am Betriebsprozess beteiligte ITSM-TI-Teilnehmer zur Behebung (Lösung, Verifizierung, Schließen) der Störung bzw. zur Wiederherstellung des erwarteten Betriebsverhaltens der zentralen oder dezentralen Produkte notwendig sind, können - qualifiziert - ausschließlich ITSM-TI-Teilnehmer treffen. Übergreifende Incidents können daher ausschließlich durch ITSM-TI-Teilnehmer erstellt werden, jedoch nicht durch einen Anwender bzw. einen DVO.

8.2.3 Anwendersupport

Der Anwendersupport hat im Gegensatz zum ITSM-TI-Teilnehmersupport eine Kommunikationsschnittstelle in Richtung Anwender bzw. DVO sowie zusätzlich eine in Richtung ITSM-TI-Teilnehmer.

Incident-Meldungen innerhalb des Anwendersupports können ausschließlich durch Anwender oder DVOs erfolgen.

Der Anwendersupport umfasst primär Regelungen zur ordnungsgemäßen Durchführung des übergreifenden Incident Managements bei Meldung eines Incidents durch einen Anwender bzw. DVO.

8.2.4 ITSM-TI-Teilnehmersupport

Der ITSM-TI-Teilnehmersupport hat ausschließlich Kommunikationsschnittstellen in Richtung andere ITSM-TI-Teilnehmersupport, nicht jedoch gegenüber Anwendern oder DVOs.

Incident-Meldungen innerhalb des ITSM-TI-Teilnehmersupports können ausschließlich von ITSM-TI-Teilnehmern erfolgen (direkt oder im Rahmen einer Weiterleitung aus dem Anwendersupport heraus).

Der ITSM-TI-Teilnehmersupport umfasst primär Regelungen zur ordnungsgemäßen Durchführung des übergreifenden Incident Managements bei Meldung eines Incident durch einen ITSM-TI-Teilnehmer.

Anforderungen an die Dokumentation, die Information und das Reporting sind so ausgeprägt, dass sie mit Hilfe von Standard-Kommunikationswerkzeugen (bspw. E-Mail, Standard-Office-Produkte) durchgeführt werden können.

Der Einsatz bzw. die Anpassung bestehender Verfahren und Werkzeuge (bspw. der Ticketsysteme) kann die Effizienz der Incident-Bearbeitung erhöhen, ist jedoch keine Voraussetzung für das übergreifende INC.

8.2.5 Supportverantwortung

Unter dem Begriff Supportverantwortung wird die originäre Verantwortung zur Supportbereitstellung eines ITSM-TI-Teilnehmers gegenüber anderen ITSM-TI-Teilnehmern sowie Anwendern bzw. DVOs verstanden, der von ihm eine Dienstleistung bezieht. Die Ausgestaltung der Supportzuordnung und -inhalte ist nicht Bestandteil der Richtlinien und erfolgtim Betriebskonzept [gemKPT_Betr].

8.2.6 Lösungsverantwortung

Ein produktverantwortlicher ITSM-TI-Teilnehmer bzw. ein durch diesen beauftragter Betreiber trägt die Lösungsverantwortung, wenn dessen Produkt für die Störungsursache verantwortlich ist. Er muss die Wiederherstellung des erwarteten Betriebsverhaltens gewährleisten.

Eine detaillierte Darstellung der betrieblichen Rollen im ITSM-TI und ihrer Produkt-, Service- und Supportverantwortung findet sich im Betriebskonzept [gemKPT_Betr].

8.3 Grundsätze des übergreifenden INC

Die nachfolgenden Grundsätze bilden die übergeordneten Regelungen des übergreifenden Incident Managements für ITSM-TI-Teilnehmer.

8.3.1 Zentrale INC-Koordinierung durch den GTI

Ausschließlich bei Eskalationen eines schwerwiegenden Incidents mit (produkt-) übergreifender Auswirkung kann der Gesamtverantwortliche der TI - zur Gewährleistung der Performance, Sicherheit und Stabilität der zentralen und dezentralen Produkte - eine zentrale Koordinierung der Aktivitäten der anderen Beteiligten übernehmen.

8.3.2 Übergabe der Lösungsverantwortung

Sofern durch einen Supportverantwortlichen keine Herbeiführung einer Lösung möglich ist - bspw. weil der zu bearbeitende Incident durch eine andere Betriebsinstanz verursacht bzw. verantwortet wird - kann er die Lösungsverantwortung an andere ITSM-TI-Teilnehmer (deren Dienstleistungen er in Anspruch nimmt) mittels einer strukturierten Informationsübermittlung übergeben. D. h. innerhalb einer Supportkette (im klassischen Sinne wäre dies bspw. der 1st-, 2nd-, 3rd-Level Support) wechselt die Lösungsverantwortung jeweils zwischen den einzelnen supportleistenden Betriebsinstanzen.

8.3.3 Incident-Melder

Der Incident-Melder im übergreifenden ITSM ist immer derjenige, der eine Incident-Meldung beim nächsten aus seiner Sicht zuständigen ITSM-TI-Teilnehmer eröffnet. Anhand der Angabe ist es für den Incident-Empfänger vor allem im Falle von Ticketweiterleitungen möglich die strukturierte Kommunikation aufrecht zu erhalten.

Es gibt zwischen dem Incident-Melder und seinem Empfänger immer eine 1:1-Beziehung.

Ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.

8.3.4 Incident-Bearbeiter

Der Incident-Bearbeiter ist immer derjenige, der aktuell an der Incident-Lösung arbeitet. Wird die Lösungsverantwortung von dem Weiterleitungsempfänger angenommen, wechselt der ursprüngliche Incident-Bearbeiter in die Rolle des Incident-Melders und der Weiterleitungsempfänger in die Rolle des (neuen) Incident-Bearbeiters. Lehnt er die Lösungsverantwortung ab, so bleibt der Weiterleitende der Incident-Bearbeiter.

Ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.

8.3.5 Betroffener Anwender

Der betroffene Anwender ist der Nutzer der TI, bei dem ursprünglich eine Störung auftrat und der diese Störung an den für ihn zuständigen ITSM-TI-Teilnehmer gemeldet hat. Durch diesen erfolgt die Erfassung der Störung als Incident.

Ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.

8.4 Prozessdurchführung Anwendersupport INC

8.4.1 Incident-Erstmeldung im Anwendersupport

An die Incident Meldung eines Anwenders oder DVO werden keine Anforderungen gestellt.

8.4.2 Vorprüfung im Anwendersupport

Abbildung 11: INC – Vorprüfung im Anwendersupport

Die Supportverantwortung gegenüber dem initial meldenden Anwender oder DVO im Rahmen des Anwendersupports verbleibt grundsätzlich bei dem ITSM-TI-Teilnehmer, welcher den Incident (im Rahmen seines Anwendersupports) entgegengenommen und eröffnet hat.

Bis zur internen Klärung, ob es sich bei dem gemeldeten Incident um einen übergreifenden Incident handelt, hat der derjenige ITSM-TI-Teilnehmer, der den Incident annimmt, zugleich die Lösungsverantwortung.

Sobald es sich um einen übergreifenden Incident handelt, muss die erstellte Dokumentation die Anforderungen an eine übergreifende Incident-Dokumentation - gemäß Kapiteln 8.4.5 „Interne Erfassung, Kategorisierung & Priorisierung übergreifender Incidents“ und 8.7 „Dokumentation“ - erfüllen und innerhalb der vorgegebenen Reaktionszeit an den zuständigen ITSM-TI-Teilnehmer strukturiert übermittelt werden. Die Supportverantwortung gegenüber dem meldenden Anwender oder DVO verbleibt weiterhin bei dem ITSM-TI-Teilnehmer, welcher die Incident-Meldung vom Anwender oder DVO entgegen genommen und die initiale Incident-Dokumentation erstellt hat.

8.4.3 Ablehnung im Anwendersupport

An die Ablehnung eines durch einen Anwender oder DVO gemeldeten Incidents werden keine Anforderungen gestellt. Es wird empfohlen, eine qualifizierte Ablehnung an den Meldenden zu versenden, der weiterführende Informationen (bspw. die Nennung des korrekten Ansprechpartners) zu entnehmen sind.

8.4.4 Lösung und Schließung im lokalen Incident Management

An das Verfahren zur Lösung und Schließung eines durch einen Anwender oder DVO gemeldeten Incidents werden nur insofern Anforderungen gestellt, wie es zur Gewährleistung der Performance, Sicherheit und Stabilität der zentralen und dezentralen Produkte bzw. TI-Services notwendig ist. Es wird empfohlen, stets eine qualifizierte Rückmeldung an den Meldenden zu versenden, wenn die Störung behoben ist.

Während der Bearbeitung eines lokalen Incidents kann durch den ITSM-TI-Teilnehmer festgestellt werden, dass ein TI-Service (bspw. für eine hohe Anzahl an Nutzern) gestört ist. Die Auswirkungsweite und die Dringlichkeit der produktspezifischen Ausprägung der Prioritäten (gemäß Kapitel 8.4.5 „Interne Erfassung, Kategorisierung & Priorisierung übergreifender Incidents“) sind - trotz der Bearbeitung im Rahmen der lokalen Incident-Prozesse - durch den ITSM-TI-Teilnehmer zu messen und bei Priorität 1 und 2 an den SBV zu berichten.

8.4.5 Interne Erfassung, Kategorisierung & Priorisierung übergreifender Incidents

Die Erfassung und Bearbeitung von übergreifenden Incidents muss auch nach Austausch bzw. der strukturierter Übermittlung dieser zwischen den Prozessbeteiligten problemlos und nachvollziehbar gewährleistetet sein.

Dabei darf der interne ITSM-TI-Teilnehmerspezifische Bearbeitungsprozess zur Behebung (Lösung, Verifikation, Schließen) eines Incidents nicht behindert werden. Aus diesem Grund erstellt jeder ITSM-TI-Teilnehmer eine interne Dokumentation für den übergreifenden Incident in Form eines Tickets, eines Formulars (bspw. Excel) oder einer E-Mail. Diese wird insbesondere auch für die Pflichten der ITSM-TI-Teilnehmer im Rahmen des Reportings benötigt.

Zur Gewährleistung einer übergreifenden Nachvollziehbarkeit muss jeder im übergreifenden Incident Management bearbeitete bzw. an diesen Prozess übergebene Incident - bspw. zur Verweismöglichkeit - mit einer eineindeutigen Referenznummer (Incident-ID) versehen und ordnungsgemäß kategorisiert, priorisiert sowie dokumentiert werden.

Abbildung 12: INC – Strukturierte Informationsübermittlung im übergreifenden INC

Eineindeutige Referenznummer von übergreifenden Incidents

Kategorisierung von übergreifenden Incidents

Priorisierung von Incidents

8.4.6 Strukturierte Informationsübermittlung übergreifender Incidents

Es dürfen ausschließlich vorqualifizierte (inhaltsanforderungskonforme) Incident-Fälle - gemäß Kapitel 8.4.5 „Interne Erfassung, Kategorisierung & Priorisierung übergreifender Incidents“ - übermittelt werden. Die Lösungsverantwortung, also die Verantwortung zur Behebung der Störung bzw. zur Wiederherstellung des erwarteten Betriebsverhaltens, wird mit der strukturierten Informationsübermittlung an den ITSM-TI-Teilnehmer übergeben, der den übergreifenden Incident empfängt und annimmt.

Die den übergreifenden Incident empfangenden ITSM-TI-Teilnehmer müssen eine erneute interne Erfassung durchführen oder können mit der vorhandenen Incident-Dokumentation die Bearbeitung direkt fortführen.

Ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.

8.4.7 Schließung übergreifender Incidents

Weitere ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.

8.4.8 Service Level Requirements (SLR)

8.5 Prozessdurchführung ITSM-TI-Teilnehmersupport INC

8.5.1 Feststellung, Lösung und Schließung im lokalen INC

Die Ausgestaltung der Prozesse zur Bearbeitung und Lösung lokaler Incidents obliegt grundsätzlich dem ITSM-TI-Teilnehmer. Der Umgang mit lokalen Störungen, die durch das interne Monitoring eines ITSM-TI-Teilnehmers erkannt werden, wird durch die Produktverfügbarkeit dimensioniert. Folgende Anforderungen sind dabei zu beachten.

8.5.2 Qualifizierte Incident-Erstmeldung im ITSM-TI-Teilnehmersupport

Eine qualifizierte Erstmeldung ist eine Incident-Meldung durch einen ITSM-TI-Teilnehmer, bei welcher der ITSM-TI-Teilnehmer ohne Meldung durch einen Anwender oder DVO eine Störung bemerkt (bspw. durch geeignete Systeme) und diese an die support- bzw. lösungsverantwortlichen ITSM-TI-Teilnehmer melden möchte.

Durch das „ITSM-TI-Teilnehmer- ITSM-TI-Teilnehmer“-Verhältnis (B2B-Kommunikation) handelt es sich bei der qualifizierten Meldung immer um einen übergreifenden Incident.

Ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.

8.5.3 Vorprüfung im ITSM-TI-Teilnehmersupport

Abbildung 13: INC – Vorprüfung im ITSM-TI-Teilnehmersupport

Ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.

8.5.4 Ablehnung im ITSM-TI-Teilnehmersupport

Ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.

8.5.5 Lösung übergreifender Incidents

8.5.6 Schließung übergreifender Incidents

Ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.

8.5.7 interne Dokumentation übergreifender Incidents

8.5.8 strukturierte Informationsübermittlung übergreifender Incidents

Ergänzende Erläuterungen sind im Rahmen des Knowledge Managements innerhalb der Wissensdatenbank dargestellt.

8.5.9 Service Level Requirements (SLR)

Die Gesamtlösungszeit für einen übergreifenden Incident wird vorerst durch diese Richtlinie nicht weiter geregelt. Diese ergibt sich aus der Lösungszeit des übergreifenden Incidents beim Lösungsverantwortlichen sowie den Qualifizierungs- und Reaktionszeiten der zuvor am übergreifenden Incident beteiligten ITSM-TI-Teilnehmern.

Beim Wechsel der Priorität eines Incidents ergeben sich im Regelfall Änderungen der Lösungszeiten. Diese Änderungen sollen gemäß den nachfolgenden Beschreibungen und Beispielen behandelt werden:

• Bei einem Prioritätenwechsel eines Incidents von 3/4 auf 1/2 beginnt die Lösungszeit von neuem (Anpassung der Service Level). Dabei darf die Restlaufzeit des „alten“ Incidents nicht überschritten werden. Die Incident-ID bleibt gleich.

Beispiel: Ein Incident der Priorität 3 hat den Service Level von 10 Stunden. Der Incident läuft bereits 8 Stunden. Der Incident wird jetzt auf Stufe 1 umpriorisiert und hat einen Service Level von 3 Stunden. Die Service Level -Zeit wird neu gesetzt, endet allerdings nach 2 Stunden, da die Restlaufzeit des alten Incidents nicht überschritten werden darf.

• Bei einem Prioritätswechsel von 1/2 auf 3/4 gilt als Restlaufzeit die Laufzeit der niedrigeren Priorität abzüglich der bereits abgelaufenen Zeit des "alten" Incidents.

Beispiel: Ein Incident der Priorität 1 hat einen Service Level von 3 Stunden. Der Incident läuft bereits 2 Stunden. Der Incident wird jetzt auf Stufe 3 umpriorisiert und hat einen Service Level von 10 Stunden. Die Service Level Zeit wird neu gesetzt, endet allerdings nach 8 Stunden, da zwei Stunden der zulässigen Laufzeit in Priorität 3 bereits in der höheren Priorität "verbraucht" wurden.

8.6 Informationspflichten

8.7 Dokumentation

Inhalte und Dokumentation von übergreifenden Incidents