A.1_Leistungsbeschreibung.pdf

[Seite 1]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

Leistungsbeschreibung

1 Leistungsgegenstand und Leistungspflichten des

Auftragnehmers

1.1 Ausführungsbedingungen (Los 1 und Los 2)

Nachfolgende Regelungen gelten für die Auftragnehmer beider Lose:

Der Auftragnehmer ist bei der Wahl der Personen, die er zur Leistungserbringung einsetzt, frei. Das Weisungsrecht und Direktionsrecht bezüglich der vom Auftragnehmer eingesetzten Mitarbeiter verbleibt vollständig und ausschließlich beim Auftragnehmer als deren Arbeitgeber. Die von ihm eigenverantwortlich eingesetzten Mitarbeiter treten in kein Arbeitsverhältnis zum Auftraggeber, auch soweit sie Leistungen in dessen Räumen erbringen. Mitarbeiter des Auftragnehmers werden nicht in den Betrieb oder die Organisation des Auftraggebers eingegliedert. Eine Arbeitnehmerüberlassung im Sinne des Gesetzes zur gewerbsmäßigen Arbeitnehmerüberlassung (Arbeitnehmerüberlassungsgesetz) ist weder vereinbart noch wird sie durchgeführt.

Im Sinne des § 128 Abs. 2 GWB fordert der Auftraggeber die Einhaltung der folgenden Ausführungsbedingungen:

• Russland-Sanktionen

• Kommunikation mit dem Auftraggeber

Dies erklärt der Bieter unter Verwendung von Anlage D.1 (Eigenerklärungen Bieter).

1.2 Datenschutzrechtliche Bestimmungen (Los 1 und Los 2)

Nachfolgende Regelungen gelten für die Auftragnehmer beider Lose:

Der zukünftige Auftragnehmer hat bei der Auftragsausführung Zugang zu personenbezogenen Daten beim Auftraggeber.

Als Anlage zum EVB-IT Vertrag wird daher ein vorausgefüllter „Auftragsverarbeitungsvertrag“ mit technischen und organisatorischen Maßnahmen mit dieser Vergabeunterlage veröffentlicht.

Seite 1 von 51

[Seite 2]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

1.3 Lose und Zielsetzung (Los 1 und Los 2)

Im Folgenden werden die vertragsgegenständlichen Leistungen und zugehörigen Rahmenbedingungen für den Bereich Unified Communications für folgende Leistungsbereiche spezifiziert:

 Los 1: Dienstleistungen im Bereich VoIP  Los 2: Dienstleistungen im Bereich Videoconferencing (mit Telefonie-Funktionen)

Mit dem hier gegenständlichen EU-weiten Vergabeverfahren werden zwei Leistungserbringer ausgewählt, die für die unterschiedlichen Leistungsbereiche in Los 1 und Los 2 jeweils:

 über fundiertes Hersteller- und Systemwissen verfügen und den Betrieb der jeweiligen Anwendungsinfrastruktur und -lösung insb. im Rahmen eines Second-Anwendersupports sicherstellen und  die Funktions- und Nutzungsmöglichkeiten der eingesetzten Umgebungen im Rahmen von notwendigen Requests for Change (technisch oder fachlich) und Projekten erhalten und weiterentwickeln.

Für den Leistungsbereich Videoconferencing wird zusätzlich die Migration bzw. der Technologiewechsel von Webex zu Microsoft Teams fachlich und technisch unterstützt.

Die Leistungsbereiche sind ausgiebig in Abschnitt 1.5 für Los 1 und 1.6 für Los 2 beschrieben.

Hinweis: Die in der hiesigen Leistungsbeschreibung festgelegten Anforderungen gelten grundsätzlich für beide Lose. Als „Auftragnehmer“ werden im Folgenden somit unabhängig voneinander sowohl der Auftragnehmer von Los 1 als auch der Auftragnehmer von Los 2 bezeichnet. Die Passagen, die lediglich für eines der Lose gelten, sind in der Farbe des jeweiligen Loses eindeutig hervorgehoben. Es ist nicht ausgeschlossen, dass für beide Lose derselbe Auftragnehmer den Zuschlag erhält, es handelt sich aber um zwei getrennte Lose.

1.4 IT-Organisation der MPG (Los 1 und Los 2)

1.4.1 Max Planck Information and Technology (MaxIT)

Unter dem Dach der MaxIT sind die Informations- und Kommunikationstechnologie (IKT), die Max Planck Digital Library (MPDL) und der IT-Enterprise Architekt zusammengeführt worden. Die Einrichtung bündelt in enger Zusammenarbeit mit den Max-Planck-Instituten und der Generalverwaltung (GV) zentrale verwaltungsbezogene und forschungsstützende IT- Aktivitäten der Max-Planck-Gesellschaft.

Abteilung Informations- und Kommunikationstechnologie (IKT)

Die Abteilung IKT ist aktuell in vier Fachbereichen organisiert:

Der Fachbereich a – „Desktop und Communications“ – stellt für die GV der MPG und die Verwaltungen der Institute virtuelle (Desktop-)Arbeitsplätze (vAP), Non-SAP-Anwendungen und Dienstleistungen bereit. Für die Mitarbeitenden der GV stellt sie auch die Desktop-Hardware

Seite 2 von 51

[Seite 3]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

bereit. Bislang nicht ausgeschöpfte und neue Funktionalitäten der Digitalisierung werden den Instituten und der GV zunehmend erschlossen. Die inhaltliche Weiterentwicklung und Umsetzung erfolgt in enger Zusammenarbeit mit den Fachabteilungen und in intensivem Kontakt zu den Instituten. Die Endanwender werden durch einen Helpdesk für alle Anwendungen unterstützt.

Die wesentlichen Support-Aufgaben für UC-Bereich der MaxIT werden durch folgende Rollen erbracht:

 IT-Verantwortlicher Communications (Anforderungs- und Projektmanagement)

 IT-Serviceverantwortlicher VoIP (Betriebs- und Rolloutverantwortung VoIP)

 IT-Serviceverantwortliche Webconferencing (Betriebsverantwortung Webconferencing)

 IT-Serviceverantwortlicher Mobility (Betriebsverantwortung Mobile Devices)

Übergreifend werden die beiden Rollen IT-Serviceverantwortlicher VoIP, IT- Serviceverantwortliche Webeconferencing auch als IT-Serviceverantwortliche UC in dieser Vergabeunterlage zusammengefasst.

Der Fachbereich b – „SAP Kompetenzzentrum“ – versteht sich als Lösungslieferant für die SAP-gestützten Verwaltungsprozesse. Hierzu zählen neben den flächendeckend genutzten Systemen für Haushalts- und Rechnungswesen sowie Personalwesen, das elektronische Einkaufssystem, das Haushaltsplanungssystem und das Arbeitssicherheitssystem. Bislang nicht genutzte und neue Funktionalitäten werden den Instituten zunehmend erschlossen. Inhaltlich werden die Systeme in enger Zusammenarbeit mit den Fachabteilungen und Vertretenden der Institute stets weiterentwickelt. Der laufende Betrieb wird durch ein Help Desk für alle SAP- Anwendungen unterstützt. Das Team gliedert sich nach den nachfolgenden Geschäftsprozessfeldern: Finanzen, Personal, Beschaffung, Planung/Controlling und Governance.

Der Fachbereich c – „IT-Sicherheit und Infrastruktur“ - konzipiert, unterstützt und prüft die Sicherheit der Daten, Tablet-PCs, Notebooks und Server im Verwaltungsbereich, stellt eine sichere Kommunikationsinfrastruktur zwischen allen Standorten bereit, betreut die IT- Basisinfrastruktur in den Generalverwaltungsstandorten und betreut eine Identitätsmanagement-Lösung für alle zentral bereitgestellten IT-Dienste.

Der Fachbereich d – „Applikationen“ umfasst die Bereiche Collaboration und Intranet, Bauen, Dokumentenbasiertes ECM und externe Kommunikation. Dazu zählen beispielsweise Services wie das Intranet MAX, der Webseitenauftritt der MPG und der Institute, SharePoint mit seinen Kollaborationslösungen, das Dokumentenmanagement DMS, Vertragsmanagement und viele weitere Softwarelösungen. Für den Baubereich stellt die Fachabteilung für die Bauprojektsteuerung und das Flächenmanagement bereits Lösungen zur Verfügung und arbeitet weiter am Ausbau der Digitalisierung von Bauvorhaben.

Abteilung Max Planck Digital Library (MPDL)

Seite 3 von 51

[Seite 4]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

Die Digitale Bibliothek der Max-Planck-Gesellschaft MPDL stellt eine umfangreiche Versorgung der MPG-Wissenschaftler mit digitalem Publikationszugang bei zahlreichen Verlagen sicher und stellt darüber hinaus Dienste zur Erfassung und Verwaltung von Publikationsdaten zur Verfügung.

1.4.2 Verwaltungs-IT

Die Abteilung Informations- und Kommunikationstechnologie (IKT) der MaxIT stellt für die Generalverwaltung (GV) der MPG, die Verwaltungen der Max-Planck-Institute (und weiterer MPG-Einrichtungen) und teils auch direkt für die Wissenschaftler Hardware, Software, Anwendungen und Dienstleistungen bereit. Sie ist strategischer Partner der Fachabteilungen der GV und unterstützt Verwaltungsprozesse mit IT-Lösungen, die anwenderfreundlich und effektiv sind.

Die bereitgestellten Dienste adressieren primär folgende Zielgruppen:

Mitarbeiter der Generalverwaltung und der Institutsverwaltungen:

Alle Verwaltungsmitarbeiter werden durch die MaxIT mit vollwertigen virtuellen Verwaltungs- Desktops (Citrix) ausgestattet. Dies schließt die zugrundeliegende Infrastruktur (Storage, AD, Server, Netzwerksicherheit etc.) ein. Für die Generalverwaltungs-Standorte übernimmt Abteilung IKT zudem die Rolle der lokalen IT und betreut die physischen Clients der AnwenderInnen.

Wissenschaftliche und Nichtwissenschaftliche Mitarbeiter der MPG:

Alle Mitarbeiter der MPG außerhalb der GV (MPG-Mitarbeiter, Stipendiaten, Drittmittelangestellte und weitere) werden von den lokalen IT-Abteilungen der Max-Planck- Institute ausgestattet und betreut, können jedoch zentrale Dienste der Generalverwaltung nutzen (SAP-Dienste, CMS, Extranet etc.).

Mitglieder von Arbeitsgruppen oder Gremien der MPG:

Mitglieder von Arbeitsgruppen oder MPG-Gremien erhalten Zugriff auf von der MaxIT bereitgestellte Kollaborationsbereiche (SharePoint).

Öffentlichkeit:

Für die Öffentlichkeit werden gedruckte und digitale Abonnements angeboten, deren Verwaltung auf Diensten der MaxIT basiert. Über Self-Service-Schnittstellen können Abonnenten selbständig Veränderungen vornehmen.

IT-Einheiten in zentralen MPG-Einrichtungen und Max-Planck-Instituten:

Die MaxIT stellt den IT-Einheiten in zentralen MPG-Einrichtungen und in den Max-Planck- Instituten Dienste und Daten zur Verfügung, die in die eigene IT-Landschaft integriert bzw. zur Prozesssteuerung genutzt werden können.

1.4.3 Wissenschaftliche IT

Die Institute der Max-Planck-Gesellschaft verfügen über eigenständige IT-Abteilungen, die die spezifischen Bedarfe der lokalen wissenschaftlichen Arbeit erfüllen. Die Instituts-IT-Abteilungen

Seite 4 von 51

[Seite 5]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

ermöglichen zudem den lokalen Institutsverwaltungen über bereitgestellte Instituts-PCs den Zugriff auf einen virtuellen Arbeitsplatz für Verwaltungen.

1.4.4 Rechenzentren der MPG

Die Rechenzentren GWDG (Göttingen) und MPCDF (Garching) stehen den Einrichtungen der Max-Planck-Gesellschaft als Dienstleister zur Verfügung. Die angebotenen Dienste reichen von Housing über Hosting bis zu SaaS und werden im Ermessen der jeweiligen Einrichtung in Anspruch genommen. Die Fachbereiche a und d nutzen hauptsächlich die GWDG als Housing- und SaaS-Anbieter.

Darüber hinaus nutzen Max-Planck-Institute örtliche Kooperationen zur Bündelung von IT- Ressourcen. Dies gilt insbesondere für das GNZ Berlin, das die in Berlin und Brandenburg ansässigen Max-Planck-Einrichtungen betreut.

1.5 Los 1: VoIP

1.5.1 Überblick über die Zuständigkeiten und Verantwortlichkeiten

Folgende generelle Verantwortlichkeiten bestehen:

Seite 5 von 51

[Seite 6]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

1.5.2 Leistungen VoIP Betrieb nach Anzahl User

Diese Leistungen werden pauschal für die angegebene Anzahl von 14.000 Usern vergütet. Bei einer Mehrung und Minderung um 1.000 User wird der Betrag entsprechend dem für Mehrung / Minderung angegebenen Preis im Preisblatt angepasst.

Zu den Leistungen, welche nach der Anzahl der User vergütet werden (vgl. Preisblatt Anlage A.2), gehören:

 Bereitstellung von Ressourcen im 2nd Level für alle zentralen und dezentralen Systemkomponenten (vgl. Kapitel 1.5.7)  Incident Management  Request Fulfillment  Problem Management  Release Management

Die Details zu den ITSM-Prozessen sind in Abschnitt 2.10 beschrieben. Die Leistungen werden für die angegebene Anzahl an Usern von 14.000 pauschal gemäß Preisposition L1_P1 vergütet. Bei einer Mehrung / Minderung der Anzahl der User um 1.000, so mehrt / mindert sich die Pauschale um den Betrag aus Preisposition L1_P2. Es sind dabei auch Mehrungen und Minderungen um ein Vielfaches von 1.000 möglich. Sollte sich bspw. die Anzahl der User um 2.000 erhöhen, so ergibt sich die Pauschale für die Abrechnung aus folgender Rechnung: L1_P1+ 2 * L1_P2 (in Worten: „Preisposition L1_P1“ plus zwei Mal „Preisposition L1_P2“).

1.5.3 Leistungen VoIP Betrieb (pauschal)

Zu den pauschal vergüteten Betriebsleistungen gehören Aufgaben der Gesamtkoordination im Betrieb. Dazu zählt die Bereitstellung eines zentralen Ansprechpartners (vgl. Kapitel 2.4), die Teilnahme an Regelterminen (vgl. Kapitel 2.5) und Aktivitäten im Service Level Management (vgl. Kapitel 2.10.10) inkl. Messung und Reporting der Service Level (vgl. Kapitel 1.7).

1.5.4 Leistungen VoIP Projekte und Change Management auf Tagespauschalpreisbasis

Zusätzliche Leistungen für Projekte und im Rahmen des Change Management werden auf Tagespauschalpreisbasis nach Aufwand vergütet. Die Tagessätze werden im Preisblatt – Anlage A.2 definiert.

Seite 6 von 51

[Seite 7]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

Die sonstigen Dienstleistungen sind nur auf ausdrückliche Anordnung des Auftraggebers mindestens in Textform auszuführen. Sie sind im Vorfeld schriftlich zu beschreiben und je nach Skill Level der Anforderung (nicht des tatsächlich ausführenden) zu beziffern. Die Leistungsnachweise sind dem Auftraggeber monatlich vorzulegen.

Die zusätzlichen Leistungen werden mit dem im Angebot angegebenen Tagespauschalpreisen entsprechend der zugewiesenen Rollen vergütet. Dem Auftraggeber obliegt die Entscheidung über die Durchführung von Projekten mit dem Auftragnehmer. Der Auftraggeber kann auch andere Dienstleister mit Projektaufgaben beauftragen. Der Ort der Leistungserbringung ist abhängig vom jeweiligen Gegenstand der Leistung und wird vom Auftraggeber vorgegeben.

Folgende Rollen sind im Bereich VoIP definiert:

 Projekt Manager

Der Projekt Manager verantwortet die operative Projektsteuerung und Koordination. Er führt die Projekte gemeinsam mit dem IT-Serviceverantwortlichen UC des Auftraggebers. Er verantwortet die Planung, Bereitstellung und Steuerung der erforderlichen personellen Ressourcen des Auftragnehmers sowie den bedarfsgerechten Einsatz der Projektmitarbeitenden.

Zusammen mit dem IT-Serviceverantwortlichen UC des Auftraggebers trägt er die Verantwortung für die Erreichung der vereinbarten Projektziele hinsichtlich Qualität, Terminen und Wirtschaftlichkeit. Das Projektteam wird projektbezogen durch Mitarbeitende der jeweiligen Institute ergänzt, die ihre fachlichen und organisatorischen Anforderungen in das Projekt einbringen und die Umsetzung vor Ort unterstützen.

Zu den Aufgaben gehören insbesondere:

• Projektplanung und Terminsteuerung
• Ressourcen- und Kapazitätsplanung
• Koordination aller Projektbeteiligten
• Risikomanagement
• Projektcontrolling und Reporting
• Durchführung von Projektstatusgesprächen
• Vorbereitung und Begleitung von Abnahmen
• Steuerung von Rollout- und Migrationsaktivitäten

 Lead Architekt

Der Lead Architekt verantwortet die fachliche und technische Zielarchitektur der VoIP- Plattform.

Zu den Aufgaben gehören insbesondere:

• Weiterentwicklung der Lösungsarchitektur
• Erstellung technischer Zielbilder
• Durchführung von Architektur- und Designreviews

Seite 7 von 51

[Seite 8]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

• Bewertung neuer Technologien und Innovationen
• Erarbeitung von Migrations- und Transformationsstrategien
• Sicherstellung der Architekturkonformität
• Beratung des Auftraggebers bei strategischen Architekturentscheidungen
• Erstellung und Pflege technischer Architektur- und Betriebskonzepte

 Technical Consultant Cisco

Der Technical Consultant Cisco übernimmt die technische Planung und Umsetzung von Projekten im Bereich Cisco.

Zu den Aufgaben gehören insbesondere mit Cisco-Produkten:

• Technische Detailplanung
• Implementierung und Konfiguration von VoIP-Komponenten
• Durchführung von Systemerweiterungen
• Integration neuer Standorte und Einrichtungen
• Durchführung von Migrationen
• Erstellung technischer Dokumentationen
• Durchführung von Funktionstests und Inbetriebnahmen
• Technische Unterstützung während der Projektlaufzeit

 Technical Consultant Ascom

Der Technical Consultant Ascom übernimmt die technische Planung und Umsetzung von Projekten im Bereich Ascom.

Zu den Aufgaben gehören insbesondere mit Ascom-Produkten:

• Technische Detailplanung
• Implementierung und Konfiguration von VoIP-Komponenten
• Durchführung von Systemerweiterungen
• Integration neuer Standorte und Einrichtungen
• Durchführung von Migrationen
• Erstellung technischer Dokumentationen
• Durchführung von Funktionstests und Inbetriebnahmen
• Technische Unterstützung während der Projektlaufzeit

1.5.5 Transition zum Leistungsbeginn

Die Transition zum Leistungsbeginn ist ausgiebig in Kapitel 3.1 (inkl. Vergütung) beschrieben.

1.5.6 Technische Infrastruktur VoIP / CUCM

Die Max Planck Information & Technology (MaxIT) der Max-Planck-Gesellschaft betreibt als Teil der Unified Communication Lösung eine zentralisierte Voice-over-IP basierende

Seite 8 von 51

[Seite 9]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

Telekommunikationsplattform für die Generalverwaltung und angeschlossene Max-Planck- Institute. Dieser UC-Service ist für die Nutzung durch alle Institute bei Neubaumaßnahmen oder bei Austausch der Altanlage in Verbindung mit Finanzmitteln der Generalverwaltung durch den Verwaltungsrat der Max-Planck-Gesellschaft verpflichtend vorgeschrieben, so dass diese sukzessive auf diese Lösung umgestellt werden.

Aktuell sind ca. 14.000 Teilnehmer an das zentrale UC System angeschlossen. Eine Bedarfsabfrage stellt eine Erweiterung um zusätzlich ca. 3.000 UC-Teilnehmer und ca. 6 UC- Standorte innerhalb der nächsten 2 Jahre in Aussicht. Die Kapazität des aufgebauten Cisco CUCM – Clusters liegt bei bis zu 20.000 Teilnehmern.

Die UC-Plattform besteht aus einem zentralen Cluster mit Cisco Unified Communications Managern zur zentralen Steuerung der Nebenstellen zuzüglich Presence Servern und Voicemail Servern über zwei redundante Breakout Standorte wird die Kommunikation in das öffentliche Vermittlungsnetz sichergestellt. Die Sprachübertragung erfolgt dabei verschlüsselt über das LAN/WAN Netzwerk der MPG und die ggf. noch lokalen Voice Gateways an den Standorten sind mit Survivability (SRST) Funktion ausgestattet, so dass die hohen Anforderungen der IT- Sicherheitsbeauftragten und Datenschutzbeauftragten der MPG an Vertraulichkeit und Verfügbarkeit der Telekommunikationsdienste sichergestellt werden.

Die Bereitstellung und der Betrieb der Virtualisierungsplattform erfolgt durch den Auftraggeber bzw. durch einen Dritten. Der Auftragnehmer erhält Accounts mit Zugriff auf den VMware vCenter Server. Er kann damit die UC-Server Ein und Ausschalten sowie einen Snapshot erstellen. Weiterhin erhält er einen Consolenzugriff auf die virtuellen Maschinen.

Die Provisionierung und Administration der Teilnehmer erfolgt mit dem Provisionierungs- System TiM von Aspiria, das mandantenfähig und rollenbasierend für zentrale Administratoren, lokale Administratoren der Institute und für die Konfiguration des eigenen Endgerätes durch die Anwender genutzt wird.

Zusätzlich werden erweiterte Leistungsmerkmale und Komfortfunktionen für Chef/Sekretariats Schaltungen mit einem zusätzlichen Modul von TiM von Aspiria auf Cisco Telefonapparaten bereitgestellt.

Die Benutzerverwaltung der Telekommunikationsplattform erfolgt über die Anbindung an das Active Directory der MPG.

Die Vermittlungsplätze werden über einen PeterConnects Server von JDM Software realisiert, der an das Cisco UC-Telefoniesystem angebunden ist und die Vermittlungsplatz-Funktionen an den jeweiligen Vermittlungsplatz Clients bereitstellt.

Ein zentraler Faxserver wird über die Softwaresuite Ferrari Officemaster zur Verfügung gestellt.

Die DECT-Systeme und –Teilnehmer der Institute werden ebenfalls an die UC- Telekommunikationsplattform angeschlossen, so dass Plattform-übergreifende Vermittlungsfunktionen und Leistungsmerkmale zur Verfügung stehen. Dazu werden die Systeme über IP-DECT Gateways und das Schnittstellen-/Integrationssystem Unite von Ascom an den Cisco Unified Communications Manager Cluster gekoppelt.

Die vom Datenschutzbeauftragen der MPG geforderte Verschlüsselung der Sprachübertragung ist konsequent umgesetzt.

Seite 9 von 51

[Seite 10]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

Die interne Notlauftelefonie ist für den Laborbetrieb einer Forschungseinrichtung existenziell und wird realisiert durch die Survivability (SRST) Funktion der ggf. vorhandenen lokalen Voice Gateways mit automatischem Fallback.

Nach Beschluss durch den Verwaltungsrat und Zustimmung des Gesamtbetriebsrats, des Datenschutzbeauftragten und des IT-Sicherheitsbeauftragten ist dieses beschriebene System mit den darin bestimmten Leistungsmerkmalen festgelegt als verbindlich einzusetzendes Telefoniesystem der Max-Planck-Gesellschaft.

Abbildung 1-1: MPG UC System High Level Sicht

1.5.7 Zentrale und dezentrale Systemkomponenten

Die Komponenten sind zwischen zentralen und dezentralen Komponenten unterteilt – zentrale Komponenten befinden sich in den 3 Rechenzentren in Göttingen und München sowie Berlin, dezentrale Komponenten in den Entitäten der MPG GV bzw. der MPI vor Ort.

In den nachfolgenden Tabellen sind die aktuellen Systemkomponenten des UC-Systems (Configuration Items) angegeben.

Hier nicht explizit aufgelistet sind lokale Endgeräte, für die der Auftragnehmer keinen direkten Support leisten muss, die aber indirekt im Rahmen der Störungsanalyse und Herstellerwartung Gegenstand der Support Leistungen werden können.

Seite 10 von 51

[Seite 11]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

Folgende zentrale Configuration Items sind in den Rechenzentren Göttingen, München und Berlin:

Tabelle 1: Zentrale Configuration Items

Folgende dezentrale Configuration Items sind an den Standorten der GV / MPIs vorhanden:

Seite 11 von 51

[Seite 12]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

Tabelle 2: Dezentrale bzw. lokale Komponenten an den Standorten der GV / MPIs (Stand 10/2026)

Basierend auf einer aktuellen Bedarfsumfrage kann von einer Mehrung innerhalb der nächsten 2 Jahre in folgendem Umfang ausgegangen werden:

 Zusätzliche IP-Telefone: ca. 3.000

 Zusätzliche DECT-Anschlüsse: ca. 60

Die Mengenangaben sind unverbindlich und verpflichten den Auftraggeber nicht zu Abnahmemengen für Mehrungen. Zusätzlich können auch während der Vertragslaufzeit neue Komponenten in Betrieb genommen werden.

1.5.8 Wartungsverträge mit Hersteller

1.5.8.1 Überprüfung bestehender Service-Verträge

Für die CIs der Hersteller Cisco und Aspiria bestehen Wartungsverträge zwischen der MPG und dem entsprechenden Hersteller, auf die der Auftragnehmer zugreifen kann.

Für die CIs der Hersteller JDM (Anwendung: PeterConnects) und Ferrari Electronics AG (Anwendung: Ferrari Officemaster) sind als der in diesem Verfahren ausgeschriebenen Leistung vom Auftragnehmer Wartungsverträge zwischen dem Auftragnehmer und dem entsprechenden Hersteller abzuschließen. Der Auftragnehmer nutzt diese Wartungsverträge, um die Leistung gegenüber der MPG zu erbringen. Der Auftragnehmer hat sicherzustellen, dass die Lieferleistungen der von Ihm abzuschließenden Hersteller-Verträge für die Anforderungen dieser Ausschreibungsunterlagen ausreichend sind. Hierzu sei auf die Kapitel 5.2.6.3 und 5.2.6.4 verwiesen.

Preisbildung: Die Kosten für die Wartungsverträge mit den Herstellern sind nicht gesondert auszuweisen und werden dem Auftragnehmer im Rahmen der übrigen Preispositionen vollständig vergütet.

Seite 12 von 51

[Seite 13]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

1.5.8.2 Wartungsverträge für Cisco Komponenten (Hardware und Software)

Für alle zentralen Cisco Softwarekomponenten wird ein Cisco ESW-Support-Vertrag und ein Vertrag über Software-Support Basic, Grundlegender Support (SWSS) zwischen der MPG und abgeschlossen, auf dessen Leistungen der Auftragnehmer zugreifen kann.

Für alle dezentralen Cisco Hardwarekomponenten sowie für einige wenige Endgeräte werden vom Auftraggeber Cisco SMARTnet Wartungsverträge (8x5xNBD) abgeschlossen.

Zur Inanspruchnahme des Herstellersupports für technische Unterstützung, zum Hardwaretausch defekter Komponenten im Garantie- bzw. Gewährleistungsfall und zum Zugriff auf Software-Releases und Knowledge Base veranlasst der Auftraggeber, dass der Auftragnehmer die Berechtigung erhält, den Herstellersupport in Anspruch zu nehmen. Hierzu wird eine Berechtigung für Cisco Accounts (CCO-IDs) des Auftragnehmers eingerichtet. Alternativ wird eine dedizierte CCO-ID für den Auftragnehmer durch den SAMT-Administrator des Auftraggebers eingerichtet. Nutzt der Auftragnehmer die entsprechenden Verträge, so wird er dadurch im Namen des Auftraggebers tätig.

Für die Abstimmung zwischen Hersteller und Auftragnehmer zur reibungslosen Nutzung dieser Verträge ist der Auftragnehmer verantwortlich. Der Auftragnehmer hat sicherzustellen, dass er am Ende der Transitionsphase Zugriff auf alle benötigten Vertragskomponenten im Herstellerportal hat, um den Herstellersupport für alle Komponenten in Anspruch nehmen zu können.

Für alle Komponenten, für die keine Hardwarewartung mit Ersatzbeschaffung besteht oder für die die Wartungsverträge ausgelaufen sind und nicht verlängert wurden, beschafft der Auftraggeber Ersatzgeräte, wenn ein Hardwaredefekt vorliegt. Die Service Level für die Wiederherstellungszeiten sind dabei bis zur Bereitstellung von Ersatzgeräten ausgesetzt, ein RMA-Austausch (inkl. Beachtung von Service-Level) durch den Auftragnehmer findet für diese Komponenten nicht statt.

1.5.8.3 Wartungsvertrag für Ferrari Electronic AG Komponenten (Software)

Für Wartungsverträge mit dem Hersteller Ferrari Electronics AG (Anwendung: Ferrari OfficeMaster) kann der Auftragnehmer nicht auf Serviceverträge, die zwischen MPG und Ferrari Electronic AG abgeschlossen sind, aufsetzen. Vor Vertragsstart ist daher in der Transitionsphase ein Basis Support Produkt (BSP) Vertrag zwischen Ferrari Electronics AG und dem Auftragnehmer abzuschließen.

Zur Inanspruchnahme des Herstellersupports für technische Unterstützung sowie zum Zugriff auf Software-Releases und Knowledge Base wird der Auftraggeber dadurch im eigenen Namen für MPG tätig.

Derzeit (Stand 08/2026) sind folgende Lizenzen im Einsatz:

Seite 13 von 51

[Seite 14]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

Pro Rollout ist der Kauf von Herstellersupport für zusätzlich ein „OfficeMaster Connector (SMTP)“ vorzusehen. Der Auftragnehmer hat die Kosten für den Herstellersupport für die o.g. vorhandenen Lizenzen sowie die jährliche Erweiterung des Herstellersupports um 4 Instanzen „OfficeMaster Connector (SMTP)“ mit in die monatliche Servicepauschale einzupreisen.

1.5.8.4 Wartungsvertrag für JDM Komponenten (Software)

Für Wartungsverträge mit dem Hersteller JDM (Anwendung: PeterConnects) kann der Auftragnehmer nicht auf Serviceverträge, die zwischen MPG und JDM abgeschlossen sind, aufsetzen. Vor Vertragsstart ist daher in der Transitionsphase ein Produkt Support Vertrag zwischen JDM und dem Auftragnehmer abzuschließen.

Seite 14 von 51

[Seite 15]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

Zur Inanspruchnahme des Herstellersupports für technische Unterstützung sowie zum Zugriff auf Software-Releases und Knowledge Base wird der Auftraggeber dadurch im eigenen Namen für MPG tätig.

Derzeit sind 14 PeterConnects Attendant-Vermittlungsplätze im Einsatz.

Pro Rollout ist der Kauf von Herstellersupport für eine zusätzliche Instanz „PeterConnects Attendant“ inkl. aller oben aufgeführten Zusatzlizenzen vorzusehen. Der Auftragnehmer hat die Kosten für den Herstellersupport für die o.g. vorhandenen Lizenzen sowie die jährliche Erweiterung des Herstellersupports um 4 Instanzen „peterConnects Attendant“ inkl. aller oben aufgeführten Zusatzlizenzen mit in die monatliche Servicepauschale einzupreisen.

1.5.8.5 Wartungsverträge Ascom Komponenten (Software)

Software Service Subscriptions für Ascom Komponenten sind Angelegenheit der Entitäten der MPG, die diese Ascom Geräte einsetzen. Das Vertragsmanagement hinsichtlich dieser Software Service Subscriptions obliegt damit nicht zentral dem MPG-Referat a, sondern jeder einzelnen Entität. Etwaige, entsprechende Software Service Subscriptions sind mit dem Hersteller Ascom abgeschlossen. Der Auftragnehmer hat sich daher im Rahmen der Transitionphase über das Vorhandensein entsprechender Software Service Subscriptions bei den Entitäten zu informieren.

Der Auftraggeber veranlasst, dass der Auftragnehmer die Berechtigung erhält, den Herstellersupport für technische Unterstützung und zum Zugriff auf Software-Releases und Knowledge Base in Anspruch zu nehmen. Der Auftragnehmer wird dadurch im Namen des Auftraggebers tätig.

Für die Abstimmung zwischen Hersteller (Software-Support) und Auftragnehmer zur reibungslosen Nutzung dieser Verträge ist der Auftragnehmer verantwortlich. Der Auftragnehmer hat sicherzustellen, dass er am Ende der Transitionsphase Zugriff auf alle benötigten Vertragskomponenten im Herstellerportal hat, um den Herstellersupport für alle Komponenten in Anspruch nehmen zu können.

1.5.8.6 Wartungsverträge Ascom Komponenten (Hardware)

Hardwarewartung für Ascom Komponenten sind Angelegenheit der Entitäten der MPG, die diese Ascom Geräte einsetzen. Das Vertragsmanagement hinsichtlich dieser Hardwarewartung obliegt damit nicht zentral dem MPG-Fachbereich a, sondern jeder einzelnen Entität. Etwaige, entsprechende Hardwarewartung ist mit dem Hersteller Ascom abgeschlossen. Der Auftragnehmer hat sich daher im Rahmen der Transitionphase über das Vorhandensein entsprechender Hardwarewartung bei den Entitäten zu informieren.

Für alle Komponenten, für die keine Hardwarewartung mit Ersatzbeschaffung besteht oder für die diese Wartungsverträge ausgelaufen sind und nicht verlängert wurden, beschafft die betroffene Entität der MPG die Ersatzgeräte, wenn ein Hardwaredefekt vorliegt. Die Service Level für die Wiederherstellungszeiten sind dabei bis zur Bereitstellung von Ersatzgeräten

Seite 15 von 51

[Seite 16]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

ausgesetzt, ein RMA-Austausch (inkl. Beachtung von Service-Levels) durch den Auftragnehmer findet für diese Komponenten nicht statt.

1.5.8.7 Wartungsvertrag für Aspiria Komponenten (Software)

Für Wartungsverträge mit dem Hersteller Aspiria (TiM) kann der Auftragnehmer auf den zwischen MPG und dem Hersteller abgeschlossenen Servicevertrag aufsetzen. Dieser, sowie die Lizenzen zu den Komponenten, werden von MPG beim Lieferanten der Lizenzen bezogen.

Zur Inanspruchnahme des Herstellersupports für technische Unterstützung, und zum Zugriff auf Software-Releases und Knowledge Base veranlasst der Auftraggeber, dass der Auftragnehmer die Berechtigung erhält, den Herstellersupport in Anspruch zu nehmen. Der Auftragnehmer wird dadurch im Namen des Auftraggebers tätig.

Für die Abstimmung zwischen Hersteller und Auftragnehmer zur reibungslosen Nutzung dieser Verträge ist der Auftragnehmer verantwortlich. Der Auftragnehmer hat sicherzustellen, dass er am Ende der Transitionsphase Zugriff auf alle benötigten Vertragskomponenten im Herstellerportal hat, um den Herstellersupport für alle Komponenten in Anspruch nehmen zu können.

1.6 Los 2: Videoconferencing

1.6.1 Technologien und Zielsetzung

Im Bereich Video Conferencing befindet sich die Umgebung der MPG im Wandel. Die Max Planck Information & Technology (MaxIT) der Max-Planck-Gesellschaft betreibt als Teil der Unified Communication Lösung mit Cisco Webex eine zentralisierte Meeting- und Videokonferenzplattform für die Generalverwaltung und angeschlossene Max-Planck-Institute. Aktuell gibt es 3300 User, die Webex nutzen. Zusätzlich sind HW-Videokonferenz-Anlagen in der Generalverwaltung, bei MaxIT und an einzelnen Max-Planck-Instituten im Einsatz. Die MPG führt aktuell im Rahmen eines großen Programmes M365 ein. In diesem Zuge soll Webex nach und nach durch MS Teams ersetzt werden. Mit der Einführung von MS Teams im Rahmen des Piloten werden geplant bereits ca. 1500 User in Webex nicht mehr benötigt und sukzessive gelöscht werden und für MS Teams eingerichtet. Der Pilot ist aktuell für einen Zeitraum von 1,5 Jahren geplant, so dass dieser Wechsel demnach im Laufe des Jahres 2028 durchgeführt werden soll. Der Wechsel der Systeme soll im Rahmen von Projektleistungen (vgl. Kapitel 0 und 1.6.4.3) vom Auftragnehmer fachlich und technisch begleitet werden. Die der Generalverwaltung zugeordneten Videokonferenzanlagen sind dabei mit einzubeziehen.

Während der Vertragslaufzeit für diesen Vertrag ergibt sich somit zunehmend eine Verlagerung der Betriebsleistungen des Dienstleisters von Webex zu MS Teams. Die Projektleistungen für MS Teams werden hingegen unmittelbar im Rahmen der Umsetzung des Piloten in Anspruch genommen. Dabei gilt es auch, die Anforderungen aufzunehmen, welche sich aus der heutigen Nutzung von Webex ergeben, um eine hohe User Akzeptanz zu erreichen.

Zusätzlich sind die bestehenden Cisco Videokonferenzsysteme an den Standorten der Generalverwaltung und von MaxIT (München, Berlin, Brüssel und München-Laim) betriebsbereit und stabil zu betreiben. Im Bedarfsfall sind zudem neue Cisco Videokonferenzsysteme an

Seite 16 von 51

[Seite 17]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

diesen Standorten zu installieren und nach erfolgter Inbetriebnahme funktionsfähig und einsatzbereit in Betrieb zu nehmen.

Die Details zu Webex und MS Teams in Bezug auf die geforderten Leistungen, die Verantwortlichkeiten und die technische Infrastruktur werden im Folgenden beschrieben.

1.6.2 Überblick über die Zuständigkeiten und Verantwortlichkeiten

Folgende generelle Verantwortlichkeiten bestehen:

Seite 17 von 51

[Seite 18]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

1.6.3 Webex inkl. Videokonferenz-Anlagen

1.6.3.1 Leistungen Webex Betrieb nach Anzahl Webex Gastgeber

Diese Leistungen werden je 100 Webex Gastgeber vergütet. Zu den Leistungen, welche nach der Anzahl der Webex Gastgeber vergütet werden (vgl. Preisblatt Anlage A.2), gehören:

 Bereitstellung von Ressourcen im 2nd Level  Incident Management  Request Fulfillment  Problem Management  Release Management

Die Details zu den ITSM-Prozessen sind in Abschnitt 2.10 beschrieben. Die Leistungen werden pro 100 Webex Gastgeber gemäß Preisposition L2_P1 vergütet.

1.6.3.2 Leistungen Webex Projekte und Change Management auf Tagespauschalpreisbasis

Zusätzliche Leistungen für Projekte und im Rahmen des Change Management werden auf Tagespauschalpreisbasis nach Aufwand vergütet. Die Tagessätze werden im Preisblatt – Anlage A.2 definiert.

Die sonstigen Dienstleistungen sind nur auf ausdrückliche Anordnung des Auftraggebers mindestens in Textform auszuführen. Sie sind im Vorfeld schriftlich zu beschreiben und je nach Skill Level der Anforderung (nicht des tatsächlich ausführenden) zu beziffern. Die Leistungsnachweise sind dem Auftraggeber monatlich vorzulegen.

Die zusätzlichen Leistungen werden mit dem im Angebot angegebenen Tagespauschalpreisen entsprechend der zugewiesenen Rollen vergütet. Dem Auftraggeber obliegt die Entscheidung über die Durchführung von Projekten mit dem Auftragnehmer. Der Auftraggeber kann auch andere Dienstleister mit Projektaufgaben beauftragen. Der Ort der Leistungserbringung ist abhängig vom jeweiligen Gegenstand der Leistung und wird vom Auftraggeber vorgegeben.

Seite 18 von 51

[Seite 19]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

Folgende Rollen sind im Bereich Webex definiert:

 Technical Consultant Cisco Webex

Der Technical Consultant Cisco Webex übernimmt die technische Planung und Umsetzung von Anforderungen im Betrieb.

Zu den Aufgaben gehören insbesondere:

• Technische Detailplanung
• Implementierung und Konfiguration von Webex-Komponenten
• Durchführung von Systemerweiterungen
• Integration neuer Einrichtungen
• Durchführung von Migrationen
• Erstellung technischer Dokumentationen
• Durchführung von Funktionstests und Inbetriebnahmen
• Technische Unterstützung während im Rahmen des Betriebs

 Cisco Collaboration-Techniker

Der Cisco Collaboration-Techniker übernimmt die Installation und notwendige Fehleranalyse von Cisco Videokonferenzsystemen vor Ort an den Standorten der Generalverwaltung und von MaxIT (München, München-Laim, Berlin, Brüssel)

Zu den Aufgaben gehören insbesondere:

• Durchführung von Inbetriebnahmen, Fehleranalysen und Funktionstests
• Kommunikation und Abstimmung mit den internen Serviceeinheiten (vor Ort Service der IT-Abteilung, Netzwerk, Hausverwaltung)
• Aufbau, Montage und ggfs. Abbau der Geräte
• Verkabelung von Strom, Netzwerk (Ethernet), Audio/Video-Kabeln
• Firmware Updates
• Optimierung von Audio- und Videokonfigurationen

1.6.3.3 Technische Rahmenbedingungen Webex

Cisco Webex ist mittlerweile integraler Bestandteil des UC-Systems der MPG. Neben der Generalverwaltung nutzen auch eine Vielzahl von angeschlossenen Max-Planck-Instituten, vornehmlich in den Verwaltungen, Webex als Meeting- und Collaboration-Tool. Das beinhaltet reine Online-Kommunikation, hybride Meetings und größere hybride Veranstaltungen. In der Generalverwaltung werden die größeren hybriden Veranstaltungen durch einen externen Dienstleister unterstützt und begleitet, das ist nicht Teil dieser Vergabe.

Seite 19 von 51

[Seite 20]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

Abbildung 1-2: Gesamt-Architektur UC System inkl. Webex

Schwerpunktmäßig wird Cisco Webex inkl. Webex App, der Video- und Webkonferenzdienst von Cisco, in der Generalverwaltung der MPG genutzt. Weiterhin wird Webex Messaging und Webex Calling (Non-PSTN) den Nutzern zur Verfügung gestellt. An ausgewählten Standorten wird zusätzlich Calling über die Webex App (Unified CM) eingesetzt. Die Webex-Dienste werden als Software-as-a-Service über die Public Cloud von Cisco bereitgestellt.

Aktuell sind 3300 Webex Gastgeber – Lizenzen im Control Hub vorhanden. Mit der Einführung von MS Teams im Rahmen des Piloten werden ca. 1500 User in Webex nicht mehr benötigt und sukzessive gelöscht werden und für MS Teams eingerichtet, siehe Kap. 1.6.1.

Die Administration und Provisionierung von Webex sowie die Echtzeit- oder nachträgliche Fehleranalyse von Webex Meetings erfolgt durch den Cisco Collaboration Control Hub, dem Web-basierten Managementportal von Webex.

Dabei werden zwei Webex ORGs betrieben: eine Produktiv-ORG und eine Test-ORG. Für die Generalverwaltung sowie Institute sind jeweils separate Webex-Sites auf der Produktiv-ORG angelegt. Dadurch können die spezifischen Anforderungen und Konfigurationen der Bedarfsträger besser abgebildet werden. Insgesamt werden derzeit ca. 70 Webex-Sites auf der Produktiv-ORG genutzt. Die ca. 70 Webex-Sites sind auf drei (3) Subscriptions verteilt, um damit der von Cisco empfohlenen Anzahl von ca. 50 Webex Sites pro Subscription zu entsprechen. Die Planung, weitere Webex-Sites für neu zu versorgende Institute anzulegen ist abhängig von der Einführung von MS Teams. Zur Erhöhung der Ausfallsicherheit sind die Webex-Sites auf die beiden Webex-Cluster AG und BG am Standort Frankfurt/Main verteilt. Auf der Test-ORG ist die Konfiguration der Produktiv-ORG nachgebildet, um etwaige Änderungen in der Architektur bzw. Änderungen des Webex-Leistungsspektrums vorab verifizieren zu können.

Der Directory Connector realisiert die Anbindung von Webex an das Active Directory der Generalverwaltung. Dabei werden die Nutzerinformationen vom Active Directory in Richtung Webex synchronisiert. Weiterhin ist Webex an den Single-Sign-On-Proxy der MPG angebunden,

Seite 20 von 51

[Seite 21]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

so dass sich Nutzer am Single-Sign-On Identity Provider der Generalverwaltung bzw. am Single-Sign-On Identity Provider des jeweiligen Institutes anmelden können.

Zudem ist Webex an das Learning Management System der MPG, SAP Successfactor Learning, im Weiteren SAPLMS genannt, angebunden. Damit können Trainer Webex Meetings aus dem SAPLMS planen und durchführen. SAPLMS nutzt dazu die REST API von Webex. Die Kommunikation zwischen SAPLMS und Webex läuft dabei nicht direkt, sondern über einen durch den Auftraggeber betriebenen Loadbalancer. Da SAPLMS derzeit den notwendigen Token- basierten Authentifizierungsmechanismus von Webex noch nicht unterstützt, wird dieser durch den Loadbalancer stellvertretend für SAPLMS gegenüber Webex realisiert. Diese Funktion wird seitens des Auftraggebers bereitgestellt. Der Auftragnehmer wird notwendige Unterstützungsleistung zur Verfügung stellen, um die Schnittstelle und das Verfahren bis zum Ende der Vertragslaufzeit betriebsbereit zu halten. Etwaige Aufwände sind in die Einheitspreise für ITSM einzukalkulieren.

Die folgenden Clients nutzen derzeit (Stand Juni 2026) den Webex-Dienst: Webex App und Mobile App, WebApp, CUCM- und Cloudregistrierte VK-Systeme, SIP-basierte Clients.

Cisco Videokonferenzsysteme werden zum jetzigen Zeitpunkt über Cisco Webex registriert, in Ausnahmefällen auch über Cisco CUCM. Im Collaboration Control Hub sind derzeit MPG-weit 88 VK-System registriert, 33 davon sind der Generalverwaltung und MaxIT mit ihren Standorten München, Berlin, Brüssel und München-Laim zugeordnet, die Übrigen verteilen sich auf die Max- Planck-Institute. Für CUCM registrierte VK-Systeme wird Webex Edge for Devices eingesetzt, um Management- und Analysemöglichkeiten im Collaboration Control Hub für diese Systeme zu nutzen.

Weitere Lösungskomponenten wie bspw. der Hybrid Calendar Connector oder Hybrid Data Security werden künftig ggf. noch umgesetzt.

1.6.3.4 Zentrale und dezentrale Systemkomponenten

Die Komponenten sind zwischen zentralen und dezentralen Komponenten unterteilt – zentrale Komponenten befinden sich in den 3 Rechenzentren in Göttingen und München sowie Berlin, dezentrale Komponenten in den Entitäten der MPG GV bzw. der MPI vor Ort.

In den nachfolgenden Tabellen sind die aktuellen Systemkomponenten des UC-Systems (Configuration Items) angegeben. Hier nicht explizit aufgelistet sind lokale Endgeräte, für die der Auftragnehmer keinen direkten Support leisten muss, die aber indirekt im Rahmen der Störungsanalyse und Herstellerwartung Gegenstand der Support Leistungen werden können.

Folgende zentrale Configuration Items sind vorhanden:

Seite 21 von 51

[Seite 22]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

Tabelle 3: Zentrale Configuration Items Webex

Folgende dezentrale Configuration zu Webex werden aktuell genutzt:

Tabelle 4: Dezentrale Configuration Items Webex

1.6.3.5 Serviceverträge für Cisco Webex

Für Cisco Webex hat der Auftraggeber Serviceverträge über Cisco Webex Basic Support abgeschlossen, auf die der Auftragnehmer zugreifen kann.

Aktuell sind die ca. 70 Webex Sites auf 3 Subscriptions verteilt, um damit der von Cisco empfohlenen Anzahl von 50 Webex Sites pro Subscription zu entsprechen.

Für alle Cisco Videokonferenzanlagen inkl. Cisco-Peripheriegeräten der GV hat der Auftraggeber Cisco Support Standard (8x5xNBD)-Verträge abgeschlossen.

Seite 22 von 51

[Seite 23]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

1.6.4 MS Teams

1.6.4.1 Zielbild

Im Rahmen eines Gesamtprogramms wird M365 aktuell mit unterschiedlichen Services eingeführt. Ein Bestandteil ist die Einführung von MS Teams. Der Auftragnehmer wird in die Einführung im Rahmen des Gesamtprogramms M365 eingebunden und übernimmt im Anschluss den Betrieb. Der Betrieb startet basierend auf der aktuellen Planung nach ca. 1,5 Jahren Einführung in Pilot-Instituten. Ein Go Live zum geplanten Zeitpunkt kann nicht garantiert werden. Leistungsbeginn für den Betrieb ist mit Abschluss des Pilotprojektes für MS Teams. Leistungsbeginn für die Projektleistungen ist mit Vertragsbeginn.

Die Gesamtumgebung M365 bzw. die Basis wird von der GWDG betrieben. Der Auftragnehmer fungiert als Experte und Dienstleister für den Bereich MS Teams. Er kümmert sich um die Bereiche, die exklusiv für MS Teams (Webconferencing, Chat und Telefonie) zur Verfügung stehen und stimmt sich mit den anderen M365 Bereichen zu übergreifenden Themen ab, welche unterschiedliche Applikationen und Bereiche von M365 betreffen. Dies betrifft sowohl den Betrieb (vgl. 1.6.4.2) mit den ITSM Vorgaben (vgl. 2.10) als auch Leistungen für die Einführung, Projekte und Change Management auf Tagespauschalpreisbasis (vgl. Abschnitt 1.6.4.3).

1.6.4.2 Leistungen MS Teams Betrieb nach Anzahl User

Diese Leistungen werden pauschal für die angegebene Anzahl von 1.500 Usern vergütet. Bei einer Mehrung und Minderung um 500 User wird der Betrag entsprechend dem für Mehrung / Minderung angegebenen Preis im Preisblatt angepasst.

Zu den Leistungen, welche nach der Anzahl der User vergütet werden (vgl. Preisblatt Anlage A.2), gehören:

 Bereitstellung von Ressourcen im 2nd Level  Incident Management  Request Fulfillment  Problem Management  Release Management

Die Details zu den ITSM Prozessen sind in Abschnitt 2.10 beschrieben. Die Leistungen werden für die angegebene Anzahl an Usern von 1.500 pauschal gemäß Preisposition L2_P2 vergütet. Bei einer Mehrung / Minderung der Anzahl der User um 500, mehrt / mindert sich die Pauschale um den Betrag aus Preisposition L2_P3. Es sind dabei auch Mehrungen und Minderungen um ein Vielfaches von 500 möglich. Sollte sich bspw. die Anzahl der User um 1.000 erhöhen, so ergibt sich die Pauschale für die Abrechnung aus folgender Rechnung: L2_P2 + 2 * L2_P3 (in Worten: „Preisposition L2_P2“ plus zwei Mal „Preisposition L2_P3“).

1.6.4.3 Leistungen MS Teams Einführung, Projekte und Change Management

Zusätzliche Leistungen für die Einführung, Projekte und im Rahmen des Change Management werden auf Tagespauschalpreisbasis nach Aufwand vergütet. Die Tagessätze werden im Preisblatt – Anlage A.2 definiert.

Seite 23 von 51

[Seite 24]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

Dienstleistungen gemäß dieser Preisposition sind nur auf ausdrückliche Anordnung des Auftraggebers, die mindestens in Textform erfolgt, durch den Auftragnehmer auszuführen. Sie sind im Vorfeld schriftlich zu beschreiben und je nach Skill Level der Anforderung (nicht des tatsächlich ausführenden) zu beziffern. Die Leistungsnachweise sind dem Auftraggeber monatlich vorzulegen.

Die zusätzlichen Leistungen werden mit dem im Angebot angegebenen Tagespauschalpreisen entsprechend der zugewiesenen Rollen vergütet. Dem Auftraggeber obliegt die Entscheidung über die Durchführung von Projekten mit dem Auftragnehmer. Der Auftraggeber kann auch andere Dienstleister mit Projektaufgaben beauftragen. Der Ort der Leistungserbringung ist abhängig vom jeweiligen Gegenstand der Leistung und wird vom Auftraggeber vorgegeben.

Folgende Rollen sind im Bereich MS Teams definiert:

 Projekt Manager MS Teams

Der Projekt Manager verantwortet die operative Projektsteuerung und Koordination. Er führt die Projekte gemeinsam mit dem IT-Verantwortlichen und den IT-Serviceverantwortlichen UC des Auftraggebers. Er verantwortet die Planung, Bereitstellung und Steuerung der erforderlichen personellen Ressourcen des Auftragnehmers sowie den bedarfsgerechten Einsatz der Projektmitarbeitenden.

Zusammen mit dem IT-Serviceverantwortlichen UC des Auftraggebers trägt er die Verantwortung für die Erreichung der vereinbarten Projektziele hinsichtlich Qualität, Terminen und Wirtschaftlichkeit. Das Projektteam wird projektbezogen durch Mitarbeitende der jeweiligen Institute ergänzt, die ihre fachlichen und organisatorischen Anforderungen in das Projekt einbringen und die Umsetzung vor Ort unterstützen.

Zu den Aufgaben gehören insbesondere:

• Projektplanung
• Projektcontrolling
• Steuerung des Projektteams
• Koordination der Aktivitäten mit dem Gesamtprogramm M365
• Projektberichte und Abstimmung mit dem Auftraggeber
• Pflege des vorgegebenen MPG-Projektplans auf dem SharePoint
• Einberufen und Moderation der Projekt-Kickoff und Projekt-Status-Meeting
• Vorplanung des Rollouts zur Klärung der Rahmenbedingungen und Aufnahme der Anforderungen in Abstimmung mit dem Auftraggeber
• Erstellung von Terminplänen für Ablauf des Rollouts, Abnahmen und Schulungen/Einweisungen
• Steuerung und Koordination der Mitarbeiter im Rollout
• Koordination, Überwachung und Kontrolle der Bestellungen und Lieferungen
• Steuerung und Überwachung der Aktivitäten und Termine im Rollout anhand des MPG- Projektplans
• Berichte über Status, Fortschritt, offene Punkte, Risiken und Probleme im Rollout
• Klärung bei auftretenden Schwierigkeiten, ggf. auch vor Ort
• Begleitung der Abnahmen
• Zusammenführung und Qualitätssicherung der Rollout-Dokumentation

Seite 24 von 51

[Seite 25]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

 Lead Architekt MS Teams

Der Lead Architekt verantwortet die fachliche und technische Zielarchitektur von MS Teams. Zu den Aufgaben gehören insbesondere:

• Entwicklung und Beratung zur Zielarchitektur für Microsoft 365 mit dem Schwerpunkt MS Teams inkl. den Bereichen Unified Communications (UC) und Videokonferenzlösungen (inklusive Meetingraum-Integration wie z. B. Teams Rooms)
• Abstimmung der Zielarchitektur mit anderen M365 Bereichen / Ansprechpartnern
• Erstellung von Richtlinien für Teams, Gastzugriffe, Namenskonventionen und Archivierung
• Überführung der Vorgaben aus der Architektur für Webex in die MS Teams Umgebung
• Übersetzung von Anforderungen des Auftraggebers und dessen Nutzer an die Nutzung von MS Teams in Anforderung, Design und Konfiguration der Zielarchitektur

 Technical Consultant MS Teams

Der Technical Consultant MS Teams übernimmt die technische Planung und Umsetzung von Projekten im Bereich MS Teams.

Zu den Aufgaben gehören insbesondere:

• Entwicklung und Beratung zur Zielarchitektur für Microsoft 365 mit dem Schwerpunkt MS Teams inkl. den Bereichen Unified Communications (UC) und Videokonferenzlösungen (inklusive Meetingraum-Integration wie Teams Rooms)
• Abstimmung der Zielarchitektur mit anderen M365 Bereichen / Ansprechpartnern
• Erstellung von Richtlinien für Teams, Gastzugriffe, Namenskonventionen und Archivierung
• Überführung der Vorgaben aus der Architektur für Webex in die MS Teams Umgebung
• Übersetzung von Anforderungen des Auftraggebers und dessen Nutzer an die Nutzung von MS Teams in Anforderung, Design und Konfiguration der Zielarchitektur

1.6.4.4 Technische Rahmenbedingungen MS Teams

MS Teams wird als Bestandteil von M365 im Rahmen eines großen Programms eingeführt. Für M365 gibt es bereits folgende grundlegende Festlegungen, die sich auch auf MS Teams auswirken:

Microsoft 365 wird grundsätzlich in einem zentralen Standard-Tenant bereitgestellt. In diesem primären Tenant werden alle Kollaborations- und Produktivitätsdienste gebündelt betrieben.

Abweichungen hiervon sind möglich, wenn besondere rechtliche, organisatorische oder technische Anforderungen bestehen. In solchen Fällen kann nach Entscheidung des Architekturteams ein separater Tenant für einzelne Einrichtungen eingerichtet werden.

Die Zusammenarbeit zwischen ggf. vorhandenen separaten Tenants und dem Standard-Tenant erfolgt über B2B-Synchronisation (z. B. Cross-Tenant Synchronization).

Seite 25 von 51

[Seite 26]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

Staging-Konzept

Das Tenant Stagingkonzept wurde auf Basis des Standard-Staging-Konzeptes der MaxIT erstellt. Das M365 Stagingkonzept folgt weitestgehend dem bereits existierenden Konzept, mit einer Aufteilung in unterschiedliche Stages für Entwicklung, Konsolidierung und Produktion, wobei es sich im Gegensatz zum oben erwähnten Konzept um einen vierstufigen Deployment- Prozess handelt, bei dem die Entwicklungsumgebung zusätzlich in eine Spielwiese (Stage 0) und Stage E aufgeteilt ist. Bei M365 handelt es sich um eine Sammlung unterschiedlicher Services, die durch die hohe Integration der Services miteinander dem Nutzenden neue Funktionalitäten bietet. Hier sei beispielsweise die Integration des Kalenders in Teams erwähnt. Änderungen an einem Service können dementsprechend auch Auswirkungen auf die Funktionalität anderer Services haben, weshalb das Staging-Konzept auf vier Stufen ausgeweitet wurde.

Benutzerprovisionierung und Identitätsmanagement

Als primäre Datenquelle für die Provisionierung in Entra ID wurde eine MPG-eigene REST- Schnittstelle als Austauschdatenbank (Mini-ADB) eingerichtet, die die grundlegenden Personalstammdaten aus dem Personalverwaltungssystem bereitstellt. Sie bietet aktuell die größte verfügbare Datenbasis für fest angestellte Mitarbeitende. Gastidentitäten und weitere Nutzergruppen sollen perspektivisch ergänzt werden. Um Abhängigkeiten von einem übergreifenden IDM-Projekt zu vermeiden, erfolgt die Provisionierung über eine temporäre Schnittstelle (Management-Host und IdHub), die Exporte aus der Mini-ADB verarbeitet und via SCIM in Entra ID synchronisiert.

Entra ID dient als zentrale Plattform für die Verwaltung von Benutzeridentitäten, wobei grundlegende Attribute wie Name, E-Mail-Adresse, Personalnummer und organisatorische Daten (Institut, Abteilung) aus der Mini-ADB übernommen werden. Der SamAccountName (in der Regel die Personalnummer) dient als primärer Schlüssel für den Abgleich. Die Authentifizierung erfolgt nicht direkt in Entra ID, sondern wird über den MPG-SSO-Proxy an das jeweilige Identity Provider-System (z. B. IKT-IDM) weitergeleitet. Entra ID übernimmt hier lediglich die Weiterleitung der Authentifizierungsanfragen und die Anwendung von Conditional Access-Richtlinien (z. B. MFA, Geräte-Compliance).

Ein weiterer zentraler Aspekt ist die automatisierte Lizenzzuweisung. Die MPG nutzt Microsoft 365 E3 (bzw. eine Teilmenge davon) sowie die technische Pflichtlizenz Microsoft Entra ID P1 für alle Benutzer. Die Zuweisung erfolgt über den IdHub (IKT), der Anforderungen der Einrichtungen sammelt und via Management Host an Entra ID übermittelt. Die Deaktivierung von Benutzerkonten basiert auf dem Austrittsdatum aus der Mini-ADB und erfolgt standardmäßig nach 100 Tagen, wobei Einrichtungen diese Frist verkürzen können. In diesem Fall wird lediglich die Lizenz entzogen, der Account selbst bleibt erhalten.

Gruppenmitgliedschaften und RBAC-Rollen (z. B. Exchange-Administrator) werden nicht aus der Mini-ADB synchronisiert, sondern müssen manuell in Entra ID verwaltet werden. Dies gilt insbesondere für administrative Rollen, die im Admin-Konzept [SD1] der MPG beschrieben sind.

Zusammenfassend fungiert Entra ID als synchronisiertes Abbild der Mini-ADB und übernimmt folgende Aufgaben:

Seite 26 von 51

[Seite 27]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

• Verwaltung von Benutzeridentitäten (Kernattribute, Status, organisatorische Daten)
• Lizenzzuweisung
• SSO-Integration (Weiterleitung an MPG-IDP)
• Conditional Access (Zugriffssteuerung)

Nicht in Entra ID verwaltet werden Authentifizierungsdaten (Passwörter, MFA), Gruppenmitgliedschaften und RBAC-Rollen (außer manuell zugewiesene Admin-Rollen). Die aktuelle Architektur ist als temporäre Lösung konzipiert und wird mit der Einführung eines zentralen MPG-IDM voraussichtlich angepasst.

Rollenbasierte Zugriffssteuerung

Die rollenbasierte Zugriffssteuerung (Role-Based Access Control) für Admins wird in Microsoft 365/Entra ID gemäß dem Enterprise Access Model mit einer 3-Tier-Architektur (Tier 0–2) umgesetzt. Ziel ist die Minimierung von Sicherheitsrisiken wie Lateral Movement und Privilege Escalation durch strikte Rollentrennung, Least-Privilege-Prinzip und zeitlich begrenzte Zugriffe. Die Umsetzung basiert auf den Vorgaben des Adminkonzepts und nutzt bestehende Systeme wie Entra PIM, Conditional Access und Intune.

1.6.4.5 Serviceverträge für MS Teams

Die Serviceverträge mit Microsoft werden vom Auftraggeber gestellt.

1.6.5 Übergreifende Betriebsleistungen Video-Conferencing (pauschal)

Zu den übergreifenden Betriebsleistungen, welche pauschal monatlich vergütet werden, gehören Aufgaben der Gesamtkoordination im Betrieb. Dazu zählt die Bereitstellung eines zentralen Ansprechpartners (vgl. Kapitel 2.4), Teilnahme an Regelterminen (vgl. Kapitel 2.5) und Aktivitäten im Service Level Management (vgl. Kapitel 2.10.10) inkl. Messung und Reporting der Service Level.

1.6.6 Transition zum Leistungsbeginn

MS Teams wird aktuell noch eingeführt. Daher wird der heutige Betrieb zu Beginn des Vertrages noch nicht übergeben. Der Auftragnehmer wird in die Einführung im Rahmen des Gesamtprogramms M365 eingebunden und übernimmt im Anschluss den Betrieb. Eine Transition wie in den anderen Leistungspaketen ist im Bereich MS Teams daher nicht nötig. Die Transition (vgl. Kapitel 3) bezieht sich somit ausschließlich auf den Bereich Webex / Videokonferenzanlagen.

1.7 Service Level (Los 1 und Los 2)

Für beide Lose gelten die in den folgenden Abschnitten dargelegten Service Level. Sie werden pro Los getrennt gemessen und beziehen sich auf die jeweiligen Leistungen in den Losen (vgl. Kapitel 1.5 und 1.6).

Seite 27 von 51

[Seite 28]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

1.7.1 Definitionen

Servicezeit:

Zeit in denen die Systeme durch den Auftragnehmer betreut werden.

Berechnung:

Die Berechnung der SLAs erfolgt monatlich auf Basis der im Service Review Meeting bereitgestellten Reports.

Reaktionszeit:

Zeitspanne von der Meldung eines Incidents beim Service Desk oder durch Übermittlung eines Tickets per Web-Interface oder E-Mail bis zur qualifizierten Bearbeitung und Rückmeldung durch einen Mitarbeiter des Auftragnehmers.

Definition der Priorität

Die Definition der Priorität erfolgt anhand von Störungssymptomen und exemplarischer Beispiele (nicht abschließend):

Los 1

Prio-1:

 Ausfall der kompletten Systemcluster für die zentralen Systemanwendung, z. B. CUCM, CUC1, CUP2

 Ausfall der zentralen Systemkomponenten, z. B. TiM, Ferrari Fax und PeterConnects

 Ausfall eines Session Border Controllers in einem der beiden RZ

 Ausfall eines lokalen Voice Gateways

 Ausfall eines lokalen Session Border Controllers

Prio-2:

 Ausfall oder starke Beeinträchtigung eines Service für mindestens 25% der Teilnehmer (das beinhaltet auch eine systematische Störung der Endgeräte)

 Komplettausfall DECT am lokalen Standort

 Ausfall einer redundanten Einzelkomponente einer zentralen Systemanwendung CUCM, CUP, CUC (nicht des gesamten Clusters), Cisco Expressway C und E

 Ausfall eines lokalen analogen Voice Gateways

 Ausfall Cisco Smart Software Manager Satellite

1 Voicemail 2 Presence

Seite 28 von 51

[Seite 29]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

Prio-3:

 Ausfall oder starke Beeinträchtigung eines Service für einzelne Teilnehmer (z.B. Ausfall IP Telefon)

Los 2

Prio-1:

 Ausfall SSO (Webex/MS Teams-Anmeldung)

 Ausfall kritischer Videokonferenzanlagen (z. B. Präsident oder Generalsekretärin, jeweils an den Standorten München oder Berlin)

Prio-2:

 Ausfall des Directory Connectors für Webex

 Ausfall der Schnittstelle Webex – SAPLMS

 Ausfall eines Cisco Videokonferenzsystems am Standort GV München, Büro Berlin, Büro Brüssel oder Standort Laim (MaxIT)

Prio-3:

 Ausfall oder starke Beeinträchtigung von Webex/MS Teams für einzelne Teilnehmer (z.B. Login Probleme)

Die Spezialfälle im Kontext von MS Teams werden im Rahmen des Einführungsprojektes festgelegt

Los 1 + Los 2

Prio-1:

 Komplettausfall oder starke Beeinträchtigung des Voice- und Video-Services für einen kompletten Standort oder mindestens 50% der Teilnehmer (das beinhaltet auch eine systematische Störung der Endgeräte)

Prio-2:

 Technische Klärung, wenn eine Servicebeeinträchtigung absehbar ist

Prio-3:

 Geringe Beeinträchtigung eines Service oder einzelner Funktionen

 Technische Klärung ohne Servicebeeinträchtigung

Seite 29 von 51

[Seite 30]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

Definition der Wiederherstellungszeit

Zeitspanne vom Bekanntwerden eines Incidents durch Meldung beim Service Desk oder durch Übermittlung eines Tickets per Web-Interface oder E-Mail bis zur Wiederherstellung der gestörten Funktion, ggf. durch einen Workaround.

Definition der Antrittszeit

Zeitspanne vom Bekanntwerden eines vor-Ort Einsatzes bis zum Eintreffen eines Mitarbeiters des Auftragnehmers am Einsatzort.

Definition Problem Recording Zeit

Maximale Zeitspanne von der Identifizierung eines Problems aus Incidents mit unbekannter Störungsursache oder Meldung eines Problems durch den Auftraggeber bis zur Erfassung in einem Problem Ticket, Klassifizierung und Zuweisung an den zuständigen Fachbereich

Definition Problem Analyse Zeit

Maximale Zeitspanne zur Problemanalyse mit Identifizierung und Dokumentation der Problemursache, beginnend ab Identifizierung eines Problems aus Incidents oder Meldung eines Problems durch den Auftraggeber

Definition Bereitstellungzeit

Maximale Zeitspanne für die Durchführung der Service Requests (IMAC-Requests), beginnend ab Meldung / Übermittlung des Service Requests an den Auftragnehmer. Falls ein IMAC-Request interdisziplinär (durch den Auftragnehmer und Fachbereichen des Auftraggebers oder anderer Dienstleister) durchgeführt werden muss, zählt nur die Zeitspanne für die Provisionierungsschritte, die vom Auftragnehmer durchgeführt werden.

1.7.2 Service Level für das Incident Management

Tabelle 5: SLA Incident Management

Seite 30 von 51

[Seite 31]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

1.7.3 Service Level für das Problem Management

Tabelle 6: SLA Problem Management

1.7.4 Service Level für Request Fulfillment (IMACs)

Tabelle 7: SLA IMACs

1.7.5 Service Level für Release Management

Tabelle 8: SLA Release Management

Seite 31 von 51

[Seite 32]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

1.7.6 Vertragsstrafen bei Service Level Verletzungen

Der Auftragnehmer verpflichtet sich zur Einhaltung der in der Service Level Übersicht enthaltenen Service Level und akzeptiert die im Folgenden festgelegten Regelungen für Pönalen im Falle der Nichterreichung der Service Level („Pönale“ und „Vertragsstrafe“ werden sinngleich verwendet). Weitergehende Schadenersatzansprüche des Auftraggebers bleiben unberührt. Die Vertragsstrafe wird jedoch auf die Höhe dieser Schadenersatzansprüche angerechnet. Die Anrechnung von Vertragsstrafen auf Schadenersatzansprüche ist konkret auf den einzelnen Schadenfall zu beziehen. Im Falle von Unstimmigkeiten werden die Parteien eine Eskalation gemäß in dieser Vergabeunterlage definiertem Verfahren einleiten.

Die den Service Leveln zugeordneten Pönalen sind in den Service Level Übersichten in den Kapiteln 1.7.2 bis 1.7.6 aufgeführt. Dabei werden folgende Abstufungen unterschieden:

 2 % des monatlichen Rechnungsbetrages für ITSM-Prozesse (Preisblatt Positionen L1_P1 bis L1_P3 für Los 1 und L2_P1 bis L2_P4 für Los 2)

 3 % des monatlichen Rechnungsbetrages für ITSM-Prozesse (Preisblatt Positionen L1_P1 bis L1_P3 für Los 1 und L2_P1 bis L2_P4 für Los 2)

 5 % des monatlichen Rechnungsbetrages für ITSM-Prozesse (Preisblatt Positionen L1_P1 bis L1_P3 für Los 1 und L2_P1 bis L2_P4 für Los 2)

Sollte im Abrechnungsmonat ein Service Level, der mit einer Pönale versehen ist, nicht eingehalten werden, so wird die diesem Service Level zugeordnete Pönale verwirkt und in der entsprechenden Rechnung gutgeschrieben (2%, 3% oder 5% des Rechnungsbetrages für ITSM- Prozesse im jeweiligen Los).

Werden mehrere Service Level im Abrechnungsmonat nicht eingehalten, so ist die höchste aufgetretene Pönale verwirkt und wird in der Rechnung gutgeschrieben. Es findet keine Kumulierung der Pönalen statt, so dass die Vertragsstrafe maximal 5% des monatlichen Rechnungsbetrags erreichen kann. Die Höchstsumme der Vertragsstrafen über das Jahr beträgt 5% der jeweiligen Jahresvergütung für ITSM-Prozesse pro Los.

2 Zusammenarbeit mit dem Auftraggeber (Los 1 und Los 2)

Die Auftragnehmer (Los 1 und Los 2) erbringen ihre Dienstleistungen je nach Bedarf, vornehmlich an ihrem Standort sowie beim Auftraggeber in München (Generalverwaltung oder MaxIT) und in Ausnahmefällen, auf gesonderte Anordnung, auch an anderen Orten innerhalb Deutschlands, z. B. bei den unterschiedlichen Instituten.

Die konzeptionelle Entwicklung sowie bedarfsgerechte und rechtskonforme Gestaltung der Auftragsvergaben können nur in enger Abstimmung zwischen Auftragnehmer und Auftraggeber erfolgen. Dazu ist ein intensiver Kontakt zwischen Auftragnehmer und Auftraggeber, auch kurzfristig sicherzustellen.

Es muss sichergestellt sein, dass kleinere Absprachen per Telefon und/oder E-Mail zu den üblichen Bürozeiten (Montag – Freitag 9:00 Uhr bis 17:00 Uhr) durchgeführt werden können. Für den Support und Betrieb gelten die definierten Servicezeiten (vgl. Kapitel 1.7).

Seite 32 von 51

[Seite 33]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

Zur vereinfachten Korrespondenz und zur Gewährleistung der Erreichbarkeit in Vertretungsfällen innerhalb der Organisation des Auftragnehmers stellt der Auftragnehmer eine Funktions-E-Mail-Adresse bereit, unter der u.a. der zentrale Ansprechpartner (vgl. Kapitel 2.4) zu erreichen ist.

Wenn nicht ausdrücklich anders vereinbart oder abgestimmt, erstellt der Auftragnehmer von Besprechungen mit dem Auftraggeber ein Ergebnisprotokoll und legt es dem Auftraggeber zur Prüfung und Zustimmung vor.

2.1 IT-Sicherheit

Die Auftragnehmer sind an die Vorgaben der MPG-Generalverwaltung hinsichtlich der IT- Sicherheit gebunden. Dies umfasst insbesondere:

 Den Umgang mit Zugangsdaten.

 Der vertrauliche Umgang mit personenbezogenen Daten und Unternehmensdaten, gem. Anlage 1 zum Vertrag: Vertrag zur Auftragsverarbeitung nach Art. 28 DS-GVO (AVV) mit technischen und organisatorischen Maßnahmen (TOM)

 Die Regelungen zur IT-Sicherheit in Gesamtbetriebsvereinbarungen der MPG.

Die entsprechenden Regelungen werden den bezuschlagten Auftragnehmern zu Beginn der Transition-Phase zur Verfügung gestellt.

2.2 Mitwirkungsleistungen und Beistellungen durch den Auftraggeber

Für die Erbringung der ausgeschriebenen Leistungen durch den jeweiligen externen Leistungserbringer für Los 1 und Los 2 kann dieser von den nachfolgenden Mitwirkungsleistungen und Beistellungen des Auftraggebers ausgehen, soweit diese jeweils in diesen Vergabeunterlagen angegeben sind. Sie sind teilweise bereits in den entsprechenden Abschnitten der Leistungsbeschreibung genannt, werden aber in diesem Abschnitt noch einmal gesamthaft zusammengefasst. Alle Ausführungen in den folgenden Unterkapiteln zu den Mitwirkungsleistungen beziehen sich auf die Auftragnehmer beider Lose.

2.2.1 Fernwartungs-Zugriff

Für den Fernwartungszugriff auf die Systeme, die in der Zuständigkeit des jeweiligen Auftragnehmers liegen, stellt der Auftraggeber in Zusammenarbeit mit dem Auftragnehmer einen zentralen Windows basierten Sprungserver zur Verfügung. Dieser wird über einen Site- to-Site VPN Tunnel mit der Infrastruktur des Auftragnehmers gekoppelt. Die Kosten für die Einrichtung dieses Site-2-VPN Tunnels sind im Rahmen der Transition zu berücksichtigen.

Der Auftraggeber stellt in Absprache mit dem Auftragnehmer für die aufgrund dieses Vertrags beim Auftraggeber zu erbringenden Leistungen erforderliche Zugriffe auf die Infrastruktur (z.B. Systemzugriffe und -berechtigungen) des Auftraggebers sicher. Im Rahmen der Transition stellt der Auftragnehmer dem Auftraggeber eine Liste der namentlich benannten Mitarbeiter inkl. E-

Seite 33 von 51

[Seite 34]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

Mail-Adresse und Telefonnummer zur Verfügung, damit die zugriffsermöglichenden Accounts auf der Infrastruktur des Auftraggebers angelegt werden können. Es ist nicht vorgesehen mehr als 50 namentlich genannte Accounts anzulegen. Der Auftragnehmer übermittelt die Nutzer für den initialen Userimport in Form der vom Auftraggeber vorgegebenen Excel Tabelle. Nach erfolgreichem Abschluss der Transition Phase können auf Anfrage des Auftragnehmers wenige einzelne neue Accounts eingerichtet werden.

Für den Cisco Collaboration Hub werden entsprechende Admin Accounts mit den notwendigen Administrationsberechtigungen durch den Auftraggeber zur Verfügung gestellt.

2.2.2 Dokumentationen

Die für die Tätigkeiten des Leistungserbringers relevanten vorhandenen Dokumentationen und Betriebshandbücher werden vom Auftraggeber im Rahmen der Transition übergeben. Sie müssen vom jeweiligen Auftragnehmer gepflegt und aktuell gehalten werden.

Während der Vertragslaufzeit können weitere Dokumentationen hinzukommen; auch diese müssen dann vom Auftragnehmer gepflegt werden.

2.2.3 Ressourcen

Im Rahmen der definierten Zuständigkeiten stellt der Auftraggeber dem jeweiligen Auftragnehmer interne Ressourcen zur Verfügung. Eine Liste der Ansprechpartner der vom Auftraggeber bereitgestellten Ressourcen wird im Rahmen der Transition übergeben.

2.3 Nutzungsrechte an Software, Lizenzen

Die Lizenzen für die auf den MPG-eigenen Servern sowie den MPG-eigenen PCs eingesetzten Betriebssysteme und Anwendungsprogramme werden vom Auftraggeber zur Verfügung gestellt. Das Gleiche gilt für die in den Bereichen Netzwerk- und System-Management, Software-Management sowie Asset-Management eingesetzten Programme.

Die o.g. Regelung betrifft nur MPG-eigene Hardware (Server / PCs / Netzwerk etc.). Es dürfen in dem MPG-eigenen Netzwerk nur vom Auftraggeber genehmigte Hard- und Software- Komponenten betrieben werden.

2.4 Zentraler Ansprechpartner

Vom jeweiligen Auftragnehmer ist für jedes Los jeweils ein zentraler Ansprechpartner zu benennen, der befugt ist, den/dem vom Auftragnehmer eingesetzten Mitarbeitenden dienstliche und fachliche Weisungen zu erteilen und der Max-Planck-Gesellschaft zur Beseitigung von Problemfällen zur Verfügung steht. Er soll die zentrale Koordination und Steuerung sämtlicher Leistungen übernehmen und als Single-Point-of-Contact für den Auftraggeber fungieren.

Folgende Aufgaben werden u.a. wahrgenommen:

 Single-Point-of-Contact für den Auftraggeber

 Angebotserstellung

Seite 34 von 51

[Seite 35]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

 Klärung abrechnungsrelevanter Mengen und Fragen zur Rechnungsstellung sowie weiterer kommerzieller Fragestellungen

 Qualitätsmanagement

 Verantwortung für das Eskalationsmanagement (vgl. Kapitel 2.6) inkl. interner Adressierung und Nachverfolgung der Themen über alle Leistungseinheiten

 Steuerung und Verantwortung der gesamten Leistungen

 Ansprechpartner für den Auftraggeber in allen Leistungspositionen

 Erstellung, Bereitstellung und Erklärung von SLA-Berichten

 Vorbereitung von Meetings und Management-Präsentationen (vgl. Kapitel 2.5)

2.5 Regeltermine

Die geplanten Regeltermine zwischen dem Auftragnehmer und Auftraggeber sind in der nachfolgenden Tabelle aufgeführt. Sie werden unabhängig voneinander jeweils für beide Lose und damit beide Leistungsbereiche durchgeführt.

Änderungen an den bestehenden Terminen sowie die Aufnahme zusätzlicher Termine durch den Auftraggeber sind in Abstimmung mit dem jeweiligen Auftragnehmer während der Vertragslaufzeit möglich. Die Termine werden nicht zusätzlich vergütet. Sie sind mit den angebotenen Pauschalen abgegolten Die Organisation der u.g. Termine liegt im Verantwortungsbereich des jeweiligen Auftragnehmers. Die u.g. Termine finden nach Abstimmung von Auftragnehmer und Auftraggeber als Online-Meeting, hybrides Meeting oder vor Ort bei der Max Planck Information and Technology (MaxIT) in München-Laim statt.

Seite 35 von 51

[Seite 36]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

Seite 36 von 51

[Seite 37]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

Tabelle 9: Regelmeetings

Seite 37 von 51

[Seite 38]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

2.6 Eskalationsverfahren

Eskalationsstufe 1 – Projektleiter-/Servicemanager-Ebene

Die erste Eskalationsstufe stellt eine Eskalation auf Projektleiter-/Servicemanager-Ebene dar und ist sowohl auf Auftraggeber-Seite als auch auf Auftragnehmer-Seite angesiedelt. Ziel dieser Stufe ist eine kurzfristige operative Klärung, Priorisierung sowie die Koordination geeigneter Maßnahmen zur Stabilisierung der Leistungserbringung.

Eskalationsstufe 2 – Operative Eskalation mit Ressourcenzugriff

Diese Eskalation greift unmittelbar bei Fortbestehen oder Verschärfung der Situation und muss auf Auftragnehmer-Seite mit direktem Ressourcenzugriff auf Personalressourcen ausgestattet sein. In dieser Stufe sind aktive Lösungsoptionen unmittelbar zu erarbeiten und deren Umsetzung verbindlich zu steuern. Parallel dazu erfolgt eine Managementeskalation bei der Fachbereichsleitung der IKT.

Eskalationsstufe 3 – Management- und Geschäftsführungsebene

Die dritte und zugleich letzte Eskalationsstufe ist auf Ebene der Abteilungsleitung des Auftraggebers angesiedelt und erfolgt gleichzeitig an die jeweilige Geschäftsführung des Auftragnehmers. In dieser Eskalationsstufe wird die bestehende, vertragliche Zusammenarbeit beziehungsweise Partnerschaft grundsätzlich auf den Prüfstand gestellt.

Im Rahmen der Transition und Transformation wird dem jeweiligen Auftragnehmer ein übergreifender Servicemanager benannt.

2.7 Ort der Leistungserbringung

Die Leistungserbringung kann überwiegend remote erfolgen. In einzelnen Fällen ist jedoch das Arbeiten vor Ort in München notwendig. Die Reise- und Übernachtungskosten an Standorte der MPG in München (inkl. Laim, Martinsried und Garching) werden nicht gesondert vergütet.

Sind zur Wahrnehmung der Aufgaben Reisen an Standorten außerhalb Münchens erforderlich, hat der Auftragnehmer im Voraus vom Ansprechpartner des Auftraggebers unter Angabe der zu erwartenden Kosten die Zustimmung einzuholen.

Sofern der Auftraggeber die Zustimmung erteilt hat, werden diese Kosten dem Auftragnehmer gegen Nachweis gesondert erstattet. Die Erstattung ist in der Höhe analog dem Bundesreisekostengesetz (BRKG) begrenzt. Reisezeiten werden nicht gesondert vergütet.

2.8 Abruf von Leistungen

Der Abruf von Leistungen nach Leistungsart ist unterschiedlich und wird durch unterschiedliche Bedarfsträger ausgelöst.

Seite 38 von 51

[Seite 39]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

Die Beauftragung der Übernahme der Leistungsinhalte zu den Betriebspauschalen und der Transition erfolgt mit Zuschlagserteilung.

Entscheidet sich der Auftraggeber für die Umsetzung eines Projekts oder Changes, so fordert er den jeweiligen Auftragnehmer zur Angebotsabgabe nach Maßgabe dieses Vertrages auf. Der Auftragnehmer erstellt ein Angebot basierend auf den Preispositionen auf Tagespauschalpreisbasis.

Ein Angebot auf Tagespauschalpreisbasis umfasst die Anzahl der für die Leistungserbringung benötigten Tätigkeiten und Rollen der jeweiligen nächsten Phase eines Projekts, sowie die hierfür erforderlichen Mitarbeitertage – basierend auf der zuvor vereinbarten Projektleistungsbeschreibung.

Der Auftragnehmer ist nicht berechtigt vor einer Bestellung aus dem ERP-System des Auftraggebers tätig zu werden.

2.9 Abrechnung

Dieser Abschnitt beschreibt, wie die im Angebot offerierten Preise zur Abrechnung gelangen.

Die Abrechnung der Leistungen erfolgt monatlich. Die im Angebot offerierten Preise, im Rahmen der einzelnen Preispositionen, behalten ihre Gültigkeit. Das für die Abrechnung relevante Mengengerüst bildet die Bedarfsentwicklung des Auftraggebers ab und kann sich während der Vertragslaufzeit ändern. Stichtag zur Abrechnung ist jeweils der Monatserste. Die Zahlung erfolgt nach ordnungsgemäßer Leistungserbringung innerhalb von dreißig (30) Tagen nach Rechnungseingang.

Stichtag zur Feststellung des für die Abrechnung relevanten Mengengerüsts ist immer der 15. des für die Rechnungsstellung einschlägigen Monats. Spätestens bis zu diesem Stichtag muss eine Meldung des Auftragnehmers hinsichtlich des aktualisierten Mengengerüsts bei MPG eingegangen sein.

Für alle Rechnungen gilt:

Die Rechnung muss auf den Rechnungspreispositionen basieren und für den Auftraggeber nachvollziehbar sein. Die zum Zeitpunkt der Rechnungsstellung jeweils geltende gesetzliche Umsatzsteuer wird dem Auftraggeber gesondert ausgewiesen. Die in Rechnung gestellten Beträge sind innerhalb von 30 Tagen nach Eingang der prüffähigen Rechnung zur Zahlung fällig. Die Rechnungsvorgaben des UStG sind einzuhalten.

Rechnungen sind unter Bezug auf Bestellnummer elektronisch einzureichen, soweit das Institut nicht einem anderen Rechnungsweg folgt.

Die Rechnungen auf die Max-Planck-Gesellschaft zur Förderung der Wissenschaften e. V., - Bedarfsträger „NAME MPI/MaxIT“ auszustellen.

Rechnungen für den Bedarfsträger MaxIT sind an die Emailadresse

• invoice-maxit@gv.mpg.de -

einzureichen.

Seite 39 von 51

[Seite 40]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

Sollte das monatliche Reporting ergeben, dass ein Service Level nicht eingehalten wurde, so stimmt der jeweilige Auftragnehmer mit Abgabe seines Angebotes zu, dass die Rechnung für den auf die Feststellung der mangelhaften Leistungserbringung folgenden Monat um den gegebenenfalls kumulierten Betrag der in dieser Vergabeunterlage aufgeführten Pönalen gekürzt wird. Der Auftragnehmer hat diesen Betrag bereits bei der Rechnungserstellung in Abzug zu bringen, anderenfalls ist der Auftraggeber berechtigt, eine entsprechende Rechnungskürzung vorzunehmen. Siehe hierzu Kapitel 1.7.6.

Die Abrechnung erfolgt für Los 1 und Los 2 durch den jeweiligen Auftragnehmer wie folgt:

2.9.1 Abrechnung Los 1

Folgende Preispositionen sind auch im Falle einer Veränderung des Mengengerüsts fix und bleiben unverändert.

Tabelle 10: Fixe Preispositionen Los 1

Folgende Preispositionen sind variabel in Abhängigkeit der jeweils relevanten Mengen.

Tabelle 11: Variable Preispositionen Los 1

Die relevanten Mengen für die variablen Preispositionen werden erstmals zum Stichtag des Monats der erstmaligen Rechnungsstellung ermittelt. Die Abrechnung der variablen Preispositionen erfolgt dann zum Folgemonat des betrachteten Monats. Die Auftragnehmer pflegen jeweils ein zentrales Verzeichnis zur Verwaltung des relevanten Mengengerüsts und informiert den Auftraggeber über die monatlichen Mehrungen/Minderungen im Rahmen des Reportings (vgl. Kapitel 2.10.10).

Seite 40 von 51

[Seite 41]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

Folgende Preispositionen erfolgen auf Abruf und damit nur dann, falls die entsprechende Leistung von MPG beauftragt wird (vgl. Kapitel 2.8).

Tabelle 12: Abruf-Preispositionen auf Tagespauschalpreisbasis Los 1

2.9.2 Abrechnung Los 2

Folgende Preispositionen sind auch im Falle einer Veränderung des Mengengerüsts fix und bleiben unverändert.

Tabelle 13: Fixe Preispositionen Los 2

Folgende Preispositionen sind variabel in Abhängigkeit der jeweils relevanten Mengen.

Seite 41 von 51

[Seite 42]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

Tabelle 14: Variable Preispositionen Los

Die relevanten Mengen für die variablen Preispositionen werden erstmals zum Stichtag des Monats der erstmaligen Rechnungsstellung ermittelt. Die Abrechnung der variablen Preispositionen erfolgt dann zum Folgemonat des betrachteten Monats. Die Auftragnehmer pflegen jeweils ein zentrales Verzeichnis zur Verwaltung des relevanten Mengengerüsts und informiert den Auftraggeber über die monatlichen Mehrungen/Minderungen im Rahmen des Reportings (vgl. Kapitel 2.10.10).

Folgende Preispositionen erfolgen auf Abruf und damit nur dann, falls die entsprechende Leistung von MPG beauftragt wird (vgl. Kapitel 2.8).

Tabelle 15: Abruf-Preispositionen auf Tagespauschalpreisbasis Los 2

2.10 ITSM und Supportprozesse

2.10.1 ITSM Vorgaben des Auftraggebers

Im Rahmen eines ITSM-Projektes wurden bei der MPG zahlreiche Prozesse nach ITIL-Standard unter Berücksichtigung von MPG-Spezifika eingeführt. Die für die Ausschreibung relevanten Informationen sind in den folgenden Abschnitten zusammengetragen.

Die Auftragnehmer beider Lose sind verpflichtet, sich an den Prozessen des Auftraggebers auszurichten und seine internen ITSM-Prozesse gemäß ITIL-Standard zu leben. Im Rahmen der Vertragslaufzeit kann es zu Anpassungen oder Änderungen an den bestehenden Prozessen und Tools bzw. zur Einführung weiterer Prozesse und Tools kommen. Der Auftragnehmer ist verpflichtet, sich auch in diesen Fällen an den Prozessen der MPG auszurichten und, soweit vorhanden, die Schnittstellen an die Tools der MPG anzupassen. Der Auftraggeber verpflichtet sich im Gegenzug, den Auftragnehmern beider Lose die dafür benötigten Informationen und Zugriffe zukommen zu lassen.

Hinweis: Die in den nachfolgenden Kapiteln beschriebenen Anforderungen gelten gleichermaßen für die Auftragnehmer in beiden Losen, jeweils in ihren Leistungsbereichen. Die allgemeine Bezeichnung bezieht sich somit sowohl auf den Auftragnehmer in Los 1 als auch den Auftragnehmer in Los 2.

Seite 42 von 51

[Seite 43]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

2.10.2 Genereller Supportprozess

Die Auftragnehmer beider Lose sind im Rahmen eines Second Level Supports für die Bearbeitung von Tickets in ihrem jeweiligen Aufgabenbereich (vgl. Beschreibung der Lose in Kapitel 1.5 und 1.6) zuständig. Sie übernehmen auch die Kommunikation mit den Herstellern der einzelnen UC-Lösungen (Third Level Support) unter Rückgriff auf die bestehenden Wartungsverträge (vgl. Kapitel 1.5.8, 1.6.3.5 und 1.6.4.5). Daraus ergibt sich folgender genereller Supportprozess:

Abbildung 3: Support Prozess

2.10.3 Supportanforderungen

Die Supportzeiten für beide Auftragnehmer (Los 1 und Los 2) sind von Montag bis Freitag 7:30

• 17:30 Uhr (außer an bundeseinheitlichen Feiertagen). Der jeweilige Auftragnehmer bearbeitet die ihm zugeordneten Tickets im ITSM-Tool (aktuell SAP Solution Manager) des Auftraggebers. Die Bearbeitungszeit beginnt unmittelbar mit Zuordnung des Tickets zu einer Arbeitsgruppe des Auftragnehmers. Dieser ist verantwortlich dafür, die unmittelbare Bearbeitung und die Einhaltung der definierten Service Level (vgl. Kapitel 1.7) sicherzustellen. Bei Bedarf kann der Auftraggeber den Support zusätzlich via Mail und Telefon direkt kontaktiert.

2.10.4 Incident Management

Das Incident Management umfasst den gesamten organisatorischen und technischen Prozess der Reaktion auf erkannte Sicherheitsvorfälle bzw. Störungen. Der jeweilige Auftragnehmer ist im 2nd Level Support zuständig für die Bearbeitung und Lösung von ihm zugewiesenen Incidents, die die Komponenten des UC-Systems im jeweiligen Los betreffen. Dies schließt Support Inhalte aus dem Herstellersupport (3rd Level) mit ein. Darunter fällt eine Unterstützung zur ausreichenden Fehlerisolierung gemeinsam mit dem Kunden, um Probleme zu identifizieren, die im Verantwortungsbereich beauftragter Drittanbieter liegen, Auslösen des Incident-Management-Prozesses mit dem Drittanbieter, Koordination des Drittanbieters bis zur Behebung des Vorfalls, und die Nachverfolgung und das monatliches Reporting der Drittanbieterleistung im Falle einer Incident-Bearbeitung.

Seite 43 von 51

[Seite 44]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

Die Störungsanalyse durch den Auftragnehmer und –behebung erfolgt grundsätzlich remote. Die IT vor Ort unterstützt bei der Fehlerbehebung on-Site auf Anweisung durch den Auftragnehmer. Falls für Störungsanalyse und -behebung keine Remotelösung gefunden werden konnte, wird durch die IT vor Ort ein Technical Consultant angefordert, der nach Aufwand („Time and Material“ – T&M) durch MPG bezahlt wird.

Wird durch den Auftragnehmer im Rahmen des Incident Managements eine Lösung präsentiert, soll als Qualitätssicherungsmaßnahme eine Rückmeldung und Freigabe der präsentierten Lösung durch die IT vor Ort geschehen.

Sollte im Rahmen der Incident Bearbeitung ein Software Problem offensichtlich werden, für das der Hersteller noch keine Lösung präsentiert, hat der Anbieter dieses Problem im Rahmen des Problem Managements zu betreuen, und wenn möglich via Workarounds zu beheben.

2.10.5 Request Fulfillment

Anforderungen aus dem Request Fulfillment gehen als Service Requests beim jeweiligen Auftragnehmer ein. Diese stellen in erster Linie zwischen MPG und dem Auftragnehmer abgestimmte Installs, Moves, Adds und Changes dar (IMAC). Die Abstimmung eines entsprechenden Katalogs der Standard Service Requests erfolgt im Rahmen der Transitionsphase.

2.10.6 Problem Management

Die Auftragnehmer von Los 1 und Los 2 verpflichten sich jeweils zur Durchführung eines Problem Managements mit Aktivitäten, um Störungen proaktiv zu vermeiden oder Lösungen für wiederholt auftretende Incidents mit unbekannter Störungsursache zu finden.

Vom jeweiligen Auftragnehmer wird erwartet, dass der Problem Management Prozess begleitend zum Incident Prozess im ITSM-Tool des Auftraggebers abgebildet wird. Bei problematischen Incidents mit unbekannter Störungsursache wird ein Problem Ticket eröffnet, das zu dem/den auslösenden Incident Ticket/s referenziert wird. Das Problem Ticket hat dabei einen eigenen Lebenszyklus bis eine erfolgreiche Lösung implementiert ist. Unabhängig vom Problem-Status muss der Incident mit schnellstmöglicher Wiederherstellung der Funktion weiterbearbeitet werden und ggf. mit einem Workaround abgeschlossen werden.

Wenn nicht klar ist, in wessen Verantwortungsbereich eine Problemursache liegt, werden die Beteiligten unter Führung des Auftragnehmers kooperativ zusammenarbeiten, insbesondere alle benötigten Informationen/Zuliefertätigkeiten zeitnah zur Verfügung stellen und gegenseitig über den Status der Problembehebung informieren. Workarounds, Maßnahmen und Problembearbeitungen haben in enger Abstimmung mit dem Auftraggeber zu erfolgen.

Im proaktivem Problem Management sind durch die Durchführung von vorbeugenden Aktivitäten Störungen zu vermeiden. Hierzu zählen insbesondere Trendanalysen und die gezielte Beobachtung anfälliger oder stark beanspruchter Komponenten.

Im reaktiven Problem Management werden durch den Auftragnehmer zumindest Prio 1 Incidents mit unbekannter Störungsursache, sowie auf Anforderung des Auftraggebers auch andere Incidents, zur Analyse an das Problem Management übergeben. Das Ergebnis ist dann ein „Known-Error“, der entsprechend zu dokumentieren ist, und für den bis zur Ermittlung einer

Seite 44 von 51

[Seite 45]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

endgültigen Lösung ein Workaround – sofern möglich - zur Verfügung gestellt werden soll. Als Mindestmaß der reaktiven Problembearbeitung gilt die regelmäßige Überprüfung der Knowledge-Base der Hersteller auf relevante „Known-Errors“ die zu Störungen in der Systemlandschaft des UC-Systems führen können, Prüfung der Knowledge-Base der Hersteller auf Lösungen bekannter „Known-Errors“, beispielsweise durch entsprechende Hersteller Release Packages, und Berücksichtigung bekannter Known-Errors im Rahmen des Release Managements.

Bei übergreifenden Problemen ist der Auftraggeber darüber zu informieren. Workarounds, Maßnahmen und Problembearbeitungen haben in enger Abstimmung mit dem Auftraggeber zu erfolgen.

Übergreifend hat der Auftragnehmer ein monatliches Problem Reporting zur Verfügung zu stellen, mit der Anzahl der offenen Problem Tickets und der im Berichtsmonat abgeschlossenen Root Cause Analysen inklusive deren Bearbeitungsdauer.

2.10.7 Release Management

Im Release-Management sind die Auftragnehmer für beide Lose dafür verantwortlich, die Softwarekomponenten der Systeme auf dem aktuellen Stand zu halten und dafür zu sorgen, dass die Interoperabilität zwischen den Systemen dabei nicht beeinträchtigt wird. Dies erfolgt in Absprache mit den IT-Serviceverantwortlichen UC. Die Implementierung neuer Releases und Patches erfordert die Beantragung über einen Change Request und der Freigabe durch den Change-Prozess des Auftraggebers. Der Change Prozess wird dabei durch die IT- Serviceverantwortlichen UC getrieben.

Besonderes Augenmerk sollte sich dabei auf sicherheitsrelevante Patches richten und Patches oder Updates, die bereits bestehende oder potentielle Probleme für das UC-System des Auftraggebers darstellen. Diese müssen möglichst gemäß der SLA dieser Vergabeunterlagen implementiert werden (vgl. Kapitel 1.7.5). Der Release Management Prozess bezieht sich dabei auf alle zentralen wie dezentralen Komponenten, die in dieser Ausschreibung erwähnt sind.

Die Implementierung sicherheitsrelevanter (Security-) Patches gemäß definierter SLA sowie die Implementierung von Patches/Updates, die ein bestehendes Problem beheben gemäß definierter SLA sind im ITSM Paketpreis des Anbieters zu inkludieren, und werden nicht separat als T&M Leistung abgerechnet (vgl. Kapitel 1.5.3 und 1.6.5).

Der jeweilige Auftragnehmer erarbeitet gemeinsam mit dem Auftraggeber einen Release Plan. Im Rahmen der Einspielung werden die Releases, die eine hohe Komplexität hinsichtlich Funktionsänderung und Planungsaufwand aufweisen, als Projekte auf Tagespauschalbasis abgerechnet.

Die Einsteuerung dieser Projekt-Releases erfolgt in Rücksprache mit und durch Freigabe von MPG im Change Advisory Board. Neue Releases werden nach Freigabe durch MPG durchgeführt. Major-Upgrades werden über T&M Leistung abgerechnet (vgl. Kapitel 1.5.4, 1.6.3.2 und 1.6.4.3). Die Einführung neuer Releases wird als Projekt behandelt und der Auftragnehmer hat bei Bedarf einen Projektleiter zur Steuerung aller nötigen Aktivitäten zu stellen.

Seite 45 von 51

[Seite 46]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

Das Einspielen neuer Releases findet außerhalb der regulären Geschäftszeiten statt, um eine Beeinträchtigung der Benutzer zu vermeiden.

Folgende Leistungsinhalte sind bei Bedarf für neue Releases zu liefern:

 Erstellung eines detaillierten Projektplans zu neuen Releases

 Erstellung einer detaillierten To-Do Liste zur Steuerung der Tasks

 Prüfung der Versionsabhängigkeiten aller angeschlossenen UC-Applikationen

 Hochrüstung aller angeschlossenen UC-Applikationen auf den neusten derzeit freigegebenen Versionsstand. Die Lizenzbeschaffung erfolgt durch den Auftraggeber.

 Prüfung der Versionsabhängigkeiten aller angeschlossenen UC-Hardware

 Hochrüstung aller angeschlossenen UC-Hardware auf den neusten derzeit freigegebenen Versionsstand

 Durchführung von Cluster Upgrades

 Funktionstests nach Durchführung der Release-Updates

Der Auftragnehmer hat alle vom Hersteller der Cloudapplikation vorab angekündigten Releases dem Auftraggeber rechtzeitig vor deren Bereitstellung darzustellen, insbesondere hinsichtlich der funktionalen, technischen und betrieblichen Auswirkungen. Gegebenenfalls erforderliche begleitende Maßnahmen erfolgen auf Grundlage der durch den Auftraggeber erteilten Vorgaben und Freigaben.

2.10.8 Monitoring und Event Management

Die Überwachung der UC-Systemkomponenten wird aktuell durch den derzeitigen Auftragnehmer durchgeführt. Das SNMP-basierende Tool erfasst kontinuierlich Systemzustände, Performance- und Kapazitätskennzahlen und Alarme. Über ein frei konfigurierbares Regelwerk werden für definierte kritische Ereignisse (Systemalarme, nicht- Erreichbarkeit von Interfaces, Überschreitungen von Schwellwerten) proaktiv Alarme für das Event Management generiert.

Die zukünftigen Auftragnehmer für Los 1 und Los 2 übernehmen die Leistungen des Monitorings und Event Managements jeweils für ihren Leistungsbereich.

Der aktuelle Auftragnehmer betreibt zurzeit eine eigene Monitoring-Lösung. Die Monitoring Lösung des Auftragnehmers überwacht die zentralen und dezentralen Systemkomponenten mittels ICMP und SNMP. Im Rahmen der Transition wird ein neues Monitoring beim Auftraggeber aufgebaut. Die von MPG gewünschten Monitoring Punkte werden während der Transitionsphase festgelegt und vom jeweiligen Auftragnehmer in den Losen eingerichtet. Zudem leitet der jeweilige Auftragnehmer bei Überschreitung der festgelegten Monitoring Punkte Gegenmaßnahmen im Incident Management oder Change Management ein.

Seite 46 von 51

[Seite 47]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

Rückmeldungen zu eingegangenen Alarmmeldungen erfolgen mit Angabe des Analyseergebnisses und ggf. eingeleiteter Maßnahmen an die IT-Serviceverantwortlichen UC.

Bei Überschreitung der festgelegten Monitoring Punkte erfolgt automatisch die Erstellung eines Incident Tickets im Ticketsystem des Auftraggebers und eine direkte Alarmierung der zuständigen Mitarbeiter des jeweiligen Auftragnehmers.

2.10.9 Change Management

Im Change Management werden sowohl die Requests for Changes als auch die Change Records im ITSM-Tool des Auftraggebers erfasst. Der jeweilige Auftragnehmer ist verpflichtet, selbstständig Änderungsbedarfe an den Services und den betreuten Systemen zu identifizieren und an den Auftraggeber zu kommunizieren. Er ist zusätzlich verpflichtet, im Bedarfsfall und je nach Zuständigkeit die Umsetzung der Changes in Abstimmung mit der IKT der MPG vorzunehmen. Die Zuständigkeiten ergeben sich aus den Servicebeschreibungen. Im Change Advisory Board (CAB) werden die Abstimmungen zwischen dem Auftragnehmer und Auftraggeber durchgeführt. Die Durchführung von Changes sind stets außerhalb der definierten Servicezeiten durchzuführen. Ausschließlich nach Freigabe durch MPG können minderkritische Changes auch während der Servicezeit durchgeführt werden.

2.10.10 Service Level Management

Für die von beiden Auftragnehmern erbrachten Dienstleistungen wird der Auftragnehmer jeweils ein Service Level Management einrichten. Der Auftragnehmer benennt einen dedizierten Service Delivery Manager, der für das Service Level Management verantwortlich ist. Der Service Delivery Manager steht als Eskalationsstufe für Probleme innerhalb der Serviceerbringung zur Verfügung und ergreift Maßnahmen zur kontinuierlichen Serviceverbesserung in Abstimmung mit den IT-Serviceverantwortlichen UC. Zudem leitet er unmittelbar Gegensteuerungsmaßnahmen ein, falls definierte Service Level unterschritten werden.

Zur Einhaltung der Service Level überwacht und erfasst der Auftragnehmer kontinuierlich die SLA relevanten Kennzahlen.

Der Service Delivery Manager berichtet einmal monatlich im Rahmen eines Service Review Meetings über die erzielten Service Level der Berichtsperiode. Das Service Review Meeting findet am Standort des Auftraggebers in München statt (Generalverwaltung). Nach vorheriger Abstimmung mit dem Auftraggeber kann dieses in Einzelfällen auch per Web- oder Videokonferenz abgehalten werden. Dieses Service Review Meetings wird durch den Service Delivery Manager bis zum 15. Arbeitstag des dem Leistungszeitraum unmittelbar folgenden Monats vorbereitet und durchgeführt. In halbjährlichen Turnus findet das Service Review Meeting als Präsenzmeeting mit erweitertem Personenkreis aus dem Management statt. Einmal pro Jahr wird das Service Review Meeting erweitert zum Strategie-Meeting, in dem der Auftragnehmer aktuelle Entwicklungen und Produktstrategien vorstellt.

Als Vorbereitung für das Service Review Meeting stellt der Service Delivery Manager den Service Report bis zum 5. Arbeitstag des dem Leistungszeitraum unmittelbar folgenden Monat in elektronischer Form zur Verfügung. Der Service Report wird im Service Review Meeting durch den Service Delivery Manager vorgestellt, und dessen Messergebnisse gemeinsam mit dem Auftraggeber bewertet. Im Service Report erfasst der Auftragnehmer alle für den Service

Seite 47 von 51

[Seite 48]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

Reports erforderlichen SLA relevanten Kennzahlen, und beurteilt die SLA Einhaltung bzw. etwaige SLA-Verletzungen. In besonderen Fällen, z.B. bei der Behandlung aktueller Krisen oder gravierender Service Level Verletzungen, kann auch die Erstellung eines spezifischen ad-hoc Reports durch den Auftragnehmer auf Anforderung der IT-Serviceverantwortlichen UC erfolgen.

3 Transition / Überleitungsphase (Los 1 und Los 2)

3.1 Übernahme der Leistungsinhalte zu Beginn des Vertragsverhältnisses

Für Los 1 und Los 2 startet die Gesamt-Vertragslaufzeit jeweils mit einer einmonatigen Transition-Phase. Im Rahmen der Leistungsübernahme zu Beginn des Vertragsverhältnisses müssen die Leistungen des bisherigen Auftragnehmers übernommen und entsprechend dem neuen Vertrag transformiert werden. Aufgrund der Transformation auf den neuen Vertrag findet die Transition-Phase auch dann statt, wenn der neue Auftragnehmer identisch mit dem alten Auftragnehmer ist.

3.1.1 Ablauf der Übernahme

Es wird eine Überleitungsphase von einem Monat für den Übergang der Aufgaben vom bisherigen Auftragnehmer und von beteiligten Fachbereichen des Auftraggebers an den neuen Auftragnehmer definiert. Die Überleitungsphase beginnt am 01.01.2027 und endet am 31.01.2027. Die Überleitungsphase wird in Form eines Projektes gestaltet.

Der Auftragnehmer verpflichtet sich dazu, spätestens 5 Werktage nach Zuschlagserteilung einen detaillierten und qualifizierten Projektplan vorzulegen, der die notwendigen Übergaben und Einarbeitungen sowie die zu erzielenden Meilensteine beinhaltet. Der Projektplan muss sich an den Überleitungsphasen orientieren, die Abhängigkeiten hinsichtlich Ressourcen sowie hinsichtlich Tätigkeiten aufzeigen und damit neben den zeitlichen Aspekten auch die Ressourcenplanung und die notwendigen Aufwände darstellen. Dieser Projektplan ist mit dem Auftraggeber abzustimmen und auch in dem Fall zu erstellen, dass der alte und der neue Auftraggeber identisch ist. Die Erstellung des Projektplans wird nicht extra vergütet, sondern ist in der jeweiligen Pauschale für die Transition inkludiert (Los 1: L1_P8, Los 2: L2_P10; vgl. Kapitel 3.1.2).

Die Überleitungsphase untergliedert sich in folgende Unterperioden mit unterschiedlichen Aufgabenverteilungen. Die Phasen 1-3 beschreiben die Phasen für die Überleitung vom alten zum neuen Auftragnehmer und erfolgen sequenziell. Die Phase zur Adaptierung auf den neuen Leistungsumfang erfolgt zeitgleich mit den anderen Phasen:

Phase 1:

Periode, in der Mitarbeiter des Auftragnehmers vom bisherigen Auftragnehmer in die Betreuungsthemen eingewiesen werden. Während dieser Periode trägt noch der bisherige Auftragnehmer die Verantwortung für die korrekte Durchführung der bisher erbrachten

Seite 48 von 51

[Seite 49]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

Leistung. Der Aufgabenumfang richtet sich nach dem Vertrag mit dem bisherigen Auftragnehmer.

Am Anfang dieser Periode wird der bisherige Auftragnehmer dem neuen Auftragnehmer eine aktualisierte Version der für den Betrieb notwendigen Dokumentationen und Betriebshandbücher des Auftraggebers aushändigen. Der bisherige Auftragnehmer wird die Mitarbeiter des Auftragnehmers im Rahmen mehrerer Workshops in die zukünftigen Aufgaben des neuen Auftragnehmers einweisen - jeweils mit Schwerpunkt auf den Besonderheiten der MPG-Umgebung.

Im Anschluss an den Workshop werden die Mitarbeiter des Auftragnehmers in die Durchführung des Tagesgeschäfts der Leistungserbringung durch den bisherigen Auftragnehmer eingeführt („Learning on the job“).

Phase 2:

Die für die Leistungserbringung erforderlichen Informationen, Dokumentationen und Zugangsdaten, die sich beim bisherigen Auftragnehmer befinden, werden dem Auftragnehmer übergeben. Der Auftraggeber kann entscheiden, dass einige Zugangskennungen noch beim bisherigen Auftragnehmer verbleiben, um dessen Unterstützung während dieser Zeit zu erleichtern.

Zu einem zwischen bisherigem Auftragnehmer, dem neuen Auftragnehmer und dem Auftraggeber abzusprechendem Zeitpunkt werden die noch nicht abgeschlossenen Tickets vom bisherigen Auftragnehmer an den neuen Auftragnehmer übergeben.

Zudem findet in dieser Phase die Einarbeitung in die Projekte / Rollouts statt.

Phase 3:

Periode, in der der Auftragnehmer die bisher vom alten Auftragnehmer erbrachte Leistung selbstständig erbringt, bei Bedarf aber noch auf Unterstützung des bisherigen Auftragnehmers zurückgreifen kann. Während dieser Periode trägt der Auftragnehmer bereits die Verantwortung für die korrekte Durchführung dieser Leistung.

Während dieser Periode stehen mehrere Mitarbeiter des bisherigen Auftragnehmers, die alle wesentlichen Kenntnisse für die Betreuung des Verwaltungsnetzes des Auftraggebers besitzen, für Unterstützungsleistungen bei der Übernahme der Leistung zur Verfügung.

Phase zur Adaptierung auf den neuen Leistungsumfang:

In dieser Phase findet der Wissenstransfer für den Betrieb derjenigen Themen statt, die bisher nicht vom alten Dienstleister, sondern vom Auftraggeber betrieben wurden und nun in die Verantwortung des Auftragnehmers übergehen, sofern dies zutrifft. Zusätzlich werden alle Vorbereitungen getroffen, die für die Leistungserbringung an der Schnittstelle zwischen Auftraggeber und Auftragnehmer erforderlich sind.

Die Inhalte werden im Rahmen von mehreren Workshops beim Auftraggeber mit mindestens zwei Mitarbeitern des Auftragnehmers und des Auftraggebers übergeben. Die Durchführung richtet sich nach dem zwischen beiden Parteien abgestimmten Projektplan zur Überleitungsphase. Im Anschluss an die Workshops werden die Mitarbeiter des Auftragnehmers beim Auftraggeber im Tagesbetrieb weiter geschult („learning by doing“).

Seite 49 von 51

[Seite 50]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

Insbesondere folgende Themen (nicht abschließend) sind in dieser Phase zu klären und im Projektplan zu berücksichtigen:

 Definition der benötigten Accounts und Berechtigungen. Insbesondere die Mitarbeiter die einen Remote-Zugang erhalten sollen, müssen aufgrund der Vorlaufzeiten frühzeitig benannt werden

 Einrichtung der Accounts durch den Auftraggeber und ggf. durch den bisherigen Dienstleister

 Einrichtung des Site-to-Site VPN in Zusammenarbeit mit der Netzwerk Abteilung des Auftraggebers.

 Definition der benötigten Accounts, Bearbeitungsgruppen und Berechtigungen in den ITSM-Tools des Auftraggebers

 Definition der benötigten Service Requests inkl. Festlegung der einzelnen Bearbeitungsschritte und zugehörigen Bearbeitungsgruppen

 Einrichtung des Monitorings durch den Auftragnehmer

 Spezifikation der Alarmmeldungen aus dem Monitoring Tool

 Definition des IMAC-Katalogs sowie benötigte Provisionierungsdaten inklusive Format und Übermittlungsmedium.

 Definition Form und Inhalt des Betriebshandbuchs an der Schnittstelle zwischen Auftraggeber und Auftragnehmer.

Alle Erkenntnisse und Ergebnisse aus der Überleitungsphase werden durch den Auftragnehmer systematisch in einem Betriebshandbuch erfasst, das schwerpunktmäßig alle Betriebsprozesse an der Schnittstelle zwischen Auftraggeber und Auftragnehmer beschreibt. Als Grundlage dafür werden die vorhandenen internen Betriebshandbücher, sowie die Systemdokumentation durch den Auftraggeber bzw. den alten Auftragnehmer bereitgestellt.

Der Fortschritt der Service Transition und die Abnahme und Bereitschaftserklärung zur Betriebsübernahme erfolgt maßgeblich auf Basis des Reifegrades dieses Betriebshandbuchs und der darin beschriebenen Prozesse, die in der Phase 3 stichprobenartig überprüft werden.

Der Auftragnehmer übernimmt ab einem festzulegenden Stichtag die komplette Verantwortung für die zu erbringenden Leistungen; bis zum 31.01.2027 kann er noch auf Unterstützung des Auftraggebers und des alten Auftragnehmers zurückgreifen.

Der Zeitpunkt der vollständigen Übergabe der Verantwortung für die Durchführung der Leistung auf den neuen Auftragnehmer ohne Mitwirkungen des alten Auftragnehmers oder des Auftraggebers wird auf den 01.02.2027, 0 Uhr festgelegt.

3.1.2 Vergütung

Die Überleitungsphase wird in Form eines Projektes gestaltet. Die Überleitungsphase vor Beginn der eigenverantwortlichen Leistungserbringung zum 01.02.2027 wird dem jeweiligen neuen

Seite 50 von 51

[Seite 51]

Max-Planck-Gesellschaft zur Anlage A.1 Förderung der Wissenschaften e. V. für das offene Verfahren UC DL 2026

Auftragnehmer nach erfolgreicher Abnahme pauschal vergütet. Die Pauschale ist im Preisblatt in Position L1_P8 für Los 1 und L2_P10 für Los 2 anzugeben.

3.2 Übergabe an einen neuen Auftragnehmer bei Beendigung des Vertragsverhältnisses (Beendigungsunterstützung)

Am Ende der Vertragslaufzeit mit dem Auftragnehmer muss wiederum eine geordnete Übergabe gegebenenfalls an einen neuen Auftragnehmer gewährleistet sein. Durch die nachfolgenden Regelungen soll sichergestellt werden, dass die Übergabe so abgewickelt wird, dass der neue Auftragnehmer dann ohne Nachteile für den Auftraggeber die bisherigen Aufgaben des Auftragnehmers wahrnehmen kann. Der Auftragnehmer verpflichtet sich, bei der Übergabe mit dem neuen Auftragnehmer die benötigten Service Assets (Ressourcen und Fähigkeiten) bereitzustellen. Dies gilt sinngemäß auch für den Fall einer vorzeitigen, z.B. außerordentlichen Beendigung, nach Wahl des Auftraggebers zum Zweck der Überleitung auf den Auftraggeber oder einen Dritten.

3.2.1 Ablauf der Übergabe

Die Übergabeperiode ist zwei Monate lang. Sie beginnt zwei Monate vor Ende der Vertragslaufzeit mit dem Auftragnehmer. Es ist vorgesehen, dass in einer ersten Phase der Übergabeperiode der Auftragnehmer den neuen Auftragnehmer einarbeitet, aber noch die Federführung und die Verantwortung für die korrekte Durchführung der Leistungen im Rahmen des bisherigen Leistungs-umfangs hat. In einer zweiten Phase werden die Informationen, Dokumentationen und Zugangsdaten an den neuen Auftragnehmer übergeben. Anschließend liegen die Federführung und die Verantwortung für die korrekte Durchführung der Leistungserbringung in der Hand des neuen Auftragnehmers. Der Auftragnehmer unterstützt ihn bei der Durchführung und steht zur Verfügung, um den neuen Auftragnehmer bei der Lösung von eventuell auftretenden Schwierigkeiten zu unterstützen.

Zeitgleich zu den drei Phasen zur Übergabe der alten Leistungen unterstützt der Auftragnehmer den neuen Auftragnehmer zu jeder Zeit der Übergabeperiode bei der Adaptierung der alten Leistungen auf die im neuen Vertrag vereinbarten Leistungsinhalte. Der Auftragnehmer hat sich an den Projektplan der Überleitungsphase zu halten.

3.2.2 Vergütung

Die Überleitungsphase an einen neuen Dienstleister zum Ende dieses Vertrages wird dem Auftragnehmer nach nachgewiesenem Aufwand auf Basis der Tagespauschalpreise gem. Preisblatt vergütet.

Seite 51 von 51