[Seite 1]
Allgemeine Rahmenbedingungen
IT-Service Management
Version 3.0 - Stand 25.02.2026
Content Management System - 250210
Kaufmännische Krankenkasse - KKH Karl-Wiechert-Allee 61 30625 Hannover
Allgemeine Rahmenbedingungen IT-Service Management Version 3.0 1
[Seite 2]
Inhaltsverzeichnis 1 Einleitung ................................................................................................................. 3 1.1 Erläuterung zur Nutzung des Dokuments ......................................................... 3 1.2 Gültigkeit der ITSM-Anforderungen in Abhängigkeit vom Betriebsmodell ......... 3 1.3 Begriffsdefinition und Abkürzungsverzeichnis ................................................... 4 2 IT-Service Management ........................................................................................... 6 2.1 Kollaboration ..................................................................................................... 7 2.2 Service Organisation ....................................................................................... 13 2.2.1 Servicezeiten ........................................................................................... 13 2.2.2 1st-Level-Support ..................................................................................... 14 2.2.3 Ticketabschluss durch den AN ................................................................ 14 2.3 Eskalationsstufen und Kommunikationswege ................................................. 15 2.4 Service Meetings ............................................................................................ 17 2.5 Service Level Management............................................................................. 18 2.5.1 Service-Level-Definition ........................................................................... 19 2.6 Wartungsfenster .............................................................................................. 24 2.7 ITSM-Prozesse ............................................................................................... 25 2.7.1 Incident Management .............................................................................. 25 2.7.2 Problem Management.............................................................................. 27 2.7.3 Change-Management & Enablement ....................................................... 28 2.7.4 Availability Management .......................................................................... 29 2.7.5 Release Management .............................................................................. 29 2.7.6 IT Service Continuity Management .......................................................... 30 2.7.7 Service Request Management ................................................................. 31 2.8 Reporting ........................................................................................................ 31
Allgemeine Rahmenbedingungen IT-Service Management Version 3.0 2
[Seite 3]
1 Einleitung
Diese allgemeine Rahmenbedingung dient als Ergänzung der jeweiligen Leistungsbeschreibung im Rahmen der Beschaffung von IT-Produkten und IT- Dienstleistungen. Sie umfasst Detaillierungen zu den zur Auswahl stehenden Betriebsmodellen, den einzuhaltenden Service Level Agreements sowie den im Rahmen der Leistungserbringung beizubringenden Dienstleistungen und weiteren Mindestanforderungen.
Sie ist in Verbindung mit der jeweils relevanten Leistungsbeschreibung zu verstehen. Alles, was in dieser Rahmenbedingung widersprüchlich, unklar oder aus Sicht des Bieters nicht ausreichend spezifiziert ist oder dem Bieter Raum für unterschiedliche Interpretationen zulässt, muss der Bieter vor der Angebotsabgabe eine schriftliche Klarstellung bei der KKH anfordern. Dasselbe gilt auch nach Zuschlagserteilung für sämtliche Ausführungen des Auftragnehmers (AN).
Der AN ist verpflichtet, die technischen und organisatorischen Vorgaben des Auftraggebers (AG) zu bewerten und deren Folgen zu analysieren. Erkennt der AN aufgrund seiner Expertise Fehler oder Unklarheiten in den Vorgaben des AG, ist der AN verpflichtet, den AG umgehend, vollständig und präzise über die wesentlichen Auswirkungen dieser Vorgaben im Vorfeld einer Umsetzung zu informieren.
1.1 Erläuterung zur Nutzung des Dokuments
Dieses Dokument definiert die allgemeinen IT-Service-Management-Anforderungen für das Betriebsmodell SaaS (Software as a Service).
1.2 Gültigkeit der ITSM-Anforderungen in Abhängigkeit vom Betriebsmodell
Die in diesen allgemeinen Rahmenbedingungen für IT-Service Management definierten Anforderungen stellen grundlegende Positionen als Standardleistungen im Rahmen der Vergabe dar.
Gegenstand dieser Beschaffung ist das Betriebsmodell SaaS (Software as a Service), im Rahmen dessen der Auftragnehmer die vereinbarten Betriebs- und Service- Leistungen für ein Web-Content-Management-System erbringt.
Der Auftragnehmer übernimmt hierbei die Verantwortung für Bereitstellung und Betrieb der Software als Service sowie Wartung, Überwachung und Support der vereinbarten Leistungen innerhalb seines Verantwortungsbereichs.
Allgemeine Rahmenbedingungen IT-Service Management Version 3.0 3
[Seite 4]
Der Zugriff auf das Web-Content-Managemant-System erfolgt über das Internet, ohne die Software beim Auftraggeber lokal zu installieren oder zu verwalten.
Incidents, Problems, Changes und Service Requests werden entsprechend der jeweiligen Betriebsverantwortung im Rahmen der vereinbarten IT-Service-Management- Prozesse bearbeitet.
1.3 Begriffsdefinition und Abkürzungsverzeichnis
| Begriff, Abkürzung | Beschreibung |
|---|---|
| Auftraggeber (AG) | Der Auftraggeber ist in dieser Vergabe die Kaufmännische Krankenkasse – KKH. Sie stellt die Vertragspartei dar, die einem anderen im Rahmen dieser Vergabe einen Auftrag zur entgeltlichen Erbringung von Leistungen überträgt. |
| Auftragnehmer (AN) | Der Auftragnehmer ist der Vertragspartner, der sich zur Erbringung der ausgeschriebenen Leistungen gegenüber dem Auftraggeber verpflichtet hat. |
| Anbieter / Bieter | Unter einem Anbieter oder Bieter versteht man ein Unternehmen, das im Rahmen dieses Vergabeverfahren ein Angebot abgibt. Hat der Bieter den Zuschlag durch die KKH erhalten, wird er als Auftragnehmer (AN) bezeichnet. |
| Arbeitstage | Unter Arbeitstage werden die Tage Montag bis Freitag verstanden. Ausnahmen bilden bundeseinheitliche Feiertage sowie der 24.12. und 31.12., es sei denn, diese fallen auf einen Samstag oder Sonntag. |
| Bearbeitungszeit | Unter Bearbeitungszeit wird die Zeit verstanden, in der eine Anfrage aktiv bearbeitet und umgesetzt wird. |
| Betriebsmodell - Software as a Service (SaaS) | Die Bereitstellung und der Betrieb von Anwendungen erfolgen durch einen externen Provider als Service. Die Nutzer greifen auf die Anwendungen über das Internet zu, ohne diese lokal installieren oder verwalten zu müssen. |
| Betriebsphase | Unmittelbar nach Zuschlagserteilung oder nach Fertigstellung (Abnahme) einer (Teil)Leistung geht diese (Teil)Leistung in die Betriebsphase über. In dieser Phase müssen die von der KKH in der Leistungsbeschreibung dargestellten Betriebsaufgaben und - Verantwortlichkeiten (z.B. Wartung und Service sowie Betriebsunterstützungsdienstleistungen) in der geforderten Art, Umfang sowie Qualität vom Dienstleister/Provider (= AN) übernommen werden. |
| Betriebszeit | Unter der Betriebszeit versteht man den Zeitraum, in dem ein technisches System oder ein technischer Service mit einem definierten Funktionsumfang für die Datenverarbeitung ohne Unterbrechung zur Verfügung steht. |
| CAB | Change Advisory Board |
Allgemeine Rahmenbedingungen IT-Service Management Version 3.0 4
[Seite 5]
| Begriff, Abkürzung | Beschreibung |
|---|---|
| COBIT | Control Objectives for Information and Related Technology |
| Anwender | Eine Person, die einen IT-Service im Rahmen ihrer täglichen Aufgaben einsetzt. Anwender unterscheiden sich von Kunden, da manche Kunden die IT-Services nicht direkt nutzen. |
| Fertigmeldung | Der AN muss unmittelbar nach Beendigung einer Entstörung oder dem Abschluss von Arbeiten den AG unaufgefordert schriftlich über den abgestimmten Kommunikationsweg informieren. |
| Hauptverwaltung (HV) | Hauptverwaltung der KKH ist der größte Einzelstandort der KKH und umfasst eine Vielzahl von Organisationseinheiten mit Back- Office-Charakter. Über die HV werden zentral IT und Dienstleistungen für die Mitarbeitenden und Standorte bereitgestellt. |
| IT-Infrastruktur | Die Gesamtheit aller Komponenten des aktiven und passiven Netzwerks sowie der gesondert abgesicherten EDV- Stromversorgung. |
| IT-Service | Die Leistungen der IT, die einem Kunden bereitgestellt werden, sind Services. Ein IT-Service wird durch eine Kombination von Informationstechnologie, Menschen und Prozessen gebildet. Ein kundenorientierter IT-Service unterstützt direkt die Geschäftsprozesse eines oder mehrerer Kunden und seine Service-Level-Ziele sollten in einem Service-Level-Agreement (SLA) definiert werden. Andere unterstützende IT-Services werden benötigt, um kundenorientierte Services zu liefern. (COBIT, ITIL). |
| ITIL | Information Technology Infrastructure Library |
| ITSM | IT-Service-Management (ITSM) bezeichnet die Gesamtheit von Maßnahmen und Methoden, die erforderlich sind, um die bestmögliche Unterstützung von Geschäftsprozessen (GP) durch die IT-Organisation zu gewährleisten. |
| Ivanti Service Manager (ISM) | Workflow-orientiertes Werkzeug zur Unterstützung der ITSM- Prozesse. Die KKH setzt Ivanti Service Manager (ISM) als ITSM- Tool ein. |
| KKH | Die Kaufmännische Krankenkasse Halle (Saale) Ersatzkasse V.V.a.G. („KKH“) ist seit dem 01. April 1926 der Rechtsnachfolger der am 10. März 1890 in Halle (Saale) eingeschriebenen „Kranken- und Begräbniskasse des Kaufmännischen Vereins zu Halle/Saale“ und führt laut Satzung vom 01.07.2009 den Namen „Kaufmännische Krankenkasse – KKH“ sowie die Kurzbezeichnung „KKH“. Die KKH ist in dieser Vergabe der Auftraggeber (AG). |
| KPI | Key-Performance-Indicator |
| Non-Standard Service Request (NSSR) | Ein Non-Standard Service Request ist eine Art von Serviceanfrage, die nicht den Standardverfahren oder -vorlagen entspricht, die von einer Organisation für die Bearbeitung und Erfüllung von Serviceanfragen verwendet werden. Diese Anfragen erfordern oft eine erweiterte Bearbeitung oder Anpassung. |
Allgemeine Rahmenbedingungen IT-Service Management Version 3.0 5
[Seite 6]
| Begriff, Abkürzung | Beschreibung |
|---|---|
| PT / PS | Der Personentag (PT) entspricht 8 (Personen)Stunden (PS). Ein Personentag bzw. eine Person(en)Stunde entspricht einer reinen Arbeitszeit (60 Zeitminuten) ohne Pausen. |
| Regelarbeitszeiten / Regelgeschäftszeiten der KKH | Die Arbeits-/Geschäftszeiten bei der KKH sind in der Regel Montag bis Freitag von 7:00 bis 19:00 Uhr. Die Zeiten können je nach Kundenbedürfnissen angepasst werden. Der Samstag zählt derzeit nicht zu den Regelarbeitszeiten der KKH. Sonn- und Feiertage sowie der 24.12. und der 31.12. fallen nicht unter die Regelarbeits- bzw. -Geschäftszeiten. |
| RZ (Regionalzentrum) | Ein Regionalzentrum (RZ) bezeichnet bei der KKH eine Organisationseinheit ohne Präsenzkundenbetreuung, die qualifizierten Kundenservice durch Bedienung von Dienstkanälen anbietet. Die KKH verfügt über 8 RZ-Standorte. |
| Schlüsselrolle | Eine Schlüsselrolle ist von entscheidender Bedeutung im Rahmen der IT Service Management Prozesse. Diese Rollen müssen immer besetzt sein. |
| Service- & Wartungsfenster | Systemrelevante Arbeiten, also Tätigkeiten, die den produktiven Betrieb der KKH beeinträchtigen können, dürfen nur außerhalb der Regelarbeitszeiten oder in Abstimmung mit dem AG durchgeführt werden. Wartungsarbeiten müssen mit einem Vorlauf von 7 Arbeitstagen angekündigt werden. |
| Servicezeit | Die Servicezeit ist der Zeitraum innerhalb der Betriebszeit, in dem der vereinbarte Service uneingeschränkt zur Verfügung stehen muss. |
| SLA | Service-Level-Agreement (SLA) definiert die Vereinbarung zwischen der KKH und dem AN (Dienstleister) bezüglich der erbrachten wiederkehrenden Dienstleistungen. Hierin werden u.a. Leistungsumfang, Reaktionszeit, Wiederherstellungszeit und Bearbeitungsgeschwindigkeit festgelegt. |
| SPOC | Single Point of Contact |
| Standard-Service-Request | Ein Standard-Service-Request ist eine formale, routinemäßige Anfrage, die einem vordefinierten Prozess folgt und sich wiederholt. |
| Verfügbarkeit | Verfügbarkeit ist der prozentuale Anteil der Zeit innerhalb eines Berichtszeitraums, die ein System oder eine Komponente in Betrieb ist und ihre vorgesehene Funktion erfüllt. |
| Wartungszeit | Die Wartungszeit bezeichnet den Zeitraum, in dem effektive Wartungsarbeiten an einem IT-System durchgeführt werden und bestimmte oder alle Funktionen nicht verfügbar sind. Wartungszeiten müssen sorgfältig geplant werden, um die Auswirkungen auf die Verfügbarkeit des Systems zu minimieren. |
2 IT-Service Management
Allgemeine Rahmenbedingungen IT-Service Management Version 3.0 6
[Seite 7]
Die Zusammenarbeit zwischen Auftraggeber und Auftragnehmer im IT-Service Management ist entscheidend für den Erfolg der bereitgestellten IT-Services. Dabei liegt der Fokus auf klarer und transparenter Kommunikation, einer vertrauensvollen und partnerschaftlichen Arbeitsweise sowie der kontinuierlichen Verbesserung der Dienstleistungen.
2.1 Kollaboration
Zur Planung, Projektierung und Durchführung der im Rahmen dieser Vergabe anstehenden Arbeiten und Aufgabe muss der AN die unterschiedlichen Rollen und Funktionen anforderungsgerecht besetzen. Im Nachfolgenden werden die durch den AN zu besetzenden Rollen dargestellt und durch konkrete Aufgaben und Verantwortungen beschrieben. Zur vollständigen Definition aller Rollen muss der Anbieter im Rahmen seiner Angebotserstellung darstellen, ob sie teilbar (d.h. ob sie von mehreren Personen übernommen werden können) und/oder kombinierbar (d.h. ob sie von einer einzigen Person in Kombination mit anderen Rollen wahrgenommen werden können) sind. Die Rollen müssen
mit zertifizierten Mitarbeitenden (mindestens mit ITIL V3 Zertifizierungen)
oder
mit Mitarbeitenden, die über nachweislich vergleichbare Qualifikation oder einschlägige Berufserfahrung verfügen,
besetzt werden.
Der AN muss alle in der nachfolgenden Tabelle aufgelisteten Schlüsselrollen in qualifizierter Form (zur Erfüllung der dargestellten Aufgaben) und Verfügbarkeit für die gesamte Vertragsdauer (innerhalb der Servicezeit) besetzen, so dass eine effiziente und kooperative Zusammenarbeit zwischen AN und AG im Umfeld IT-Service Management gewährleistet ist.
Bei unvorhergesehenen Störungen muss der AN sicherstellen, dass die definierten Rolleninhaber selbst oder ggf. qualifizierte Vertretungen auch außerhalb der vertraglich definierten Verfügbarkeitszeiten erreichbar sind, z.B. in Form einer Rufbereitschaft. Dies stellt eine inkludierte Leistung dar.
Allgemeine Rahmenbedingungen IT-Service Management Version 3.0 7
[Seite 8]
| Rolle | Schlüssel rolle | Beschreibung | Kernaufgaben |
|---|---|---|---|
| Projektleiter / Rolloutmanager | ja | Der Projektleiter verantwortet die Planung, Steuerung und Umsetzung des Projekts. Er sorgt für die Einhaltung von Zeit, Budget und Qualität und ist zentraler Ansprechpartner für alle Projektbeteiligten. Der Rolloutmanager plant und koordiniert die Einführung von Produkten oder Services. Er stellt sicher, dass der Rollout reibungslos und termingerecht verläuft und alle Ressourcen effizient eingesetzt werden. | Gesamtverantwortung für die Transition / Rollout, Eskalationsführung und Organisation des Teams |
| Service Delivery Manager | ja | Der Service Delivery Manager fungiert als SPOC für alle relevanten Betriebsthemen und gewährleistet, dass verbindliche Rahmenbedingungen für die operativen Prozesse vorhanden sind und eingehalten werden. Er sorgt für die kontinuierliche Verbesserung der ITSM-Prozesse und Services. Er trägt die Verantwortung für das vertragskonforme Erbringen der Services (Delivery) gemäß den vereinbarten quantitativen sowie qualitativen Vereinbarungen. | Abschluss sowie Verwaltung von (IT-) Servicevereinbarungen Überwachung und Reporting des vereinbarten Servicelevels Durchführung regelmäßiger Reviews mit dem AG zur Bewertung der Dienstleistungserbringung Planung, Berechnung und Monitoring der Serviceverfügbarkeit Fungiert als Schnittstelle zum AG und koordiniert interne Abläufe des ANs Zentraler Ansprechpartner (SPOC) für alle relevanten Betriebsthemen End-2-End Verantwortung für das vertragskonforme Erbringen der Services (Delivery) gemäß den vereinbarten quantitativen und qualitativen Vorgaben Beratung bei der Entwickelung und Einführung neuer Services Kontinuierliche Verbesserung der Reife und der inhaltlichen Gestaltung der Services und des Service Level Management Prozesses Teilnahme an Gremien Bearbeitung von Eskalation und Beschwerden |
Allgemeine Rahmenbedingungen IT-Service Management Version 3.0 8
[Seite 9]
| Rolle | Schlüssel rolle | Beschreibung | Kernaufgaben |
|---|---|---|---|
| IT Operations Manager | ja | Der IT Operations Manager trägt die gesamtheitliche Verantwortung für alle Aktivitäten im Bereich Service Operation beim AN. Die Rolle ist weisungsbefugt und steuert die Betriebsteams. Er arbeitet eng mit dem Service Delivery Manager zusammen, der die Schnittstelle zum AG darstellt. | Definition der Regeln für die Standardaufgaben des IT-Betriebes (Standard Operating Procedures) Sicherstellung, dass alle operativen Routineaufgaben zeitgerecht und zuverlässig ausgeführt werden. |
| Service Level Manager | nein | Der Service Level Manager ist verantwortlich für die Service-Level- Vereinbarungen und gewährleistet, dass diese erfüllt werden. In dieser Funktion sorgt er dafür, dass alle IT- Service-Management-Prozesse und Vereinbarungen auf Betriebsebene optimal ausgerichtet sind, um die Ziele der vereinbarten Service Levels zu erreichen. Der Service Level Manager überwacht kontinuierlich die Service Levels und stellt regelmäßig Reports zu den Service Levels zur Verfügung. | Stellt sicher, dass die vom AG vorgegebene Service Level Management Policy eingehalten wird Verantwortet den Prozess zur kontinuierlichen Verbesserung des Service Level Management beim AN Koordiniert in Abstimmung mit dem Service Delivery Manager mit dem Auftraggeber (AG) Änderungen und/oder Unterbrechungen in der Servicebereitstellung Sorgt dafür, dass die vereinbarten Service Levels und Praktiken umgesetzt werden Erstellt regelmäßige SLA- und Management Reports Informiert bei drohender SLA- Verletzung Überwacht die Einhaltung der SLA |
Allgemeine Rahmenbedingungen IT-Service Management Version 3.0 9
[Seite 10]
| Rolle | Schlüssel rolle | Beschreibung | Kernaufgaben |
|---|---|---|---|
| Service Request Manager | nein | Der Service Request Manager ist verantwortlich für den gesamten Service Request-Prozess sowie dessen Effektivität und Effizienz. Übernimmt das Berichtswesen und trägt die Verantwortung für die kontinuierliche Verbesserung des Prozesses. Er ist die erste Eskalationsstufe für Service Requests, die nicht innerhalb der vereinbarten Service-Level gelöst werden können. Das Service Request Management bearbeitet alle Benutzeranfragen im Zusammenhang mit bestehenden Services, überwacht den Prozess und berichtet regelmäßig über die vereinbarten Key Performance Indicators (KPIs) gegenüber dem AG. | Pflegen und Überwachen des Ticket-Lifecycles Sicherstellen der Kopplung der Service Request Management Konfiguration mit dem ITSM-Tool des AGs und Anpassung bei Änderungen Bearbeitung von Eskalation und Beschwerden zu prozessualen Fragestellungen Durchführung kontinuierlicher Verbesserungsmaßnahmen im Service Request Management Überwachung des richtigen ressourcengerechten Einsatzes bei der Service Request Bearbeitung Regelmäßige Berichterstattung an den AG Überwachung des Service Request Management Prozesses hinsichtlich der SLA-Einhaltung Einleitung von Maßnahmen bei SLA-Verletzungen |
| Availability Manager | nein | Der Availability Manager definiert, analysiert, plant, misst und optimiert alle Faktoren, die für die Verfügbarkeit der gegenüber dem AG erbrachten IT- Services entscheidend sind. Er trägt die Verantwortung dafür, dass die gesamte IT-Infrastruktur (Systemumgebung) sowie alle Prozesse, Werkzeuge, Rollen und weitere Ressourcen geeignet sind, um die vereinbarten Verfügbarkeitsziele zu erreichen. | Service-Verfügbarkeit planen und berechnen Service-Verfügbarkeit überwachen Aktualität der Service-CIs sicherstellen Verbesserungs- und Optimierungsmaßnahmen initiieren |
Allgemeine Rahmenbedingungen IT-Service Management Version 3.0 10
[Seite 11]
| Rolle | Schlüssel rolle | Beschreibung | Kernaufgaben |
|---|---|---|---|
| IT-Service Continuity Manager | nein | Der IT-Service Continuity Manager ist verantwortlich für das Management von Risiken, die erhebliche Auswirkungen auf die IT-Services haben können. Dazu gehören unter anderem das Ergreifen von Vorkehrungen für Risiken, Überprüfen, Pflegen und Optimieren des Kontinuitätsplans sowie das Einleiten von Maßnahmen zur Risikoreduzierung in katastrophalen Fällen, um diese auf ein akzeptables Niveau zu senken. Diese Rolle sorgt dafür, dass die in den Service Levels vereinbarten Minimalanforderungen auch bei ungeplanten Notfällen beim AN immer bereitgestellt werden können. | Vorkehrungen treffen für Risiken, die gravierende Auswirkungen auf die IT-Services haben Durchführen von Überprüfungen nach der Wiederaufnahme von Service-Unterbrechungen Überprüfen, Pflegen und Optimieren des Kontinuitätsplans in Abstimmung mit dem AG Einleiten von Maßnahmen zur Risikoreduzierung in katastrophalen Fällen, um diese auf ein akzeptables Niveau zu senken Erstellen und Testen von Katastrophen- /Wiederherstellungsplänen sowie gezielten Wiederherstellungsmaßnahmen für IT-Services in Notfällen Ausführen, Testen und Überprüfen des Geschäftskontinuitätsplans (BCP) und Katastrophenschutzplans (DRP) Managen von Backup- Vorkehrungen Strukturierte Dokumentation der Testergebnisse und Weitergabe an den AG bei Aufforderung |
| Incident Manager | nein | Der Incident Manager ist verantwortlich für die effektive Umsetzung des Incident-Management-Prozesses und die Eskalationen von Incidents, die nicht innerhalb der vereinbarten Service Levels gelöst werden können. Er unterstützt den Service Delivery Manager bei der Lösung solcher Incidents. | Verantwortet die Einhaltung der vom AG vorgegebene Incident Management Policy Prozessverantwortlicher für das Incident Management, sorgt für die kontinuierliche Verbesserung des Prozesses Bearbeitung von Beschwerden und Eskalationen im Rahmen des Incident Managements Überwachung des Incident Management Prozesses (SLA- Einhaltung der Incident Bearbeitung) Eskalation und Kommunikation bei SLA-Verletzung Koordination bei Major Incident |
Allgemeine Rahmenbedingungen IT-Service Management Version 3.0 11
[Seite 12]
| Rolle | Schlüssel rolle | Beschreibung | Kernaufgaben |
|---|---|---|---|
| Problem Manager | nein | Der Problem Manager ist verantwortlich für die effiziente Durchführung des Problem-Management-Prozesses und führt das entsprechende Berichtswesen durch. Der Problem Manager fungiert als erste Eskalationsstufe für Problems, falls diese nicht innerhalb der vereinbarten Service Levels gelöst werden können. | Prozessverantwortlicher für das Problem Management, sorgt für die kontinuierliche Verbesserung des Prozesses Präventives/Proaktives und Reaktives Problem Management Bereitstellung eines Workarounds Generieren von Change Requests (RFC) aus einem Problem Überwachung/Durchführung des Problem Management Prozesses (SLA-Einhaltung / Kategorisierung und Priorisierung) Eskalation und Kommunikation bei SLA-Verletzung |
| Change Manager | nein | Der Change Manager autorisiert und dokumentiert sämtliche Änderungen an der IT-Systemumgebung, um negative Auswirkungen auf den laufenden Betrieb zu minimieren. Er nimmt Change Requests des AG entgegen und sorgt dafür, dass diese gemäß dem vereinbarten Change- Management Prozess bearbeitet werden. Bei Changes, die den AG betreffen informiert er den AG und stellt einen Request for Change (RFC) beim AG. Bei weitreichenden Änderungen bezieht der Change Manager das Change Advisory Board (CAB) des AG in den Entscheidungsprozess mit ein. | Change-Anforderungen dokumentieren Change-Anforderungen prüfen, validieren und in CABs vorstellen Plan zur Durchführung von Changes erstellen Changes durchführen |
Allgemeine Rahmenbedingungen IT-Service Management Version 3.0 12
[Seite 13]
| Rolle | Schlüssel rolle | Beschreibung | Kernaufgaben |
|---|---|---|---|
| Anforderungs- Manager | nein | Der Anforderungs-Manager ist verantwortlich für die Durchführung der Aktivitäten im Demand-Management- Prozess. Diese Rolle sorgt dafür, den Bedarf des AGs an Services zu verstehen, qualifizieren und zu beraten. Sie trägt die Verantwortung für das Erkennen, Analysieren, Planen, Steuern und Dokumentieren des Bedarfs an Dienstleistungen und Produkten des AGs. | Verantworteten das Erkennen, Analysieren, Planen, Steuern und Dokumentieren des Bedarfs an Dienstleistungen und Produkten des AGs Organisieren und Verwalten der Prioritäten in der Umsetzung der Anforderungen Beraten des AGs in der Qualifizierung der Bedarfsermittlung Pflegen eines Registers der Anforderungen, deren Steuerung und Abgleich mit dem Vertragsmanagement des ANs Erstellen von Reports und Berichten gegenüber des AGs Kontinuierliche Pflege und Verbesserung des Anforderungsmanagement- prozesses |
| Vertragsmanager | nein | Der Vertragsmanager ist verantwortlich für die Betreuung der vertraglichen Verhandlungen zwischen AN und AG. Er übernimmt die Implementierung von Verträgen sowie die Steuerung von Vertragsänderungen. Der Vertragsmanager fungiert als Single- Point-of-Contact („SPOC") zum AG für alle vertragsbezogenen Fragen. | Durchführung von Vertragsänderungen Vertragserstellung / -entwurf Vertragsreviews Vertragsabstimmung / -freigabe SPOC für Preise und Verrechnungen |
2.2 Service Organisation
Dieses Kapitel beschreibt die organisatorischen Strukturen und die Prozesse, die für die Erbringung von IT-Services und den Support des AN im Rahmen der vereinbarten Servicelevels erforderlich sind. Es regelt die Servicezeiten sowie die Bearbeitung und Dokumentation von Störungen, Problemen und Anfragen, einschließlich der Leistungen des 1st-Level-Supports.
2.2.1 Servicezeiten
Allgemeine Rahmenbedingungen IT-Service Management Version 3.0 13
[Seite 14]
Die Servicezeiten sind Montag bis Freitag, 08:00 - 18:00 Uhr außer an bundeseinheitlichen Feiertagen und an vorher abgestimmten Change-Tagen (z.B. Samstag von 08:00 -15:00 Uhr, mindestens 2-mal im Monat).
Innerhalb der Servicezeit ist der Service Desk des AN zur Annahme und Bearbeitung von Serviceanfragen erreichbar. Der AN stellt während der Servicezeit qualifiziertes Personal zur Verfügung, das sowohl für die Störungsannahme und -behebung als auch für fachlichen Unterstützung sorgt.
Außerhalb der regulären Servicezeiten kann der AG nach vorheriger Vereinbarung (mindestens einen Monat im Voraus) und gegen gesonderte Verrechnung gemäß Kap. "Additive Wartungs- und Serviceleistungen" eine erweiterte Servicezeit in Anspruch nehmen. In diesem Fall steht dem AG sachkundiges Personal auch telefonisch zur Verfügung.
2.2.2 1st-Level-Support
Die Störung oder das Problem wird beim AN aufgenommen (telefonisch, schriftlich oder durch Erstellung eines Tickets beim AN) und eine erste einfache Störungs- /Problemvorklärung durch den 1st-Level-Support des AN vorgenommen.
Die gesamte Kommunikation (Wort u. Schrift) erfolgt ausschließlich auf Deutsch, mindestens Niveaustufe B2 (Eigenständige Sprachanwendung gem. dem Gemeinsamen Europäischen Referenzrahmen für Sprachen).
Die Erfassung, Kategorisierung und Priorisierung der Störung oder des Problems erfolgen durch den AN in Abstimmung mit dem AG. Die Verantwortung für die weitere Bearbeitung des Prozesses (z. B. 2nd- und 3rd-Level-Support) liegt beim AN.
2.2.3 Ticketabschluss durch den AN
Sobald die Arbeiten zur Störungs-/Problembehebung abgeschlossen sind, muss der AN den neuen Status an den AG in Textform elektronisch übermitteln. Dabei ist die vom AN vergebene eindeutige Referenz anzugeben.
Jede gelöste Störung darf nur mit positiver Rückmeldung des Erstellers innerhalb von 5 Arbeitstag geschlossen werden. Vor der Schließung muss der Ersteller mindestens einmal kontaktiert worden sein, um eine Rückmeldung einzuholen. Nach Ablauf von 5 Arbeitstagen kann eine gelöste Störung auch ohne Rückmeldung geschlossen werden.
Der AN muss jedes Störung-/Problem-Ticket in seinem Ticketsystem so lange aktiv halten, bis
Allgemeine Rahmenbedingungen IT-Service Management Version 3.0 14
[Seite 15]
Eine qualifizierte Rück- oder Abschlussmeldung der Störung-/Problembearbeitung vorliegt und im Ticket dokumentiert ist. Der Melder/AG in Form einer qualifizierten Rück- oder Abschlussmeldung informiert wurde. Der Betrieb des ursprünglich betroffenen Produkts bzw. Dienstleistung mindestens 24 Stunden nach der Behebung der Störung ohne Fehler oder Auffälligkeiten verläuft. Der Melder/AG die Freigabe zum Abschluss des Tickets erteilt hat.
Für die Einhaltung des vereinbarten SLA ist der Zeitpunkt der Übermittlung einer qualifizierten Abschlussmeldung vom AN an den AG über den vereinbarten Kommunikationsweg maßgeblich. Eine Störung darf nicht einseitig vom AN als beendet gemeldet oder als beendet gelten, wenn die Fertigmeldung unzutreffend ist (z.B. zur Vermeidung einer Fristüberschreitung). Sollte sich herausstellen, dass eine Fertigmeldung unzutreffend war, bleibt die Störung - unabhängig von der Fertigmeldung - weiterhin bestehen. Die Entstörzeit wird durch eine unzutreffende Fertigmeldung nicht unterbrochen.
Rück- oder Abschlussmeldungen müssen in deutscher Sprache verfasst sein und stets folgende Angaben enthalten:
Eine eindeutige Referenz zur Zuordnung des Störungs-/Problemfalls Eine technisch detaillierte Beschreibung der Störungs-/Problemanalyse. Informationen zum Störungsanlass. Informationen zur Behebung der Störung oder des Problems.
Der Inhalt von Status-, Rück- oder Abschlussmeldungen muss so formuliert sein, dass er für einen Endanwender mit IT-Grundkenntnissen verständlich und nachvollziehbar ist. Bei Bedarf können ergänzend detailliertere technische Angaben für die weiterführende Bearbeitung bereitgestellt werden.
2.3 Eskalationsstufen und Kommunikationswege
Eskalationen treten insbesondere auf,
wenn vereinbarte Service-Level-Agreements (SLA) nicht eingehalten wurden oder deren Nichteinhaltung absehbar ist, wenn die Leistung nicht wie vereinbart erbracht wurde oder eine Schlecht- oder Fehlleistung absehbar ist, bei Uneinigkeiten (fachlicher oder menschlicher Art), die auf Arbeitsebene nicht gelöst werden können, wenn für die Leistungserbringung erforderliche Ressourcen nicht rechtzeitig bereitgestellt werden können.
Allgemeine Rahmenbedingungen IT-Service Management Version 3.0 15
[Seite 16]
Im Eskalationsfall findet ein Eskalationsmodell Anwendung, das für beide Vertragsparteien definierte Ansprechpartner vorsieht.
Auftraggeber und Auftragnehmer benennen spätestens nach Zuschlagserteilung für jede Eskalationsstufe einen verantwortlichen Ansprechpartner sowie eine Vertretung. Die Angaben müssen mindestens Name, E-Mail-Adresse und eine telefonisch erreichbare Rufnummer aus dem deutschen Fest- oder Mobilfunknetz enthalten. Hotline oder kostenpflichtige Servicerufnummern (shared-cost) sind unzulässig.
Beide Vertragsparteien stellen sicher, dass die benannten Ansprechpartner während der gesamten Vertragslaufzeit aktuell gehalten werden. Änderungen sind der jeweils anderen Partei unverzüglich mitzuteilen.
Die Parteien arbeiten im Rahmen der Eskalations- und Kommunikationsprozesse eng zusammen, um Probleme, Störungen oder Verzögerungen strukturiert, effizient und zielgerichtet zu bearbeiten und die vereinbarte Servicequalität sowie die Service-Level schnellstmöglich wiederherzustellen.
Die Ansprechpartner der Eskalationsstufen werden im Dokument „Eskalationsmatrix und Kommunikationskontakte“ geführt und während der Vertragslaufzeit von beiden Vertragsparteien aktuell gehalten; die Tabelle dient als Referenzstruktur.
| Eskalation | Kaufmännische Krankenkasse | Dienstleister Servicepartner |
|---|---|---|
| 1. Eskalationsebene | Service Owner (SPOC) Name, Vorname Tel.: +49 511 2802-xxx E-Mail: N.N.@kkh.de | IT-Operations Manager Name, Vorname Tel.: +49 xxx E-Mail: N.N.@AN.de |
| 2. Eskalationsebene | Sachgebietsleitung Name, Vorname Tel.: +49 511 2802-xxx E-Mail: NN@kkh.de | Service (Delivery) Manager Name, Vorname Tel.: +49 xxx E-Mail: N.N.@AN.de |
| 3. Eskalationsebene | Abteilungsleitung Name, Vorname Tel.: +49 511 2802-xxx E-Mail: N.N.@kkh.de | Leitung Service (Delivery) Management Name, Vorname Tel.: +49 xxx E-Mail: N.N.@AN.de |
| 4. Eskalationsebene | Bereichsleitung IT Name, Vorname Tel.: +49 511 2802-xx E-Mail: N.N.@kkh.de | Geschäftsführung Name, Vorname Tel.: +49 xxx E-Mail: N.N.@AN.de |
Allgemeine Rahmenbedingungen IT-Service Management Version 3.0 16
[Seite 17]
2.4 Service Meetings
Regelmäßige Service-Review Meetings sind durch den AN zu organisieren unter Teilnahme von Auftragnehmer und Auftraggeber durchzuführen.
Der Auftragnehmer übernimmt hierbei insbesondere folgende Aufgaben:
Organisation: Frühzeitige Abstimmung von Terminen und Teilnehmern sowie fristgerechte Versand der Einladungen, Vorbereitung: Erstellung einer Agenda einschließlich Präsentation und Reporting, Durchführung und Dokumentation: Moderation des Meetings sowie Erstellung und Bereitstellung eines Ergebnisprotokolls.
Im Rahmen der Service-Review-Meetings werden, die im zurückliegenden Zeitraum erbrachten Leistungen bewertet sowie Optimierungsmaßnahmen, Änderungen und geplante Weiterentwicklungen abgestimmt.
Die Meetings finden in der Regel als Online-Meetings (Audio und Video) statt
Nachfolgend ist eine Übersicht der wesentlichen Meetings mit verpflichtender Teilnahme des Auftragnehmers dargestellt. Die Meetings erfolgen bedarfsorientiert, sofern Auftraggeber oder Auftragnehmer dies für erforderlich erachten. Mindestens ein Service-Review-Meeting ist verbindlich einzuplanen. Intervalle sowie eine mögliche Zusammenlegung von Gremien können nach Absprache von AG und AN, abhängig von Betriebsmodell, Vertragsumfang und Leistungsperformance festgelegt werden.
Darüber hinaus können durch Auftraggeber oder Auftragnehmer jederzeit zusätzliche Abstimmungs- oder Eskalationsmeetings einberufen werden, sofern dies zur Sicherstellung der Leistungserbringung oder Servicequalität erforderlich ist.
| Gremium | Intervall | Teilnehmer AG | Teilnehmer AN | Inhalt (Mindestanforderung) |
|---|---|---|---|---|
| Strategie Meeting | ½ jährlich oder jährlich | Ggf. Bereichsleiter Abteilungsleiter IT / Sachgebiets- leiter IT Service Owner Vertreter Fachbereich | Ggf. Geschäftsführer Vertragsmanager | strategische Weiterentwicklung der Partnerschaft und der damit verbundenen Dienstleistungen (Services, SLAs) und des Vertrags |
Allgemeine Rahmenbedingungen IT-Service Management Version 3.0 17
[Seite 18]
| Gremium | Intervall | Teilnehmer AG | Teilnehmer AN | Inhalt (Mindestanforderung) |
|---|---|---|---|---|
| Service Delivery Board | Quartalsweise | Service Owner Provider Manager (strategische Provider) | Service Delivery Manager | Status der Maßnahmen bei SLA- Verletzungen Planung und Status der Ergebnisse der kontinuierlichen Verbesserung Performance-Rückblick und - Ausblick in Bezug auf vergangene und die kommende Periode |
| Service Level Review Meeting | Monatlich | Service Owner Provider- und Servicelevel Manager (strategische Provider) | Service Delivery Manager Service Level Manager | Vorstellung der SLA-Erfüllung durch den AN und Review mit dem AG Vorstellung der Maßnahmen zur Vermeidung zukünftiger SLA- Verletzungen |
| Operational Provider Meeting | Wöchentlich oder 14-tägig oder nach Vereinbarung | Service Owner | IT-Operations Manager | Review des Servicebetriebs (Incidents, Problems, Service Requests, Changes) Planung des Servicebetriebs |
2.5 Service Level Management
Das Service Level Management (SLM) basiert auf einer Dienstgütevereinbarung (SLA) und baut auf den zuvor definierten Rahmenbedingungen auf. Es legt den Inhalt der Vereinbarung fest und definiert die Maßnahmen, die bei Beeinträchtigung der Leistung zu ergreifen sind, einschließlich der möglicher Sanktionen im Fall von Schlecht- oder Fehlleistungen. Für jede erbrachte Leistung gelten spezifische Service Levels mit unterschiedlichen Service- und Verfügbarkeitsparametern.
Die in den Serviceparametern festgelegten Verfügbarkeiten beziehen sich auf die gesamte Ende-zu-Ende-Verbindung, die den End User bzw. der Anwendung mit dem internen oder externen Ziel verbindet.
Eine Leistung gilt als nicht anforderungsgerecht verfügbar, wenn sie in ihrer Qualität dauerhaft oder wiederholt spürbar beeinträchtigt ist. Entsprechende Schwellwerte werden für diese Beeinträchtigung definiert.
Sollte der AN aus Gründen, die er nicht zu vertreten hat, eine Regelung der Dienstgütevereinbarung nicht einhalten können, liegt die Beweislast dafür beim AN.
Innerhalb der ersten sechs Monate nach Beginn der Betriebsphase werden die vereinbarten Service Level hinsichtlich ihrer Angemessenheit und Effektivität überprüft.
Allgemeine Rahmenbedingungen IT-Service Management Version 3.0 18
[Seite 19]
Nach dieser ersten Phase können AN und AG gemeinsam entscheiden, ob Anpassungen erforderlich sind. Kann keine Einigung erzielt werden, bleibt das ursprünglich vereinbarte Service Level Agreement in Kraft.
Die Prioritätskategorien für die Benachrichtigungs-, Reaktions- und Wiederherstellungszeiten für Störungen/Incidents richten sich nach der Prioritätenmatrix des AG gemäß Kapitel „Incident Management“ in diesem Dokument und werden wie folgt bezeichnet:
P1 = Priorität 1 P2 = Priorität 2 P3 = Priorität 3 P4 = Priorität 4 P5 = Priorität 5
Die Berechnung der Erfüllungsquote erfolgt rückwirkend für jede Berichtsperiode. Die Berichtsperiode wird monatlich festgelegt und umfasst den Zeitraum vom ersten bis zum letzten Tag des Monats. Diese Vorgehensweise gilt für alle SLAs und deren jeweiligen Leistungskennzahlen (KPIs), die regelmäßig überprüft werden, um die Einhaltung der vereinbarten Service-Level-Vorgaben sicherzustellen.
2.5.1 Service-Level-Definition
| SLA ID | Bezeichnung | Beschreibung | Leistungsziel | Erfüllungs-quote | Berichts- intervall |
|---|---|---|---|---|---|
| SL 10a | Incident Reaktionszeit P1 - P5 | Die Reaktionszeit ist der Zeitraum während der Servicezeit, der zwischen dem erstmaligen Eingang einer Störmeldung (ab Empfangsbestätigung) und dem Beginn der Störungsanalyse liegt. Formel Erfüllungsquote: (Anzahl der Incidents innerhalb der vereinbarten Reaktionszeit / Gesamtzahl der Incidents) * 100 | P1 = 0,25 Std P2 = 0,50 Std P3 = 2 Std P4 = 11 Std P5 = 11 Std | 95% | Monatlich |
| SL 12a | Incident P1 Wiederherstellung szeit | Die Wiederherstellungszeit für Incidents ist die Zeitspanne von der Meldung einer Störung bis zur vollständigen Wiederverfügbarkeit des ursprünglichen Service. Die Erfüllungsquote misst die Einhaltung der vereinbarten SLA-Zeit während der Servicezeit. Formel Erfüllungsquote: (Anzahl der gelösten P1 Incidents innerhalb der vereinbarten Wiederherstellungszeit / Gesamtzahl der gelösten P1 Incidents) * 100 | 2 Stunden | 95% | Monatlich |
Allgemeine Rahmenbedingungen IT-Service Management Version 3.0 19
[Seite 20]
| SLA ID | Bezeichnung | Beschreibung | Leistungsziel | Erfüllungs-quote | Berichts- intervall |
|---|---|---|---|---|---|
| SL 12b | Incident P2 Wiederherstellung szeit | Die Wiederherstellungszeit für Incidents ist die Zeitspanne von der Meldung einer Störung bis zur vollständigen Wiederverfügbarkeit des ursprünglichen Service. Die Erfüllungsquote misst die Einhaltung der vereinbarten SLA-Zeit während der Servicezeit. Formel Erfüllungsquote: (Anzahl der gelösten P2 Incidents innerhalb der vereinbarten Wiederherstellungszeit / Gesamtzahl der gelösten P2 Incidents) * 100 | 2 Stunden | 95% | Monatlich |
| SL 12c | Incident P3 Wiederherstellung szeit | Die Wiederherstellungszeit für Incidents ist die Zeitspanne von der Meldung einer Störung bis zur vollständigen Wiederverfügbarkeit des ursprünglichen Service. Die Erfüllungsquote misst die Einhaltung der vereinbarten SLA-Zeit während der Servicezeit. Formel Erfüllungsquote: (Anzahl der gelösten P3 Incidents innerhalb der vereinbarten Wiederherstellungszeit / Gesamtzahl der gelösten P3 Incidents) * 100 | 2 Arbeitstage | 95% | Monatlich |
| SL 12d | Incident P4 + P5 Wiederherstellung szeit | Die Wiederherstellungszeit für Incidents ist die Zeitspanne von der Meldung einer Störung bis zur vollständigen Wiederverfügbarkeit des ursprünglichen Service. Die Erfüllungsquote misst die Einhaltung der vereinbarten SLA-Zeit während der Servicezeit. Formel Erfüllungsquote: (Anzahl der gelösten P4 + P5 Incidents innerhalb der vereinbarten Wiederherstellungszeit / Gesamtzahl der gelösten P4- und P5-Incidents) * 100 | 5 Arbeitstage | 90% | Monatlich |
| SL 13 | Statusupdate bei Major Incidents | Statusupdate /-meldung durch Bearbeitungsgruppe Formel Erfüllungsquote: (Anzahl der Major Incidents mit Status- Update erfüllt innerhalb der vereinbarten Zeit/ Gesamtzahl der Major Incidents) * 100 | jede Stunde | 95% | Monatlich |
Allgemeine Rahmenbedingungen IT-Service Management Version 3.0 20
[Seite 21]
| SLA ID | Bezeichnung | Beschreibung | Leistungsziel | Erfüllungs-quote | Berichts- intervall |
|---|---|---|---|---|---|
| SL 20 | Problem Reaktionszeit P1 - P5 | Die Reaktionszeit bei Problems ist der Zeitraum zwischen der Meldung eines Problems und der Empfangsbestätigung durch den AN. Die Erfüllungsquote misst die Einhaltung der vereinbarten SLA-Zeit während der Servicezeit. Formel Erfüllungsquote: (Anzahl der Problems innerhalb der vereinbarten Reaktionszeit / Gesamtzahl der Problems) * 100 | 15 Minuten | 95% | Monatlich |
| SL 21a | Problem Ursachenanalyse P1 + P2 | Die Ursachenanalyse-Zeit ist der Zeitraum von der Identifizierung eines Problems bis zur Bestimmung seiner Ursache. Die Erfüllungsquote misst die Einhaltung der vereinbarten SLA-Zeit während der Servicezeit. Formel Erfüllungsquote: (Anzahl aller P1- und P2-Problems innerhalb der vereinbarten Ursachenanalyse-Zeit / Gesamtzahl der P1- und P2-Problems) * 100 | 10 Arbeitstage | 95% | Monatlich |
| SL 21c | Problem Ursachenanalyse P3 + P4 + P5 | Die Ursachenanalyse-Zeit ist der Zeitraum, der von der Identifizierung eines Problems bis zur Bestimmung seiner Ursache benötigt wird. Die Erfüllungsquote misst die Einhaltung der vereinbarten SLA-Zeit während der Servicezeit. Formel Erfüllungsquote: (Anzahl der P3-, P4- und P5-Problems innerhalb der vereinbarten Ursachenanalyse-Zeit / Anzahl der P3-, P4- und P5-Problems) * 100 | 15 Arbeitstage | 95% | Monatlich |
| SL 22a | Problem Resolution P1 + P2 | Die Problemlösungszeit ist der Zeitraum, der von der Identifizierung der Ursache eines Problems bis zu dessen endgültiger Lösung. Die Erfüllungsquote misst die Einhaltung der vereinbarten SLA-Zeit während der Servicezeit. Formel Erfüllungsquote: (Anzahl der P1- und P2-Problems innerhalb der vereinbarten Problemlösungszeit / Gesamtzahl der P1- und P2-Problems) * 100 | 10 Arbeitstage | 95% | Monatlich |
Allgemeine Rahmenbedingungen IT-Service Management Version 3.0 21
[Seite 22]
| SLA ID | Bezeichnung | Beschreibung | Leistungsziel | Erfüllungs-quote | Berichts- intervall |
|---|---|---|---|---|---|
| SL 22c | Problem Resolution P3 + P4 + P5 | Die Problemlösungszeit ist der Zeitraum, der von der Identifizierung der Ursache eines Problems bis zu dessen endgültiger Lösung. Die Erfüllungsquote misst die Einhaltung der vereinbarten SLA-Zeit während der Servicezeit. Formel Erfüllungsquote: (Anzahl der P3-, P4- und P5-Problems innerhalb der vereinbarten Problemlösungszeit / Gesamtzahl der P3-, P4- und P5-Problems) * 100 | 15 Arbeitstage | 95% | Monatlich |
| SL 30 | Service Request Reaktionszeit (Sta ndard Request/None- Standard Request) | Die Reaktionszeit für Service Requests ist der Zeitraum zwischen dem Eingang einer Serviceanfrage und dem Beginn der Anfragebearbeitung. Der Beginn der Anfragenbearbeitung umfasst die Empfangsbestätigung durch den AN sowie die Sichtung, Kategorisierung und Priorisierung des Service Request. Die Erfüllungsquote misst die Einhaltung der SLA-Zeit während der Servicezeit. Formel Erfüllungsquote: (Anzahl der Service Requests innerhalb der vereinbarten Reaktionszeit / Gesamtzahl der Service Requests) * 100 | 1 Arbeitstag | 95% | Monatlich |
| SL 31 | Service Request Bearbeitungszeit (Standard Request) | Die Bearbeitungszeit für Service Requests ist der Zeitraum zwischen dem Beginn der Bearbeitung einer Serviceanfrage und deren endgültiger Umsetzung. Die Erfüllungsquote misst die Einhaltung der vereinbarten SLA- Zeit während der Servicezeit. Formel Erfüllungsquote: (Anzahl der Service Requests innerhalb der vereinbarten Bearbeitungszeit / Gesamtzahl der Service Requests) * 100 | 4 Arbeitstage | 95% | Monatlich |
| SL 40a | Reaktionszeit - Notfall Changes | Die Reaktionszeit für Notfall-Changes ist der Zeitraum zwischen dem Eingang eines Changes und dem Beginn der Change-Bearbeitung. Beginn der Change-Bearbeitung umfasst die Empfangsbestätigung durch den AN. Die Erfüllungsquote misst die Einhaltung der vereinbarten SLA-Zeit während der Servicezeit. Formel Erfüllungsquote: (Anzahl der Notfall-Change innerhalb der vereinbarten Reaktionszeit / Gesamtzahl der Notfall-Change) * 100 | 15 Minuten | 95% | Monatlich |
Allgemeine Rahmenbedingungen IT-Service Management Version 3.0 22
[Seite 23]
| SLA ID | Bezeichnung | Beschreibung | Leistungsziel | Erfüllungs-quote | Berichts- intervall |
|---|---|---|---|---|---|
| SL 40b | Reaktionszeit - Planbare Changes | Die Reaktionszeit für planbaren Changes ist der Zeitraum zwischen dem Eingang eines Changes und dem Beginn der Change-Bearbeitung. Der Beginn der Change-Bearbeitung umfasst die Empfangsbestätigung durch den AN sowie die Sichtung, Kategorisierung und Priorisierung des Changes. Die Erfüllungsquote misst die Einhaltung der vereinbarten SLA-Zeit während der Servicezeit. Formel Erfüllungsquote: (Anzahl der planbaren Change innerhalb der vereinbarten Reaktionszeit / Gesamtzahl der planbaren Change) * 100 | 1 Arbeitstag | 95% | Monatlich |
| SL 41a | Qualifizierungszei t - Notfall Changes | Die Qualifizierung von Notfall-Changes beginnt mit der Empfangsbestätigung und endet mit der zwischen AG und AN vereinbarten Planung. Die Erfüllungsquote misst die Einhaltung der vereinbarten SLA-Zeit während der Servicezeit. Formel Erfüllungsquote: (Anzahl der Notfall-Changes innerhalb der vereinbarten Qualifizierungszeit / Gesamtzahl der Notfall-Changes) * 100 | 1 Stunde | 95% | Monatlich |
| SL 41b | Lieferzeitpunkt - Notfall- und Planbare Changes | Die Bearbeitung aller Changes (Notfall- und Planbare Changes) beginnt mit der Empfangsbestätigung und endet mit Fertigstellungsmeldung durch den AN. Der Lieferzeitpunkt gilt als erfüllt, wenn die Lieferung zum geplanten Zeitpunkt erfolgt. Formel Erfüllungsquote: (Anzahl der Changes, die innerhalb des vereinbarten Lieferzeitpunkts abgeschlossen wurden / Gesamtzahl der Changes) * 100 | Lieferzeitpunkt = Planzeitpunkt | 95% | Monatlich |
Allgemeine Rahmenbedingungen IT-Service Management Version 3.0 23
[Seite 24]
| SLA ID | Bezeichnung | Beschreibung | Leistungsziel | Erfüllungs-quote | Berichts- intervall |
|---|---|---|---|---|---|
| SL 50b | Verfügbarkeit von Services | Die Verfügbarkeit eines Service ist die Zeitspanne innerhalb der Betriebszeit, in der der Service tatsächlich verfügbar ist. Zur Messung der Ausfallzeiten eines Services wird die Bearbeitungszeit der Major- Incidents (P1-Incident) herangezogen. Die Ausfallzeit wird von Eröffnung des Vorfalls (Open Time) der Störung im ITSM/Ticketsystem bis zur endgültigen Lösung (Resolved Time) des gemeldeten Vorfalls berücksichtigt. Die Erfüllungsquote misst die Einhaltung der vereinbarten SLA-Zeit während der Betriebszeit des Services. Formel Erfüllungsquote: (Summe der Verfügbarkeitszeit innerhalb der Berichtsperiode und Betriebszeit – Ausfallzeiten) / Summe der Verfügbarkeitszeit innerhalb der Berichtsperiode und Betriebszeit * 100 | 99,5 % | Monatlich |
2.6 Wartungsfenster
Der AN ist verantwortlich für die Betriebssicherheit seiner Software und/oder Systeme und muss sicherstellen, dass diese stets auf einem aktuellen (Software-)Stand gehalten werden. Eventuell erforderliche Wartungsarbeiten mit signifikanter Downtime sind vom AN mit einem Vorlauf von 7 Arbeitstagen beim AG anzukündigen und müssen außerhalb der vereinbarten Servicezeiten durchgeführt werden.
Das festgelegte Wartungsfenster mit Downtime umfasst:
- Werktags von 18:30 Uhr bis 06:30 Uhr.
- Sonn- und bundesweit einheitlichen Feiertage ganztägig.
In Einzelfällen kann die KKH zusätzliche Restriktionen festlegen, die vom AN beachtet werden müssen. Alternativ kann der AN abweichende Zeitfenster beantragen.
Für Wartungsarbeiten, die keine Beeinträchtigung der Performance und keine Nichtverfügbarkeit der Software und/oder Systeme verursachen, können in begründeten Einzelfällen auch abweichende Wartungsfenster vereinbart werden.
Für Wartungsarbeiten, die zur Beeinträchtigung der Performance oder zur Nichtverfügbarkeit führen können, muss der AN stets im Voraus die Zustimmung des AG in Textform einholen.
Allgemeine Rahmenbedingungen IT-Service Management Version 3.0 24
[Seite 25]
Die Zeiten innerhalb der genehmigten Wartungsfenster werden nicht in die Berechnung der Verfügbarkeit des Systems einbezogen.
2.7 ITSM-Prozesse
In diesem Dokument werden die Anforderungen der IT-Service-Management-Prozesse (ITSM) dargestellt.
2.7.1 Incident Management
Das Incident Management hat das Ziel, den normalen Servicebetrieb nach einem Service-, Dienst- oder Systemausfall so schnell wie möglich wiederherzustellen. Die vom AN zu erbringende Leistung umfasst die Instandhaltung und Instandsetzung der vertragsgegenständlichen Systeme, Services und Dienste sowie die Beseitigung von Fehlern bzw. Störungen im Betrieb.
Zur Wiederherstellung der Betriebsbereitschaft können Maßnahmen wie technische und/oder konfigurationsbezogene Anpassungen sowie die Durchführung von Firmware- und Software-Updates oder Sicherheits-Patches erforderlich sein. Diese Maßnahmen gehören zum Leistungsumfang des AN und sind Bestandteil der vertraglich vereinbarten Leistungen.
Die nachfolgenden Beschreibungen der Art und des Umfangs der Arbeiten stellen die Mindestanforderungen dar und dürfen vom AN nicht als allumfassend angesehen werden. Der AG erwartet vom AN stets eine ganzheitliche Betrachtung der jeweiligen Wartungs- und Serviceaufgaben, die auch über die beschriebenen Tätigkeiten hinausgehen kann. Um eine klare Struktur und Verständlichkeit zu gewährleisten, sind nur die grundlegenden Aufgaben dargestellt. Der AN muss diese mit dem Fachwissen und Erfahrung seiner Techniker oder Systemspezialisten bedarfsgerecht ergänzen, um eine vollständige anforderungsgerechte Umsetzung sicherzustellen.
Im Rahmen des Incident Managements sind folgende Anforderungen zu erfüllen:
Der AN muss klare Prozesse und Verantwortlichkeiten für die Meldung, Klassifizierung, Priorisierung, Untersuchung, Behebung und Dokumentation von Incidents etablieren.
Der AN muss Mechanismen zur Priorisierung von Incidents gemäß der vom AG definierten Priorisierungsmatrix implementieren.
Der AN richtet im Incident-Management-Prozess eine zusätzliche Eskalationsstufe „0“ ein. Bei drohender oder tatsächlicher SLA-Überschreitung eskaliert der 1st-
Allgemeine Rahmenbedingungen IT-Service Management Version 3.0 25
[Seite 26]
Level-Support an den Service Owner des AG und den Incident Koordinator des AN, der bei Bedarf an die erste Eskalationsstufe weiterleitet, gemäß Kapitel „Eskalationsstufen und Kommunikationswege“.
Der AN muss Incident-Daten kontinuierlich analysieren und überwachen, um Trends zu identifizieren, die auf mögliche Probleme oder Verbesserungspotenziale hinweisen.
In regelmäßigen Service Reviews muss der AN den AG über identifizierte Probleme, Verbesserungspotenziale und Trends informieren.
Eine Störung darf vom AN nicht als beendet gemeldet werden, wenn die Fertigmeldung falsch war (z.B. zur Vermeidung einer Fristüberschreitung). Sollte sich herausstellen, dass die Fertigmeldung falsch war, bleibt die Störung weiterhin bestehen und die Entstörzeit wird nicht unterbrochen.
Prioritätsmatrix
Allgemeine Rahmenbedingungen IT-Service Management Version 3.0 26
[Seite 27]
Fallback
Bei der Erbringung der vertragsgegenständlichen Leistungen muss der AN bereits in der Vorplanung potenzielle Herausforderungen berücksichtigen. Sollte es während der Durchführung der Arbeiten zu Problemen kommen, ist der AN verpflichtet, unverzüglich, eigenständig und eigenverantwortlich Lösungen zu erarbeiten und diese mit dem AG abzustimmen. Bei einem erforderlichen Fallback ist sicherzustellen, dass die vereinbarten Verfügbarkeitsanforderungen gemäß SLA eingehalten werden.
2.7.2 Problem Management
Allgemeine Rahmenbedingungen IT-Service Management Version 3.0 27
[Seite 28]
Das Problem Management hat das Ziel, die Ursachen von häufig auftretenden oder schwerwiegenden Störungen zu identifizieren und zu beheben, um deren Wiederholung zu verhindern. Im Rahmen des Problem Managements sind folgende Anforderungen zu erfüllen:
Prozesse und Verantwortlichkeiten: Der AN muss klare Prozesse und Verantwortlichkeiten für die Identifikation, Analyse, Behandlung und Dokumentation der Probleme in der IT-Infrastruktur und den damit verbundenen Services festlegen.
Einrichtung und Pflege des Problem-Registers: Der AN muss alle relevanten Informationen einschließlich Ursachen, Symptomen, Lösungen und der Bearbeitungshistorie nachvollziehbar dokumentieren und dem AG bei Bedarf bereitstellen.
Proaktive Maßnahmen: Der AN muss proaktive Problem Management-Aktivitäten durchführen, wie die kontinuierliche Überwachung und Analyse von Incident- und Servicedaten, um potenzielle Probleme frühzeitig zu erkennen und zu beheben.
Berichterstattung im Service Review: Der AN muss den AG in regelmäßigen Service Reviews über potenzielle Probleme, Verbesserungspotenziale und die relevanten Trends informieren.
2.7.3 Change-Management & Enablement
Der AN ist verpflichtet während der gesamten Vertragslaufzeit alle geplanten Änderungen an dem vereinbarten Service rechtzeitig anzuzeigen.
Die Durchführung, Terminierung und Abstimmung von Änderungen, die zur Beeinträchtigung der Performance oder zur Nichtverfügbarkeit des Service führen können, muss stets mit dem AG abgestimmt werden.
Im Rahmen des Change Managements und -Enablements sind folgende Anforderungen zu erfüllen:
Planung und Koordination: Die Durchführung von Changes ist unter Berücksichtigung der vereinbarten Zeitfenster, Ressourcen und Abhängigkeiten zu planen und zu koordinieren.
Transparente Kommunikation: Der AN muss eine klare Kommunikation mit allen beteiligten Parteien sicherstellen und dafür sorgen, dass ggf. erforderliche Freigaben rechtzeitig eingeholt werden.
Dokumentation: Alle Changes sind im ITSM-Tool des AG durch den Service Owner des AG vollständig zu dokumentieren. Der AN liefert dem Service Owner die erforderlichen Informationen.
Allgemeine Rahmenbedingungen IT-Service Management Version 3.0 28
[Seite 29]
Wahrung der Stabilität: Der AN muss die Integrität und Stabilität der IT-Services während und nach der Durchführung von Changes gewährleisten.
Befähigung der Mitarbeiter: Alle relevanten Mitarbeiter des AN müssen entsprechend geschult und befähigt sein, um Change-Prozesse ordnungsgemäß durchzuführen.
2.7.4 Availability Management
Der AN ist verantwortlich für das Availability Management, das darauf abzielt, die Verfügbarkeit der IT-Services und Systemen zu optimieren und sicherzustellen, dass die vereinbarten Service Level Agreements (SLAs) eingehalten werden. Die Anforderungen an das Availability Management werden vom AG im Rahmen der Service Levels definiert.
Der AN ist verpflichtet, folgende Maßnahmen umzusetzen:
Kontinuierliche Überwachung: Die Verfügbarkeit der vereinbarten IT-Services kontinuierlich zu überwachen und sicherzustellen, dass die Service Level eingehalten werden.
Analyse und Prävention: Ursachen von Verfügbarkeitsstörungen zu analysieren und geeignete Maßnahmen zur Prävention und Minimierung von Ausfällen umzusetzen.
Dokumentation: Alle Verfügbarkeitsereignisse, getroffene Maßnahmen und Verbesserungen nachvollziehbar zu dokumentieren.
Prozessoptimierung: Den Availability-Management-Prozess kontinuierlich zu überprüfen und zu optimieren, um eine nachhaltige Servicequalität sicherzustellen.
2.7.5 Release Management
Der AN ist verantwortlich für das Release Management, das die Planung, Koordination und Implementierung von neuen Software-Versionen und Updates sicherstellt. Diese Leistungen sind, soweit erforderlich, vom AN als inkludierte Leistung zu erbringen
Im Rahmen des Release Managements ist der Auftragnehmer verpflichtet, folgende Anforderungen umzusetzen:
Sorgfältige Planung und Abstimmung: Releases sorgfältig zu planen und mit dem AG abzustimmen, um eine reibungslose Einführung sicherzustellen.
Allgemeine Rahmenbedingungen IT-Service Management Version 3.0 29
[Seite 30]
Qualitätssicherung: Sicherzustellen, dass Releases vor der Freigabe umfassend getestet werden und die Qualität überprüft wird.
Informations- und Freigabemanagement: Den AG rechtzeitig über bevorstehende Releases zu informieren und sicherzustellen, dass alle erforderlichen Freigaben vorliegen.
Risikomanagement: Mögliche Risiken zu bewerten und geeignete Rückfall- bzw. Notfallpläne für den Fall von Problemen während des Releases bereitzustellen.
Überwachung nach dem Release: Die Stabilität und Funktionalität des Service nach dem Release zu überwachen und bei etwaigen Störungen zeitnah zu reagieren.
2.7.6 IT Service Continuity Management
Das IT Service Continuity Management (ITSCM) befasst sich mit der Sicherstellung der kontinuierlichen Erbringung von IT-Services und der Wiederherstellung kritischer Geschäftsprozesse im Falle schwerwiegender Störungen, Ausfälle oder Notfälle. Der AN ist alleinverantwortlich dafür, ein effektives Service Continuity Management für die IT-Services zu etablieren und aufrechtzuerhalten.
Im Rahmen des IT Service Continuity Managements ist der AN verpflichtet, folgende Anforderungen umzusetzen:
Risikomanagement: Erstellung und regelmäßige Risikoanalysen zur Identifikation und Bewertung potenzieller Bedrohungen und Schwachstellen in der IT- Infrastruktur, Services und Geschäftsprozessen.
Risikomindernde Maßnahmen: Entwicklung und Implementierung geeigneter Maßnahmen wie Redundanz, Backups und Ausfallsicherheit, um Unterbrechungen zu minimieren.
Notfall- und Wiederherstellungspläne: Erstellung umfassender Notfall- und Wiederherstellungspläne, die konkrete Schritte und Verantwortlichkeiten für die Reaktion auf Ereignisse festlegen, die IT-Services und Geschäftsprozesse beeinträchtigen könnten.
Tests und Übungen: Regelmäßige Durchführung von Tests und Übungen der Notfall- und Wiederherstellungspläne, um deren Effektivität zu prüfen und Verbesserungspotenziale zu identifizieren.
Dokumentation: Dokumentation von Risikoanalysen, Notfallplänen, Testergebnissen und Aktualisierung der Unterlagen bei Bedarf.
Allgemeine Rahmenbedingungen IT-Service Management Version 3.0 30
[Seite 31]
Kontinuierliche Verbesserung: Sicherstellung einer kontinuierlichen Verbesserung des IT Service Continuity Managements, indem Erkenntnisse aus Tests, Übungen und realen Ereignissen systematisch in die Anpassung von Plänen und Prozessen einfließen.
2.7.7 Service Request Management
Das Service Request Management hat das Ziel, alle Serviceanfragen effizient und strukturiert zu erfassen, zu bearbeiten und abschließend zu erfüllen, um eine hohe Servicequalität und Kundenzufriedenheit sicherzustellen.
Im Rahmen des Service Request Managements ist der AN verpflichtet, folgende Anforderungen umzusetzen:
Erfassung und Dokumentation: Alle eingehenden Service Requests unverzüglich und vollständig zu erfassen, zu klassifizieren, zu priorisieren und zu bearbeiten. Die Bearbeitungsschritte sind nachvollziehbar zu dokumentieren und der aktuelle Status ist dem Anfragenden entsprechend der vereinbarten Reaktions- und Bearbeitungszeiten mitzuteilen.
Fachgerechte Bearbeitung: Sicherstellen, dass Service Requests innerhalb der vereinbarten Reaktions- und Bearbeitungszeiten fachgerecht bearbeitet werden.
Kontinuierliche Prozessverbesserung: Den Service Request Management-Prozess kontinuierlich zu überwachen und geeignete Verbesserungsmaßnahmen umzusetzen, um Effizienz und Qualität sicherzustellen.
2.8 Reporting
Der AN ist verpflichtet regelmäßige Berichte zu erstellen, die den aktuellen Stand sowie die Leistung der erbrachten IT-Dienstleistungen transparent darstellen.
Bis spätestens am 15. Kalendertag eines jeden Monats hat der AN einen Report mit den nachfolgend aufgeführten Informationen und Parametern zu erstellen und diesen unaufgefordert per E-Mail an den AG zu übermitteln. Die genaue Empfängeradresse wird dem AN nach Beauftragung durch den AG mitgeteilt.
Die Reports werden im Rahmen des Service Reviews zusammengefasst vorgestellt und bei Bedarf näher erläutert.
Der monatliche Report muss mindestens folgende Daten enthalten:
Allgemeine Rahmenbedingungen IT-Service Management Version 3.0 31
[Seite 32]
Übersicht der einzelnen Tickets mit folgenden Kennzahlen
o Eindeutige Identifikationsnummer/Referenz o Melder o Zeitpunkt des Eingangs der Störungsmeldung o Zeitpunkt des erfolgreichen Abschlusses des Vorgangs o Fehlerursache bei Störungen o Störungsdauer
Das regelmäßige Reporting gewährleistet eine transparente und systematische Darstellung der erbrachten Leistungen und ermöglicht es beiden Parteien, Verbesserungspotenziale frühzeitig zu erkennen, rechtzeitig auf Probleme oder Verzögerungen zu reagieren und die Qualität der IT-Dienstleistungen dauerhaft sicherzustellen:
| Bezeichnung | Beschreibung | Intervall |
|---|---|---|
| SLA-Reports gemäß Service- Level-Definition | Bericht über die Erfüllungsquote der vereinbarten Service Level Agreements der letzten 6 Monate. | Monatlich |
| Incident Trend | Bericht über die Anzahl der Störungen aller Prioritäts-Level der letzten 6 Monate. | Monatlich |
| Problem Trend | Bericht über die Anzahl der Problems aller Prioritäts-Level der letzten 6 Monate. | Monatlich |
| Service Requests Plan/IST | Bericht über die Anzahl der geplanten und offenen sowie geschlossenen Service Requests der letzten 6 Monate. | Monatlich |
| ITSCM Bericht | Bericht über durchgeführte ITSCM Maßnahmen und deren Ergebnisse. | Auf Anfrage |
| Risikobericht | Bericht über identifizierte Risiken und deren Status der letzten 6 Monate. | Monatlich |
Allgemeine Rahmenbedingungen IT-Service Management Version 3.0 32