[Seite 1]
IT 019-2026 Offenes Verfahren „Noten- und Zeugnisverwaltungssoftware“
ANLAGE 2.2: MINDESTANFORDERUNGEN AN DAS BE-
TRIEBS- UND EXITKONZEPT
1 ZWECK, ANWENDUNGSBEREICH, ABGRENZUNG
1.1 Das Betriebs- und Exitkonzept dient der betriebsfähigen Nutzung der Lösung im jeweils festgelegten Betriebsmodell sowie der geordneten Transition/Beendigung (Exit) bei Eintritt eines Exit-Ereignisses gem. Teil A Nr. 25.8 (4) der EVB-IT Rahmenvereinbarung oder bei Ablauf der Rahmenvertragslaufzeit bzw. der ggf. darüber hinausgehenden Laufzeit des letzten wirksamen Einzelabrufs. Für WP 1 betrifft dies den On-Premises-Betrieb der zeitlich befristet überlassenen Software beim Auftraggeber; für WP 2 die Bereitstellung und Nutzung der Software als Software-as-a-Service (SaaS).
Die Anforderungen dieser Anlage gelten für beide Betriebsmodelle. Das nach Zuschlag zu erstellende Betriebs- und Exitkonzept ist auf das im Zuschlagsschreiben festgelegte Betriebsmodell auszurichten. Die nachfolgenden Anforderungen sind jeweils insoweit umzusetzen, wie sie für das festgelegte Betriebsmodell und die vertragsgegenständlichen Leistungen einschlägig sind.
1.2 Das Konzept ist als praxisorientiertes Betriebshandbuch und Exit-Playbook zu erstellen. Inhaltlich ist es auf die in dieser Anlage definierten Mindestbestandteile beschränkt. Anlagen (z. B. Checklisten, Software Bill of Materials (SBOM), Exportbeispiele) sind zulässig.
1.3 Das Konzept darf keine abweichenden oder zusätzlichen „Exit-Ereignisse“ definieren; maßgeblich sind ausschließlich die Exit-Ereignisse nach Teil A Nr. 25.8 (4) der EVB-IT Rahmenvereinbarung.
2 MINDESTBESTANDTEILE BETRIEBSKONZEPT (TEIL A)
Das Betriebskonzept enthält mindestens:
2.1 System- und Betriebsübersicht
•
Kurzbeschreibung der Lösung (Komponenten, Versionen, Rollen), der jeweiligen Betriebs- bzw. Bereitstellungsumgebung und der Systemlandschaft einschließlich Abhängigkeiten und Verantwortlichkeiten (WP 1: Betriebsumgebung des Auftraggebers; WP 2: vom Auftragnehmer bereitgestellte SaaS-/Cloudumgebung).
•
Übersicht wesentlicher Schnittstellen/Anbindungen und Datenflüsse (inkl. Authentisierung/SSO, Datenquellen, Export-/Importwege), bei WP 2 einschließlich wesentlicher Datenflüsse zu externen Dienstleistern bzw. Cloud-Diensten und deren Funktion innerhalb der Leistungserbringung.
Mindestanforderungen an das Anlage 2.2 1 | 6 Betriebs- und Exitkonzept
[Seite 2]
IT 019-2026 Offenes Verfahren „Noten- und Zeugnisverwaltungssoftware“
2.2 Betriebsprozesse (Runbooks)
•
Initialbereitstellung/-konfiguration, Deployment und Konfigurationsmanagement einschließlich der jeweiligen Verantwortlichkeiten von Auftraggeber und Auftragnehmer.
•
Rollen-/Berechtigungsverwaltung.
•
Monitoring/Logging einschließlich Zuständigkeiten, bereitgestellter Logs/Metriken, Zugriffsmöglichkeiten, Ablage und Retention; bei WP 2 ist insbesondere darzustellen, welche Verwaltungs- und Datenzugriffe protokolliert werden und welche Protokollinformationen dem Auftraggeber zur Verfügung stehen.
•
Backup/Restore einschließlich Sicherungsumfang, Zuständigkeiten, Restore-Verfahren und Testmöglichkeiten.
•
Störungs-/Incidentprozess inkl. Eskalationspfad (Kontaktwege, Mindestinhalte einer Störungsmeldung).
Die beschriebenen Prozesse sind so zu dokumentieren, dass die jeweils auf Seiten des Auftraggebers wahrzunehmenden Betriebs-, Administrations- und Mitwirkungsaufgaben sowie die Schnittstellen zum Auftragnehmer nachvollziehbar sind.
2.3 Release-/Update-/Patchprozess
•
Beschreibung des Release-/Update-/Patchprozesses einschließlich Bereitstellung bzw. Einspielung, Validierung, Information des Auftraggebers und Rollback, jeweils soweit für das festgelegte Betriebsmodell einschlägig.
•
Anforderungen an Bereitstellung (z. B. Signatur/Integritätsprüfung, Prüfsummen).
•
Hinweis auf alternative Bereitstellungs-, Versorgungs- oder Updatewege, soweit für Restriktionsfälle nach Ziff. 3.4 relevant.
2.4 Lizenzierung, Aktivierung und Bereitstellung
(Betriebskontinuität)
•
Beschreibung der Lizenzierungs-, Aktivierungs- und Bereitstellungslogik einschließlich Abläufen, Abhängigkeiten, erforderlichen Informationen, Accounts, Mandanten/Tenants bzw. Subscriptions sowie Erneuerungs-/Reaktivierungsprozessen, soweit für das festgelegte Betriebsmodell einschlägig.
•
Darstellung eines Notfall-/Fallback-Vorgehens für den Fall, dass lizenz- oder aktivierungsbezogene Mechanismen rechtlich/tatsächlich nicht oder nicht vollständig nutzbar sind (z. B. Offline- oder Ersatzmechanismen), soweit dies nach dem Vertrag geschuldet ist. Ggf. ist darzustellen, wie Offline‑ oder Ersatzmechanismen aktiviert werden können, einschließlich Voraussetzungen und Kontaktpunkten der Hersteller/Reseller.
Mindestanforderungen an das Anlage 2.2 2 | 6 Betriebs- und Exitkonzept
[Seite 3]
IT 019-2026 Offenes Verfahren „Noten- und Zeugnisverwaltungssoftware“
2.5 Drittkomponenten/Komponentenregister (SBOM)
•
Bereitstellung eines Komponentenregisters (SBOM) der für Betrieb, Informationssicherheit und Exit wesentlichen Bestandteile einschließlich relevanter Drittkomponenten; bei WP 2 sind zusätzlich wesentliche externe Dienste sowie Cloud-/Plattformabhängigkeiten anzugeben: anzugeben sind dabei Name, Version, Lizenztyp, Kritikalität (kritisch/nicht kritisch), Bezugs-/Updateweg, jeweils soweit für die betreffende Komponente oder Abhängigkeit einschlägig.
•
Kennzeichnung kritischer Komponenten sowie kritischer externer Dienste und Abhängigkeiten (mindestens: Komponenten, Dienste oder Abhängigkeiten, deren Wegfall die Kernfunktion, Security-Patchfähigkeit, Supportfähigkeit oder Lizenzierungs- /Aktivierungsfähigkeit wesentlich beeinträchtigt).
•
Für als kritisch gekennzeichnete Komponenten oder Abhängigkeiten ist das vorgesehene Vorgehen zur Risikobehandlung und, soweit technisch und rechtlich möglich, ein Fallback- /Weiterbetriebsverfahren zu beschreiben (z. B. Substitution, Mirror, alternative Support- oder Versorgungspfade). Ist eine Substitution technisch oder wirtschaftlich nicht sinnvoll möglich, ist dies entsprechend darzustellen.
3 MINDESTBESTANDTEILE EXITKONZEPT (TEIL B)
Das Exitkonzept enthält mindestens:
3.1 Exit-Ziele
•
Ziele: geordnete Übergabe der für Betrieb/Migration erforderlichen Artefakte, Minimierung von Betriebsunterbrechungen, Sicherstellung der Konfigurations-/Metadatenportabilität.
•
Exit-Maßnahmen begründen keine über die vertraglich geschuldeten Betriebs- und Exit- Leistungen hinausgehenden Verpflichtungen. Die Betriebsverantwortung bis zur Beendigung der jeweiligen Leistungen richtet sich nach dem festgelegten Betriebsmodell und den hierfür geltenden vertraglichen Regelungen.
3.2 Exit-Ablaufplan (in Phasen)
•
Phase 1 (Aktivierung): Benennung Ansprechpartner, Zeitplan, Erstpaket Exit-Artefakte.
•
Phase 2 (Übergabe): Übergabe aller Exit-Artefakte, Durchgehen der Runbooks, Q&A.
•
Phase 3 (Transition-Unterstützung): Unterstützung gemäß Ziff. 5 inkl. Abstimmung mit ggf. Nachfolgeauftragnehmer.
•
Phase 4 (Abschluss): Übergabeprotokoll, Abschlussliste offener Punkte.
Mindestanforderungen an das Anlage 2.2 3 | 6 Betriebs- und Exitkonzept
[Seite 4]
IT 019-2026 Offenes Verfahren „Noten- und Zeugnisverwaltungssoftware“
Hinweis: Bei Eintritt eines Exit-Ereignisses aktiviert der Auftragnehmer unverzüglich die Phase 1 ohne gesonderte Aufforderung. Das „Erstpaket“ umfasst: aktuelle SBOM, System‑/Schnittstel- lenübersicht, Konfigurations‑ und Metadatenexportliste, Lizenz-/Aktivierungs-/Bereitstellungs- übersicht.
3.3 Wissenstransfer
Der Auftragnehmer führt bei Eintritt eines Exit-Ereignisses bzw. bei Abruf der Exitleistungen nach Ziff. 5 zum Ablauf der Vertragslaufzeit die nach Ziff. 5 vorgesehenen strukturierten Über- gabetermine (Workshops) durch und beantwortet Rückfragen im Rahmen der Exit-Unterstüt- zungsleistungen nach Ziff. 5. Inhalte sind auf die für Betrieb bzw. Nutzung und Administration, Patch/Release, Lizenzierung/Aktivierung/Bereitstellung sowie Export und Migration erforderli- chen Informationen zu beschränken.
3.4 Restriktions-/Kontinuitätsfall
Beeinträchtigen rechtliche Restriktionen oder behördliche Anordnungen die Bereitstellung we- sentlicher Leistungsbestandteile (insb. Sicherheitsupdates/Patches, Pflege-/Supportleistungen, SaaS-Leistungen oder Lizenzierungs-/Aktivierungs-/Bereitstellungsmechanismen), beschreibt das Konzept ein praxisnahes Vorgehen (Informationskette, Sofortmaßnahmen, alternative Be- reitstellungs-, Versorgungs-, Update- oder Aktivierungswege), soweit dies nach dem Vertrag geschuldet ist. Das Konzept hat darzustellen, welche gleichwertigen, vertragskonformen Inte- rimsmaßnahmen vorgesehen sind und wie diese, soweit technisch und rechtlich möglich, bin- nen 7 Kalendertagen aktiviert sowie binnen 30 Kalendertagen durch eine vollständige Umstel- lung abgelöst werden können.
4 EXIT-ARTEFAKTE (TRANSFEROBJEKTE)
Bei Eintritt eines Exit-Ereignisses sowie bei Abruf der Exitleistungen nach Ziff. 5 zum Ablauf der Vertragslaufzeit stellt der Auftragnehmer dem Auftraggeber in aktueller Fassung mindestens fol- gende Artefakte bereit (soweit vorhanden und vertragsgegenständlich):
a) System-/Betriebsdokumentation inkl. Runbooks sowie Benutzer-/Administrationshand- buch (mit Versionsstand/Datum). b) SBOM/Komponentenregister inkl. Kennzeichnung kritischer Komponenten und Be- zugs-/Updatewegen. c) Exportliste und Exporte der vertragsgegenständlichen Fach- und Anwendungsdaten des Auftraggebers sowie der für eine Migration erforderlichen Konfigurationen und Metada- ten in einem dokumentierten, strukturierten und marktüblichen maschinenlesbaren Aus- tauschformat; sonstige in der Lösung erzeugte oder verwaltete Artefakte sind bereitzu- stellen, soweit die Lösung dies unterstützt bzw. dies nach der Leistungsbeschreibung geschuldet ist. d) Migrations-/Betriebs-/Deploy-/Rollback-Anweisungen und projektbezogene Skripte/Vor- lagen, soweit erstellt und erforderlich. e) Lizenz-/Aktivierungsübersicht inkl. erforderlicher Abläufe/Abhängigkeiten sowie (soweit geschuldet) dokumentierte Fallback-/Offline-Verfahren.
Mindestanforderungen an das Anlage 2.2 4 | 6 Betriebs- und Exitkonzept
[Seite 5]
IT 019-2026 Offenes Verfahren „Noten- und Zeugnisverwaltungssoftware“
f) Quellcode einschließlich Build-/Deploy-Anweisungen für vertragsgegenständlich erstellte Individualsoftware bzw. Anpassungen, soweit dessen Übergabe nach der EVB-IT Rah- menvereinbarung geschuldet ist; die zugrunde liegende Standardsoftware ist hiervon ausgenommen. g) Bei WP 2: Dokumentation der ordnungsgemäßen Beendigung der SaaS-Bereitstellung einschließlich der nach den vertraglichen Regelungen vorgesehenen Datenlöschung und deren Bestätigung auf Verlangen des Auftraggebers.
Hinweise: Für vom Auftragnehmer bereitgestellte Artefakt-Pakete sind Integritätsnachweise (z. B. Prüfsummen) beizufügen.
Bei WP 1 sind produktive Daten, die ausschließlich in der Betriebsumgebung des Auftraggebers vorliegen, nicht durch den Auftragnehmer herauszugeben; der Auftragnehmer schuldet insoweit die Bereitstellung der vereinbarten dokumentierten Exportverfahren/-werkzeuge und die Unter- stützung nach Ziff. 5.
Bei WP 2 sind die beim Auftragnehmer bzw. in der von ihm bereitgestellten SaaS-Umgebung vorhandenen Daten des Auftraggebers nach Maßgabe von lit. c bereitzustellen. Die Löschung der Daten des Auftraggebers erfolgt erst nach Bereitstellung der geschuldeten Exporte und nach Maßgabe der vertraglich vereinbarten Löschregelungen.
5 EXIT-UNTERSTÜTZUNGSLEISTUNGEN
Exit-Unterstützungsleistungen sind bis zu einem Umfang von 8 Personentagen als Basisleistun- gen zu erbringen; deren Vergütung erfolgt pauschal gem. Anlage 1 (Preisblatt), Pos. 1.9. Der Abruf erfolgt durch den Auftraggeber in Textform; der Auftragnehmer bestätigt Abruf und Ter- mine innerhalb von 4 Werktagen (Mo - Fr). Phase 1 („Aktivierung“) und die Übergabe des Erst- pakets nach Ziff. 3.2 erfolgen unabhängig hiervon gemäß Teil A Nr. 25.8 (4) der EVB-IT Rah- menvereinbarung. Die hierfür erbrachten Leistungen werden auf die vorgenannte Obergrenze von 8 Personentagen angerechnet.
Innerhalb der vorstehenden Obergrenze sind mindestens die folgenden Basisleistungen abzu- decken: Phase-1-Leistungen einschließlich Übergabe des Erstpakets, zwei Übergabe-Work- shops (1. Handover; 2. Abstimmung/Debugging), Unterstützung bei Export und Migration nach Ziff. 4 sowie bei WP 2 bei der geordneten Beendigung der SaaS-Bereitstellung, technische Klä- rungen zur Transition sowie Abstimmung mit einem etwaigen Nachfolgeauftragnehmer. Darüber hinausgehende Leistungen erfolgen ausschließlich aufgrund gesonderter Beauftragung und werden gemäß Anlage 1 (Preisblatt) nach Tages- und Stundensätzen vergütet (Pos. 1.10 und 1.11).
Unbeschadet der Exit‑Unterstützungsleistungen bleiben die vertraglichen Leistungs‑ und Sup- portpflichten einschließlich vereinbarter Reaktions‑/Wiederherstellungszeiten bis zur wirksamen Vertragsbeendigung unberührt. Exit‑Unterstützungsleistungen nach dieser Ziff. 5 sind hiervon abzugrenzen und unterliegen der o. g. Obergrenze.
Mindestanforderungen an das Anlage 2.2 5 | 6 Betriebs- und Exitkonzept
[Seite 6]
IT 019-2026 Offenes Verfahren „Noten- und Zeugnisverwaltungssoftware“
Unabhängig vom Eintritt eines Exit-Ereignisses ist der Auftraggeber berechtigt, ohne hierzu ver- pflichtet zu sein, zum Ablauf der Rahmenvereinbarung, soweit zu diesem Zeitpunkt kein Einzel- abruf fortbesteht, andernfalls zum Ablauf des letzten wirksamen Einzelabrufs, die Exitleistungen gemäß dieser Anlage abzurufen.
6 RECHTE AN INDIVIDUALSOFTWARE UND
ANPASSUNGEN IM EXIT-FALL
Soweit dem Auftraggeber nach Teil A Nr. 25.8 (4) der EVB-IT Rahmenvereinbarung aufschie- bend bedingte Nachnutzungsrechte an vertragsgegenständlich erstellter Individualsoftware oder Anpassungen eingeräumt sind, hat das Exitkonzept die hiervon erfassten Arbeitsergebnisse so- wie die für deren Weiterbetrieb, Fehlerbehebung und Anpassung erforderlichen und nach dem Vertrag herauszugebenden Artefakte auszuweisen. Weitergehende Nutzungs-, Herausgabe- und Weiterverwendungsrechte nach der EVB-IT Rahmenvereinbarung und den einbezogenen EVB-IT AGB bleiben unberührt.
7 AKTUALISIERUNG UND BEREITSTELLUNG
Das Konzept ist bei wesentlichen Änderungen der Lösung, der Betriebs- bzw. Bereitstellungs- umgebung oder kritischer Drittkomponenten unverzüglich zu aktualisieren und dem Auftragge- ber spätestens innerhalb von 14 Kalendertagen nach Eintritt der wesentlichen Änderung in ak- tualisierter Fassung zur Verfügung zu stellen. Jede Fassung ist mit Versionsstand/Datum zu versehen; Änderungen sind in einer Kurz-Änderungshistorie zu dokumentieren. Die aktualisierte Fassung enthält eine Änderungsmatrix (Vorher/Nachher) und Versionsstand/Datum
Mindestanforderungen an das Anlage 2.2 6 | 6 Betriebs- und Exitkonzept