ML-144150 - E-Rechnung - Einführung (Betrieb)

[<=]

TIP1-A_7261 - Erreichbarkeit der TI-ITSM-Teilnehmer untereinander

Alle TI-ITSM-Teilnehmer MÜSSEN untereinander uneingeschränkt elektronisch erreichbar sein, aufgeteilt in Haupt- und Nebenzeit mit differenzierten Reaktionszeiten. [<=]

TIP1-A_7262 - Haupt- und Nebenzeit der TI-ITSM-Teilnehmer

Alle TI-ITSM-Teilnehmer MÜSSEN untereinander folgende Hauptzeit einhalten:
Mo – Fr 09:00 – 17:00 im Rahmen eines Einschichtbetriebs [außer an bundeseinheitlichen Feiertagen]. Alle anderen Zeiten gelten als Nebenzeit. [<=]

TIP1-A_7265-05 - Serviceleistung der TI-ITSM-Teilnehmer im TI-ITSM-Teilnehmersupport zur Haupt- und Nebenzeit

TI-ITSM-Teilnehmer mit Mitwirkungsverpflichtung zur Haupt- und Nebenzeit gemäß Tab_KPT_Betr_TI_002 Mitwirkungspflichten der TI-ITSM-Teilnehmer MÜSSEN die folgenden Service Level (Zeiten) einhalten:

Tabelle 2: Tab_KPT_Betr_TI_052 Service Level (Zeiten) im TI-ITSM

A_23347-01 - Performance - Wartungsfenster - Durchführung

Der Anbieter SOLL Wartungsfenster so planen, dass diese vollständig in der Nebenzeit liegen.
Hinweis: Nach voriger Absprache mit und Genehmigung durch den Gesamtverantwortlichen TI ist ein Wartungsfenster in der Hauptzeit möglich.

Ist für einen Anbieter und einem seiner zugeordneten Produkt(e) nur eine Hauptzeit und keine Nebenzeit definiert, dann SOLL der Anbieter ein Wartungsfenster so planen, dass dieses in Zeiten mit wenig Systemlast stattfindet. Das Wartungsfenster muss mit dem Gesamtverantwortlichen TI abgesprochen und durch diesen genehmigt werden. [<=]

A_23348 - Performance - Servicezeiten des Produktes - Hauptzeit - Montag bis Freitag

Der Produkttyp MUSS folgende Servicezeiten gewährleisten:

• Hauptzeit ist Montag bis Freitag von 6 bis 22 Uhr.
• Bundeseinheitliche Feiertage und alle übrigen Stunden der Woche sind Nebenzeit.

A_24962 - Performance - Servicezeiten des Anbieters basierend auf Produkttypen

Der Anbieter MUSS gemäß der in [gemKPT_Betr#Tab_gemKPT_Betr_Servicekomponente] aufgeführten Servicekomponenten bzw. der Zuordnung von Produkttypen zu serviceverantwortlichen Anbieter die dem entsprechenden Produkttypen zugeordneten Servicezeiten erfüllen. [<=]

A_23615 - Performance - Wartungsfenster und Ausfall - Ausnahme zur Verfügbarkeitsberechnung bei Wartung

Der Anbieter MUSS den Anteil der Ausfallzeit, der innerhalb einer geplanten Ausfallzeit innerhalb eines genehmigten Wartungsfensters liegt, von der Verfügbarkeitsberechnung ausschließen.

Hinweis: Fällt der Dienst vor oder nach einem genehmigten Wartungsfenster aus, so ist die Zeit außerhalb des Wartungsfensters als Ausfall in die Verfügbarkeitsberechnung des Dienstes mit einzubeziehen. [<=]

A_26151-01 - Redundanz - Lokale Redundanz

Der Anbieter MUSS sicherstellen, dass bei Ausfall eines funktionalen Elements die Gesamtverfügbarkeit gemäß der definierten Performancevorgaben in [gemSpec_Perf] weiterhin gegeben ist.
Das Ziel der Maßnahme ist, dass lokale Beeinträchtigungen nicht zu einem Ausfall oder verminderter Leistungsfähigkeit des angebotenen Dienstes führen.

Hinweis: Dazu nutzt der Anbieter beispielsweise die Verteilung der eingesetzten Instanzen auf verschiedene Abschnitte eines Standorts. [<=]

A_22057 - Performance - Betriebsdatenlieferung - Verpflichtung des Anbieters

Der Anbieter MUSS die Erfassung, Aufbereitung und Übermittlung der Betriebsdaten gemäß der allgemeinen und spezifischen Anforderungen gewährleisten. [<=]

A_22482-01 - Performance - Betriebsdatenlieferung - Erfassung von Betriebsdaten

Der Produkttyp MUSS Betriebsdaten gemäß der Vorgaben an der Außenschnittstelle erfassen.

Hinweis: Der Begriff Außenschnittstelle ist im Kapitel 1.1 Bearbeitungszeit definiert.
[<=]

A_22002 - Performance - Betriebsdatenlieferung v2 - Übermittlung

Der Produkttyp MUSS zur Übertragung der Betriebsdatenlieferung die Schnittstelle I_OpsData_Update::fileUpload gemäß [gemSpec_SST_LD_BD#A_17733] verwenden.
Die Übermittlung der Betriebsdatenlieferung MUSS pro Produktinstanz (CI ID - Configuration Item ID) nach Vorgabe der gematik erfolgen.  [<=]

A_21976 - Performance - Betriebsdatenlieferung v2 - Konfigurierbarkeit der Lieferintervalle

Der Produkttyp MUSS die Lieferintervalle der Berichtsdateien flexibel zwischen 1 Minute und 24 Stunden (1440 Minuten) mit einer Taktung von 1 Minute konfigurieren können, ohne ein Produktupdate durchführen zu müssen. [<=]

A_22005 - Performance - Betriebsdatenlieferung v2 - Frist für Nachlieferung

Der Produkttyp MUSS, falls im Ausnahmefall eine Lieferung nicht wie gefordert erfolgt, die Datei(en) in der geforderten Qualität bis zum Ende des folgenden Werktages (Mo-Fr ausgenommen bundeseinheitliche Feiertage) nachliefern. [<=]

A_22047 - Performance - Betriebsdatenlieferung v2 - Änderung der Konfiguration der Lieferintervalle

Der Produkttyp MUSS eine Anpassung der Lieferintervalle von Betriebsdatenlieferungen ermöglichen. [<=]

A_21981-02 - Performance - Betriebsdatenlieferung v2 - Format

Der Produkttyp MUSS bei der Erstellung der Datenlieferung folgende Konventionen umsetzen:
Die Datei:

• MUSS ein CSV-Format mit den Feldern

• MUSS das Semikolon ";" als Feldtrennzeichen verwenden.
• DARF das Feldtrennzeichen innerhalb der CSV-Felder NICHT inhaltlich verwenden.
• DARF Feldinhalte NICHT quotieren.
• DARF Feldinhalte weggelassen, sofern diese Produkttyp- oder operationsbedingt entfallen können, was ggf. zu direkt aufeinanderfolgenden Semikola führt.
• MUSS UTF-8 Zeichensatzkodierung ohne ByteOrderMark verwenden.
• MUSS CR-LF-Zeilenumbrüche (ASCII-13-Zeichen (Carriage return), ASCII-10-Zeichen (Line feed)) verwenden.
• DARF Kommentierungen NICHT verwenden.
• DARF leeren Zeilen NICHT verwenden.
• DARF Tausendertrennzeichen NICHT verwenden.
• DARF einen CSV-Header NICHT verwenden.
• MUSS Leerzeichen am Rand der Feldinhalte entfernen, sofern diese nicht intendiert sind.

A_21975-01 - Performance - Betriebsdatenlieferung v2 - Default-Wert des Lieferintervalls

Der Produkttyp MUSS den Lieferintervall von 5 Minuten als Standardeinstellung nutzen. [<=]

A_22001-02 - Performance - Betriebsdatenlieferung v2 - Dateiname der Lieferung

Der Produkttyp MUSS für die Übermittlung der Datei zur Betriebsdatenlieferung beim Dateinamen folgende Konventionen umsetzen:
<CI-ID>_<Start>_<Ende>_perf.log

• <CI-ID> = identifiziert die Produktinstanz, gemäß [A_17764] in [gemRL_Betr_TI].
  
• <Start> = Startzeitpunkt des Berichtsintervalls als Unixzeit-Zeitstempel in Millisekunden
  (immer volle Minuten, erster Zeitraum des Tages beginnt um 00:00 Uhr UTC).
  
• <Ende> = Endezeitpunkt des Berichtsintervalls als Unixzeit-Zeitstempel in Millisekunden
  (offenes Intervallende, d.h. erster Zeitpunkt, der gerade nicht mehr zum Intervall gehört, immer volle Minuten)

A_21979 - Performance - Betriebsdatenlieferung v2 - Bezug der Lieferverpflichtung

Der Produkttyp MUSS sich bei der Betriebsdatenlieferung ausschließlich am Lieferintervall orientieren (NICHT z.B. an der Datenmenge). [<=]

A_22996 - Performance - Betriebsdatenlieferung v2 - Zeitpunkte der Übermittlungen

Der Anbieter MUSS jede Lieferung der Betriebsdaten unverzüglich - spätestens innerhalb der 10 auf das Lieferintervall folgenden Minuten - beginnen. [<=]

A_22620 - Performance - Betriebsdatenlieferung v2 - Umsetzungszeit für Änderung der Lieferintervalle

Der Anbieter MUSS die Anpassung der Lieferintervalle gemäß [A_22047] innerhalb von 5 Werktagen (ausgenommen bundeseinheitliche Feiertage) vornehmen. [<=]

A_22500-01 - Performance - Betriebsdatenlieferung v2 - Status-Block

Der Produkttyp MUSS im Status-Block entweder einen HTTP-Statuscode gemäß Tab_gemSpec_Perf_Standard_Statuscodes oder gemäß produkttypspezifischer Definition übermitteln.

Tabelle 5: Tab_gemSpec_Perf_Standard_Statuscodes

A_22003-01 - Performance - Betriebsdatenlieferung v2 - Nachlieferung auf Anforderung

Der Anbieter MUSS auf Anforderung der gematik eine Nachlieferung der Betriebsdaten bis zum 5. Werktag (ausgenommen bundeseinheitliche Feiertage) des auf dem Lieferzeitraum folgenden Monats ermöglichen. [<=]

A_22513-02 - Performance - Betriebsdatenlieferung v2 - Message-Block im Fehlerfall

Der Produkttyp MUSS das betroffene Key-Value-Paar mit <<"key":null>> übermitteln oder das gesamte Key-Value-Paar entfernen, sofern die - im Fehlerfall oder aus einem anderen Grund - für die Erstellung des Message-Blocks (message-Feld in der CSV-formatierten Betriebsdatenlieferung) notwendigen Informationen nicht vorliegen. [<=]

A_21982-01 - Performance - Betriebsdatenlieferung v2 - Message-Block

Der Produkttyp MUSS bei der Erstellung des Message-Blocks (message-Feld in der CSV-formatierten Betriebsdatenlieferung) das JSON-Format (gemäß [RFC 8259] oder [ECMA-404]) für den gesamten Message-Block verwenden. [<=]

A_21980-01 - Performance - Betriebsdatenlieferung v2 - Leerlieferung

Der Produkttyp MUSS die Lieferung gemäß des konfigurierten Lieferintervalls gewährleisten, auch wenn im dazugehörigen Lieferintervall keine Operationsausführung stattgefunden hat. In diesem Fall ist die Datei zur Betriebsdatenlieferung mit dem Inhalt 'leer' (4 Zeichen) zu übertragen. [<=]

A_22004 - Performance - Betriebsdatenlieferung v2 - Korrektheit

Der Produkttyp MUSS die Lieferung vollständig, zeitlich lückenlos (auch über Ausfälle hinweg), überlappungsfrei, intervalltreu, syntaktisch und semantisch korrekt senden.  [<=]

A_26178 - Performance - Selbstauskunft - Umsetzungszeit zur Änderung des Lieferintervalls

Der Anbieter MUSS die Änderung der Konfiguration vom Lieferintervall (gemäß [A_26177*]) nach Aufforderung durch die gematik innerhalb von 5 Werktagen (ausgenommen bundeseinheitliche Feiertage) vornehmen. [<=]

A_26177 - Performance - Selbstauskunft - Konfigurierbarkeit des Lieferintervalls

Der Produkttyp MUSS die Lieferintervalle der Selbstauskunft flexibel zwischen 1 Minute und 1440 Minuten (24 Stunden) konfigurieren können, ohne ein Produktupdate durchführen zu müssen. [<=]

A_26176 - Performance - Selbstauskunft - Lieferintervall

Der Produkttyp MUSS die Selbstauskunft in einem konfigurierbaren Lieferintervall senden. Sofern nicht explizit anders spezifiziert, ist das Lieferintervall von 60 Minuten als Default-Wert zu nutzen. [<=]

A_26175 - Performance - Selbstauskunft - Verpflichtung des Anbieters

Der Anbieter MUSS die Erfassung, Aufbereitung und Übermittlung der Daten zur Selbstauskunft gewährleisten. [<=]

A_26174 - Performance - Selbstauskunft - Verpflichtung zur Erfassung

Der Produkttyp MUSS notwendige Metadaten für die Lieferung einer Selbstauskunft erfassen und verarbeiten. [<=]

A_26181 - Performance - Selbstauskunft v2 - Format und Übermittlung

Der Produkttyp MUSS notwendige Metadaten für die Selbstauskunft im JSON-Format gemäß A_26180 erfassen, verarbeiten und an die Schnittstelle I_OpsData_Update der Betriebsdatenerfassung gemäß [gemSpec_SST_LD_BD] versenden. [<=]

A_26180 - Performance - Selbstauskunft v2 - Grundgerüst

Der Produkttyp MUSS folgende Werte als Grundgerüst für die Selbstauskunft v2 im angegebenen Format zusammenstellen und liefern.
{

A_27271 - Performance - Selbstauskunft v2 - Schemaversion 1

Der Produkttyp MUSS folgende Werte für die Selbstauskunft v2 im angegebenen Format zusammenstellen und liefern.
{

A_27494 - Telemetrie-Daten Service, Custom Collector für Selbstauskunft

Der Telemetrie-Daten Service MUSS einen Custom Collector für die Selbstauskunft des Resource Servers implementieren.
Die Selbstauskunft des Resource Servers erfolgt für jede eigenständige Instanz.
Die OTLP Metrik ist wie folgt definiert:
Name: product_info
Typ: Gauge (zeigt den aktuellen Zustand)
Labels/Attributes:

• product.name – Name des Produkts
• product.version – Aktuelle Produktversion
• producttype.version – Version des Produkt-Typs
• configuration.version – Konfigurationsversion
• pod.name – Name des Pods/der Instanz des Resource Servers
• timestamp – Zeitpunkt der letzten Änderung

A_27543 - Performance - E-Rechnung - Messung von Bearbeitungszeiten

Der E-Rechnung Fachdienst MUSS alle Zeiten zu einem Request/Response-Paar aufzeichnen und verarbeiten. Unterzeiträume werden gleichzeitig gesondert gemessen und verarbeitet.

Rahmenbedingungen:
Die Zeit (in ms) vom vollständigen Eingang eines Requests an der Außenschnittstelle bis hin zum Start des Versands einer Antwortnachricht (Response) an derselben ist die Gesamtbearbeitungszeit.
Die Gesamtbearbeitungszeit unterteilt sich ggf. in Unterzeiträume, die gesondert gemessen und ausgewertet werden (z.B. gem. [A_27544*]). [<=]

A_27544 - Performance - E-Rechnung - Bearbeitungszeiten für Unterzeiträume

Der E-Rechnung Fachdienst MUSS zu folgenden Zeiträumen eigene Unterzeiträume selbstständig erfassen, verarbeiten und im Rahmen des Monitorings weiterleiten.

• ResourceServer-Duration: Zeit in ms bei jedem Aufruf des Resource Servers ab Erhalt des Requests vom ZeTA-Guard bis zum vollständigen Versand der Antwort an den ZeTA-Guard.

A_27361 - Performance - E-Rechnung - Bearbeitungszeit unter Last

Der E-Rechnung Fachdienst MUSS die Bearbeitungszeitvorgaben unter Last aus Tabelle "Tab_gemSpec_Perf_eRechnung: Last- und Bearbeitungszeitvorgaben" erfüllen.

Tabelle 6: Tab_gemSpec_Perf_eRechnung: Last- und Bearbeitungszeitvorgaben

A_27362 - Performance - E-Rechnung - Verfügbarkeit

Der Anbieter E-Rechnung Fachdienst MUSS folgende Verfügbarkeit in den festgelegten Servicezeiten einhalten:

• Hauptzeit: 99,80% und
• Nebenzeit: 99,00%

A_27363 - Performance - E-Rechnung - Skalierung

Der Anbieter E-Rechnung Fachdienst MUSS die Skalierbarkeit des angebotenen Dienstes im laufenden Betrieb jederzeit gewährleisten und der gematik nachvollziehbar darstellen. Dazu dokumentiert er das eingesetzte Skalierungskonzept im Betriebshandbuch. [<=]

A_27365 - Performance - Betriebsdatenlieferung v2 - Spezifika E-Rechnung - Status

Der E-Rechnung Fachdienst MUSS bei Betriebsdatenlieferungen bzgl. des Feldes "status" vorrangig den Fehlercode aus der Spalte "Errorcode" gemäß [A_27547*#gemSpec_eRg_FD] verwenden. In allen anderen Fällen ist der gültige, an den Client zurückgemeldete, HTTP-Response Code in das Feld einzutragen. [<=]

A_27547 - E-Rechnung Fachdienst - interne Fehlercodes

Der E-Rechnung Fachdienst MUSS folgende interne Fehlercodes verwenden:

Tabelle 7 : Tab_eRg_interne_Fehlercodes

A_27366 - Performance - Betriebsdatenlieferung v2 - Spezifika E-Rechnung - Operation

Der E-Rechnung Fachdienst MUSS bei Betriebsdatenlieferungen bzgl. des Feldes "operation" die Angabe der Spalte "UseCase" aus Tabelle [Tab_gemSpec_Perf_eRechnung: Performancerelevante UseCases] nutzen. [<=]

A_27565 - Performance - Betriebsdatenlieferung v2 - Spezifika E-Rechnung - Konfigurierbarkeit der Lieferung

Der E-Rechnung Fachdienst MUSS bei Betriebsdatenlieferungen das an- und abschalten von gelieferten Operationen gemäß [A_27366] konfigurativ ermöglichen. Standardmäßig ist die Lieferung aller definierten Operationen angeschaltet.

Hinweis: Die Änderung dieser Konfiguration darf nur auf betriebliche Anordnung der gematik vorgenommen werden. [<=]

A_27367 - Performance - Betriebsdatenlieferung v2 - Spezifika E-Rechnung - Duration

Der E-Rechnung Fachdienst MUSS bei Betriebsdatenlieferungen bzgl. des Feldes "duration_in_ms" die Gesamtbearbeitungszeit gemäß [A_27543*] verarbeiten. [<=]

A_27368 - Performance - Betriebsdatenlieferung v2 - Spezifika E-Rechnung - Message

Der E-Rechnung Fachdienst MUSS bei Betriebsdatenlieferungen bzgl. des Feldes "message" folgende spezifischen Festlegungen hinsichtlich des Formates und der Inhalte berücksichtigen:

{ "cid": "$clientid", "cv": "$clientversion", "size": $size, "rsdur": $resourceServerDuration }

• $clientid: <product_id> gemäß Token Self-Assessment des Clientsystems, Datentyp String
  
• $clientversion: <product_version> gemäß Token Self-Assessment des Clientsystems, Datentyp String
  
• $size: Größe des Requests in kilobyte, Datentyp Integer
• $resourceServerDuration: Zeit in ms für die Bearbeitungszeit im Resource-Server, Datentyp Integer 
  

A_27369 - Performance - Bestandsdaten - Spezifika E-Rechnung

Der Anbieter E-Rechnung Fachdienst MUSS in einem definierten, konfigurierbaren Zeitintervall folgende Informationen berichten:

• Anzahl der neu eingestellten E-Rechnungen
• Anzahl aller abgelegten E-Rechnungen
• • davon im Status "offen"
  • davon im Status "erledigt"
  • davon im Status "Papierkorb"
• Anzahl aller registrierten Nutzerkonten
• • davon Versicherte
  • davon Kostenträger
  • davon Rechnungsersteller

A_27370 - Performance - Bestandsdaten - Spezifika E-Rechnung - Format

Der Anbieter E-Rechnung MUSS jeweils zum Wechsel in den nächsten Berichtsintervall, folgende Informationen im JSON Format als HTTP Body an die Betriebsdatenerfassung gemäß [A_23110-*] liefern.

{ 
"timestamp": "<Zeitstempel der Abfrage gemäß ISO 8601 unter expliziter Angabe der Zeitzone UTC im konkreten Format: YYYY-MM-DDTHH:mm:ss[.fff]Z, als String>",
"ci": "<CI-ID der abgefragten Produktinstanz gemäß [A_17764], als String>",
"rech": {

GS-A_5039-01 - Änderung der Produktversion bei Änderungen der Produkttypversion

Hersteller bzw. Anbieter von Produkten MÜSSEN folgende Festlegungen bei der Vergabe einer Produktversion bei Produktänderungen berücksichtigen, falls sich die zugrundeliegende Produkttypversion durch die gematik ändert:

• Die Hauptversionsnummer MUSS geändert werden, wenn sich die Haupt- oder Nebenversionsnummer des zugrundeliegenden Produkttypen ändert.

GS-A_5040-01 - Änderung der Produktversion bei Produktänderungen außerhalb von Produkttypänderungen

Hersteller bzw. Anbieter von Produkten MÜSSEN folgende Festlegungen bei der Vergabe einer Produktversion bei Produktänderungen berücksichtigen, falls die zugrundeliegende Produkttypversion durch die gematik unverändert bleibt oder die Produktänderung neben Änderungen aufgrund einer neuen Produkttypversion weitere Anteile enthält:

• Die Hauptversionsnummer MUSS geändert werden, wenn die Produktänderung größere Features oder Feature-Änderungen enthält (Signifikante Änderung).
  
• Die Nebenversionsnummer MUSS geändert werden, wenn die Produktänderung kleinere Features oder Feature-Änderungen enthält (Moderate Änderung).
• Die Revisionsnummer MUSS geändert werden, wenn die Produktänderung das Verhalten des Produktes an den Außenschnittstellen beeinflusst, jedoch keine signifikante oder moderate Änderung vorliegt.
• Das optional vorhanden Patchlevel MUSS geändert werden, wenn die Produktänderung das Verhalten des Produktes an den Außenschnittstellen nicht beeinflusst und auch keine signifikante oder moderate Änderung vorliegt.

GS-A_3695 - Grundlegender Aufbau Versionsnummern

Versionsnummern der TI MÜSSEN folgenden grundlegenden Aufbau haben:
Hauptversionsnummer.Nebenversionsnummer.Revisionsnummer<Trenner>Suffix
Die Bestandteile „Trenner“ und Suffix sind optional. Details hierzu werden pro Artefakttyp (vgl. 2.1.1) festgelegt.
Die kleinste Versionsnummer ist 0.0.1<Trenner>0. Die Bestandteile der Nummerierung sind numerisch.

[<=]

GS-A_3696 - Zeitpunkt der Erzeugung neuer Versionsnummern

Neue Versionsnummern für zu versionierende Artefakte der TI MÜSSEN mindestens dann erzeugt werden, wenn die Artefakte zur Nutzung freigegeben werden, unabhängig vom Grund ihrer Erstellung im Entwicklungsprozess.

GS-A_3697 - Anlass der Erhöhung von Versionsnummern

Bei der Erhöhung von Versionsnummern MUSS nach folgenden Regeln verfahren werden:

• Die Hauptversionsnummer eines Artefakts MUSS sich erhöhen, falls daran signifikante Änderungen durchgeführt werden.

• Die Nebenversionsnummer MUSS sich erhöhen, falls moderate Änderungen durchgeführt werden.

• Die Revisionsnummer MUSS sich erhöhen, falls Änderungen notwendig werden, die das Artefakt bezüglich seiner Außensicht nicht beeinflussen.

• Das optionale Suffix MUSS sich erhöhen, falls Änderungen notwendig werden, die das Artefakt bezüglich seiner Außensicht nicht beeinflussen und nicht bereits durch die Revisionsnummer abgebildet wurden.

• Bei einer Erhöhung eines Versionsnummernteils (Haupt-, Neben-, Revisionsnummer) MÜSSEN alle rechts davon angegebenen Versionsnummernanteile auf null gesetzt werden.

GS-A_5611 - Umsetzung von autorisierten RfC

TI-ITSM-Teilnehmer MÜSSEN vor der Umsetzung eines RfC die Autorisierung des Gesamtverantwortlichen TI einholen. Ausnahmeregelungen beziehen sich einzig auf Emergency Changes.
[<=]

GS-A_5610-03 - Change Management - Vorlaufzeiten in der Bewertung von Changes

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

• Master-Change: mindestens 24 Stunden zur Hauptzeit (zwischen Validierungsanforderung und Umsetzungsbeginn des ersten Sub-Changes)
• Standard-/Sub-Change: mindestens 24 Stunden zur Hauptzeit (zwischen Validierungsanforderung und Umsetzungsbeginn

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
  

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

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

GS-A_5600-01 - Change Management - Beschreibung der Verifikation des Changes in Auswirkung auf andere TI-Services im RfC

Jeder TI-ITSM-Teilnehmer, der einen 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-Services nachweist.
[<=]

GS-A_5599-01 - Change Management - Beschreibung der Verifikation des Changes im RfC

Jeder TI-ITSM-Teilnehmer, der einen RfC stellt, MUSS für diesen eine Verifikation beschreiben, welche die Wirksamkeit des Changes nachweist.

Mit der Verifikation wird nachgewiesen, dass der Change wie geplant Ende-zu-Ende implementiert wurde und die TI-Services weiterhin verfügbar und funktional sind. Die Verifikationsbeschreibung ist Bestandteil eines jeden Changes.

[<=]

GS-A_5597-01 - Change Management - 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.
[<=]

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

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

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

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

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

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

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_5378 - Change Management: 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_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;

• das Ticket wurde irrtümlich angelegt.

GS-A_5366-01 - Change Management - Mitwirkungspflicht der TI-ITSM-Teilnehmer bei der Festsetzung von Standard-Changes

TI-ITSM-Teilnehmer MÜSSEN zur abschließenden Kategorisierung von 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 Changes als „Standard-Change“ die zum jeweiligen Change dazugehörigen Umsetzungsaktivitäten dokumentieren und diese dem Gesamtverantwortlichen TI übergeben.
[<=]

GS-A_5361 - Change Management: 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.
   

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

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

GS-A_5343-01 - 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
• Außenschnittstelle des Produkttypen

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.
   

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

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

GS-A_4425-01 - Change Management - Übermittlung von Optimierungsmöglichkeiten zur Umsetzung von genehmigten Changes

TI-ITSM-Teilnehmer MÜSSEN mit erfolgtem Abschluss oder Abbruch des Changes eine Bewertung des Changes durchführen und dabei gegebenenfalls erkannte Potenziale für mögliche Optimierungen zukünftiger Durchführungen von Changes dem Gesamtverantwortlichen TI mitteilen. [<=]

GS-A_4424-01 - Change Management - Umsetzung des Fallbackplans

TI-ITSM-Teilnehmer MÜSSEN einen Fallbackplan erstellen und – bei erkannter Notwendigkeit während des Change – umsetzen.
[<=]

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

GS-A_4418-01 - Change Management - Übermittlung von Abweichungen vom RfC

TI-ITSM-Teilnehmer, die während der Umsetzung des autorisierten Changes Abweichungen zur Planung in Bezug auf zeitliche, inhaltliche und in der Auswirkung im RfC feststellen, MÜSSEN diese unverzüglich dem Gesamtverantwortlichen TI melden.
[<=]

GS-A_4417-01 - Change Management - Stetige Aktualisierung des Change-Datensatzes im TI-ITSM-System

Realisierende TI-ITSM-Teilnehmer MÜSSEN die interne Dokumentation der Planungs- und Realisierungsdaten von autorisierten Changes stetig im TI-ITSM-System aktuell halten.
[<=]

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

TI-ITSM-Teilnehmer MÜSSEN für jeden genehmigungspflichtigen Change eine Dokumentation der Aktivitäten und Nachweise im TI-ITSM-System ablegen. [<=]

GS-A_4402-01 - Change Management - Mitwirkungspflicht bei der Bewertung vom RfC

Alle betroffenen TI-ITSM-Teilnehmer MÜSSEN bei der Bewertung eines RfC mitwirken. [<=]

GS-A_4400-01 - Change Management - Request for Change erstellen

Alle TI-ITSM-Teilnehmer MÜSSEN je nach Änderungsbedarf einen Request for Change im TI-ITSM-System erstellen.
[<=]

GS-A_4399-01 - Configuration Management - Übermittlung von Produktdaten nach Abschluss von autorisierten Normal-Changes

Alle TI-ITSM-Teilnehmer MÜSSEN mit der Umsetzung eines Software Deployments die Konfigurationsdaten im TI-ITSM übermitteln. Die Übermittlung der Konfigurationsdaten erfolgt mit der Beantragung eines Change Requests im TI-ITSM-System. Nach Abschluss des Changes werden die Konfigurationsdaten in der CMDB aktualisiert.
[<=]

GS-A_4398-01 - Change Management - Prüfung auf genehmigungspflichtige Änderung

Alle TI-ITSM-Teilnehmer MÜSSEN jeden festgestellten Änderungsbedarf einer Prüfung gemäß der unten abgebildeten Tab_Betr_TIP_024 CHG – Vorprüfung Ä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 Änderung handelt.

Tabelle 8: Tab_Betr_TIP_024 CHG – Vorprüfung. Änderungsbedarf

GS-A_4397 - Teilnahme am Service Review

TI-ITSM-Teilnehmer MÜSSEN am Service Review teilnehmen und die bilateral vereinbarten Optimierungsaktivitäten umsetzen.

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.

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.

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

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

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

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

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

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

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

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

GS-A_4124 - Umsetzung Vorkehrungen zur TI-Notfallvorsorge

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

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

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.

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

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.

GS-A_4114 - Bereitstellung von TI-Konfigurationsdaten

TI-ITSM-Teilnehmer MÜSSEN entsprechend ihrer Rolle (vgl. [gemKPT_Betr#Tab_KPT_Betr_TI_002]) TI-Konfigurationsdaten mit dem Gesamtverantwortlichen TI zu Beginn der Serviceerbringung initial abstimmen und im TI-ITSM-System hinterlegen.
[<=]

GS-A_4101 - Übermittlung der Service Level Messergebnisse

TI-ITSM-Teilnehmer MÜSSEN die Service Level Messergebnisse an die durch den Gesamtverantwortlichen TI benannte Kommunikationsschnittstelle übermitteln.
[<=]

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

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_26501 - Kommunikation - Benennung von Ansprechpartnern und Kontakten (FULL)

Der TI-ITSM-Teilnehmer MUSS Kontaktdaten von Ansprechpartnern und bei Bedarf auch von notwendigen Funktionskontakten im TI-ITSM-System erfassen und stets aktuell halten. Der vom TI-ITSM-Teilnehmer benannte Partner Manager übernimmt für seine Organisation verantwortlich diese Aufgabe.
Kontaktdaten werden jeweils benötigt für

• die Rolle Partner Manager,
• die Rolle Service Delivery Manager,
• die Rolle Service Executive Manager,
• die Rolle TI-ITSM Prozess-Manager,
• die Rolle Notfallbeauftragter,
• den Ansprechpartner Unternehmenskommunikation / Krisenkommunikation,
• den Ansprechpartner Informationssicherheit,
• den Ansprechpartner Datenschutz,
• den Ansprechpartner für vertragliche und kaufmännische Fragestellungen.

• Erreichbarkeit des jeweiligen Help Desks (Funktionskontakt)
• verantwortlicher Ansprechpartner für den Help Desk

• 24/7-Kontaktpunkt,
• Single-Point-of-Contact (SPOC),
• Manager-on-Duty.

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_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 (bspw. zur Rücksprache zu einem TI-ITSM-Vorgang);
  
• E-Mail (bspw. zur Übermittlung von Ad-hoc-Reports);
  
• TI-ITSM-System zur Informationsübermittlung eines übergreifenden Vorgangs entsprechend [GS-A_3886-*].

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

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

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

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

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

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

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

GS-A_3981 - Annahme eines übergreifenden Problems

TI-ITSM-Teilnehmer MÜSSEN das übergreifende Problem annehmen, wenn sie die Serviceverantwortung haben.
[<=]

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

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_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_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 9: Tab_Betr_TIP_102 PRO – Festlegung von Dringlichkeit

Tabelle 10: Tab_Betr_TIP_103 PRO – Festlegung von Auswirkung

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

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

GS-A_3920-01 - 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
  

• es kann keine Einigung über die Serviceverantwortung für den übergreifenden Vorgang mit anderen TI-ITSM-Teilnehmern erzielt werden
  

• es kann keine Einigung über die Lösungsunterstützung für den übergreifenden Vorgang mit anderen TI-ITSM-Teilnehmern erzielt werden
  

• es treten bei der Bewertung oder Durchführung eines Changes schwerwiegende Konflikte auf
  

• es ist zur Gewährleistung der Performance, Sicherheit und Stabilität der zentralen und dezentralen Produkte eine übergeordnete Koordination notwendig.

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

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

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

GS-A_3904 - Annahme eines übergreifenden Incidents

TI-ITSM-Teilnehmer MÜSSEN einen übergreifenden Incident annehmen, wenn sie die Serviceverantwortung haben.
[<=]

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

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

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 11: Tab_Betr_TIP_026 INC – Festlegung der Dringlichkeit

Tabelle 12: Tab_Betr_TIP_027 INC – Festlegung von Auswirkung

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

A_18407-01 - Change Management - Unterstützung bei Change-Verifikation

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

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

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

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

A_13575 - Qualität von RfC

Der RfC-stellende TI-ITSM-Teilnehmer MUSS die RfC 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. [<=]