02_Leistungsbeschreibung-und-Preisblatt_leuphana-de_ausfüllbar.pdf

[Seite 1]

UNIVERSITÄTSKOMMUNIKATION

LEISTUNGSBESCHREIBUNG:

BETRIEB, WEITERENTWICKLUNG UND PFLEGE LEUPHANA.DE

1. INFRASTRUKTURKONTEXT (GILT FÜR ALLE POSITIONEN)

Die folgende Infrastrukturbeschreibung bildet den technischen Rahmen für alle Positionen des Gesamtauftrages. Sie ist nicht Bestandteil des zu erbringenden Onboardings, sondern Ausgangspunkt und Planungsgrundlage.

Vom Medien- und Informationszentrum (MIZ) der Leuphana Universität bereitgestellt: • Live-VM: Produktivserver des Webauftritts leuphana.de (TYPO3 auf Apache/Linux) • Dev-VM: Entwicklungsserver mit Kapazität für bis zu zehn parallelen Instanzen (Branches, Staging- Umgebungen, Testsysteme) • Git-Dienst auf der Dev-VM: Für das Versionsmanagement wird keine gesonderte Git-Server-VM bereitgestellt. Es bestehen eine Live-VM und eine Dev-VM; Git-Dienst (z. B. Gitea, GitLab CE), Deployment-Pipelines und Entwicklungs-Instanzen betreibt und administriert der Auftragnehmer auf der Dev-VM. • Backups: Vollständige VM-Backups werden durch das Rechenzentrum (MIZ) erzeugt. Zusätzlich werden auf dem Livesystem stündliche Snapshots erzeugt, die situativ angefordert werden können. Diese Leistung obliegt ausschließlich dem MIZ. • VM-Administration: Das MIZ administriert die VMs hinsichtlich Ressourcenzuweisung, Betriebssystem- Updates und Netzwerkkonfiguration. Der Auftragnehmer ist nicht für die Infrastrukturebene (Hypervisor, Netzwerk, OS-Patches) verantwortlich. • Zugänge: Das MIZ richtet SSH-Zugänge und ggf. VPN-Zugänge für externe Dienstleister ein. Der Auftragnehmer koordiniert den Zugangsantrag mit MIZ und Webredaktion.

Verantwortung des Auftragnehmers auf den VMs:

Der Auftragnehmer ist für alle auf den VMs betriebenen Anwendungen verantwortlich: TYPO3-Instanzen, Apache-Konfiguration (soweit für TYPO3 und den Webauftritt erforderlich), Composer-Abhängigkeiten, Deployment-Prozesse sowie den Betrieb des Git-Dienstes auf der Git-Server-VM.

Abgrenzung – nicht Bestandteil des Auftrags:

Die folgenden Leistungen sind kein Bestandteil des Auftrags: • Redaktionelle Arbeiten, Content-Produktion und -Pflege sowie Bildbearbeitung • Erstellung von Redaktionshandbüchern oder Schulungsunterlagen für Redakteure • Durchführung von Redakteursschulungen • Suchmaschinenmarketing (SEM) und Marketing-Kampagnen • DSGVO-rechtliche Prüfungen (Verantwortung des Datenschutzbeauftragten der Hochschule) • Administration der VM-Infrastruktur auf Betriebssystem- und Netzwerkebene (Verantwortung des MIZ) • Vollständige VM-Backups (Verantwortung des MIZ / Rechenzentrums)

[Seite 2]

2

2. POSITION: ONBOARDING

Abschluss Onboarding: Unmittelbar nach Auftragserteilung, sodass Betrieb und Weiterentwicklung ohne Unterbrechung aufgenommen werden können. Abschluss Onboarding bei hergestellter Arbeitsfähigkeit, nachgewiesen durch ein vollständiges Test-Deployment auf die Dev-VM samt übergabefähiger Dokumentation (abnahmefähiger Meilenstein und Zahlungsauslöser) Diese Position ist Grundvoraussetzung für alle anderen Positionen des Gesamtauftrages. Die hier beschriebene Infrastruktur und die in der Bewertungsmatrix geregelten allgemeinen Anforderungen und Ausschlusskriterien gelten für den Gesamtauftrag und sind verbindlich für jede weitere Position.

2.2 Übernahme & Einrichtung der Arbeitsumgebung Der Auftragnehmer plant und koordiniert die Übernahme der bestehenden Betriebsumgebung vom bisherigen Dienstleister und stellt seine eigene Arbeitsfähigkeit vollständig her:

• Übergabetermine: Planung und Durchführung von Übergabegesprächen mit dem Vordienstleister zur Übernahme von Git-Repositories, Deployment-Konfigurationen, Dokumentation, Zugangsdaten und Systemkonfigurationen. • Lokale Entwicklungsumgebung: Einrichtung der internen Entwicklungsumgebung des Auftragnehmers, inkl. lokalem DDEV/Docker-Setup auf Basis der bestehenden Codebasis. • Hinweis (Testumgebung): Die Produktivumgebung läuft auf Apache 2.4.58; die lokale DDEV-Umgebung fährt hingegen nginx. Apache-spezifisches Verhalten (u. a. .htaccess-Regeln, 301-Redirects, staticfilecache) ist daher gegen Apache (Live-/Dev-VM) zu testen, nicht ausschließlich im lokalen DDEV. • Zugänge und Konnektivität: Koordination aller erforderlichen Zugänge mit MIZ (SSH, VPN, Firewall- Freigaben) und Nachweis der Konnektivität zu Live- und Dev-System. • Test-Deployment: Absolvieren mindestens eines vollständigen Test-Deployments auf das Dev-System als Funktionsnachweis der eingerichteten Pipeline. • Pattern-Lab Übernahme: Übernahme und Einrichtung des Pattern-Lab-Systems (Webstyleguide der Universität, www.leuphana.de/styleguide/), das alle Seitentemplates und Inhaltselemente für die Frontendausgabe abbildet. Der Auftragnehmer prüft die lokale Lauffähigkeit und Übereinstimmung mit dem aktuellen Frontend-Stand. • Hinweis (Stand der Frontend-Build-Kette): Die vorhandene Toolchain rund um das Pattern Lab (Pattern Lab 2, Webpack 4, node-sass 4, Node 14) ist vollständig End-of-Life. Für das Onboarding ist die Arbeitsfähigkeit mit dieser Toolchain herzustellen; eine Modernisierung erfolgt bedarfsgetrieben im Rahmen von Service & Support und ist nicht Teil des reinen v13-Upgrades.

2.3 Git-Server & Deployment-Pipelines

• Git-Dienst: Der Auftragnehmer übernimmt die Administration des auf der MIZ-VM betriebenen Git- Dienstes (Benutzer- und Rechteverwaltung, Wartung, Updates). Die Webredaktion erhält Lesezugriff sowie – nach Absprache – eingeschränkte Schreibrechte für definierte Branches. • Deployment-Pipeline Live: Einrichtung und Betrieb einer automatisierten oder halbautomatisierten Deployment-Pipeline für das Produktivsystem, inkl. Cache-Flush, Solr-Reindex-Trigger und Monitoring- Benachrichtigung.

[Seite 3]

3

• Deployment-Pipeline Dev: Einrichtung von Branch-basierten Deploy-Prozessen für das Dev-System (bis zu 10 parallele Instanzen). Die Webredaktion soll nach Einarbeitung eigene Test-Deployments auf dem Dev-System durchführen können; der Auftragnehmer definiert hierfür verbindliche Vorgaben und Abgrenzungen. • Dokumentation: Alle Deployment-Konfigurationen und Zugangswege werden so dokumentiert, dass eine spätere Übergabe an einen Nachfolge-Dienstleister ohne Wissensverlust möglich ist.

2.4 Monitoring & Systemüberwachung

Einrichtung und laufender Betrieb einer Systemüberwachung für Live- und Dev-Umgebung:

• Log-Tracking: Zentrale Erfassung und Auswertung von TYPO3-Fehlerprotokollen und Apache-Logs; proaktive Meldung auffälliger Einträge an die Webredaktion. • Performance-Monitoring: Überwachung von Antwortzeiten und Caching-Verhalten; Schwellenwerte und Alerting definieren. • Verfügbarkeitsüberwachung: Erreichbarkeit von Frontend und Backend; automatische Benachrichtigung bei Ausfall (innerhalb der in der Leistungsbeschreibung definierten Reaktionszeiten, siehe Position „Service & Support"). • Maßnahmenvorschläge: Der Auftragnehmer berichtet der Webredaktion regelmäßig (mind. quartalsweise) über Systemzustand, identifizierte Risiken und empfohlene Optimierungsmaßnahmen.

2.5 Projektmanagement, Ticketsystem & kapazitätsgerechte Steuerung

• Ticketsystem: Der Auftragnehmer richtet ein Ticketsystem ein und betreibt es für die gesamte Vertragslaufzeit. Die Webredaktion wird als Nutzer eingebunden. Alle Service-, Support- und Entwicklungsaufgaben werden ausschließlich über dieses System erfasst, priorisiert und dokumentiert. • Wiki / Technische Dokumentation: Einrichtung eines Wikis (kann Teil des Ticketsystems sein) zur Ablage von Konfigurationsdokumentationen, Entscheidungsprotokollen und Onboarding-Unterlagen. Bei der Entwicklung neuer Funktionen wird zusammen mit der Auslieferung eine technische Dokumentation (Zweck, Einstellungsoptionen, Abhängigkeiten) bereitgestellt. • Regelmäßige Meetings: Der Auftragnehmer initiiert und moderiert ein regelmäßiges Abstimmungsformat mit der Webredaktion (z. B. bi-wöchentlich). Agenda, Ergebnisprotokoll und offene Punkte werden im Wiki festgehalten. • Kommunikationskonventionen: Benennung einer festen Ansprechperson (inkl. Vertretungsregelung), Definition von Erreichbarkeitszeiten und Eskalationswegen.

Kapazitätsgerechte Projektsteuerung

Das AG-seitige Webteam umfasst 3,5 Vollzeitstellen. Die für projektbezogene Mitwirkungsleistungen (Briefing, fachliche Klärung, Review, Test, Abnahme) verfügbare Kapazität beträgt als gleitender Mittelwert 40 Personenstunden pro Woche. Dieser Wert ist ein Orientierungsrahmen für die Projektplanung; die tatsächliche Verfügbarkeit variiert phasenabhängig.

[Seite 4]

4

Der Auftragnehmer ist verpflichtet, seine Projektsteuerung nicht am eigenen maximalen Entwicklungsdurchsatz auszurichten, sondern an dieser Absorptionskapazität des AG-Teams. Im Einzelnen:

• Kapazitätsorientierte Zeitplanung: Projektlaufzeiten und Liefertaktung berücksichtigen den gleitenden Mittelwert der AG-Kapazität als reale Durchsatzbegrenzung. Die Planung macht AG-seitige Engpassphasen sichtbar und schlägt Pufferung oder Umpriorisierung vor. • Kleinteilige Liefereinheiten: Entwicklungsleistungen werden in klar abgegrenzten, prüfbaren Einheiten übergeben. Gebündelte Großlieferungen, die eine punktuelle Überlastung des AG-Teams erzeugen, sind zu vermeiden. • Transparenz über AG-Prüfaufwände: Für jede Liefereinheit werden vorab die erwarteten Prüfschritte, der geschätzte AG-seitige Prüfaufwand und die fachlichen Abnahmevoraussetzungen dokumentiert, damit die Webredaktion ihre Ressourcen vorausschauend disponieren kann. • Eskalationsverfahren: Das Projektmanagement enthält ein definiertes Verfahren für den Fall, dass AG-seitige Rückmeldungen den Zeitplan gefährden — inklusive konkreter Anpassungsoptionen (Umpriorisierung, temporäre Durchsatzreduktion, Vorziehen AG-unabhängiger Aufgaben).

2.6 Controlling & Budgetübersicht Der Auftragnehmer stellt ab Onboarding eine fortlaufende, für die Webredaktion einsehbare Übersicht bereit, die zeigt: • verbrauchtes und reserviertes Zeitbudget nach Position (Service & Support, Upgrade, Entwicklung) • offene und abgeschlossene Tickets mit Zeitaufwand • Prognose der verbleibenden freien Kapazität Format und Aktualisierungsrhythmus werden beim Onboarding gemeinsam mit der Webredaktion festgelegt.

3. POSITION: TYPO3-UPGRADE AUF VERSION 13

Aktueller Stand: TYPO3 12.4.x (LTS), Composer-basiertes SetupZielversion: TYPO3 13.x (LTS)Zielfenster: Ende 2026 / Anfang 2027Repository-Zugang: Wird erst nach Zuschlagserteilung unter der Vertraulichkeitsregelung (siehe Dokument Besondere Vertragsbedingungen Ziffer 2.5) und dem AVV als Read-only-Zugang bereitgestellt.

3.1 Drittanbieter-Extensions (Composer) Der Auftragnehmer aktualisiert alle Drittanbieter-Pakete auf v13-kompatible Versionen. Dazu gehören insbesondere Extensions mit komplexen Upgrade-Pfaden (Apache Solr, EXT:news, powermail, femanager, b13/container, sf_event_mgt). Eine vollständige Übersicht der relevanten Pakete mit Versionsconstraints wird als Analyseunterlage bereitgestellt. Lizenz- und Subskriptionskosten für Drittanbieter-Extensions trägt die Auftraggeberin; der Auftragnehmer kalkuliert ausschließlich den Aufwand für Aktualisierung und Integration.

Der Auftragnehmer führt vor Projektbeginn einen composer dry-run auf der aktuellen Codebasis durch und kommuniziert Abweichungen gegenüber der Analyseunterlage.

[Seite 5]

5

3.2 Custom Extensions – PHP-Migration

Das Projekt umfasst 28 Custom Extensions (Git composer.lock), davon mehrere mit erheblichem Migrationsaufwand. Zu den wesentlichen Aufgaben zählen:

• Migration der SC_OPTIONS-Hooks auf PSR-14-Events, soweit im TYPO3-Kern ein Ersatz-Event besteht (ButtonBar, FlexForm, RecordList). Für die DataHandler-Hooks besteht kein Ersatz im Kern; sie bleiben in TYPO3 13.4 unverändert in Gebrauch. • Migration von XClass-Registrierungen nach Drittanbieter-Updates • Ablösung entfernter APIs (specCharsToASCII(), AbstractPlugin, LocalizationFactory, MarkerBasedTemplateService) • Überprüfung und ggf. Migration von list_type-Registrierungen auf CType-basierte Plugin- Registrierung • Besondere Sorgfalt bei datenschutzrelevanten Funktionen (Hooks, die Datensätze aus Backend-Listen ausblenden oder bei Löschvorgängen aktiv sind)

Der Auftragnehmer erhält eine detaillierte Klassen-Analyse der kritischsten Extension (theme_leuphana) mit Breaking-Change-Dokumentation je Klasse.

3.3 Projektmanagement bei Extensions-Migration und redaktionellen Folgeaufwänden

Der Austausch oder die Neuentwicklung von Extensions kann weitreichende Konsequenzen haben, die über technische Programmierarbeit hinausgehen. Insbesondere dann, wenn Extension-Migrationen Änderungen an der Datenbankstruktur zur Folge haben, die sich nicht vollständig durch Programmierung automatisieren lassen, kann erheblicher manueller redaktioneller Aufwand entstehen — etwa bei der Nachbearbeitung von Inhaltselementen, der Überprüfung von Seitenstrukturen oder der Anpassung von Inhalten, die in geänderten Feldern oder Strukturen gespeichert waren.

Das Projektmanagement des Auftragnehmers hat solche Konstellationen frühzeitig zu erkennen, zu bewerten und in die Projektplanung einzubeziehen. Die Leuphana-Webredaktion muss rechtzeitig informiert werden, damit redaktionelle Mitwirkungsleistungen organisiert und terminlich in die Arbeitsprozesse der Redakteursgruppen integriert werden können. Da ca. 250 aktive Redakteurinnen und Redakteure betroffen sein können, erfordert die Koordination vorlaufende Planung und klare Kommunikation: Welche Inhalte müssen manuell nachgepflegt werden? Wie groß ist der Aufwand je Redakteur? In welchem Zeitfenster ist die Mitarbeit erforderlich?

Der Auftragnehmer legt in seinem Angebot dar, wie er diesen Koordinationsprozess erkennt, bewertet und proaktiv steuert.

3.4 Container-Migration (gridelements b13/container) →

Eine bestehende Custom Extension referenziert tx_gridelements_container-Felder. Der Auftragnehmer migriert die betroffene Logik auf das b13/container-Modell. Die Datenstruktur in tt_content ist dabei einzubeziehen; der Auftragnehmer stimmt das Vorgehen vor Umsetzung mit dem Leuphana-Webteam ab.

[Seite 6]

6

3.5 TypoScript & TCA

Migration aller veralteten TypoScript-Direktiven (u. a. includeJS/CSS, bodyTagCObject, styles.content.get, htmlTag_setParams) sowie TCA-Feldtypen (type=input type=datetime/link/color, eval-Strings, → subtypes_addlist). Der Bestand an Hook- und XClass-Klassen ist in Anlage D dokumentiert; die vollständigen TypoScript- und TCA-Fundstellen ermittelt der Auftragnehmer nach Erhalt des Repository- Zugangs.

3.6 Testing & Qualitätssicherung

• Ausführen aller TYPO3-Upgrade-Wizards (Install Tool) • Der Apache Solr Server läuft bereits in Version 9.10.1 und erfüllt damit die Mindestanforderung für EXT:solr v13; ein Solr-Server-Upgrade ist nicht Teil des Auftrags. Erforderlich bleibt der Wechsel auf ein v13-kompatibles EXT:solr auf Anwendungsebene. Apache Solr läuft auf dem Liveserver und wird vollständig vom Auftragnehmer administriert. Das Access Filter Plugin (aktuell 6.0.0) ist auf Kompatibilität mit der vorhandenen Solr-Version (9.10.1) zu prüfen und ggf. zu aktualisieren. • Regressionstest Frontend: alle Seitentypen, Content-Elemente, Sprachen, Solr-Suche, Events, News • Regressionstest Backend: TCA-Formulare, Scheduler, Redirects, Import/Export • Funktionstest der datenschutzrelevanten Hooks (Nachweis durch Testprotokoll) • Übergabe an Leuphana-Webteam auf Staging-System vor Produktionsdeployment

3.7 Deployment & Kommunikation bei Systemunterbrechungen

Deployment auf Staging mit Abnahme durch Leuphana, anschließend Produktionsdeployment mit Cache- Flush, Solr-Reindex und Monitoring (mind. 24h Nachbeobachtung). Dokumentation aller vorgenommenen Änderungen (Änderungsprotokoll je Extension).

Der Auftragnehmer legt im Angebot dar, für welche Phasen des Upgrades Einschränkungen im laufenden Betrieb zu erwarten sind. Dabei ist konkret zu beschreiben:

• In welchen Phasen können Redakteure keine Inhalte pflegen (Content-Freeze im Backend)? • In welchen Phasen sind Frontend-Funktionen wie Registrierungsprozesse (Veranstaltungsanmeldungen, Formularübermittlungen) nicht verfügbar? • Wie lange dauern die jeweiligen Einschränkungszeiträume voraussichtlich? • Welche Maßnahmen sind geplant, um die Einschränkungen zu minimieren (z. B. Deployment außerhalb der Kernarbeitszeiten)?

Da der Webauftritt von ca. 250 aktiven Redakteurinnen und Redakteuren kontinuierlich gepflegt wird, sind Ausfallzeiten im Backend im Voraus zu kommunizieren. Der Auftragnehmer stimmt Zeitplan und Kommunikationsvorlage mit der Webredaktion ab. 3.8 Abgrenzung – nicht Bestandteil dieser Position

[Seite 7]

7

Durch die Position „Onboarding" abgedeckt (kein gesonderter Aufwand in dieser Position): Einrichtung der Entwicklungsumgebung beim Auftragnehmer, Administration der vom Rechenzentrum (MIZ) bereitgestellten Live- und Dev-VMs, Einrichtung und Betrieb des Git-Servers, Deployment-Pipelines sowie des Projektmanagement- und Ticketsystems. Das Upgrade nutzt die im Onboarding hergestellte Infrastruktur.

Leistungen der Leuphana / des MIZ (keine Auftragnehmerleistung): Vollständige VM-Backups durch das Rechenzentrum der Universität, DSGVO-rechtliche Prüfung durch den Datenschutzbeauftragten der Hochschule.

Von der Leuphana gesondert beauftragt (kein Bestandteil dieser Position): Die Anhebung von leuphana_jobboerse und leu_mystudy_events auf TYPO3 13 sowie das Upgrade von ewpsimodulelist und leuchtfeuer/typo3-mautic-form. Der RAG-/KI-Anteil von leuphana_solr ist ein Testvorhaben des Webteams und nicht Gegenstand des Upgrades. Die Pflege dieser Komponenten im laufenden Betrieb bleibt von der Position Service & Support erfasst.

4. POSITION: SERVICE & SUPPORT (4 JAHRE)

Leistungsart: Laufender Betrieb, Störungsmanagement und bedarfsgetriebene Entwicklung

Vertragslaufzeit: 4 Jahre ab Auftragserteilung Die Leistungen dieser Position gliedern sich in drei funktional verschiedene Ebenen, die im laufenden Betrieb ineinandergreifen. Alle Ebenen werden durch einen einheitlichen Stundensatz und ein gemeinsames Zeitbudget abgedeckt.

4.1 Ebene 1 – Laufender Betrieb

Rollenabgrenzung: Das Leuphana-Webteam administriert TYPO3 auf der organisatorisch-redaktionellen Ebene: Es betreut Redakteurinnen und Redakteure bei der CMS-Nutzung, steuert die Website-Architektur, verwaltet Rechte- und Rollenaccounting und nimmt Problemmeldungen entgegen. Der Auftragnehmer ist für den technischen Betrieb zuständig und sorgt dafür, dass TYPO3 und die zugehörige Systemumgebung optimal laufen. Alle anfallenden Aufwände werden mit der Webredaktion abgestimmt; kostenpflichtige Maßnahmen werden ausschließlich nach Freigabe durch die Webredaktion durchgeführt. Der Orientierungsrahmen für den regulären technischen Betrieb beträgt auf Basis langjähriger Erfahrungswerte 33 Personenstunden pro Monat. Dieser Wert ist ein Planungsrichtwert; der tatsächliche Bedarf kann phasenabhängig variieren.

Zu den dauerhaften technischen Betriebsleistungen des Auftragnehmers zählen: • TYPO3-Administration: Systemwartung, Minor-Updates, Extension-Updates im laufenden Betrieb, Cache-Management, Scheduler-Kontrolle, Fehlerprotokoll-Auswertung • Apache-Konfiguration: Pflege der Webserver-Konfiguration soweit für TYPO3 und den Betrieb des Webauftritts erforderlich (im Rahmen der AN-Verantwortung gemäß Position „Onboarding")

[Seite 8]

8

• Pattern-Lab: Übernahme, Pflege und Weiterentwicklung des Webstyleguides der Universität (www.leuphana.de/styleguide/), der alle Seitentemplates und Inhaltselemente für die Frontendausgabe abbildet • Monitoring & Fehlertracking: Laufende Überwachung von TYPO3-Fehlerprotokollen, Apache-Logs und Performance-Indikatoren; proaktive Meldung auffälliger Einträge an die Webredaktion • Solr-Betrieb: Laufender Betrieb und Pflege des Apache-Solr-Servers (inkl. Access Filter Plugin) auf dem Liveserver; Sicherstellung der Suchfunktionalität • Qualitätsdimensionen: Bei allen Betriebsaufgaben sind die technischen Aspekte von SEO, Barrierefreiheit (WCAG 2.1 AA) und Betriebssicherheit sowie die langfristige Komplexitätsminimierung als Querschnittsanforderungen zu berücksichtigen • Dokumentationspflicht: Alle Konfigurationen, Infrastrukturinformationen und systemrelevanten Entscheidungen werden fortlaufend dokumentiert, so dass eine spätere Übergabe an einen Nachfolge- Dienstleister ohne Wissensverlust möglich ist • Upgrade-Fähigkeit und Release-Beobachtung: Der Auftragnehmer beobachtet die TYPO3-Release- und Support-Zyklen und teilt der Webredaktion spätestens zwölf Monate vor dem Ende des offiziellen Supports der eingesetzten LTS-Version mit, welche Maßnahmen für den Wechsel auf die nachfolgende LTS-Version erforderlich werden und welche Bestandteile des Systems dafür Aufwand erwarten lassen. Er hält die Codebasis upgrade-fähig: Custom Extensions und Anpassungen werden so entwickelt, dass sie einen späteren Versionswechsel nicht erschweren; migrationsrelevante Abhängigkeiten, Hooks, XClasses und Versionsconstraints von Drittanbieter-Paketen werden fortlaufend dokumentiert. Die Durchführung eines weiteren Major-Upgrades selbst ist nicht Bestandteil dieser Position (siehe Abschnitt 4.5).

4.2 Ebene 2 – Störungsmanagement & Reaktionszeiten

Der Auftragnehmer stellt für die gesamte Vertragslaufzeit ein definiertes Störungsmanagement mit verbindlichen Reaktionszeiten bereit. Störungen werden über das Ticketsystem erfasst und nach folgenden Prioritätsstufen bearbeitet:

Definition Reaktionszeit: Reaktionszeit bezeichnet den Zeitraum zwischen Eingang der Störungsmeldung und der ersten qualifizierten Rückmeldung des Auftragnehmers. Diese Rückmeldung muss enthalten: Bestätigung des Eingangs, Angabe dass die Analyse läuft, Einschätzung wann die Lösungsarbeit beginnt sowie eine erste Prognose der voraussichtlichen Lösungszeit. Ziel ist es, der Webredaktion frühzeitig eine belastbare Einschätzung zu ermöglichen, die intern an betroffene Einrichtungen der Hochschule kommuniziert werden kann.

Priorität 1 – Ausfall (Nichterreichbarkeit): Vollständige oder weitgehende Nichterreichbarkeit des Webauftritts (TYPO3-Frontend oder -Backend) oder Ausfall systemkritischer Funktionen (z. B. FAL).

Reaktionszeit: innerhalb von 4 Stunden bei Meldung werktags zwischen 08:00 und 17:00 Uhr. → Bei Meldung außerhalb der Betriebszeiten: Rückmeldung und Aufnahme der Lösungssuche am nächsten → Werktag.

[Seite 9]

9

Priorität 2 – Betriebsproblem: Einschränkungen, die die Arbeitsfähigkeit von Redakteurinnen und Redakteuren bei der Seitenpflege behindern, oder Beeinträchtigungen der Frontend-Ausgabe, die die Nutzbarkeit für Seitenbesucher einschränken.

Reaktionszeit: innerhalb von 24 Stunden (Werktage). →

Priorität 3 – Normalbetrieb: Reguläre Aufgaben und nicht betriebskritische Probleme — darunter auch Störungen der Solr-Suche — die über das Ticketsystem erfasst und in gemeinsamen Abstimmungen priorisiert werden.

Lösungsbereitstellung: innerhalb von 7 Werktagen nach Klärung und Freigabe. → Sicherheitsrelevante Updates:

Erfordern kritische Sicherheitslücken (z. B. in TYPO3-Core, PHP oder eingesetzten Extensions) eine sofortige Maßnahme — etwa das Unterbinden redaktioneller Bearbeitung im CMS oder das Stoppen von Registrierungsprozessen zur Sicherung der Datenkonsistenz — stimmt der Auftragnehmer das Vorgehen kurzfristig direkt mit der Webredaktion ab. Die Umsetzung erfolgt dann mit Priorität, jedoch im Rahmen der regulären Reaktionszeiten. Ein gesonderter Notfalldienst ist dafür nicht vorgesehen.

Kein 24/7-Support: Ein Notfalldienst außerhalb der Betriebszeiten (08:00–17:00 Uhr, Werktage) wird nicht erwartet und ist nicht Bestandteil dieses Auftrags. Hintergrund: Die vom MIZ bereitgestellten VMs werden außerhalb der MIZ- Betriebszeiten nicht administriert; bei Infrastrukturausfällen (Server, Netzwerk, Hypervisor) kann der Auftragnehmer nicht auf die VMs zugreifen und ist auf die Wiederherstellung durch das MIZ angewiesen.

4.3 Ebene 3 – Bedarfsgetriebene Entwicklungsleistungen

Neben dem laufenden Betrieb entstehen im Projektverlauf kontinuierlich Entwicklungsbedarfe, die sich aus universitären Anforderungen ergeben und nicht vollständig vorausplanbar sind. Dazu zählen insbesondere:

• Anpassungen und Erweiterungen bestehender Custom Extensions • Entwicklung neuer TYPO3-Plugins oder Content-Elemente • Neue API-Integrationen und Webservice-Anbindungen • UX-Konzeption und Frontend-Umsetzung neuer Seitentypen oder Inhaltselemente • Server-seitige Konfigurationsanpassungen und Datenbankentwicklung • Sonstige IT-Leistungen, die sich aus dem Betrieb eines komplexen Hochschulwebauftritts ergeben

Diese Leistungen sind nicht separaten Positionen zugeordnet, sondern werden frei aus dem Gesamtbudget disponiert, sobald ein Bedarf durch die Webredaktion freigegeben wird.

Übergang zu Entwicklungsprojekten: Überschreitet ein Entwicklungsauftrag einen Aufwand von mehr als 10 Stunden, wird er als eigenständiges Entwicklungspaket behandelt: mit separatem Stundenrahmen, Briefing, definierten Abnahmekriterien und

[Seite 10]

10

schriftlicher Freigabe durch die Webredaktion. Freigabeentscheidungen werden im wöchentlichen Statusmeeting getroffen; erfordert eine Abstimmung mehr als eine Stunde, wird ein gesondertes Abstimmungsmeeting anberaumt. Der Auftragnehmer legt in seinem Angebot dar, wie er diesen Übergang organisiert. Solche Pakete sind in kompakten, zusammenhängenden Zeitfenstern zu erbringen; Unterbrechungen sollen minimiert werden.

Entwicklungsanteil und Stundenbudget: Der Entwicklungsanteil ist bewusst nicht vorausplanbar und wird frei aus dem Gesamtbudget disponiert. Er bildet nicht selten eine Schnittmenge mit den laufenden Basisstunden (Ebene 1); eine strikte Trennung ist nicht erforderlich. Bieter werden nicht aufgefordert, einen separaten Stundenrahmen für Entwicklungsleistungen zu kalkulieren.

Die Webredaktion entscheidet über Aufwand, Freigabe und Abnahme aller Entwicklungsaufgaben. Kostenpflichtige Leistungen werden ausschließlich nach schriftlicher Freigabe durch die Webredaktion erbracht.

4.4 Strategische AI-Integration (ab TYPO3 v13)

Ab dem abgeschlossenen TYPO3 v13-Upgrade wird erwartet, dass der Auftragnehmer die AI-Integration des Webauftritts aktiv mitgestaltet und weiterentwickelt. Dies ist keine optionale Leistung, sondern Teil der strategischen Betriebsperspektive für die Vertragslaufzeit.

Zu den erwarteten Kompetenzen und Leistungen gehören:

• MCP-Server-Integration: Aufbau und Betrieb eines Model Context Protocol (MCP) Servers für die TYPO3-Installation, der KI-Werkzeuge (z. B. aktuelle LLMs, n8n, Cursor) mit dem CMS verbindet — für interne Workflows der Webredaktion und auch für Themen im öffentlichen Webauftritt (Headless CMS etc.) • RAG-Systeme: Konzeption und Umsetzung von Retrieval-Augmented-Generation-Ansätzen auf Basis des bestehenden Apache-Solr-Setups, die Website-Inhalte als strukturierte Wissensbasis für KI- gestützte Anwendungen nutzbar machen • Automatisierungsworkflows: Integration von Automatisierungstools (z. B. n8n) mit TYPO3 für content- bezogene KI-Workflows (z. B. Content-Aufbereitung, Bulk-Updates, strukturierter Import) • Pure-API-Kompetenz: Da die Elsevier-Pure-API fester Bestandteil der TYPO3-Installation ist (Personenseiten für Forschende), wird Erfahrung mit der Pure-API (aktuell v5.34.2-alpha) und dem Verständnis von Forschungsdatenstrukturen einer Universität als Vorteil eingebracht

KI im Projektalltag — Prozess- und Compliance-Ebene: Erwartet wird darüber hinaus, dass der Auftragnehmer KI-Tools nicht nur für die technische Umsetzung, sondern auch für die Verbesserung der gemeinsamen Projektkommunikation einsetzt. Konkret: Der Auftragnehmer kann dem Leuphana-Webteam strukturierte Prompt-Templates für Support-Anfragen und Entwickler-Briefings bereitstellen, die Leuphana-Konventionen (Corporate Design, TYPO3-Seitenstruktur, Barrierefreiheitsanforderungen) als vorbefüllten Kontext enthalten. Dies reduziert Rückfragen, beschleunigt

[Seite 11]

11

Klärungsrunden und verbessert die Qualität von Entwicklungsaufträgen auf beiden Seiten. Effizienzgewinne sollen als Qualitäts- und Kostenvorteile an den Auftraggeber weitergegeben werden.

Ebenso wird erwartet, dass der Auftragnehmer die datenschutzrechtlichen Implikationen des KI-Einsatzes im Projektalltag erkannt und gelöst hat. Ticketinhalte, Code-Repositories und Systemprotokolle können personenbezogene Daten oder proprietäre Inhalte der Leuphana Universität enthalten. Der Einsatz von Cloud-LLMs durch den Auftragnehmer, bei dem Leuphana-Daten verarbeitet werden, unterliegt dem geschlossenen Auftragsverarbeitungsvertrag (AVV) und den Anforderungen der DSGVO. Der Auftragnehmer legt dar, welche KI-Tools er im Projektalltag einsetzt, welche Datenklassen dabei verarbeitet werden und durch welche technischen oder organisatorischen Maßnahmen (z. B. lokale LLM-Instanzen, EU-gehostete Dienste mit eigenem AVV, Datenanonymisierung) die Compliance sichergestellt wird.

Der Auftragnehmer muss nicht heute über vollständige Produktionsreferenzen in allen genannten Bereichen verfügen — das Thema ist im TYPO3-Umfeld noch im Entstehen. Erwartet wird jedoch eine erkennbare strategische Auseinandersetzung, nachgewiesene Lernkurve und eine substanzielle Darstellung des geplanten Vorgehens für die Vertragslaufzeit.

4.5 Abgrenzung

Durch die Position „Onboarding" geregelt (kein gesonderter Aufwand in dieser Position): Einrichtung der Entwicklungsumgebung, Administration der MIZ-VMs auf Infrastrukturebene, Einrichtung des Git-Servers und der Deployment-Pipelines, Ticketsystem und Projektmanagement-Setup. Leistungen der Leuphana / des MIZ (keine Auftragnehmerleistung): VM-Administration auf Betriebssystem- und Netzwerkebene, vollständige VM-Backups, DSGVO-rechtliche Prüfungen. Bei Infrastrukturausfällen außerhalb der MIZ-Betriebszeiten ist der Auftragnehmer nicht handlungsfähig; Reaktionszeiten gelten erst ab Wiederherstellung des VM-Zugriffs. Künftige Major-Upgrades (kein Bestandteil dieser Position): Die Durchführung eines weiteren Wechsels auf eine nachfolgende TYPO3-Hauptversion nach dem in dieser Ausschreibung beauftragten Upgrade auf Version 13 ist nicht Gegenstand dieses Vertrags und wird gesondert beauftragt. In dieser Position geschuldet bleiben die vorbereitenden Leistungen nach Abschnitt 4.1 — Release-Beobachtung, rechtzeitige Meldung, Erhalt der Upgrade-Fähigkeit und Dokumentation der migrationsrelevanten Abhängigkeiten — sowie Minor- und Maintenance-Releases innerhalb der eingesetzten LTS-Linie.

5. ANLAGENVERZEICHNIS Die Anlagen A–D werden in digitaler Form (PDF, XLSX) mit den Vergabeunterlagen im Vergabeportal zum Download bereitgestellt. Sie bilden die Planungsgrundlage für das Angebot. Detaillierte Systemzugänge (Repository, Staging) werden erst nach Zuschlagserteilung unter der Vertraulichkeitsregelung (siehe Dokument Besondere Vertragsbedingungen) und dem AVV gewährt. Gilt für folgende Anlage Titel Datei Positionen A Systemübersicht: TYPO3-Umgebung, Anlage-A_TYPO3- Onboarding, Extensions, Server-Konfiguration Systemuebersicht.pdf Upgrade, S&S B Drittanbieter-Kompatibilitätsmatrix Anlage-B_TYPO3-v13- Upgrade (v12 v13, Versionsconstraints) Drittanbieter-Kompatibilitaet.xlsx →

[Seite 12]

12

C Custom-Extensions-Analyse (Bestand Anlage-C_TYPO3-v13-Custom- Upgrade an Mechanismen je Extension) Extensions-Analyse.xlsx D Hook- und XClass-Analyse Anlage-D_TYPO3-v13-Hook- Upgrade (SC_OPTIONS, XClass-Register, PSR- XClass-Analyse.xlsx 14-Bezug)

Hinweis: Die Anlagen B–D wurden auf Basis des aktuellen Codestands erstellt und dienen als Planungsgrundlage. Der Auftragnehmer führt vor Projektbeginn einen composer dry-run auf der dann aktuellen Codebasis durch und kommuniziert Abweichungen gegenüber den Analyseunterlagen (vgl. Position TYPO3-Upgrade).

6. PREISBLATT

Alle Beträge in Euro, netto. Es gilt ein einziger, einheitlicher Stundensatz für alle stundenbasierten Leistungen (Onboarding, Service & Support, Weiterentwicklung, künftige LTS-Upgrades); nach Rollen oder Positionen differenzierte Stundensätze sind unzulässig.

A — Vom Auftraggeber gesetzter Vergütungsrahmen (nicht vom Bieter auszufüllen): Maximalbudget (finanzielle Obergrenze, für Gesamtvertragslaufzeit): 280.000 € netto (gesetzt) Onboarding — maximal vergütungsfähiger Stundenrahmen (Deckel): 150 h Service & Support — Basisstunden (Orientierung 33 h/Monat × 48): 1.584 h Referenzstunden für die Preiswertung (Onboarding-Deckel + S&S-Basis): 1.734 h

Da der Webauftritt leuphana.de ein technisch komplexes System mit 28 Custom Extensions, einem aktiven Redaktionsbetrieb von ca. 250 Personen und anspruchsvollen Migrationsaufgaben darstellt, erwartet der Auftraggeber einen Stundensatz, der diese Projektkomplexität und die erforderliche Spezialisierung widerspiegelt. Angebote mit einem Stundensatz unter 110,– € netto können als ungewöhnlich niedrig im Sinne der anwendbaren Vergaberechtsvorschriften eingestuft werden. Der Auftraggeber behält sich vor, in diesen Fällen eine detaillierte Kalkulation anzufordern und das Angebot bei nicht ausreichend begründeter Preisgestaltung vom Verfahren auszuschließen.

B — Preise vom Bieter einzutragen: Einheitlicher Stundensatz für Onboarding und Service & Support (netto): __________ €/h Upgrade TYPO3 v13 — Festpreis (netto): __________ € Onboarding — kalkulierter Stundenaufwand (höchstens Onboarding-Deckel): __________ h