Beschluss (EU) 2024/1873 des Rates vom 24. Juni 2024 über den im Namen der Europäischen Union in dem durch das Abkommen zwischen der Europäischen Union und der Schweizerischen Eidgenossenschaft zur Verknüpfung ihrer jeweiligen Systeme für den Handel mit Treibhausgasemissionen eingerichteten Gemeinsamen Ausschuss im Hinblick auf die Änderung des Anhangs II des Abkommens sowie der gemeinsamen Verfahrensvorschriften und der technischen Verknüpfungsstandards zu vertretenden StandpunktText von Bedeutung für den EWR.

Durchsuchbarer Text in vereinfachter Darstellung. Tabellen, Abbildungen und verbindliche Gestaltung bitte anhand der Originaldateien prüfen.

äße Funktionieren der Verknüpfung sind weitere technische Spezifikationen erforderlich, um sie weiter zu operationalisieren. Gemäß Artikel 3 Absatz 7 des Abkommens werden diese Aspekte eingehend in dem Dokument mit technischen Verknüpfungsstandards (Linking Technical Standards, LTS) geregelt, das gesondert durch einen Beschluss des Gemeinsamen Ausschusses angenommen werden soll. Die gemeinsamen Verfahrensvorschriften sollen sicherstellen, dass die IT-Dienste im Zusammenhang mit dem Funktionieren der Verknüpfung zwischen den Registern des EU-EHS und des EHS der Schweiz wirksam und effizient ausgeführt werden, namentlich im Hinblick auf die Erledigung von Dienstanfragen, die Behebung von Dienstausfällen und von Problemen sowie auf die Durchführung von betrieblichen Routineaufgaben im Einklang mit internationalen Normen für das IT-Servicemanagement. Für die dauerhafte Registerverknüpfung sind lediglich die folgenden gemeinsamen Verfahrensvorschriften erforderlich, die Teil des vorliegenden Dokuments sind: — Vorfallmanagement — Problemmanagement — Anfrageerledigung — Änderungsmanagement — Releasemanagement — Sicherheitsvorfall-Management — Informationssicherheits-Management 2.2. Adressaten Zielgruppe dieser gemeinsamen Verfahrensvorschriften sind die Supportteams des Registers der EU bzw. der Schweiz. 3. VORGEHEN UND STANDARDS Der folgende Grundsatz gilt für alle gemeinsamen Verfahrensvorschriften: — Die EU und die Schweiz vereinbaren, die gemeinsamen Verfahrensvorschriften auf der Grundlage der Version 4 der Bibliothek für Informationstechnologie-Infrastruktur (ITIL) festzulegen. Praktiken aus diesem Standard werden herangezogen und an den besonderen Bedarf im Zusammenhang mit der dauerhaften Registerverknüpfung angepasst. — Die für die Regelung der gemeinsamen Verfahrensvorschriften erforderliche Kommunikation und Abstimmung zwischen den beiden Vertragsparteien erfolgt über die Register-Servicedesks der Schweiz und der EU. Aufgaben werden stets innerhalb einer Vertragspartei zugewiesen. — Besteht Uneinigkeit über die Handhabung einer gemeinsamen Verfahrensvorschrift, so wird diese von beiden Servicedesks gemeinsam untersucht und gelöst. Kann keine Einigung erzielt werden, wird die Suche nach einer gemeinsamen Lösung an die nächsthöhere Ebene eskaliert. Eskalationsebenen EU CH Erste Ebene Servicedesk der EU Servicedesk der Schweiz Zweite Ebene EU-Operationsmanager Anwendungsmanager des Schweizer Registers Dritte Ebene Gemeinsamer Ausschuss (der diese Zuständigkeit angesichts des Artikels 12 Absatz 5 des Abkommens delegieren könnte) Vierte Ebene Gemeinsamer Ausschuss, falls auf der dritten Ebene delegiert wird — Jede Vertragspartei kann die Verfahren für den Betrieb ihres eigenen Registersystems unter Berücksichtigung der Anforderungen an diese gemeinsamen Verfahrensvorschriften und der damit verbundenen Schnittstellen festlegen. — Die gemeinsamen Verfahrensvorschriften werden durch ein IT-Servicemanagement-Tool (ITSM-Tool) unterstützt, insbesondere in Bezug auf Vorfallmanagement, Problemmanagement und Anfrageerledigung sowie die Kommunikation zwischen den beiden Vertragsparteien. — Darüber hinaus ist der Informationsaustausch per E-Mail zulässig. — Beide Vertragsparteien stellen sicher, dass die Anforderungen an die Informationssicherheit im Einklang mit den Handhabungsanweisungen erfüllt werden. 4. VORFALLMANAGEMENT Ziel des Vorfallmanagement-Prozesses ist es, das normale Leistungsniveau von IT-Diensten so schnell wie möglich nach einem Vorfall mit möglichst geringer Störung der Geschäftsabläufe wiederherzustellen. Darüber hinaus sollte das Vorfallmanagement für Berichtszwecke Aufzeichnungen über Vorfälle führen und sich in andere Prozesse eingliedern, um ständige Verbesserungen zu erzielen. Allgemein betrachtet umfasst das Vorfallmanagement die folgenden Tätigkeiten: — Ermittlung und Aufzeichnung von Vorfällen — Einstufung und Erstsupport — Untersuchung und Diagnose — Lösung und Wiederherstellung — Abschluss des Vorfalls Während der gesamten Dauer eines Vorfalls muss die kontinuierliche Handhabung von Eigentumsrechten, Überwachung, Verfolgung und Kommunikation durch den Vorfallmanagement-Prozess gewährleistet sein. 4.1. Ermittlung und Aufzeichnung von Vorfällen Ein Vorfall kann von einem Supportteam, durch automatisierte Überwachungstools oder durch technisches Personal im Zuge der Routineüberwachung ermittelt werden. Ein ermittelter Vorfall muss aufgezeichnet werden; dabei ist ihm eine eindeutige Kennung zuzuweisen, die eine ordnungsgemäße Verfolgung und eine ordnungsgemäße Überwachung ermöglicht. Die eindeutige Kennung eines Vorfalls ist die Kennung, die ihm im gemeinsamen Ticketsystem des Servicedesks der Vertragspartei (EU oder Schweiz), die den Vorfall festgestellt hat, zugewiesen wird; sie muss in jeder Mitteilung im Zusammenhang mit dem Vorfall angegeben werden. Anlaufstelle für alle Vorfälle sollte der Servicedesk der Vertragspartei sein, der das Ticket erfasst hat. 4.2. Einstufung und Erstsupport Durch die Einstufung eines Vorfalls soll verstanden und ermittelt werden, welches System und/oder welcher Dienst von einem Vorfall in welchem Umfang betroffen ist. Um wirksam zu sein, sollte der Vorfall bei der Einstufung im ersten Anlauf zur korrekten Ressource geroutet werden, sodass der Vorfall schneller gelöst werden kann. In der Einstufungsphase sollte der Vorfall nach seiner Wirkung und Dringlichkeit kategorisiert und priorisiert werden, damit er innerhalb eines Zeitrahmen behandelt wird, der der Priorität gerecht wird. Besteht die Möglichkeit, dass der Vorfall sich auf die Vertraulichkeit oder die Integrität sensibler Daten und/oder auf die Systemverfügbarkeit auswirkt, muss der Vorfall außerdem als Sicherheitsvorfall deklariert und nach dem Verfahren behandelt werden, das im Kapitel „Sicherheitsvorfallmanagement“ dieses Dokuments festgelegt ist. Soweit möglich nimmt der Servicedesk, der das Ticket erfasst hat, eine erste Diagnose vor. Zu diesem Zweck stellt der Servicedesk fest, ob es sich bei dem Vorfall um einen bekannten Fehler handelt. Ist dies der Fall, so ist der Lösungsweg oder die Ausweichlösung bereits bekannt und dokumentiert. Konnte der Servicedesk den Vorfall lösen, so wird er den Vorfall zu diesem Zeitpunkt abschließen, da der Primärzweck des Vorfallmanagements erfüllt wurde (nämlich die schnelle Wiederherstellung des Dienstes für den Endnutzer). Anderenfalls eskaliert der Servicedesk den Vorfall zur weiteren Untersuchung und Diagnose an die geeignete Resolvergruppe. 4.3. Untersuchung und Diagnose Die Untersuchung und Diagnose von Vorfällen erfolgt, wenn der Servicedesk einen Vorfall nicht im Rahmen der Erstdiagnose lösen kann und dieser daher in geeigneter Weise eskaliert wird. Die Eskalation von Vorfällen ist Teil des Untersuchungs- und Diagnoseprozesses. Eine gemeinsame Praxis in der Untersuchungs- und Diagnosephase ist der Versuch, den Vorfall unter kontrollierten Bedingungen nachzuvollziehen. Bei der Untersuchung und Diagnose eines Vorfalls ist wichtig, dass die richtige Abfolge der Ereignisse, die zu dem Vorfall geführt haben, deutlich wird. Mit der Eskalation wird anerkannt, dass ein Vorfall auf der derzeitigen Supportebene nicht gelöst werden kann und an eine Supportgruppe auf höherer Ebene oder an die andere Vertragspartei weitergeleitet werden muss. Die Eskalation kann auf zwei Wegen erfolgen: horizontal (funktionsabhängig) oder vertikal (hierarchisch). Der Servicedesk, der den Vorfall aufgezeichnet und ausgelöst hat, ist dafür verantwortlich, den Vorfall an die geeignete Ressource zu eskalieren und den Gesamtstatus und die Zuweisung des Vorfalls zu verfolgen. Die Vertragspartei, der der Vorfall zugewiesen wurde, ist dafür verantwortlich, sicherzustellen, dass die angeforderten Maßnahmen zügig durchgeführt werden, und ihren eigenen Servicedesk auf dem Laufenden zu halten. 4.4. Lösung und Wiederherstellung Die Vorfalllösung und die Wiederherstellung finden statt, sobald der Vorfall vollständig verstanden wurde. Eine Lösung für einen Vorfall zu finden bedeutet, dass ein Weg gefunden wurde, um Abhilfe zu schaffen. Der Akt der Anwendung der Lösung ist die Wiederherstellungsphase. Wurde der Dienstausfall von den geeigneten Ressourcen behoben, so wird der Vorfall an den zuständigen Servicedesk zurückgeleitet, der den Vorfall erfasst hat; der Servicedesk bestätigt dem Initiator des Vorfalls, dass der Fehler berichtigt wurde und der Vorfall abgeschlossen werden kann. Die Erkenntnisse aus der Bearbeitung des Vorfalls sind für die künftige Verwendung aufzuzeichnen. Die Wiederherstellung kann von IT-Supportpersonal durchgeführt werden oder durch Übermittlung von zu beachtenden Anweisungen an den Endnutzer. 4.5. Abschluss des Vorfalls Der Abschluss ist der letzte Schritt des Vorfallmanagement-Prozesses und erfolgt kurz nach der Lösung des Vorfalls. Aus der Checkliste der Tätigkeiten, die in der Abschlussphase durchzuführen sind, werden die folgenden hervorgehoben: — Überprüfung der Kategorie, in die der Vorfall ursprünglich eingeordnet wurde; — ordnungsgemäße Erfassung aller Informationen zu dem Vorfall; — ordnungsgemäße Dokumentation des Vorfalls und Aktualisierung der Wissensbasis; — angemessene Kommunikation mit allen direkt oder indirekt von dem Vorfall betroffenen Beteiligten. Ein Vorfall ist förmlich abgeschlossen, sobald der Servicedesk die Vorfallabschlussphase ausgeführt und die andere Vertragspartei darüber unterrichtet hat. Ein einmal geschlossener Vorfall wird nicht wieder geöffnet. Tritt ein Vorfall innerhalb kurzer Zeit erneut auf, wird nicht der ursprüngliche Vorfall wieder geöffnet, sondern stattdessen muss ein neuer Vorfall erfasst werden. Wird der Vorfall sowohl vom Servicedesk der EU als auch von dem der Schweiz verfolgt, so ist der Servicedesk, der das Ticket erfasst hat, für den endgültigen Abschluss zuständig. 5. PROBLEMMANAGEMENT Dieses Verfahren sollte immer dann angewandt werden, wenn ein Problem ermittelt und dadurch der Problemmanagement-Prozess ausgelöst wird. Das Problemmanagement konzentriert sich auf Qualitätssteigerung und die Verringerung der Zahl der gemeldeten Vorfälle. Ein Problem kann einen oder mehrere Vorfälle verursachen. Wird ein Vorfall gemeldet, so besteht das Ziel des Vorfallmanagements darin, den Dienst so schnell wie möglich wiederherzustellen, was auch Ausweichlösungen umfassen kann. Wird ein Problem gestellt, so besteht das Ziel darin, den Ursprung des Problems zu untersuchen, um herauszufinden, welche Änderung gewährleistet, dass das Problem und die entsprechenden Vorfälle nicht mehr auftreten. 5.1. Ermittlung und Aufzeichnung eines Problems Je nachdem, welche Vertragspartei das Ticket initiiert hat, ist entweder der Servicedesk der EU oder derjenige der Schweiz die Anlaufstelle für Fragen im Zusammenhang mit einem Problem. Die einmalige Kennung eines Problems ist die vom IT-Servicemanagement zugewiesene Kennung. Sie muss in jeder Mitteilung im Zusammenhang mit dem Problem angegeben werden. Ein Problem kann durch einen Vorfall ausgelöst oder auf Eigeninitiative mit dem Ziel geöffnet werden, im System ermittelte Mängel zu einem beliebigen Zeitpunkt zu beheben. 5.2. Problempriorisierung Zwecks einfacherer Verfolgung können Probleme unter Berücksichtigung der Wirkung und Häufigkeit der damit zusammenhängenden Vorfälle genau wie Vorfälle nach ihrem Schweregrad und ihrer Priorität kategorisiert werden. 5.3. Untersuchung und Diagnose eines Problems Jede Vertragspartei kann auf ein Problem hinweisen; der Servicedesk der Vertragspartei, von der die Initiative ausgeht, ist dafür verantwortlich, das Problem zu erfassen, es der geeigneten Ressource zuzuweisen und den Gesamtstatus des Problems zu verfolgen. Die Resolvergruppe, an die das Problem eskaliert wurde, ist für die zügige Behandlung des Problems und die Kommunikation mit dem Servicedesk verantwortlich. Auf Anfrage sind beide Vertragsparteien dafür verantwortlich, sicherzustellen, dass die zugewiesenen Maßnahmen durchgeführt werden, und ihren eigenen Servicedesk auf dem Laufenden zu halten. 5.4. Problemlösung Die Resolvergruppe, der das Problem zugewiesen wurde, ist verantwortlich dafür, das Problem zu lösen und dem Servicedesk ihrer eigenen Vertragspartei sachdienliche Informationen zu übermitteln. Die Erkenntnisse aus der Bearbeitung des Problems sind für die künftige Verwendung aufzuzeichnen. 5.5. Abschluss eines Problems Ein Problem ist förmlich geschlossen, sobald das Problem durch die Umsetzung der Änderung behoben wurde. Die Phase des Problemabschlusses wird von dem Servicedesk wahrgenommen, der das Problem erfasst und den Servicedesk der anderen Vertragspartei darüber informiert hat. 6. ANFRAGEERLEDIGUNG Bei dem Prozess der Anfrageerledigung handelt es sich um das durchgehende Management einer Anfrage nach einem neuen oder bestehenden Dienst vom Zeitpunkt ihrer Registrierung und Genehmigung bis zum Abschluss. Bei Dienstanfragen handelt es sich in der Regel um kleine, vordefinierte, wiederholbare, häufige, vorab genehmigte und verfahrenstechnische Anfragen. Die wichtigsten Schritte werden nachstehend kurz beschrieben: 6.1. Einleitung einer Anfrage Die Angaben zu einer Dienstanfrage werden dem Servicedesk der EU oder dem der Schweiz per E-Mail, Telefon oder über das IT-Servicemanagement-Tool oder jeden anderen vereinbarten Kommunikationskanal übermittelt. 6.2. Erfassung und Analyse von Anfragen Anlaufstelle für alle Dienstanfragen sollte der Servicedesk der EU oder derjenige der Schweiz sein, je nachdem, welche Vertragspartei die Dienstanfrage eingeleitet hat. Der Servicedesk ist dafür verantwortlich, die Dienstanfrage mit der gebotenen Sorgfalt zu erfassen und zu analysieren. 6.3. Genehmigung der Anfrage Der Sachbearbeiter des Servicedesks der Vertragspartei, die die Dienstanfrage eingeleitet hat, prüft, ob für die Anfrage etwaige Genehmigungen der anderen Vertragspartei erforderlich sind, und holt diese gegebenenfalls ein. Wird die Dienstanfrage nicht genehmigt, aktualisiert der Servicedesk das Ticket und schließt es. 6.4. Anfrageerledigung Dieser Schritt dient der wirksamen und effizienten Bearbeitung von Dienstanfragen. Hierbei ist unter folgenden Fällen zu unterscheiden: — Die Erledigung der Dienstanfrage betrifft nur eine Vertragspartei. In diesem Fall erteilt diese Vertragspartei die Arbeitsaufträge und koordiniert die Ausführung. — Die Erledigung der Dienstanfrage betrifft sowohl die EU als auch die Schweiz. In diesem Fall erteilen die Servicedesks die Arbeitsaufträge in ihrem Zuständigkeitsbereich. Der Ablauf der Erledigung der Dienstanfrage wird von den beiden Servicedesks gemeinsam koordiniert. Die Gesamtverantwortung trägt der Servicedesk, der die Dienstanfrage erhalten und initiiert hat. Sobald die Dienstanfrage erledigt wurde, muss sie den Status „Erledigt“ (Resolved) erhalten. 6.5. Anfrageeskalation Der Servicedesk kann die offene Dienstanfrage erforderlichenfalls an die geeignete Ressource (Drittpartei) eskalieren. Eskaliert wird an die jeweilige Drittpartei, d. h. der Servicedesk der EU muss den Servicedesk der Schweiz einschalten, um an eine Schweizer Drittpartei zu eskalieren und umgekehrt. Die Drittpartei, an die die Dienstanfrage eskaliert wurde, ist für die zügige Behandlung der Dienstanfrage und die Kommunikation mit dem Servicedesk, der diese Anfrage eskaliert hat, verantwortlich. Der Servicedesk, der die Dienstanfrage erfasst hat, ist für die Verfolgung des Gesamtstatus und der Zuweisung einer Dienstanfrage verantwortlich. 6.6. Überprüfung der Anfrageerledigung Der zuständige Servicedesk unterzieht die Aufzeichnungen zu der Dienstanfrage vor dem Abschluss einer abschließenden Qualitätskontrolle. So soll sichergestellt werden, dass die Dienstanfrage tatsächlich bearbeitet wurde und dass alle zur Beschreibung des Lebenszyklus der Dienstanfrage erforderlichen Angaben mit hinreichenden Einzelheiten vorliegen. Darüber hinaus sind die Erkenntnisse aus der Bearbeitung der Anfrage für die künftige Verwendung aufzuzeichnen. 6.7. Abschluss der Anfrage Sind sich die Vertragsparteien, denen die Anfrage zugewiesen wurde, einig, dass die Dienstanfrage erledigt wurde, und betrachtet der Urheber der Anfrage den Fall als gelöst, so wird als Nächstes der Status „Abgeschlossen“ (Closed) erteilt. Eine Dienstanfrage wird förmlich abgeschlossen, sobald der Servicedesk, der die Anfrage erfasst hat, die Anfrageabschlussphase abgewickelt und den Servicedesk der anderen Vertragspartei unterrichtet hat. 7. ÄNDERUNGSMANAGEMENT Das Änderungsmanagement soll sicherstellen, dass alle Änderungen zur Kontrolle von IT-Infrastruktur effizient und zeitnah nach standardisierten Methoden und Verfahren durchgeführt werden, damit die Zahl und die Auswirkungen etwaiger Vorfälle in diesem Zusammenhang auf den Dienst möglichst gering gehalten werden. Änderungen der IT-Infrastruktur können sich reaktiv infolge von Problemen oder von außen auferlegten Anforderungen, z. B Änderungen der Rechtsvorschriften, oder proaktiv ergeben, indem eine Verbesserung von Effizienz und Wirksamkeit angestrebt wird oder um unternehmerische Initiativen zu ermöglichen oder zu reflektieren. Der Änderungsmanagement-Prozess umfasst verschiedene Schritte, bei denen jede Einzelheit einer Änderungsanfrage für die künftige Nachverfolgung erfasst wird. Diese Prozesse gewährleisten, dass die Änderung vor ihrer Einführung validiert und getestet wird. Der Releasemanagement-Prozess sorgt für eine erfolgreiche Einführung. 7.1. Änderungsanfrage Eine Änderungsanfrage (RFC) wird dem Änderungsmanagement-Team zur Validierung und Genehmigung vorgelegt. Anlaufstelle für alle Änderungsanfragen sollte der Servicedesk der EU oder derjenige der Schweiz sein, je nachdem, welche Vertragspartei die Anfrage eingeleitet hat. Der Servicedesk ist dafür verantwortlich, die Anfrage mit der gebotenen Sorgfalt zu erfassen und zu analysieren. Änderungsanfragen können ausgelöst werden durch — einen Vorfall, der eine Änderung verursacht; — ein bestehendes Problem, das zu einer Änderung führt; — einen Endnutzer, der eine neue Änderung anfragt; — eine Änderung infolge laufender Wartungsarbeiten; — Änderungen von Rechtsvorschriften. 7.2. Bewertung und Planung einer Änderung Diese Phase umfasst die Bewertung von Änderungen und Planungstätigkeiten. Dazu gehören Priorisierung und Planungstätigkeiten zur Minimierung der Risiken und Auswirkungen. Wenn die Durchführung der Änderungsanfrage sowohl die EU als auch die Schweiz betrifft, überprüft die Vertragspartei, die die Anfrage erfasst hat, die Änderungsbewertung und -planung mit der anderen Vertragspartei. 7.3. Genehmigung einer Änderung Eine eingeloggte Änderungsanfrage muss von der zuständigen Eskalationsebene genehmigt werden. 7.4. Durchführung der Änderung Die Durchführung der Änderung erfolgt im Rahmen des Releasemanagement-Prozesses. Die Releasemanagement-Teams beider Vertragsparteien folgen bei der Planung und dem Testen ihren eigenen Prozessen. Die Änderung wird überprüft, sobald die Durchführung abgeschlossen ist. Um sicherzustellen, dass alles planmäßig abgewickelt wurde, wird der bestehende Änderungsmanagement-Prozess laufend überprüft und bei Bedarf aktualisiert. 8. RELEASEMANAGEMENT Ein Release entspricht einer oder mehreren Änderungen eines IT-Dienstes, die in einem Releaseplan zusammengefasst sind und zusammen genehmigt, vorbereitet, aufgebaut, getestet und eingeführt werden. Bei einem Release kann es sich um eine Fehlerbehebung, eine Änderung der Hardware oder anderer Komponenten, Softwareänderungen, Aktualisierungen von Anwendungsversionen und/oder Änderungen der Dokumentation bzw. von Prozessen handeln. Jedes Release wird inhaltlich als Einheit verwaltet, getestet und eingeführt. Releasemanagement zielt auf die Planung, den Aufbau, das Testen und die Validierung sowie die Schaffung der Fähigkeit ab, die konzipierten Dienste bereitzustellen, mit denen die Anforderungen der Beteiligten erfüllt und die angestrebten Ziele erreicht werden. Bei der Designkoordinierung werden für alle Änderungen des Dienstes Akzeptanzkriterien festgelegt und dokumentiert, die den Releasemanagement-Teams zur Verfügung gestellt werden. Das Release besteht in der Regel aus mehreren Problembehebungen und Verbesserungen für einen Dienst. Es umfasst die erforderliche neue oder geänderte Software oder jegliche neue oder geänderte Hardware, die zur Umsetzung der genehmigten Änderungen erforderlich ist. 8.1. Planung des Releases Als erster Schritt in diesem Prozess werden genehmigte Änderungen Releasebündeln zugewiesen und der Umfang und Inhalt des Releases festgelegt. Auf der Grundlage dieser Informationen wird als Teilprozess der Releaseplanung ein Zeitplan für den Aufbau, das Testen und die Einführung des Releases aufgestellt. Bei der Planung sollte Folgendes festgelegt werden: — Umfang und Inhalt des Releases; — Risikobewertung und Risikoprofil des Releases; — von dem Release betroffene Kunden/Nutzer; — für das Release zuständiges Team; — Bereitstellungs- und Einführungsstrategie; — Ressourcen für das Release und dessen Einführung. Die beiden Vertragsparteien unterrichten einander über ihre Releaseplanung und ihre Wartungsfenster. Wenn ein Release sowohl die EU als auch die Schweiz betrifft, koordinieren diese die Planung und legen ein gemeinsames Wartungsfenster fest. 8.2. Aufbau und Testen des Releasebündels In der Aufbau- und Testphase im Rahmen des Releasemanagement-Prozesses wird zum einen das Konzept für die Ausführung des Releases oder des Releasebündels und die Wartung der kontrollierten Umgebungen vor der Vornahme der Änderung und zum anderen das Konzept für das Testen aller Änderungen in allen betroffenen Umgebungen nach dem Release festgelegt. Wenn ein Release sowohl die EU als auch die Schweiz betrifft, koordinieren diese die Bereitstellungpläne und die Tests. Dies umfasst die folgenden Fragen: — Wie und wann werden Releaseeinheiten und Dienstleistungskomponenten bereitgestellt? — Was sind die typischen Vorlaufzeiten und was geschieht bei Verzögerungen? — Wie kann der Fortschritt der Bereitstellung verfolgt und eine Bestätigung eingeholt werden? — Was sind die Messgrößen für die Überwachung und Feststellung des Gelingens der Releasemaßnahme? — Welches sind die gemeinsamen Testfälle für wichtige Funktionen und Änderungen? Am Ende dieses Teilprozesses sind alle erforderlichen Releasekomponenten für den Schritt der realen Einführung bereit. 8.3. Vorbereitung der Einführung Beim Teilprozess der Vorbereitung wird sichergestellt, dass Kommunikationspläne korrekt festgelegt werden und Mitteilungen bereitliegen, um an alle betroffenen Beteiligten und Endnutzer versandt zu werden, und dass das Release in den Änderungsmanagement-Prozess eingebunden wird, um zu gewährleisten, dass alle Änderungen kontrolliert durchgeführt und von den erforderlichen Gremien genehmigt werden. Wenn ein Release sowohl die EU als auch die Schweiz betrifft, koordinieren diese die folgenden Tätigkeiten: — Aufzeichnungen zur Änderungsanfrage für die Planung und Vorbereitung der Einführung in die Produktionsumgebung; — Aufstellung des Durchführungsplans; — Zurücksetzungskonzept, damit bei einer misslungenen Einführung der vorherige Stand wiederhergestellt werden kann; — Mitteilungen an alle notwendigen Parteien; — Einholung der Genehmigung für die Durchführung des Releases von der zuständigen Eskalationsebene. 8.4. Zurücksetzen des Releases Ist eine Einführung misslungen oder haben Tests ergeben, dass die Einführung ein Fehlschlag war oder die vereinbarten Akzeptanz-/Qualitätskriterien nicht erreicht hat, müssen die Releasemanagement-Teams beider Vertragsparteien zum vorigen Stand zurückkehren. Alle notwendigen Beteiligten müssen darüber unterrichtet werden, einschließlich der betroffenen/anvisierten Endnutzer. Bei e