LOS_GDI_Leistungsbeschreibung.pdf

[Seite 1]

RAG Aktiengesellschaft

Projekt: RAG IT 2027

Los GDI Applikationsbetrieb

Leistungsbeschreibung

[Seite 2]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 1 (47)

Inhaltsverzeichnis

Kapitel Seite Einführung....................................................................................................... 49 1.1 Beschreibung der Leistungspflichten ................................................................ 49 1.2 Service-Level .................................................................................................. 510 1.3 Beistellleistungen ............................................................................................ 510 1.4 Preismodell ..................................................................................................... 611 IT-Security-Management .............................................................................. 712 2.1 Grundsätzliche Anforderungen ....................................................................... 712 2.2 Verantwortlichkeiten IT-Security ..................................................................... 914 RAG - Energiemanagementsystem ........................................................... 1015 3.1 Energiemanagementsystem beim AN .......................................................... 1015 3.1.1 Grundsätzliche Anforderungen ..................................................................... 1015 Serviceprozesse ......................................................................................... 1116 4.1 Ausgangssitutation ................................... Fehler! Textmarke nicht definiert.16 4.2 Grundsätzliche Anforderungen ..................................................................... 1116 4.3 Aufwandserfassung ...................................................................................... 1318 4.4 Betriebs- und Prozesshandbücher ................................................................ 1318 4.4.1 Grundsätzliche Anforderungen ..................................................................... 1318 4.4.2 Gliederungs- und Inhaltsvorgabe BHB ......................................................... 1418 4.5 Steuerung der Zusammenarbeit ................................................................... 1620 4.5.1 Grundsätzliche Anforderungen ..................................................................... 1620 4.5.2 Agenda für Servicemeetings ......................................................................... 1721 4.6 Dokumentation Enterprise Architecture Management .................................. 1822 4.6.1 Grundsätzliche Anforderungen LUY ............................................................. 1823 4.7 Preismodell ................................................................................................... 1823 Übergreifende Services .............................................................................. 1924 5.1 Einleitende Beschreibung ............................................................................. 1924 5.2 Netzwerkanbindung zwischen AN und AG ................................................... 1924 5.2.1 Grundsätzliche Anforderungen ..................................................................... 1924 5.2.2 Verantwortlichkeiten Netzwerkanbindung ..................................................... 1924 5.3 Virenschutz ................................................................................................... 1924 5.4 Backup und Restore ..................................................................................... 1924 Rollen und Skill-Level für Optionale Leistungen ..................................... 2127 6.1 Skill-Level ..................................................................................................... 2127

[Seite 3]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 2 (47)

6.2 Rollen ........................................................................................................... 2228 Applikationsbetrieb GDI ............................................................................. 2632 7.1 Ausgangssituation ........................................................................................ 2632 7.1.1 Eingesetzte Versionen (Stand März 2026) ................................................... 2733 7.1.2 GDI Entwicklungsumgebung ........................................................................ 2834 7.1.3 GDI QS Umgebung ....................................................................................... 2834 7.1.4 GDI Produktionsumgebung .......................................................................... 2834 7.1.5 Sharepoint Entwicklungsumgebung .............................................................. 2935 7.2 Leistungsübergabepunkt .............................................................................. 2935 7.3 Anforderungen und Verantwortlichkeiten Applikationsbetrieb GDI ............... 2935 7.3.1 Grundsätzliche Anforderungen ..................................................................... 2935 7.3.2 Verantwortlichkeiten Entstörung ................................................................... 3036 7.3.3 Verantwortlichkeiten Monitoring .................................................................... 3036 7.3.4 Optional: Verantwortlichkeiten Installation von Applikationen und Updates (Minor/Major Version) ................................................................................... 3137 7.3.5 Verantwortlichkeiten Patches von Applikationen .......................................... 3137 7.3.6 Verantwortlichkeiten Applikationsbetrieb ...................................................... 3238 7.3.7 Verantwortlichkeiten Service Continuity Management .................................. 3238 7.3.8 Verantwortlichkeiten Kontinuierliche Verbesserung ...................................... 3238 7.3.9 Optional: Verantwortlichkeiten Übernahme aus Weiterentwicklung .............. 3238 7.3.10 Verantwortlichkeiten Betrieb von Datenschnittstellen ................................... 3339 7.4 Beistellleistungen Applikationsbetrieb GDI ................................................... 3339 7.5 Preismodell Applikationsbetrieb GDI ............................................................ 3339 Applikationssupport GDI ........................................................................... 3440 8.1 Ausgangssituation ........................................................................................ 3440 8.2 Leistungsübergabepunkt .............................................................................. 3440 8.3 Anforderungen und Verantwortlichkeiten Applikationssupport GDI .............. 3440 8.3.1 Grundsätzliche Anforderungen ..................................................................... 3440 8.3.2 Verantwortlichkeiten Incident Management .................................................. 3541 8.3.3 Verantwortlichkeiten Problem Management ................................................. 3541 8.3.4 Verantwortlichkeiten Change Management .................................................. 3743 8.3.5 Optional: Technischer Support und Anpassungen ....................................... 3743 8.4 Beistellleistungen Applikationssupport GDI .................................................. 3844 8.5 Preismodell Applikationssupport ................................................................... 3844 Transition und Transformation .................................................................. 3945 9.1 Grundsätzliche Anforderungen ..................................................................... 3945

[Seite 4]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 3 (47)

9.1.1 Grundsätzliche Anforderungen Transitionskonzeption ................................. 3945 9.1.2 Grundsätzliche Anforderungen Projektmanagement in der Transition .......... 4046 9.1.3 Durchführung der Transition ......................................................................... 4046 9.1.4 Design und Implementierung Service Prozesse ........................................... 4046 9.2 Beistellleistungen Transition ......................................................................... 4147 9.3 Preismodell ................................................................................................... 4147 Abnahmeverfahren ..................................................................................... 4248 10.1 Abnahme ...................................................................................................... 4248 Abkürzungsverzeichnis ............................................................................. 4450 Anhänge ...................................................................................................... 4652

[Seite 5]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 4 (47)

Einführung Mit Einstellung der deutschen Steinkohlenförderung endete 2018 ein Kapitel Industriegeschichte – nicht jedoch die Arbeit der RAG. Das Unternehmen übernimmt langfristig Verantwortung in den Bergbauregionen. Mit der Bearbeitung der sogenannten Ewigkeitsaufgaben trägt die RAG im Ruhrgebiet dazu bei, den Wasserhaushalt dort unter und über Tage zu regulieren. Oberstes Gebot sind dabei der Trinkwasser- und Umweltschutz. Bei den Ewigkeitsaufgaben handelt es sich um Bergbaufolgen, die – daher der Name – auf ewig Maßnahmen erfordern. Dazu zählen die Grubenwasserhaltung, Poldermaßnahmen über Tage sowie die Grundwasserreinigung an einigen ehemaligen Kokerei Standorten und das Grundwassermonitoring an kontaminierten Standorten. Ausdrücklich nicht Teil der Ewigkeitsaufgaben sind die Bergschäden an Gebäuden, Grundstücken oder Straßen, die auf den Steinkohlenbergbau zurückgehen. Sie zählen, wie auch die Sanierung alter Schächte, der Rückbau von Betriebsanlagen und Pensionsverpflichtungen, zu den sogenannten endlichen Aufgaben. Mit seiner Verantwortung trägt das Unternehmen dafür Sorge, dass es nicht nur während des Auslaufs, sondern auch in der Nachbergbau-Ära stabile Prozesse auf dem neuesten Stand der Technik sowie hohe Standards im Arbeits-, Gesundheits- und Umweltschutz gewährleistet. Für eine bestmögliche Unterstützung der Geschäftsprozesse setzt die RAG auf einen verlässlichen, stabilen und bedarfsgerechten IT-Betrieb, der in einem angemessenen Kosten-Nutzen-Verhältnis umgesetzt wird. Gegenstand der vorliegenden Leistungsbeschreibung ist der von der RAG benötigte Leistungsinhalt für den Applikationsbetrieb der Geodaten- Informationssysteme (GDI) Ziel ist eine verlässliche und Sichere IT-Basis für Applikationen und die Dienste, die die IT Ihren Nutzern zur Verfügung stellt.

Der AN erbringt diese Services primär auf Systemen, die durch andere Dienstleister im Auftrag der RAG betrieben werden. Das Zusammenwirken aller Services und die Sicherstellung einer stabilen Leistungserbringung für die Endanwender der RAG ist aus Sicht der RAG immer im Blick zu halten.

1.1 Beschreibung der Leistungspflichten Die Beschreibung der Services setzt sich aus der je Service dargelegten Ausgangssituation, den vom AN abzudeckenden bzw. zu erfüllenden Service- Anforderungen und Funktionalitäten sowie den von ihm grundsätzlich zu erbringenden Service-Aktivitäten zusammen. Der Beschreibung der Ausgangslage, der grundsätzlichen Anforderungen und Funktionalitäten nachfolgenden Aufstellungen der Service-Aktivitäten, ist jeweils eine entsprechende DEMI-Matrix (Verantwortlichkeitsmatrix) zugeordnet.

[Seite 6]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 5 (47)

Das Kürzel DEMI leitet sich dabei aus den Begriffen „Durchführend“, „Entscheidend“ (im Sinne einer Ergebnisverantwortung), „Mitarbeitend/ Mitwirkend“ und „Informiert“ ab. Diese Matrix bildet u.a. die mit den Services jeweils verbundenen, vom AN mindestens zu erbringenden Service-Aktivitäten ab. Soweit Mitwirkungspflichten der RAG bestehen, so sind diese, wie auch etwaig erforderliche Beistellleistungen, innerhalb der nachfolgenden jeweiligen Servicebeschreibungen abschließend aufgeführt.

1.2 Service-Level Die geforderten Qualitäten für die im Folgenden beschriebenen Services werden über Service-Level festgelegt. Sämtliche Service-Level sind im Anhang Service- Level gebündelt aufgeführt.

1.3 Beistellleistungen Folgende Beistellleistungen gelten übergreifend für alle Services dieses Loses und werden durch die RAG kostenfrei erbracht. Weitere servicespezifische Beistellleistungen sind in den jeweiligen Kapiteln festgelegt.

[Seite 7]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 6 (47)

Element

Erforderlicher Zugang zu Räumlichkeiten sofern zur Leistungserbringung erforderlich

Räumlichkeiten und max. 2 Arbeitsplätze für die Transition sofern notwendig

Benannte Ansprechpartner für Transition und Betrieb, die über die notwendigen Entscheidungsbefugnisse verfügen, sowie Personen für Tests und Abnahmen

Benennung von Wissensträgern

Beistellung aller notwendigen technischen Zugänge (Useraccounts, Kennwörter, Schnittstellendefinitionen etc.) zur Übernahme der Leistungen

Bereitstellung der bestehenden Dokumentationen, sofern diese vorliegen

Information über Veränderungen in Unternehmensrichtlinien

Sicherheitsleitfäden und sonstige, einzuhaltende, organisatorische Richtlinien

Organisationsdaten innerhalb des IAM Systems

Zugang zu Leistungen Dritter, sofern die RAG Vertragsinhaber ist und diese Leistungen zur Leistungserbringung des AN erforderlich sind

Terminkoordination mit anderen Losen, Dienstleistern

Zentrales ITSM Tool TOPdesk und Zugänge für Bearbeiter

Tabelle 1: Beistellleistungen übergreifend

1.4 Preismodell Die Verrechnung der Leistungen erfolgt entweder monatlich (M) jährlich (J) einmalig (E) Welches Verrechungsmodell für die jeweilige Leistung maßgeblich ist, ergibt sich aus der Spalte V der Tabellen in den jeweiligen Kapiteln zum Preismodell und dem Preiserhebungsblatt. Der AN wird ein entsprechendes Reporting neben der eigentlichen Rechnungstellung aufbauen, um Mengen und Verbräuche je Preiselement monatlich über die Vertragslaufzeit zu berichten.

[Seite 8]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 7 (47)

IT-Security-Management 2.1 Grundsätzliche Anforderungen  Die RAG setzt die Regelungen aus ISO 27001 für die Definition und Steuerung aller internen Prozesse im Bereich IT-Sicherheit um.  Der AN wird zum Vertragsbeginn geforderte Zertifizierungen über die Vertragslaufzeit aufrechterhalten und kontinuierlich an der Verbesserung der IT- Sicherheit arbeiten.  Der AN benennt seinen für die RAG zuständigen Sicherheitsbeauftragten. Dieser dient als direkter Ansprechpartner zu Fragen der IT-Sicherheit.  Der AN wird die Services kontinuierlich überwachen und etwaige Fehler bzw. Mängel identifizieren und diese beseitigen bzw. auf deren Behebung hinwirken, sofern diese nicht in seinem Verantwortungsbereich liegen.  Bei Änderungen der Vorgaben des Standards, wird der AN diese in seine eigenen Prozesse und Verfahrensweisen sowie in seine technischen Lösungen übernehmen.  Des Weiteren wird der AN unverzüglich Mitteilung über wesentliche Probleme oder sonstige außergewöhnliche Vorkommnisse bei der Leistungserbringung, sofern in berechtigtem Interesse der RAG, wie etwa den Verdacht von Straftaten eigener Mitarbeiter oder technische Störungen, machen und die zur Behebung der Probleme ergriffenen Maßnahmen benennen sowie in Bezug auf den Fortschritt bei deren Umsetzung der RAG fortlaufend Bericht erstatten. Soweit ein berechtigtes Interesse der RAG besteht, wird der AN im Rahmen der rechtlichen Zulässigkeit sämtliche vorliegenden Informationen zugänglich machen und bei der Aufklärung kooperativ mitwirken.  Der AN wird im Hinblick auf die Leistungen, insbesondere für die technischen Systeme, eine Notfallplanung implementieren, die eine vertragsgegenständliche Leistungserbringung auch bei unvorhersehbaren Ereignissen und weitreichenden Ausfällen sicherstellt. Die Dokumentationen werden Teil der Betriebsdokumentation.  Der AN wird IT- Systeme anhand anerkannter Standards wie z.B. BSI und CIS sicher betreiben. Der BSI Standardlevel wird immer angenommen, sofern nicht anderweitig in einem Service definiert. Abweichungen sind immer zu dokumentieren.  Der AN berücksichtigt SLA gemäß Meldungen und Sicherheitshinweise von BSI, und CERT. Sofern diese für die geschuldeten Services Relevanz besitzen, werden behebende Maßnahmen dokumentiert, geplant, eingeleitet und über deren Umsetzung berichtet. Kommentiert [MM1]: Doppelter Textblock  Der AN berücksichtigt SLA gemäß Meldungen und Sicherheitshinweisen von BSI, und CERT. Sofern diese für die geschuldeten Services Relevanz besitzen, werden behebende Maßnahmen dokumentiert, geplant, eingeleitet und über deren Umsetzung berichtet. Der AN gewährt ausreichende technische Zugriffe für die SIEM und Vulnerability-

[Seite 9]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 8 (47)

Scanner-Systeme der RAG auf Systeme, die exklusiv für die RAG betrieben werden bzw. die durch die RAG beigestellt wurden. Mehrmandantensysteme, die der AN für mehrere Kunden einsetzt, und die keinem eigenen SIEM/Vulnerability Scanning durch den AN unterliegen, sind auch anzubinden. Sofern im Rahmen einer Risikobetrachtung durch den AN dargestellt werden kann, dass durch die Nnicht-Anbindung keine erhöhten IT- Sicherheitsrisiken entstehen, kann diese Anforderung durch die RAG ausgesetzt werden.  Der AN nimmt am Austausch mit dem SOC/SIEM Dienstleister teil, um ein optimales Zusammenspiel sicherzustellen.  Auf Systeme, die bereitgestellt oder ausschließlich für die RAG betrieben oder genutzt werden, behält die RAG uneingeschränkte Lese- und Schreibrechte für benannte Mitarbeitende der RAG. Auf Systeme, die vom AN für mehrere Kunden eingesetzt werden, die jedoch keine Mehrmandatenfähigkeit besitzen, erhält die RAG mindestens uneingeschränkten, lesenden Einblick in die Bereiche, die die RAG betreffen.  Auf Systeme, die bereitgestellt oder ausschließlich für die RAG betrieben oder genutzt werden, behält die RAG uneingeschränkte Rrechte für benannte Mitarbeitende der RAG. Auf Systeme, die vom AN für mehrere Kunden eingesetzt werden, die jedoch keine Mehrmandatenfähigkeit besitzen, erhält die RAG mindestens uneingeschränkten, lesenden Einblick in die Bereiche, die die RAG betreffen. Kommentiert [SL2]: Was ist mit Logging? Also der Protokollierung von Administrativen Zugriffen? Wollen wir das  Sollte ein System nachweislich technisch keine Möglichkeit besitzen, der hier zentral vorgeben? RAG lesenden Zugriff einzurichten, ohne dass Daten anderer Kunden des AN hiervon offengelegt werden, wird der AN kostenfrei auf Verlangen der RAG die gewünschten Informationen exportieren und Daten von Dritten unkenntlich machen.  Die RAG setzt generell ein 3-Tier Admin- und Serverkonzept um. So kommen z.B. je natürlicher Person je Tier unterschiedliche Admin Accounts zum Einsatz. Der AN wird dies berücksichtigen.  Die RAG strebt an, sämtliche administrativen Zugänge über eine PIM- Lösung abzusichern. Für Microsoft Entra ist dies bereits implementiert und soll weiter ausgebaut werden. Der AN wird dies berücksichtigen.

[Seite 10]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 9 (47)

2.2 Verantwortlichkeiten IT-Security

Tabelle 2: Verantwortlichkeiten IT Security Management

[Seite 11]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 10 (47)

RAG - Energiemanagementsystem Die RAG hat in Ihrer Strategie die Förderung des Ausbaus erneuerbarer Energien durch die Bereitstellung bergbauspezifischer Ressourcen verankert. Wir leisten damit sowohl einen Beitrag zur Schonung natürlicher Rohstoffe als auch zum Umwelt- und Klimaschutz. Zu unserem Selbstverständnis gehört es, den Energieverbrauch in unserem Unternehmen kontinuierlich zu senken. Um das zu erreichen, haben wir die Einführung eines Energiemanagementsystems nach DIN EN ISO 50001 beschlossen und umgesetzt. Hierbei wird durch das Zusammenwirken von Energiepolitik, strategischen Energiezielen, Aktionsplänen der Betriebe und Verwaltungen sowie der jährlichen Überprüfung durch eigene Mitarbeiter und externe Sachverständige die stetige Verbesserung unseres Energieverbrauchs angestrebt. Es soll dabei helfen, die Energieeffizienz zu verbessern, Emissionen von Treibhausgasen und anderen Umweltbelastungen zu reduzieren sowie Einsparpotenziale aufzudecken. Darüber hinaus schafft es die Grundlage zur weiteren Inanspruchnahme der sogenannten „besonderen Ausgleichsregelung“ nach dem Erneuerbare-Energien-Gesetz. Als dynamischer Prozess unterliegt das Energiemanagementsystem einem sich jährlich wiederholenden Zyklus.

3.1 Energiemanagementsystem beim AN 3.1.1 Grundsätzliche Anforderungen  Der AN hat ein Energiemanagementsystems nach DIN EN ISO 50001 oder ISO14001 eingeführt oder Sie berücksichtigen Energie- und Umweltschutz in Ihrem Unternehmen  Der AN verwendet intern eine Beschaffungsrichtlinie, die auch Kriterien wie Energieverbrauch und/oder weitere Anforderungen wie z.B. Blauer Engel, EU-Umweltzeichen, Energy Star etc. berücksichtigt.  Die Zuschlagskriterien des AN enthalten: Betriebskosten, Energieverbrauch, Lebenszykluskosten und Rentabilität.  Der AN fordert von seinen Lieferanten eine Aussage, mit zur Verfügung gestellten Energieträgern wirtschaftlich umzugehen.  Die Einkaufsbedingungen des AN beinhalten die Forderung, dass sämtliche Lieferungen/ Leistungen dem neuesten Stand der Technik, den einschlägigen rechtlichen Bestimmungen sowie den Vorschriften und Richtlinien von Behörden, Berufsgenossenschaften und Fachverbänden entsprechen.

[Seite 12]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 11 (47)

Serviceprozesse 4.1 Ausgangssituation Die RAG hat angelehnt an ITIL die Prozesse Incident, Change, Problem und Request Fulfillment eingeführt und unterstützt diese mit dem Service Management Tool TOPdesk1. Der Servicedesk wird durch einen Dienstleister der RAG erbracht und nimmt Anfragen der Mitarbeitenden und weiterer berechtigter Personen (idR. Externe Mitarbeiter, Dienstleister) an, dokumentiert, kategorisiert und priorisiert diese. Sofern möglich erfolgt eine Erstlösung direkt durch den Servicedesk. Hierzu kommt das Knowledge Base Modul zum Einsatz, in dem entsprechende Informationen vorgehalten werden. Sofern keine Erstlösung möglich ist, erfolgt eine Weiterleitung als Incident, Change oder Request an die zuständigen 2nd Level Stellen. Gesteuert werden die Prozesse intern von einem Incident und Change-Manager, der hierzu mit allen relevanten Dienstleistern im Austausch steht, um akute Themen zu klären und prozessuale Verbesserungen umzusetzen. Die RAG nutzt TOPdesk in der SaaS Variante, weshalb externe Anbindungen von Dienstleistern direkt über das Internet möglich sind. Hierzu bietet TOPdesk eine Web-API, die auch bereits aktuell aktiv genutzt wird. Genauere Informationen finden Sie unter https://developers.topdesk.com/ 4.2 Grundsätzliche Anforderungen  Der AN hat folgende Servicemanagement-Prozesse, angelehnt an ITIL Version 3 ff., aktuell eingeführt:  Event Management  Incident Management  Problem Management  Change Management  Request Fulfillment  Alle Grundsätze, Arbeitsanweisungen und Pläne für die verpflichtenden Prozesse sind dokumentiert und die entsprechenden Dokumente werden gepflegt.  Die Ziele für jeden verpflichtenden Prozesse sind definiert.  Rollen und Verantwortlichkeiten für jeden verpflichtenden Prozess sind festgelegt und zugewiesen.  Der AN wird wichtige Funktionen (Steuerung und Erbringung) innerhalb der Prozesse so besetzen, dass auch beim Ausfall oder Abwesenheit von Mitarbeitenden die Prozesse weiterhin in gleicher Qualität erbracht werden können.  Die Schnittstellen zwischen den eingesetzten Prozessen sind dokumentiert

1 www.topdesk.com

[Seite 13]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 12 (47)

 Der AN verpflichtet sich der Unterstützung der Lösungsfindung bei übergreifenden Störungen, die ggf. nicht im direkten Zuständigkeitsbereich des AN befinden.  Der AN versteht sich als Teil der Gesamt-IT der RAG, die neben internen Kräften der RAG auch aus anderen Dienstleistern besteht. Das höchste Ziel des AN ist die Zufriedenheit der Endanwender der RAG durch zügige und dienstleisterübergreifende Lösungsorientierung.  Sofern Weiterleitungsempfänger für Events, Störungen oder Changes/Tasks bekannt sind, erfolgt eine direkte Weiterleitung an den zuständigen Empfänger.  Bereitstellung von Informationen an den Servicedesk zur Steigerung der Erstlösungsrate.  Im Rahmen der Servicesteuerung erfolgt ein regelmäßiger Austausch der für die Prozesse zuständigen Manager (z.B. Incident Manager, Change Manager) mit den jeweiligen entsprechenden Personen bei der RAG.  Der AN wird fortlaufend an der Optimierung und Automatisierung der Prozesse arbeiten.  Der AN wird eigene Verfahren zur Messung und dem Berichten von Serviceleveln aufsetzen und hierzu nötigen Plattformen und Systeme beistellen und betreiben.  Der AN nutzt das Tickettool „TOPdesk2“ der RAG oder bindet sich an das Tickettool per elektronischer Schnittstelle 3 an.  Die Ticketnummer aus TOPdesk ist in der Kommunikation immer führend und zu verwenden.  Sofern eine Schnittstelle zum Einsatz kommt, werden folgende Anforderungen erfüllt:  die Möglichkeit Incident-, Change- und Changeaktivitäts- -Tickets zu beidseitig zu übertragen  Inhaltsänderungen und Statusänderungen an übertragenen Tickets werden nahezu in Echtzeit und sofern für die RAG relevant, umfänglich an TOPdesk übertragen.  Sofern Changes zur Dokumentation von Vorgängen innerhalb der Serviceorganisation des AN erforderlich sind, wird der AN diese stellen und sofern erforderlich, die RAG zur Freigabe auffordern.  Schriftliche und mündliche Kommunikation mit der RAG ist grundsätzlich Deutsch.

2 www.topdesk.com

3 https://developers.topdesk.com/

[Seite 14]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 13 (47)

4.3 Aufwandserfassung  Mitarbeitende des AN erfassen Ihre Aufwände im Rahmen von T&M Leistungen als Grundlage der Rechnungsstellung.  Die Aufwandserfassung erfolgt mit einer Genauigkeit von 15min.  Die Erfassung von Aufwänden erfolgt immer zeitnah, spätestens wöchentlich, je Ticket oder Auftrag unter Angabe der Ticketnummer der RAG oder der Auftragsnummer.  Je Ticket oder Auftrag sind die Aufwände sowohl je Einzelaufwand als auch kumuliert auszuweisen.  Die monatliche Abrechnung muss mit den erfassten Stunden übereinstimmen.  Eine Nacherfassung ist nur bei begründeten Ausnahmen zulässig.

4.4 Betriebs- und Prozesshandbücher 4.4.1 Grundsätzliche Anforderungen  Der AN ist verpflichtet, im Rahmen der Transition (Betriebsübernahme) der Services auf eigene Kosten Betriebs- und Prozesshandbücher - nachfolgend kurz: BHBs und PHB - initial bereit zu stellen und während der Vertragslaufzeit kontinuierlich zu pflegen.  In den BHBs werden die konkreten Vorgaben für den Betrieb je Service festgelegt. Das PHB regelt die konkreten Vorgaben für die übergreifenden betrieblichen Service Prozesse. Die Vorgaben aus den BHBs und dem PHB sind vom AN im Rahmen der Leistungserbringung einzuhalten.  BHBs und PHB sind der RAG in elektronischer Form zu überlassen und auf einer gemeinsamen Teams Ablage im Tenant der RAG abzulegen. Die Handbücher sind vom AN in deutscher Sprache zu verfassen. Alle Handbücher unterliegen einer Abnahme durch die RAG (AN zeigt Abnahmebereitschaft an, RAG prüft und meldet Abnahmeergebnis bzw. Abweichungen).  Der AN gewährt nach Betriebs-/Leistungsübergang der RAG und den übrigen Leistungsempfängern sowie gegebenenfalls von der RAG beauftragten Dritten an den Daten bzw. an den damit verbundenen Inhalten der BHBs bzw. PHB ein ausschließliches, unwiderrufliches, räumlich und zeitlich unbeschränktes und übertragbares Nutzungsrecht, das auch nach Beendigung des Vertrages fortdauert. Das Nutzungsrecht beinhaltet auch die Befugnis zur Veränderung und Bearbeitung.  BHBs und PHB sind bei wesentlichen Änderungen vom AN anzupassen.  Der AN stellt die historischen Versionen (ältere Versionsstände) von BHBs und PHB über die Vertragslaufzeit der RAG zur Verfügung. Der AN gewährt der RAG jederzeit Zugriff auf BHBs und PHB sowie auf die jeweiligen älteren Versionsstände.

[Seite 15]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 14 (47)

4.4.2 Gliederungs- und Inhaltsvorgabe BHB  Das Betriebshandbuch wird vom AN mit nachfolgender Gliederung erstellt.  Nicht relevante Gliederungspunkte können in Abstimmung mit der RAG entfallen und übergreifende Themen können in eigenständige Dokumente ausgelagert werden. Nicht relevante oder redundante Gliederungspunkte können in Abstimmung mit der RAG entfallen und übergreifende Themen können in eigenständige Dokumente ausgelagert werden. Punkte der 2. Gliederungsebene sind Kommentiert [MM3]: fehlt hier ein Halbsatz?  Sofern Verweise auf externe Systeme und Inhalte (Assetmanagementsysteme, Dokumentationssysteme und -Ablagen, Generelle Betriebsvorgaben etc.) erfolgen, auf die die RAG keinen direkten Zugriff hat, werden diese kenntlich gemacht. Verweise, auf die die RAG keinen Zugriff hat, sind durch den AN zu minimieren bzw. es ist entsprechender Lesender Zugriff einzurichten. (Vergl. hierzu auch 2.1 lesender Zugriff auf Systeme)

 Bestandsdokumente entsprechen nicht der neuen Gliederung. Bestandsdokumentationen sind bei Serviceübernahme entsprechend zu aktualisieren und anzupassen  Gliederung:  1. Zusammenfassung und Service-Steckbrief  Versionsstand, Datum, Status, Änderungshistorie  Service-Name  Service-Beschreibung (Zweck, Nutzen, Kerntasks)  Business Owner / Service Owner / Technischer Owner  Kontaktpunkte (Support-Kanal, Rufbereitschaft, Eskalation)  Geltungsbereich und Abhängigkeiten zu anderen Services  2. Leistungsumfang und Service-Level  Leistungsmerkmale (Funktion, Umfang, Nicht- Leistungsumfang/Exclusions)  SLA/OLA: geltende Verfügbarkeit, Reaktions- und Lösungszeiten  Support-Zeiten und Wartungsfenster  KPIs und Zielwerte  3. Architektur und technische Basis  Systemübersicht (Diagramm/Beschreibung: Komponenten, Datenflüsse)  Infrastruktur (Compute, Storage, Netzwerk, Cloud-Accounts)  Applikations-Stack (Versionen, Frameworks, Abhängigkeiten)  Schnittstellen und Integrationen (APIs, Drittsysteme)  Datenflüsse und Speicherorte

[Seite 16]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 15 (47)

 4. Rollen, Verantwortlichkeiten  DEMI für Betrieb, Change, Security, Incident  Interne Rollen (Ops Lead, Admins, Produktverantwortliche)  Provider-Rollen (Delivery Manager, Support-Leads)  Kunden-Rollen (Applikationsverantwortliche, Key- User/Abteilungen)  Eskalationspfade (technisch und managementseitig)  5. Betriebsprozesse und Workflows  Incident Management: Priorisierungskriterien, Ablauf, Status- Updates, Abschlussbedingungen  Request Fulfilment: Standard-Requests, Genehmigungen,  Change & Release Management: Change-Typen, Tests, Rollback- Plan, Deployment-Checklisten  Kapazitäts- und Performance-Management: Schwellwerte, Alert- Regeln, Skalierungsstrategien  6. Runbooks und Aufgaben  Tägliche/Wöchentliche/Monatliche Routinen (Checks, Reports, Patches)  Standard-Tasks mit Schritt-für-Schritt-Anweisungen  Automatisierungen (Skripte, Pipelines, Jobs)  Backup & Restore: Pläne, Testzyklen, Recovery-Zeiten, RPO/RTO- Ziele, Medien, Offsite  7. Monitoring und Logging  Metriken, Logs: Messpunkte, Quellen, Schwellwerte  8. Sicherheit und Compliance  Sicherheitsarchitektur (Zugriff, Rollen, Secrets, Schlüsselmanagement)  Härtung & Baselines (CIS/Benchmarks, Konfig-Standards)  Identity & Access: JML-Prozesse, RBAC, Rezertifizierung  Vulnerability Management: Scans, Priorisierung, Remediation- SLAs  Regulatorik/Compliance: Datenschutz, Logging/Retention, Audits  Notfallmanagement: Incident Response, Forensik, Krisenkommunikation  9. Datenmanagement  Datenklassifizierung und Schutzbedarfe  Archivierung und Retention

[Seite 17]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 16 (47)

4.5 Steuerung der Zusammenarbeit 4.5.1 Grundsätzliche Anforderungen  Die Steuerung der Zusammenarbeit wird im Rahmen der Prozessdefinitionen gemeinsam festgelegt und im Prozesshandbuch dokumentiert. Hierzu zählen z.B.  Regelungen zur Eskalationsstruktur  Regelungen zur Kommunikationsstruktur  Regelungen zur Gremienstruktur  Die Steuerung der Zusammenarbeit umfasst gleichermaßen fachlich- technische, operative, kaufmännische und vertragliche Themen.  Vor diesem Hintergrund benennen RAG und AN zentrale Ansprechpartner, die der jeweils anderen Partei, die für die Erbringung der Leistungen erforderlichen Informationen aus dem Bereich der Services zur Verfügung stellen und notwendige Entscheidungen treffen und/oder herbeiführen.  Im Prozesshandbuch sind die zentralen Ansprechpartner beim AN festzulegen, die ein gesteigertes Maß an Qualifikation erfordern und von besonderer Bedeutung für die Erbringung der Leistungen sind. Der gleichwertige Austausch dieser Personen erfolgt nur aus triftigem Grund und in Abstimmung mit der RAG.  Die zentralen Ansprechpartner fokussieren sich primär auf die Optimierung der jeweiligen Services, sei es prozessual oder technisch und sind aktiv in der Erstellung von Zieldesigns im Rahmen von Changes eingebunden. Sie sorgen weiterhin dafür, dass Services nicht gegen die vereinbarten Designgrundsätze verstoßen.  Die RAG ist berechtigt, unter Angabe wichtiger Gründe (z.B. Verstoß gegen strafrechtliche Vorschriften oder Verfehlungen im arbeitsrechtlichen Sinn, die mindestens eine Abmahnung rechtfertigen würden) den Austausch eines vom AN eingesetzten Mitarbeiters zu verlangen.  Die zur Steuerung notwendigen Protokolle, Meetings etc. werden im Prozesshandbuch vereinbart. Die Vertragsparteien stimmen sich in regelmäßigem Zyklus über die Qualität der Leistungserbringung, über Problemfälle sowie anstehende Änderungen des Leistungsumfangs ab. Zur Abstimmung gehören regelmäßige Meetings.  Die Meetingstruktur folgt dem Aufbau strategisch, taktisch, operativ. Im operativen Bereich erfolgen die Abstimmungen je Service und können auf Basis von Verantwortungen bei der RAG oder dem AN sinnvoll gruppiert werden. Die Sstrategischen und Ttaktischen Meetings erfolgen je Los.  Die Meetingfrequenzen sind  Strategisch -> jährlich  Taktisch -> Monatliches Servicemeeting (Inhalte siehe 4.5.2)

[Seite 18]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 17 (47)

 Operativ -> mindestens monatlich, nach Bedarf und in der Transition häufiger  Formatiert: Einzug: Links: 4,54 cm, Keine Aufzählungen oder Nummerierungen 4.5.2 Agenda für Servicemeetings Um einen einheitlichen Ablauf und Inhalt zu gewährleisten, erfolgen Servicemeetings nachfolgender Agenda. Eine Anpassung der Agenda erfolgt in gegenseitigem Einverständnis (z.B. Übertragung Punkt 5 in ein CAB Meeting).  1. Service-Status und Highlights  Kurzüberblick: Stabilität, Verfügbarkeit, besondere Ereignisse  Positive Highlights/Erfolge, Lessons Learned  2. SLA/OLA-Performance und KPIs  SLA-Erfüllung  Trends vs. Vormonate/-Quartale, Zielerreichung und Forecast  Pönalestand  3. Kosten und Kostenübersicht  Abgenommene Mengen (Plan/Ist/Forecast)  Kosten (Plan/Ist/Forecast) von Zusatzbeauftragungen und Projekten  4. Incidents, Major Incidents und Problem Management  Top-3 Incidents inkl. Root Cause, Impact, Zeitlinie  Major Incident Review: Kommunikation, Wirksamkeit der Maßnahmen  Offene Problems/RCAs, Known Errors, Maßnahmenfortschritt  5. Changes, Releases und Deployments  Durchgeführte Changes: Erfolg, Abweichungen, Rollbacks  Anstehende Changes/Freeze-Fenster, Risiken und Abhängigkeiten  Release-Qualität: Defect-Raten, Post-Deployment-Issues  Change-Planung die nächsten 4 Wochen  6. Kapazität, Performance und Verfügbarkeit  Ressourcenauslastung: Compute/Storage/Netzwerk, Lizenzen  Performance-Bottlenecks, Skalierungsplan  Monitoring/Alerting-Qualität: blinde Flecken, Runbook-Abdeckung  7. Sicherheit, Compliance und Audit-Themen  Vulnerabilities: offene Findings, Risk Acceptance, Remediation- SLAs  Identity & Access: Rezertifizierungen, kritische Berechtigungen  Backup/Restore-Tests, DR-Readiness, Datenschutz/Regulatorik  8. Verbesserungen, Automatisierungen

[Seite 19]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 18 (47)

 Continual Improvement: Maßnahmen, Prioritäten, Business Value  Automatisierungschancen, Self-Service, Standardisierung  Formatiert: Einzug: Links: 4,54 cm, Keine Aufzählungen oder Nummerierungen 4.6 Dokumentation Enterprise Architecture Management Der methodische Einsatz von Enterprise Architecture Management (EAM) hilft, die IT-Landschaft transparent abzubilden, u.a. in Form einer vollständigen Dokumentation der bestehenden IT-Landschaft. Das stellt eine gute Basis für die Know-how-Sicherung sowie die Bebauungsplanung und Strategieentwicklung dar. Dadurch können Geschäftsanforderungen schnell im richtigen IT-Kontext bewertet und die notwendigen Maßnahmen zeitnah eingeleitet werden. Die RAG verwendet hierzu im Bereich der Server das Tool LUY, um die Ausgestaltung der IT-Systeme, der Anwendungen und insbesondere die Verbindungen der Komponenten Untereinander zu dokumentieren. LUY stellt hierbei eine Ergänzung zur CMDB innerhalb TOPdesk dar, die in größerer Detailtiefe die Ausprägung von Applikationen zeigt. Die RAG verwendet im LAN/WAN Bereich das Tool Docusnap, um die Ausgestaltung der LAN/WAN Infrastruktur und insbesondere die Verbindungen der Komponenten Untereinander zu dokumentieren.

4.6.1 Grundsätzliche Anforderungen LUY  Der AN liefert der RAG bei Veränderungen die benötigten Informationen zur Pflege der Dokumentationssysteme zu.  Formatiert: Einzug: Links: 3,54 cm, Keine Aufzählungen oder Nummerierungen, Tabstopps: 3,54 cm, Listentabstopp 4.7 Preismodell Die vorangehend beschriebenen Leistungen sind integrale Bestandteile aller in dieser Leistungsbeschreibung enthaltenen Services. Sie werden daher nicht separat bepreist, sondern sind vielmehr mit den Servicepauschalen der zu erbringenden Services abgegolten.  Formatiert: Einzug: Links: 3,54 cm, Keine Aufzählungen oder Nummerierungen

[Seite 20]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 19 (47)

Übergreifende Services 5.1 Einleitende Beschreibung Die im Folgenden beschriebenen, übergreifenden Services sind wie z.B. die Serviceprozesse durch den AN im Rahmen der Erbringung der einzelnen Services zu erfüllen bzw. zu leisten. Die Kosten sind jeweils anteilig pro Service einzukalkulieren. Für die Implementierung und Erbringung der übergreifenden Services erfolgt keine gesonderte Berechnung, außer es existiert eine entsprechende Preisposition im Preismodell.

5.2 Netzwerkanbindung zwischen AN und AG 5.2.1 Grundsätzliche Anforderungen  Der AN stellt im Rahmen der Leistungserbringung eine geeignete Netzwerkanbindung her, sofern dies zur Leistungserbringung notwendig ist  Diese Netzwerkanbindung kann auch per VPN erfolgen. Der AN unterhält hierzu einen entsprechenden VPN Endpunkt.  Die RAG stellt hierzu ein dediziertes Management-LAN zur Verfügung

5.2.2 Verantwortlichkeiten Netzwerkanbindung

Tabelle 3: Verantwortlichkeiten Netzwerkanbindung

5.3 Virenschutz Die RAG betreibt eine zentrale Virenschutzlösung auf Basis von zurzeit Defender. Der AN wird mit den zuständigen Stellen zusammenarbeiten, um ein optimales Zusammenspiel zwischen Applikationsplattform und Virenschutz sicherzustellen. Ausnahmen kommen nur dann zur Anwendung, wenn dies zur Funktion der Applikation essentiell ist. Der AN unterstützt das zuständige Team zur Sicherstellung der Sicherheit der gesamten Plattform.

5.4 Backup und Restore Die RAG betreibt eine zentrale Sicherungsplatform auf Basis von zurzeit Veeam. Der AN wird mit den zuständigen Stellen zusammenarbeiten, um eine geeignete Sicherung der betriebenen Applikationen sicherzustellen. Der AN wird auf Basis der bereitgestellten Backupplattform nach Stand der Technik, den SLA Anforderungen, den vereinbarten Anforderungen an RTO/RPO und der

[Seite 21]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 20 (47)

Systemkritikalität Datensicherungen durchführen und den Erfolg von Sicherungsjobs sicherstellen.

[Seite 22]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 21 (47)

Rollen und Skill-Level für Optionale Leistungen 6.1 Skill-Level Leistungen, die nicht pauschal vergütet (optionale Leistungen), werden nach Aufwand entsprechend dem Skill-Level vergütet. Die ersten 3 Level können auch durch Nearshore Ressourcen abgedeckt werden, sofern die Rolle der Ressource dies laut Tabelle 5Fehler! Verweisquelle konnte nicht gefunden werden. zulässt. Kommentiert [MM4]: welche Tabelle? Vor diesem Hintergrund werden folgende Skill-Level gefordert:

[Seite 23]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 22 (47)

Tabelle 4: Skill-Level

6.2 Rollen Für die Leistungserbringung kommen aus Sicht der RAG insbesondere die im Folgenden aufgeführten Rollen in Betracht. Die dort beschriebenen Rollen erfordern unterschiedlich hohe Qualifikationen und Erfahrungen. Aus diesem Grunde wird für jede Rolle der mögliche Skill-Level festgelegt. Mit einem Stern () gekennzeichnete Einträge können auch durch Nearshore-Ressourcen abgedeckt werden. Mit einem Stern () gekennzeichnete Einträge können auch durch Nearshore-Ressourcen abgedeckt werden.

[Seite 24]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 23 (47)

[Seite 25]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 24 (47)

Tabelle 5: Rollen innerhalb der Service-Erbringung Die erforderlichen Skill-Level orientieren sich an der Aufgabenstellung und nicht an den ausführenden Personen.

6.3 Preismodell Optionale Leistungen Für kleine Veränderungen (<10PT) besonders bei optionalen Leistungen, die über den Betrieb hinausgehen, wird folgendes Preismodell vereinbart:

[Seite 26]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 25 (47)

[Seite 27]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 26 (47)

Applikationsbetrieb GDI Der AN wird im Rahmen des GDI Applikationsbetriebs für die Anwendungen der Anwendungsliste den Applikationsbetrieb erbringen. Der Begriff Applikationsbetrieb umfasst dabei ein Bündel organisatorisch, sachlich und technisch zusammenhängender IT-Aufgaben, Funktionen und Leistungen sowie übergreifender Prozesse und Standards für die zu betreibenden Anwendungen, die insgesamt der Installation, Inbetriebnahme und Aufrechterhaltung des stabilen und performanten Betriebs dieser Anwendungen dienen. Abgrenzung Leistungen zur (Weiter-)-Entwicklung der Anwendungen sind nicht Gegenstand dieser Servicebeschreibung, sondern werden in der Regel durch einen Dritten erbracht. Sofern aus der vorliegenden Servicebeschreibung organisatorische und/oder technische Schnittstellen zu den Entwicklungsleistungen erforderlich werden, sind diese in den nachfolgenden Leistungsbeschreibungen angegeben. Der AN gewährleistet vor diesem Hintergrund eine koordinierte, störungs- und unterbrechungsfreie Übernahme in den Betrieb und eine Zusammenarbeit der eingesetzten Mitarbeiter und/oder Subunternehmer mit den Entwicklern und sorgt für eine ausreichende Abstimmung und Kommunikation. 7.1 Ausgangssituation Geodateninfrastruktur RAG-GDI Raumbezogene Informationen (Geodaten) sind für verschiedenste Entscheidungsprozesse in einem Unternehmen von großer Bedeutung. Um die organisationsübergreifende Verfügbar- und Zugänglichkeit hochwertiger Geodaten zu gewährleisten und eine standardisierte gemeinsame Nutzung zu ermöglichen, setzt die RAG auf ein zentrales, konzernweites Geodatenmanagement in Form einer Geodateninfrastruktur (RAG-GDI). Dabei umfasst die RAG-GDI sowohl technische als auch organisatorische Festlegungen, die den Betrieb der Geodateninfrastruktur regeln und sicherstellen. Technische Bestandteile der RAG-GDI Auf der technischen Seite umfasst die RAG-GDI Geodaten, Geodienste, Schnittstellen und Netzwerke. Dabei bildet die ArcGIS-Plattform mit seinen Kernprodukten (Desktop, Server, Datenmanagement) eine wichtige Grundlage zur Erzeugung, Ablage, Verwaltung und Bereitstellung von Geodaten. Sie kann jedoch aufgrund der Vielzahl von Applikationen, Anwendungsfällen und Schnittstellen innerhalb des Unternehmens nicht alle Geschäftsprozesse abbilden.

[Seite 28]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 27 (47)

Geodaten Je nach Anwendungsfall werden Geodaten über ein zentrales Datenmanagement in Esri-Geodatabases oder anderen relationalen Datenbanksystemen (Oracle, Microsoft SQL Server) gespeichert oder in hochverfügbaren Storage-Produkten von NetApp und EMC (Luftbilder, Orthophotos, Höhenmodelle, Punktwolken) verwaltet. Geodienste Geodaten und -informationen bilden die Grundlage für viele Geschäftsprozesse bei der RAG. Bei der Nutzung und Verteilung setzt die RAG-GDI auf eine service- orientierte Architektur und ermöglicht somit, Geodaten herstellerunabhängig in beliebigen Anwendungen zu nutzen. Schnittstellen Um die Interoperabilität innerhalb der RAG-GDI aber auch zwischen der RAG- GDI und anderen im Konzern eingesetzten Systemen (Sharepoint, ELO, SAP) zu gewährleisten, sind generische Schnittstellen von großer Bedeutung. Informations- und Integrationsplattformen, die einen zentralen Einstiegspunkt für die Arbeit mit raumbezogenen Daten liefern, ermöglichen in diesem Zusammenhang einen fach- und organisationsübergreifenden Zugang zu Informationen. Anwendungen Die RAG-GDI stellt das Fundament für eine Vielzahl unterschiedlicher Fachanwendungen dar. Die Lauffähigkeiten dieser kleineren und größeren Anwendungen (z.B. Rissarchiv, Schachtkataster, GeoMonPlus) muss gewährleistet sein. In der Regel handelt es sich dabei nicht um Standardsoftware, sondern um spezielle Entwicklungen für die RAG. Auch zwischen diesen Fachanwendungen und den RAG-GDI-Komponenten gibt es zahlreiche Schnittstellen.

7.1.1 Eingesetzte Versionen (Stand März 2026)

[Seite 29]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 28 (47)

7.1.2 GDI Entwicklungsumgebung Die Entwicklungsumgebung umfasst zurzeit 3 virtuelle Server für die Applikationen:

• ArcGIS Server

• ArcGIS Web Adaptor

• ArcMAP

• IIS

• Tomcat

• Security Manager

• Map.Apps

• Smart.Finder

• Mapfish

• Java 7.1.3 GDI QS Umgebung Die QS Umgebung umfasst zurzeit 8 virtuelle Server für die Applikationen:

• ArcGIS Server

• ArcGIS Web Adaptor

• ArcMAP

• FME Server

• FME Flow Kommentiert [MM5]: Ist FME Flow und FME Server nicht identisch? • IIS

• Tomcat

• Security Manager

• Map.Apps

• Smart.Finder

• GTP Admin Kommentiert [MM6]: wurde in 2024 zurückgebaut

• Mapfish

• Java 7.1.4 GDI Produktionsumgebung Die Produktionsumgebung umfasst zurzeit 9 virtuelle Server für die Applikationen:

• ArcGIS Server

• ArcGIS Web Adaptor

[Seite 30]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 29 (47)

• ArcMAP

• FME Server

• FME Flow

• Apollo

• IIS

• Tomcat

• Security Manager

• Map.Apps

• Smart.Finder

• GTP Admin

• Mapfish

• Java

• Service Monitor ▪ Formatiert: Einzug: Links: 3,27 cm, Keine Aufzählungen oder Nummerierungen 7.1.5 Sharepoint Entwicklungsumgebung

7.2 Leistungsübergabepunkt Leistungsübergabepunkt ist die Funktionsfähigkeit am Ausgangsport des Serversystems bzw. der Funktionalität der Applikation

7.3 Anforderungen und Verantwortlichkeiten Applikationsbetrieb GDI 7.3.1 Grundsätzliche Anforderungen  Die zu betreibenden Applikationen mit Angaben zu den verwendeten Umgebungen (Prod, Staging, Test) sind in der Anlage „Applikationsliste“ aufgeführt.  Sicherstellung der mit dem Anwendungsbetrieb verbundenen und erforderlichen, fachlich-technischen Qualifikationen seitens der für den Betrieb vom AN eingesetzten Mitarbeitern und/oder Subunternehmer:  Wissen über die Geschäftsprozesse der RAG sowie der prozessualen und IT-technischen Einbindung der Applikationen  Gutes bis sehr gutes Wissen und Verständnis über die Datenschnittstellen  Gute bis sehr gute Analysefähigkeit zur Fehlersuche und Beseitigung  Gute bis sehr gute Kenntnisse bezüglich der Performance-Faktoren der Anwendungen

[Seite 31]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 30 (47)

 Software Lifecycle Management – Nachhaltung aller Softwareversionen und deren Wartungszyklen  Der AN finanziert und beschafft alle zusätzlich benötigten Anwendungen und Tools, die der AN für einen sicheren und effizienten Betrieb einsetzt  Der AN nimmt eine Schnittstellenfunktion zu Dritten wahr. Dieses schließt insbesondere alle nachfolgenden Leistungen ein:  Einforderung der Leistungen von Dritten, die der Dritte gegenüber der RAG zur Erbringung des Applikationsbetriebs schuldet  Koordination und Überwachung - im Sinne einer Ticket-Ownership - der Beseitigung aller Incidents für den Anwender, die in der Sphäre des Dritten entstehen  Unterstützung des Dritten bei der Erbringung seiner Leistungen, sofern hierzu Leistungen erforderlich sind, die die RAG im Rahmen der vorliegenden Servicebeschreibung zu erbringen hat, z.B. technische Prüfung der Applikation nach Betriebssystem-Patch  Jährlicher Restoretest für eine der betriebenen Applikationen

7.3.2 Verantwortlichkeiten Entstörung

Tabelle 6: Verantwortlichkeiten Entstörung 7.3.3 Verantwortlichkeiten Monitoring

[Seite 32]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 31 (47)

Überwachung der Systemperformance x x

Tabelle 7: Verantwortlichkeiten Monitoring

7.3.4 Optional: Verantwortlichkeiten Installation von Applikationen und Updates (Minor/Major Version)

Aufgaben AG AN

D E M I D E M I

Ausgestaltung der System-Architektur, inkl. Sizing im Einklang mit x x x der RAG Enterprise Architektur Mitwirkung: Nennung der fachlichen Anforderungen

Bewertung der fachlichen Auswirkungen x x

Abnahme der geplanten Systemarchitektur x x

Konfiguration der Systemumgebung incl. Schnittstellen x x

Bereitstellung von Lizenzen der Fachanwendungen (sofern keine x x x Eigenentwicklung)

Haltung von Software-Wartungsverträgen für die Fachanwendungen x x (sofern keine Eigenentwicklung)

Installation der Applikation(en) auf Serverebene x x x

Übergabe von Installationsvorgaben an die Client x x Softwarepaketierung (sofern erforderlich)

Einrichtung Job-Scheduling x x x Mitwirkung: Nennung von fachlichen Anforderungen

Einrichtung/Erneuerung von SSL Zertifikaten, sofern erforderlich x x x Mitwirkung: Zertifizierungsstelle

Tabelle 8: Verantwortlichkeiten Installation von Applikationen 7.3.5 Verantwortlichkeiten Patches von Applikationen

Tabelle 9: Verantwortlichkeiten Patches / Upgrades

[Seite 33]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 32 (47)

7.3.6 Verantwortlichkeiten Applikationsbetrieb

Tabelle 10: Verantwortlichkeiten Betrieb 7.3.7 Verantwortlichkeiten Service Continuity Management

Tabelle 11: Verantwortlichkeiten Service Continuity Management 7.3.8 Verantwortlichkeiten Kontinuierliche Verbesserung

Tabelle 12: Verantwortlichkeiten Kontinuierliche Verbesserung 7.3.9 Optional: Verantwortlichkeiten Übernahme aus Weiterentwicklung

[Seite 34]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 33 (47)

Sicherstellung des Wissenstransfers durch AN – sofern die x x Weiterentwicklung hier ebenfalls verantwortet wird

Tabelle 13: Verantwortlichkeiten Übernahme aus Weiterentwicklung 7.3.10 Verantwortlichkeiten Betrieb von Datenschnittstellen

Tabelle 14: Verantwortlichkeiten Betrieb von Datenschnittstellen

7.4 Beistellleistungen Applikationsbetrieb GDI  RZ Infrastruktur (Housing, Server, Storage, LAN, WAN)  Softwarelizenzen  Wartungsverträge  Bestehende Dokumentationen

7.5 Preismodell Applikationsbetrieb GDI Die Kosten für die Erbringung der im Kapitel 7 aufgeführten Anforderungen und Verantwortlichkeiten sind in der Vertragsanlage Preisblatt hinterlegt.

Tabelle 15: Preismodell Applikationsbetrieb

[Seite 35]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 34 (47)

Applikationssupport GDI Ziel des Applikationssupports GDI ist die Unterstützung der Mitarbeiter der RAG in allen Fragen zu den im Einsatz befindlichen Modulen und Systemen im Rahmen eines 2nd Level Supports und der Einbindung des Herstellersupport bzw. der Applikationsentwicklung in Fällen, in denen dies notwendig ist.

8.1 Ausgangssituation Der aktuelle Dienstleister der RAG übernimmt den Support für alle Anwendungen innerhalb der GDI Plattform und steht den Anwendern der GDI Plattform zur Verfügung. Im Falle von Störungen erfolgt die Störungsbehebung bei Eigenentwicklungen eigenständig durch den AN, im Falle von Produkten mit bestehenden Wartungsverträgen (Esri, con terra) erfolgt die Weitergabe von Störungen an den Herstellersupport.

8.2 Leistungsübergabepunkt entfällt

8.3 Anforderungen und Verantwortlichkeiten Applikationssupport GDI 8.3.1 Grundsätzliche Anforderungen  Sicherstellung der mit dem Support verbundenen und erforderlichen, fachlich-technischen Qualifikationen seitens der für den Support vom AN eingesetzten Mitarbeiter und/oder Subunternehmer:  Gutes bis sehr gutes Wissen in Bedienung und Funktion der Applikationen der GDI Plattform  Gutes bis sehr gutes Wissen und Verständnis über den Einsatz der Applikationen in den Geschäftsprozessen der RAG sowie deren technischen Ausgestaltung  Gutes bis sehr gutes Wissen und Verständnis über die Datenschnittstellen  Gute bis sehr gute Analysefähigkeit zur Fehlersuche und Beseitigung  Gute bis sehr gute Kenntnisse bezüglich der Performance-Faktoren der Anwendungen  Der AN nimmt eine Schnittstellenfunktion zu Dritten wahr. Dieses schließt insbesondere alle nachfolgenden Leistungen ein:  Einforderung der Leistungen von Dritten, die der Dritte gegenüber der RAG vertraglich schuldet  Koordination und Überwachung - im Sinne einer Ticket-Ownership - der Beseitigung aller Incidents für den Anwender, die in der Sphäre des Dritten entstehen  Durchführung der vereinbarten Serviceprozesse

[Seite 36]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 35 (47)

8.3.2 Verantwortlichkeiten Incident Management Konkretisierung in Bezug auf Kapitel 4

Kommentiert [MM7]: Kann nicht auch der Auftraggeber ein Problem-Management anstoßen?

Tabelle 16: Verantwortlichkeiten Incident Management

8.3.3 Verantwortlichkeiten Problem Management Konkretisierung in Bezug auf Kapitel 4

Tabelle 17: Verantwortlichkeiten Problem Management

[Seite 37]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 36 (47)

[Seite 38]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 37 (47)

8.3.4 Verantwortlichkeiten Change Management Konkretisierung in Bezug auf Kapitel 4

Tabelle 18: Verantwortlichkeiten Change Management 8.3.5 Optional: Technischer Support und Anpassungen

Tabelle 19: Optional: Technischer Support und Anpassungen

[Seite 39]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 38 (47)

8.4 Beistellleistungen Applikationssupport GDI  Wartungsverträge (ESRI, con terra)  Bestehende Dokumentationen

8.5 Preismodell Applikationssupport Die Kosten für die Erbringung der imn Kapitel 8 aufgeführten Anforderungen und Verantwortlichkeiten sind in der Vertragsanlage Preisblatt hinterlegt. Zusätzlicher Applikationssupport wird optional zusätzlich erbracht.

Tabelle 20: Preismodell Applikationssupport

[Seite 40]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 39 (47)

Transition und Transformation 9.1 Grundsätzliche Anforderungen Der AN muss sicherstellen, dass unter der Voraussetzung, dass Ddie RAG seinen Mitwirkungspflichten nachgekommen ist, die Übernahme des Betriebs (Current Mode of Operation CMO) zum 01.01.2027 erfolgt. Optimierungen und Anpassungen in den Services zur Erreichung des geplanten Soll-Zustands (Future Mode of Operation FMO) sollten final bis zum 30.03.2027 abgeschlossen werden Im Rahmen der Transformation erbringt der AN die folgenden, wesentlichen Leistungen:  Erstellung eines Transitionskonzepts als ein Gesamtkonzept oder zeitlich unterteilt je Applikation  Projektmanagement während der Transitionsphase  Gemeinsame Definition des Vorgehens zur Ermittlung von SLAs (Messverfahren, -Punkte, -Werkzeuge, Ergebniseinheit)  Übernahme der Betriebs- und Supporttätigkeiten  Durchführung der Transformation und Produktivübergang der Applikationen  Design und Einführung der Serviceprozesse  Test und Abnahme  Dokumentation

9.1.1 Grundsätzliche Anforderungen Transitionskonzeption Das vom AN im Vorfeld der Transition zu erstellende „Grobkonzept Transition“ hat mindestens die folgenden Punkte zu berücksichtigen:  Annahmen  Der AN trifft für offene Punkte, die im Rahmen der Angebotserstellungsphase nicht geklärt werden können, Annahmen.  Mitwirkungspflichten der RAG in Bezug auf:  Dokumentationen  Lizenzen  Räumlichkeiten  Ansprechpartner  Daten  weiteres  Allgemeine vorbereitende Maßnahmen  Geplante Teamstärke  Vorgehen zu Wissenstransfer je Managed Service  Vorgehen zum Verantwortungsübergang je Managed Service  Vorgehen zur Etablierung der übergreifenden Leistungen

[Seite 41]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 40 (47)

 Vorläufiger Projektplan unterteilt nach den Applikationen unter Berücksichtigung der Abhängigkeiten zu anderen Leistungen und Dienstleistern der RAG

9.1.2 Grundsätzliche Anforderungen Projektmanagement in der Transition  Bestandsaufnahme der IST-Situationen  Projektplanung und Vorbereitung in Abstimmung mit der RAG unter Berücksichtigung der, mindestens anzugebenden Meilensteine je Service  Datenmigration  Feinplanung und Koordination  Gemeinsame Projektorganisation und -koordination mit der RAG  Abstimmung von Aktivitäten, Meilensteinen, Schnittstellen, Terminen und Verantwortlichkeiten, Präsentation und Kommunikation, rechtzeitige Eskalation sollten geplante Ziele gefährdet sein  Projektkoordination, Überwachung und Steuerung  Termineinhaltung und Bereitstellung zur Abnahme (Richtlinien, SLA, Qualität, Sicherheit)

9.1.3 Durchführung der Transition  Im Folgenden sind die Mindestanforderungen je Meilenstein aufgeführt. Der AN hat zu den folgenden, mindestens geforderten Meilensteinen je Applikation, die folgenden Ergebnisse der RAG bereitzustellen:  Planung & Konzeption  Solution Design  Zeitplanung  Abstimmung andere Leistungen  Übergreifende Prozesse ITIL  Betriebsübernahme  Einarbeitung in die Applikationen  Übernahme von Dokumentationen  Übernahme von Daten und Betriebsverfahren

9.1.4 Design und Implementierung Service Prozesse  Design der Service Support- und Service Delivery-Prozesse  Spezifikation der organisatorischen Schnittstellen  Erstellung und Abstimmung von Pflichtenheften für die technischen Schnittstellen und Tools  Implementierung der Prozesse, Tools und technischen bzw. organisatorischen Schnittstellen

[Seite 42]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 41 (47)

 Zuordnung von Rollen und Verantwortlichkeiten zur Aufbauorganisation  Spezifikation der Prozesssteuerung (KPI/Reporting)  Implementierung der Governance-Struktur und festgelegten Gremien  Kopplung aller prozessunterstützenden Systeme (z. B. Ticket-Systeme)  Erstellung eines Prozesshandbuchs

9.2 Beistellleistungen Transition  Kommunikation innerhalb der RAG und gegenüber anderen Dienstleistern  Schnittstellen und Übergabepunkte zu anderen Dienstleistern  Definition von Frozen Zones in denen keine Transitionsmaßnahmen durchgeführt werden können.  Übergabe von zur Transition benötigten Unterlagen des Bestandsproviders oder anderen Dienstleistern

9.3 Preismodell Die Kosten für die Erbringung der im Kapitel 9 aufgeführten Anforderungen und Verantwortlichkeiten sind in der Vertragsanlage Preisblatt hinterlegt. Im genannten Preiselement ist die Transition aller geforderten Services gesamtheitlich zu bepreisen.

[Seite 43]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 42 (47)

Abnahmeverfahren 10.1 Abnahme Die Vertragsparteien vereinbaren folgende Regelungen für die Durchführung von Abnahmen:  Bei abnahmerelevanten Leistungen (z.B. Transitionsleistungen, Durchführung von nichtstandardisierten Änderungen) stimmen die Vertragsparteien bereits vor der Umsetzung die für eine spätere (Teil-) Abnahme relevanten Kriterien ab. Dazu hat der AN der RAG die Kriterien in Form eines Abnahmeprotokolls vorzuschlagen und Änderungswünsche der RAG einzuarbeiten. Das gemeinsam vereinbarte Abnahmeprotokoll wird Anhang zur Leistungsbeschreibung.  Sofern sich während der Leistungserbringung einvernehmlich Änderungen und/oder Ergänzungen der Abnahmekriterien ergeben, sind diese im jeweiligen Abnahmeprotokoll festzuhalten. Sind keine Abnahmekriterien definiert, so hat der AN der RAG die Abnahmebereitschaft dennoch anzuzeigen. Eine Abnahme erfolgt auch in diesem Fall wie im Folgenden beschrieben.  Bei (Teil-) Abnahmen ist der AN verpflichtet, der RAG die Bereitschaft zur Abnahme schriftlich anzuzeigen. Der AG führt danach die Abnahme im Zusammenwirken mit dem AN durch und wird unverzüglich, spätestens aber 5 (fünf) Arbeitstage nach Anzeige der Abnahmebereitschaft durch den AN mit der Durchführung der Abnahmehandlungen beginnen. Als „Arbeitstage“ zählen Montage bis einschließlich Freitage, ausschließlich bundeseinheitliche und NRW-Feiertage.  Der AG überprüft während der Abnahmehandlung die Leistungen des AN auf die vereinbarten Eigenschaften. Die Leistungen sind dann vertragsgemäß, wenn sie bei Gefahrenübergang frei von Sach- und Rechtsmängeln sind, sowie den vertragstypischen, insbesondere den in der jeweiligen Leistungsbeschreibung vereinbarten Eigenschaften sowie den angestimmten Abnahmekriterien entsprechen. Der AG hat die Abnahme zu erteilen, wenn bei der Überprüfung nach den vereinbarten Testkriterien keine Fehler der Fehlerklassen 1 und 2 festgestellt werden (Abnahmeverhinderung) oder nur solche Fehler der Fehlerklassen 3 und 4, welche die Nutzung der Leistung nur unwesentlich beeinträchtigen (= bedingte Abnahme) und die Fehler der Fehlerklassen 3 und 4 nicht in einer Anzahl vorliegen, die abnahmeverhindernd ist (s.u.). Die bei der Abnahme festgestellten Fehler, unabhängig welcher Fehlerklasse zugeordnet, werden vom AG und dem AN nachvollziehbar dokumentiert und werden vom AN unverzüglich unentgeltlich beseitigt. Nach Beseitigung der aufgeführten Fehler wird die Leistung erneut zur Abnahme gestellt. Fehler der nachfolgend aufgeführten Fehlerklassen 1 und 2 sind abnahmeverhindernd. Fehler der Fehlerklassen 3 und 4 sind nicht abnahmeverhindernd, es sei denn, es liegen zusammen mehr als drei Fehler der Klasse 3 vor. In diesem Fall tritt eine Abnahmeverhinderung ein. Sofern keine Abnahmeverhinderung eingetreten ist, hat der AG bei Vorliegen von Fehlern der Klassen 3 und 4 jedoch das Recht, 10 Prozent der dieser fehlerhaften Leistung

[Seite 44]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 43 (47)

zugrunde liegenden (Teil-) Vergütung bis zur endgültigen Fehlerbeseitigung zurückzuhalten. Fehlerklassen:  Fehlerklasse 1: Bereits die Kernfunktionalität oder -eigenschaft eines Systems oder einer Applikation ist nicht gewährleistet.  Fehlerklasse 2: Die Kernfunktionalität/-eigenschaft ist gewährleistet, es liegt jedoch ein wesentlicher Fehler in einem Teilsystem vor, der das Arbeiten mit diesem System verhindert oder Kern- und Hauptfunktionalität sind gewährleistet, aber nachgelagerte Systeme werden nicht oder nicht korrekt beliefert oder Lieferungen von vorgelagerten Systemen werden nicht oder nicht korrekt verarbeitet.  Fehlerklasse 3: Die Kern- und Hauptfunktionalität/-eigenschaft ist gewährleistet, es tritt aber ein Fehler in nicht wesentlichen Teilfunktionen oder Eigenschaften auf.  Fehlerklasse 4: Fehler, welche die Funktionalität des Gesamtsystems nur unwesentlich beeinträchtigen oder untergeordnete Eigenschaften sind nicht gegeben (Beispielhafte Mängel: Rechtschreibfehler auf der Bildschirmmaske, Fehler in der Dokumentation). In den Abnahmeprotokollen (s.o.) hat der AN neben den Abnahmekriterien auch eine Zuordnung der Fehlerklassen vorzuschlagen (welche Fehlerklasse kommt zur Anwendung, wenn das jeweilige Kriterium nicht erfüllt wird). Bei Teilabnahmen gilt die Gesamtleistung mit der Abnahme der letzten Teilleistung als abgenommen.

[Seite 45]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 44 (47)

Abkürzungsverzeichnis

[Seite 46]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 45 (47)

[Seite 47]

Leistungsbeschreibung Los 2 GDI Plattform Seite: 46 (47)

Anhänge  Anhang 1 GDI Systemübersicht Produktivsystem  Anhang 2 GDI Systemübersicht QS/Stagingsystem  Anhang 3 GDI Systemübersicht Entwicklungssystem  Anhang 4 Applikationsliste GDI