


	Anlage 1 Anforderungen und Vorgaben zur Leistungserbringung

	EU Vergabe AiM Verhandlungsverfahren

ID:	Anlage 1
Erste Vertragspartei:	DB Systel GmbH
Zweite Vertragspartei:	Auftragnehmer - Bietername [Bitte eintragen]
Datum:	30.06.2026
Version:	1.0
Autor:	DB Systel GmbH
Status:	Zur Abstimmung

Instruktionen an die Bieter

Das vorliegende Dokument dient als Antwortvorlage für die Anlage 1 „Leistungsbeschreibung“ im Rahmen des Angebots.

Es ist mit dem Angebot einzureichen und muss ausschließlich unter Anwendung einer der folgenden Vorgehensweisen bearbeitet werden:

Sofern eine Zeile „grau hinterlegt“ ist, ist diese nicht verhandelbar und somit ist in diesen Zeilen auch keine Bearbeitung durch den Bieter erforderlich. Eine Änderung von grau hinterlegten Anforderungen durch den Bieter führt im Rahmen der verbindlichen Angebote zum Ausschluss– siehe hierzu insb. Ziffern 11.4 der Bewerbungsbedingungen und Anhang C2 (Gesamtbewertungsmatrix_AiM) Tabellenblatt Informationen Kriterienkatalog.

Die Zeilen, welche in kursiver blauer Schriftbefüllt sind, enthalten Erläuterungen, Hinweise oder Beschreibungen von Prozessschritten, die keine Anforderungen an den Auftragnehmer sind. In diesen Zeilen ist keine Bearbeitung durch den Bieter erforderlich.

Die nicht grau hinterlegten Bedingungen der Vertragsunterlagen sind verhandelbar in dem Sinne, dass für den Bieter die Möglichkeit besteht, ein vom „Auftraggeberentwurf abweichendes Angebot“ abzugeben.

Zustimmung zu den Vorgaben des Auftraggebers

Die mittleren Spalten dienen dazu, die Zustimmung der Bieter dazu einzuholen, dass sie die Vertragspassage bzw. Anforderung anerkennen. Hat ein Bieter eine Anforderung gelesen, verstanden und stimmt er zu, sie genau wie beschrieben zu erfüllen, so geht er wie folgt vor:

In der mittleren Spalte „(J/N)“ trägt er ein „J“ ein. „J“ steht für „Ja“ und zeigt an, dass der jeweilige Bieter die Anforderung, wie von dem Auftraggeber beschrieben und ausformuliert, vollständig erfüllen wird. In diesem Fall darf er keine weiteren Informationen oder eine Abweichung vom Auftraggeberentwurf in der entsprechenden Zelle der rechten Spalte „Auftragnehmer“ eintragen.

Abweichungen vom Auftraggeberentwurf

Zur Bewertung von durch den Bieter vorgeschlagenen Abweichungen vom Auftraggeberentwurf wird insb. auf Ziffern 11.4 der Bewerbungsbedingungen und Anhang C2 (Gesamtbewertungsmatrix_AiM) Tabellenblatt Informationen Kriterienkatalog. verwiesen.

Möchte der Bieter zu einer (nicht grau hinterlegten) Vertragspassage oder Anforderung ein vom Auftraggeberentwurf abweichendes Angebot abgeben, weil er Änderungswünsche beim Wortlaut hat und/oder einen alternativen Ansatz vorschlägt, hat er wie folgt vorzugehen:

In der mittleren Spalte „(J/N)?“ trägt er den Buchstaben „N“ ein. „N“ steht für „Nein“ und zeigt an, dass der jeweilige Bieter der entsprechenden Anforderung nicht vollumfänglich, wie von dem Auftraggeber beschrieben, zustimmt. Die Anforderung aus der linken Spalte „Auftraggeber“ ist vom Bieter zu kopieren und in die entsprechende Zelle in der rechten Spalte „Auftragnehmer“ einzufügen. Der Bieter muss dann den Wortlaut der Passage entsprechend seines Vorschlags mit angeschaltetem Änderungsmodus ändern. Der Bieter muss sicherstellen, dass die Spalte „Aufragnehmer“ den gesamten Text der ursprünglichen Passage enthält und nimmt dann sichtbar Streichungen oder Änderungen am ursprünglichen Text vor, sodass neben den vorgenommenen Streichungen/Änderungen auch der ursprüngliche Text sichtbar bleibt. Dazu kann er in der Spalte „Auftragnehmer“ ein oder mehrere Worte streichen (im Änderungsmodus) und/oder den gewünschten Wortlaut hinzufügen (im Änderungsmodus).

Den jeweiligen Änderungsvorschlägen optisch nachgeordnet kann der Bieter in der entsprechenden Zelle in der rechten Spalte „Auftragnehmer“ eine kurze Erklärung als Grund für diese Änderungen hinzufügen. Die Erklärung sollte getrennt aufgeführt sein und sich vom korrigierten Text abheben und sollte der vorgeschlagenen Änderungen folgen. Alle Erklärungen der Bieter müssen klar, kurz und angemessen sein. Es dürfen keine Angaben aufgeschoben werden (z.B.: „Der Bieter ABC wird dies gern zu einem späteren Zeitpunkt besprechen“ stellt eine unzulässige Aufschiebung einer Erklärung dar.).

Der Bieter darf die Möglichkeit, Änderungswünsche zu platzieren, nicht dazu nutzen, das gesamte Vergabeverfahren umzuschreiben. Die Identität des Gegenstandes des Vergabeverfahrens muss auch in einem Verhandlungsverfahren gewahrt bleiben. Die von dem Bieter vorgeschlagenen Änderungen werden durch den Auftraggeber gesichtet und bewertet. Hierzu wird nochmal auf die Möglichkeit eines Angebotsausschlusses bei Erreichen der Bewertungsstufe 5 für eine Passage im Rahmen der verbindlichen Angebote hingewiesen – siehe insb. Anhang C2 (Gesamtbewertungsmatrix_AiM) Tabellenblatt Informationen Kriterienkatalog.

Im Falle eines Vertragsschlusses gelten die Formulierungen, auf welche sich Auftraggeber und Bieter im Zuge der Verhandlungen geeinigt haben, in die Vertragsunterlagen aufgenommen und sind vom Bieter im Zuge der Leistungserbringung entsprechend zwingend einzuhalten.

Inhalt

1 Einleitung 6

1.1 Kurzvorstellung Auftraggeber 6

1.2 Ausgangssituation und Leistungsgegenstand 7

1.3 Motivation und Projektziele des Auftraggebers 7

1.4 Funktionen und Leistungen des Auftragnehmers 8

1.5 Eigenleistung des Auftraggebers 10

1.6 Lesehinweise 10

2 Funktionale Anforderungen an die Sofwarelösung [FAN] 10

2.1 Benutzerregistrierung und -anmeldung für die Gesamtlösung 11

2.2 Allgemeine Funktionen 11

2.3 Use Cases / Funktionalitäten 13

2.4 Benachrichtigungssystem 16

2.5 Zusätzliche Funktionen 17

3 Architektur und Schnittstellen [AST] 17

3.1 Beschreibung Ist-Architektur 17

3.2 Anforderungen an die Architektur 19

3.3 Allgemeine Anforderungen an Schnittstellen 26

4 Usability und Dokumentation [UDO] 35

4.1 Barrierefreiheit 35

4.2 Usability 38

4.3 Dokumentation 44

5 Service-Level, Support, Wartung und Fehlerbehebung [SUP] 46

5.1 Verfügbarkeit 46

5.2 Support 49

5.3 Incident-Prioritäten, Reaktionszeiten und Fehlerbehebungszeiten / Wiederherstellungszeiten 50

5.4 Behebung und Dokumentation von Fehlern 51

5.5 Messung und Reporting von Service-Leveln 52

5.6 Kompensation / Auswirkung bei Nicht-Einhaltung der SLA 53

5.7 Allgemeine Anforderungen zu Service-Leveln 54

5.8 Wartung / Weiterentwicklung 54

5.9 Releasenotes 57

6 INtegration, Migration und Test [IMT] 58

6.1 Anforderungen an die Migration 58

6.2 Test 67

6.3 Freigabe/ Freigabeverfahren 73

7 Sicherheitsrelevante Anforderungen [SAN] 75

7.1 Datenschutzanforderungen 75

7.2 Anforderungen an die Informationssicherheit und Authentifizierung 79

7.3 Anforderungen an das geschäftliche Kontinuitätsmanagement (BCM) 94

8 PRODUKT- UND PROZESSBEZOGENE RAHMENBEDINGUNGEN [PPR] 96

8.1 Anforderungen an die Nachhaltigkeit 96

8.2 Regelungen der Zusammenarbeit 98

8.3 Exitmanagement 102

8.4 Produktbezogene Schulung und unterstützende Dienstleistungen 110

Ref #	Auftraggeber	J/N	Auftragnehmer
1	Einleitung
2	Dieses Dokument beinhaltet zum einen die Beschreibung der durch den Auftragnehmer zu erbringenden Leistungen sowie der Funktionalitäten und Anforderungen an die Softwarelösung. Daneben enthält es Regelungen, welche durch den Auftragnehmer im Rahmen der Leistungserbringung einzuhalten sind bzw. für die Zusammenarbeit zwischen Auftraggeber (im nachfolgenden auch AG) und Auftragnehmer (im nachfolgenden auch AN) gelten.
3	Kurzvorstellung Auftraggeber
4	Auftraggeber in diesem Vertrag ist die DB Systel GmbH. Dieses Unternehmen wird in diesem Abschnitt kurz vorgesellt.
5	DB Systel GmbH (nachfolgend auch Auftraggeber oder AG genannt) ist der Digitalpartner der Deutschen Bahn AG und betreut als zentrale IT-Tochter die Digitalisierung des Konzerns. Das Unternehmen bietet ein breites Spektrum an IT-Dienstleistungen, einschließlich Cloud-Services, Softwareentwicklung, IT-Sicherheit und Datenanalysen. Hauptziel von DB Systel ist es, die Effizienz und Leistungsfähigkeit der Deutschen Bahn durch innovative IT-Lösungen zu steigern. Als zentraler IT-Provider und Digitalisierungspartner des DB-Konzerns versorgt sie über ihr Portfolio ihre Konzernpartner mit maßgeschneiderten und innovativen IT-Lösungen.
6	Das Team JiCoTe der DB Systel GmbH bietet die Atlassian Suite Jira, Confluence und Jira Service Management als Service für den Konzern an. Bedingt durch die Abkündigung der Data Center Variante von Atlassian (März 2029) wird in dieser Ausschreibung ein Nachfolgeprodukt gesucht. Ein wichtiger Bestandteil dieser Ausschreibung stellt ebenfalls der Migrationspfad in die SaaS-Lösung dar. Die SaaS Lösung stellt dabei eine Möglichkeit dar, welche alle Anforderungen von unseren Kunden abdeckt.
7	Ausgangssituation und Leistungsgegenstand
8	Die DB Systel stellt heute bereits über sein Portfolio Softwarelösungen im Bereich agiles Projekt- /Workmanagement und Kollaboration allen Konzerngesellschaften der Deutschen Bahn AG zur Verfügung. Eine SaaS Lösung soll auch zukünftig den Konzerngesellschaften über das Portfolio der DB Systel GmbH zur Verfügung gestellt werden, um den vorhanden Service Jira as a Service vollumfänglich zu ersetzen.
9	Die Softwarelösung des Auftragnehmers (nachfolgend auch AN genannt) wird dem AG als Software-as-a-Service (SaaS) bereitgestellt, d.h. der Betrieb der Softwarelösung erfolgt vollständig durch den AN in einer der Cloud-Umgebungen des AN.
10	Die Leistungen, welche nicht Gegenstand der zu erbringende Leistungen des ANs sind und sich in der Hoheit des AG befinden, sind Ziffer 1.5 („Eigenleistungen des Auftraggebers“) zu entnehmen.
11	Motivation und Projektziele des Auftraggebers
12	Durch die Abkündigung der Atlassian On-Prem Lösung, welche im März 2029 stattfindet, ist der DB-Konzern gezwungen eine Nachfolgelösung zu beschaffen und die Migration durchzuführen. Bedingt durch die Cloud Strategie des Konzerns wird eine SaaS-Lösung gesucht.
13	Einsatzzweck der Softwarelösung
14	Operatives Projekt- /Workmanagement und die Umsetzung jeglicher Arbeitsprozesse der DB Konzern Unternehmen, sowie die Unterstützung der Agilität im Konzern.
15	Darstellung einer Kollaborationsplattform sowie tiefgreifende Integration
16	Nutzen der Softwarelösung
17	Das Team der JiCoTe der DB Systel GmbH stellt dem Konzern ein Projekt- /Workmanagement- und Kollaborationssystem, welches dem Konzern als Service angeboten wird.
18	Funktionen und Leistungen des Auftragnehmers
19	Der AN erbringt in diesem Kontext die in diesem Dokument nachfolgend aufgeführten Leistungen. Die Anforderungen an die einzelnen Leistungen sind in diesem Dokument sowie dem Rahmenvertrag und den weiteren Anlagen beschrieben.
20	Der AN stellt die Softwarelösung in der vereinbarten Qualität zur Verfügung und stellt einen Support bereit, sodass die Softwarelösung für den AG zu den - insbesondere in diesem Dokument beschriebenen - Zwecken nutzbar ist. Die Verantwortung für die gesamte Software, das Hosting, die Wartung und alle sicherheitsrelevanten Aspekte, liegt beim AN. Die einzelnen Inhalte sind voll miteinander integriert, d.h. aus Sicht der Anwender nahtlos ineinander übergehend. Die im Kapitel 2 näher beschriebenen fachlichen Funktionalitäten werden durch den AN abgedeckt.
21	Der Auftragnehmer stellt eine kontinuierliche Weiterentwicklung der Softwarelösung, insbesondere Anpassungen an gesetzliche Änderungen, sicher und stellt sie dem Auftraggeber zur Verfügung.
22	In diesem Dokument sind in den folgenden Kapiteln Anforderungen beschrieben, welche der AN bzw. die von ihm bereitgestellte Softwarelösung einhalten bzw. erfüllen müssen. Das „Wie“ bezüglich der Umsetzung einiger dieser Anforderungen ist in den Lösungsdokumenten (Anlage 13 (Lösungsdokumente Hauptanlage) mit Anhang 13.1 beschrieben.
23	Der AN erbringt Dienstleistungen im Rahmen des Migrationsprojekts (siehe Kapitel 6).
24	Der AN bietet Unterstützungsleistungen bei weiteren Umsetzungsprojekten sowie Beratungsleistungen und Schulungsleistungen an. Die grundlegenden Anforderungen hieran sind ebenfalls in diesem Dokument beschrieben, die konkreten Dienstleistungen werden im Einzelvertrag vereinbart.
25	Der AN stellt eine umfangreiche Dokumentation seiner Softwarelösung zur Verfügung, die alle Funktionalitäten ausführlich und transparent beschreibt.
26	Der AN ermöglicht dem AG jederzeit Zugriff auf sein komplettes Produkt-/ Service Portfolio im Bereich Agile integrative Managementsuite, insbesondere weitere Module in Zusammenhang mit der eingekauften Lösung, rund um Planung und Verwaltung der Agile integrative Managementsuite. Sofern Lösungen aus dem Portfolio des AN die Durchführung Agile integrative Managementsuite, unterstützen, können diese Lösungen ebenfalls Bestandteil dieses Vertrages, nach Durchführung eines entsprechenden Change-Request-Verfahrens, werden.
27	Die in den folgenden Kapiteln dieses Dokuments vereinbarten Anforderungen und Vorgaben werden – soweit nicht ausdrücklich anders vermerkt – vom AN im Rahmen der Leistungserbringung eingehalten.
28	Eigenleistung des Auftraggebers
29	Der Auftraggeber selbst führt einige Leistungen durch, welche vom Auftragnehmer nicht als Leistung angeboten bzw. erbracht werden sollen. Der Auftraggeber ist der Single-Point-of Contact für den Auftragnehmer. Folgende Themen liegen bei ihm:
30	Fachliche Betriebsführung: Vollständiger Anwenderbetrieb inkl. Rollen- und Rechteverwaltung
31	First und Second-Level Support innerhalb des Konzerns der Deutsche Bahn AG
32	Beratung und Weiterentwicklung im fachlichen Kontext
33	Lesehinweise
34	Den nachfolgenden Lesehinweis soll die Verständlichkeit und Nachvollziehbarkeit des Dokuments fördern.
35	Gender Disclaimer
36	Aus Gründen der besseren Lesbarkeit wurde im gesamten Dokument durchgängig das generische Maskulinum verwendet. Selbstverständlich sind weibliche, diverse wie auch männliche Personen gleichermaßen angesprochen.
37	Funktionale Anforderungen an die Sofwarelösung [FAN]
38	Benutzerregistrierung und -anmeldung für die Gesamtlösung
39	Die Nutzer dürfen nicht eigenverantwortlich Accounts anlegen. Eine vollumfängliche Steuerung der AD-Gruppen muss gegeben sein.
40	Das System muss Benutzer zu Gruppen zuordnen können. Diese Gruppen müssen über mehrere Active Directory erstellt werden können, die Rechtevergabe muss über OpenID oder SAML erfolgen.
41	Eine Anbindung an verschiedenste Identity Provider muss möglich sein.
42	Es muss technische Konten geben, welche auch als technische Konten ersichtlich sind. Das bedeutet, dass erkennbar sein muss, dass es sich bei dem Konto um keinen natürlichen User handelt.
43	Beschränkungen der Ansichten für unterschiedliche User. User haben besondere Rollen im Unternehmen, da sie weniger oder mehr Berechtigungen erhalten als andere User. Daher müssen die Ansichten dieser Konten so einschränkbar sein, dass sie nur bestimmte Teile oder Aufgabenbereiche sehen können, welche ihren Aufgabenbereichen entsprechen.
44	User-Provisionierung muss Mechanismen zur Deaktivierung und Aktivierung der User beinhalten. Hierdurch ist es möglich, die User nach bestimmten Zeiträumen der Inaktivität zu deaktivieren. Eine automatische Aktivierung des Users ist ebenfalls möglich.
45	Allgemeine Funktionen
46	Die Lösung besitzt eine komplexe Suchfunktion, die auf einer Anfragesprache basiert und mit mehreren Aggregationen arbeiten kann.
47	Die Lösung muss neben einfachen Feldtypen auch berechnete und automatisierte Feldtypen beinhalten. Hierbei muss eine Bearbeitung der Feldtypen mittels einer Maske möglich sein. Diese müssen alle oder als Teilmengen konfigurierbar sein. Zusätzlich muss es auch eine Möglichkeit geben, dass Feldtypen individuell konfiguriert werden können.
48	Die Lösung besitzt eine Kommentarfunktion, sodass die User untereinander kommunizieren können.
49	Dashboards und Boards müssen zur Übersicht der Aufgaben vorhanden sein. Die Daten müssen in einer Übersicht, gruppiert, strukturiert, projektübergreifend, grafisch und gefiltert angezeigt werden. Hierbei muss es ebenfalls die Möglichkeit geben, dass diese Boards spezifisch und individuell konfiguriert werden können.
50	Die unterschiedlichen Use Cases müssen mithilfe mehrerer Prozessabläufe steuerbar, konfigurierbar und abbildbar sein.
51	Die Lösung muss Automatisierungsmöglichkeiten und KI-Funktionalitäten beinhalten. Diese sind durch den AG deaktivierbar.
52	Alle Informationen lassen sich exportieren. Dies ist in verschiedenen Formaten möglich.
53	Die Lösung besitzt ein fachliches Monitoring, das für den AG einsehbar ist.
54	Die Lösung besitzt die Funktion, individuell konfigurierbare Nutzungsbedingungen zu erstellen, die von den Nutzern regelmäßig bestätigt werden müssen (6-12 Monate).
55	Die Lösung besitzt Funktionen zur Archivierung.
56	Die Lösung besitzt einen Mailausgangsserver (SMTP), dieser ist konfigurierbar.
57	Auch Read-Only User müssen sich authentifizieren
58	Das System besitzt Funktionalitäten zur E-Mail-Verschlüsselung (SMIME über Schlüssel im AD).
59	Backups müssen möglich sein. Die Lösung unterstützt mindestens 1 Woche Backup davon mindestens 6 Tage inkrementell sowie 1 Tag Full-Backup.
60	Use Cases / Funktionalitäten
61	Agiles Projekt- /Workmanagement
62	Die Lösung unterstützt das agile Arbeiten (Story Map, Scrum of Scrum, Scale Agile).
63	Ein flexibler Wechsel zwischen den agilen Arbeitsmethoden von Scrum und Kanban ist möglich.
64	SAFe Konstrukte sind abbildbar.
65	Daten-Auswertungsmöglichkeiten in Form von Reportings (Burn-Down-Charts, BI-Funktionalität) sind möglich.
66	Capacity Planung und Roadmap-Planung ist möglich.
67	Metriken zur Bestimmung des Aufwands sind möglich (u.a. Scrum-Poker)
68	Wissensmanagement (Kollaboration)
69	Seiten-Templates können individuell erstellt, angepasst, bearbeitet, verwendet und gespeichert werden.
70	Die Seiten müssen in einer Hierarchie abgebildet werden. Hierbei ist eine dynamische Bearbeitung und Veränderung der Hierarchie möglich.
71	Die Lösung besitzt die Möglichkeit zur Versionierung und eine Änderungshistorie ist ersichtlich.
72	Die Lösung besitzt eine Kennzeichnungsmöglichkeit der Vertraulichkeit/Klassifizierung.
73	Ein Lebenszyklus einer Seite ist erkennbar. Mindestens durch letztes Bearbeitungsdatum, Gültigkeitskennzeichnung oder Flaggen.
74	Es muss die Möglichkeit geben, Verknüpfungsmöglichkeiten oder Verweise zu der Projekt- /Workmanagementkomponente herzustellen. Diese Verbindung besteht Bi-Direktorial.
75	Links auf Seiten können so gesetzt werden, dass die Seiten auch nach Verschiebung zugreifbar sind (shortlinks).
76	Formatierungsmöglichkeiten bestehen in Form von Content, Tabs, Templates
77	Graphische Einbindungsmöglichkeiten bestehen in Form von Tabellen, Diagrammen, @-Mention, Datumsanzeige, Bereichsverwaltung (Text und Tabellen), Bilder, PowerPoint, Word, Excel.
78	Berechtigungen auf Seitenebene sind beschränkbar und nachvollziehbar.
79	Mindestens ein PDF-Export einzelner Seiten ist auf Basis eigener Templates möglich.
80	Ein Veröffentlichungsstatus mit Staging Prozess ist möglich.
81	Die Lösung ermöglicht die parallele Bearbeitung der Seiten durch mehrere Anwender/Users.
82	Kundenportal
83	Eine Zusammenarbeit mit Kunden ohne Lizenzierung muss mit Hilfe eines Portals möglich sein.
84	Es muss mindestens eine E-Mail Schnittstelle oder Portal geben, wo andere Personen ohne Lizenzierung Kontakt mit Agents oder Mitarbeitenden aufnehmen können.
85	Die Lösung besitzt die Möglichkeit zur Hinterlegung von Service Level Agreements.
86	Das Tool muss die Möglichkeit bieten, dass eine Kommunikation stattfindet. Die unterschiedlichen Anfragen werden hierbei mit Anfragetypen und Prozessschritten versehen.
87	Die unterschiedlichen Anfragen können nach Wichtigkeit klassifiziert werden.
88	Es ist eine geordnete Ansicht auf die Daten möglich, hierbei besteht die Möglichkeit, eine Strukturierung und Klassifizierung individuell durchzuführen.
89	Anfragen können in die Projekt- /Workmanagement und Kollaborationskomponente überführt werden, um den integrativen Ansatz zu vervollständigen. Die Anfragen können als Anforderung im Projekt- /Workmanagement abgearbeitet und in den Kollaborationsansatz als Seite hinterlegt werden.
90	Agiles Testmanagement
91	Die Lösung bietet die Möglichkeit zur Anbindung der Funktionalität Testmanagement mindestens über Add-On Erweiterung durch Drittanbieter.
92	Die angebundene Funktionalität Testmanagement muss Metriken zur Automatisierung beinhalten.
93	Erstellen, bearbeiten, durchführen und auswerten von Testfällen ist mittels der Funktionalität Testmanagement möglich.
94	Die Testfälle können in die Projekt- /Workmanagement-Komponente überführt werden.
95	Verwalten von Assets für die Bestandsverwaltung
96	Die hierarchische Verwaltung der Assets ist möglich.
97	Die Assets können über die Projekt- /Workmanagement-Komponente Aufgaben zugeordnet werden.
98	Sehr große Asset Strukturen (bis zu 1,5 Mio Assets) sind ohne Performance Probleme abbildbar.
99	Benachrichtigungssystem
100	Das Lösung bietet die Möglichkeit der Benachrichtigung der Anwender über Veränderungen, die den Anwender betreffen.
101	Eine @-Mention muss durch das System unterstützt werden und den Anwender benachrichtigen.
102	Zusätzliche Funktionen
103	Die Lösung bietet die Möglichkeit zur Anbindung folgender Funktionen mindestens über Add-On Erweiterung durch Drittanbieter:
104	Anpassungsfähigkeit der Lösung mit Hilfe von Scripting muss gewährleistet sein.
105	Auswahl- oder Checkfelder sind vorhanden.
106	Architektur und Schnittstellen [AST]
107	Beschreibung Ist-Architektur
108	Das nachfolgende Schaubild zeigt die aktuelle Systemlandschaft mit der Bestandslösung und den relevanten Umsystemen und Schnittstellen:

Ref #	Auftraggeber	J/N	Auftragnehmer
109	Nachfolgend werden die relevanten Komponenten und Schnittstellen der Ist-Architektur kurz erläutert:
110	API-Weiterentwicklung
111	Schnittstelle ITSM Tools
112	GIT-Anbindung Push-Systeme -> Automatisierung scheitern aufgrund von Schnittstellen
113	Office Integration
114	Anbindung von DOORS und POLARION von Vorteil
115	Microsoft Projekt → Termindatensynchronisation
116	BahnGPT
117	Power BI und Azure
118	Anforderungen an die Architektur
119	Bereitstellung und Betrieb der Lösung als SaaS (Software as a Service)
120	Die Lösung steht inklusive der benötigten IT-Infrastruktur für die Durchführung der Anwendung (Server, Online-Plattform etc.) als SaaS-Dienst zur Verfügung.
121	Alle nötigen Aktivitäten zur Implementierung und Testung von Funktionen werden auf Basis dieser IT-Infrastruktur durchgeführt.
122	Um eine robuste Lösung zur Verfügung zu stellen, werden mindestens die Anforderungen umgesetzt:
123	Der Auftragnehmer betreibt die Lösung redundant in mindestens zwei Rechenzentren. Bei Ausfall eines Rechenzentrums wird die Lösung automatisch im zweiten Rechenzentrum betrieben.
124	Fallen einzelne Funktionen der SaaS-Lösung aus, so betrifft dies jeweils nur isolierte Funktionalitäten. Nicht betroffene Funktionalitäten können ohne Datenverlust und Inkonsistenz weiter benutzt werden.
125	Die Lösung stellt über die folgende Anforderung einen stabilen Einsatz sicher:
126	Funktionale Ausfälle beeinträchtigen die Datenintegrität nicht.
127	Umgebungen / Stages
128	Der Auftragnehmer stellt mindestens folgende Umgebungen / Stages zur Verfügung:
129	Test- und Entwicklungsumgebung
130	Produktivumgebung
131	Die Testumgebung kann als Schulungsumgebung genutzt werden
132	Die Lizenzen für alle Umgebungen mit Ausnahme der Produktivumgebung werden durch den Auftragnehmer kostenfrei zur Verfügung gestellt bzw. die Nutzung dieser Umgebungen ist kostenfrei.
133	Standardarchitektur, Architekturprinzip und Architekturbeschreibung
134	Alle Anforderungen sind vom Auftraggeber als System-Standards ausgelegt, deren Erfüllung über alle Versionen der Vertragslaufzeit hinweg sichergestellt wird.
135	Für die Nutzung von Desktop- und Web-Clients wird das Client/Server Architekturprinzip verwendet. Es darf auf keinen Fall eine monolithische Architektur verwendet werden.
136	Für die Lösung verfügt der Auftragnehmer über eine fachliche Architekturbeschreibung. Diese enthält die fachliche Konzeption der Anforderungen in Bezug auf die Funktionen der beschriebenen Lösung. Sie dokumentiert ausführlich und detailliert jede Anforderung und deren Umsetzung als Programmfunktion. Diese Beschreibung wird dem Auftraggeber auf Anfrage zur Verfügung gestellt.
137	Für die Lösung verfügt der Auftragnehmer über eine technische Architekturbeschreibung. Diese enthält die technische Konzeption mit allen Komponenten und betriebsrelevante technische Angaben. Sie dokumentiert ausführlich und detailliert die Architektur der beschriebenen Lösung und ist dazu geeignet, dass sich Chefarchitekten, Architekturprüfer, Entwickler, Designer oder Release Manager einen Überblick verschaffen können.
138	Skalierbarkeit
139	Die Lösung ermöglicht eine bedarfsgerechte Skalierbarkeit. Hierfür ist sichergestellt, dass bei steigenden Eingabemengen bzw. Verarbeitungsaufwand, die Antwortzeiten für Programmfunktionen oder Algorithmen konstant gehalten werden können
140	Sollten hierfür in besonderen Lastsituationen zusätzliche Ressourcen benötigt werden, stellt die Lösung Mechanismen zur automatischen Skalierung bereit.
141	Die Skalierung erfolgt ohne Betriebsunterbrechung so, dass die zugesicherte Performance bezüglich Benutzer-Frontend und Backend jederzeit zur Verfügung steht und Benutzer nicht durch den Skalierungsprozess eingeschränkt werden.
142	Die Lösung nimmt selbständig eine Skalierung vor, wenn die Anzahl der Schnittstellenaufrufe wächst.
143	Die Lösung stellt im Überlastfall einen hohen Durchsatz von fehlerfrei durchgeführten Aktionen. Die Überlast darf zu Fehlermeldungen und zu Timeouts von Aktionen führen.
144	Daten und Struktur
145	Dokumentation Datenmodell und Erweiterbare Datenstruktur
146	Das zugrunde liegende Standard-Geschäftsdatenmodell, welches alle Geschäftsobjekte auflistet inkl. ihrer Attribute und Beschreibungen wird durch den Auftragnehmer an den Auftraggeber als Dokumentation übergeben.
147	Die Lösung ermöglicht die Definition zusätzlicher, Auftraggeber-spezifischer Attribute in allen Geschäftsobjekten des Systems.
148	Diese Attribute können sowohl in Oberflächen als auch über APIs und Export/Import-Funktionen gepflegt werden.
149	Diese Attribute sind sowohl in Konfiguration als auch im Customizing wie Standard-Attribute nutzbar.
150	Datenverlust und Datenkorruption
151	Die Lösung ist gegen Datenverlust und Datenkorruption infolge technischer Fehler sowie krimineller Angriffe von außen (Cyberangriffe) gehärtet. Dies weist der Auftragnehmer auf Nachfrage des Auftraggebers nach.
152	Die Lösung bleibt unabhängig von der Last stets konsistent.
153	Die Lösung ist in der Lage, den Ausfall einzelner technischer Infrastrukturkomponenten zu verkraften, ohne dass hierbei ein Datenverlust entsteht.
154	Die Lösung unterstützt ein Sperrkonzept, mit dessen Hilfe sich die Konsistenz des Datenbestandes sicherstellen lässt, indem es die gleichzeitige Bearbeitung derselben Daten durch mehrere Benutzer verhindert. Das Sperrkonzept wird für sämtliche Bearbeitungsvorgänge angewendet. Sperrungen wirken sich nur auf die explizit gesperrten Objekte bzw. Objektklassen und nicht auf die damit verknüpften Objekte aus.
155	Mandantentrennung / Datentrennung
156	Der Auftragnehmer stellt eine Datentrennung zwischen den Daten des Auftraggebers und den Daten anderer Kunden sicher. Dies gilt insbesondere bei der Nutzung einer gemeinsamen Infrastruktur.
157	Die Lösung stellt sicher, dass eine Datentrennung und Steuerung der Sichtbarkeit u.a.
158	von unterschiedlichen Geschäftsfeldern des DB Konzerns,
159	von unterschiedlichen Regionen eines Geschäftsfeldes,
160	von unterschiedlichen Zielgruppen,
161	von unterschiedlichen Rollen,
162	oder von unterschiedlichen Abteilungen eines Geschäftsfeldes
163	möglich ist.
164	Benutzer können durch administrative Benutzerrollen des Auftraggebers für den Zugriff auf einen oder mehrere Mandantendaten zugelassen werden.
165	Die Lösung stellt sicher, dass die Sichtbarkeit der Datenfelder den Zugriffsrechten entspricht. Dies bedeutet, dass ein Datenfeld erst gar nicht sichtbar wird, wenn in der entspr. Rolle / in dem entspr. Mandanten keine Datensätze vorhanden sind.
166	Die Lösung stellt sicher, dass Benutzer in Auswahlfeldern entsprechend ihrer konfigurierten Zugriffsmöglichkeiten nur die Auswahlmöglichkeiten sehen, die entsprechend der Zuordnung des Benutzers zu einem bestimmten Mandanten einen Zugriff erlauben (und nicht alle Auswahlmöglichkeiten).
167	Datenanonymisierung und Datenlöschung
168	Die Lösung stellt sicher, dass personenbezogene Daten (alternativ zur Löschung) ereignis- oder zeit-gesteuert bei Bedarf anonymisiert werden können.
169	Die Lösung stellt sicher, dass auf Anwendungsebene gelöschte Daten wie Dateien, Verzeichnisse oder sonstige Objekte nicht mehr zugänglich sind.
170	Dazu existiert eine genaue Beschreibung des Auftragnehmers, wie mit gelöschten Daten umgegangen wird und wie diese und entsprechende Sicherheitskopien (Backups) unkenntlich gemacht werden. Diese wird auf Anfrage zur Verfügung gestellt.
171	Die finale Datenlöschung wird protokolliert und die Log-Dateien durch den Auftragnehmer aus der Lösung extrahiert.
172	Datenqualität
173	Um eine hohe Datenqualität sicherzustellen, beinhaltet die Lösung Funktionen, um folgende Anforderungen umzusetzen:
174	Vermeidung bzw. Minimierung von fehlerhaften Dateneingaben durch die Anwender. Dabei sind sowohl sämtliche Dimensionen bzgl. Datenqualität (v.a. bzgl. Format) wie auch Maßnahmen bzgl. Vollständigkeit (also Pflichtfeld-Markierungen) relevant. Hierzu gehören:
175	Sicherstellung der Qualität händischer Dateneingaben
176	Vermeidung von Eingabefehlern durch Drop-Down-Felder, Checkboxen oder Autovervollständigung
177	Prüfung freier Eingabefelder auf Korrektheit und Plausibilität (z.B. Wertgrenzen)
178	Maßnahmen zum Management der Qualität an den Eingangsschnittstellen
179	Durchführung der gleichen Korrektur- und Plausibilitätsprüfungen, wie im händischen Fall
180	Erkennen und Zurückweisen doppelter und unplausibler Datensätze
181	Protokollierung von Zurückweisungen
182	Handling von Dateninkonsistenzen zwischen verschiedenen Geschäftsobjekten
183	Möglichkeiten zum Erkennen „ähnlicher“ Datensätze
184	Prüfung von Kausalketten
185	Zurückweisungen von Datensätze mit falschen Referenzen auf nicht (mehr) vorhandene Objekte
186	Mindestanforderungen Systemressourcen und Endgeräte
187	Mindestanforderungen Systemressourcen Server
188	Mengengerüst JiCoTe:
189	Skalierbar Projekt- /Workmanagement Lösung bis 50.000 Nutzer
190	Skalierbarkeit Kollaborations Lösung bis 50.000 Nutzer
191	Möglichkeit des Umgangs mit 1.500.000 Assets
192	Allgemeine Anforderungen an Schnittstellen
193	Unterstützung Standard API-Technologien und Standard-Schnittstellen
194	Die Lösung besitzt API-Funktionalitäten (mind. REST), um Schnittstellen von und zu anderen Systemen anbinden zu können.
195	Das Abrufen/ Erstellen/ Bearbeiten und Löschen der Daten ist per API möglich.
196	Der Datenaustausch mittels APIs wird über gängige Datenformate wie XML, JSON oder CSV ermöglicht.
197	Über Standardschnittstellen können Funktionalitäten der Lösung von außen gestartet und somit Prozesse automatisiert ausgeführt werden können. Hierzu zählt das Anstoßen eines Workflows, das Berechnen von Werten oder das Auslösen von Hintergrundcode.
198	Alle APIs erreichen eine Verfügbarkeit von mind. 98,8%.
199	Die APIs können zu üblichen Bedienzeiten ohne Einschränkung der Performance der Benutzer-Oberflächen genutzt werden.
200	Die automatische Skalierbarkeit gemäß Kapitel 3.2.4 greift auch für APIs.
201	Die Lösung macht über die Standard-Schnittstellen (API-Technologie) alle darin gespeicherten Daten und alle Geschäftsobjekte und deren Attribute für Umsysteme zugänglich (CRUD). Die Daten werden aus dem aktuellen Datenbestand der Lösung ermittelt.
202	Bedienoberflächen und API-Aufrufe zeigen Daten mit der gleichen Aktualität an.
203	Alle Aufträge und Datenänderungen, die über Oberflächen der Lösung eingegeben werden können, sind auch per API erstellbar, änderbar und stornierbar.
204	Der Status zu einem Auftrag ist ebenfalls per API abrufbar. Aufträge und Änderungen umfassen beispielhaft Adressänderungen oder Ausstattungsänderungen.
205	Änderungen, die zu inkonsistenten Daten führen würden, werden durch die API mit einer strukturierten, auswertbaren Fehlermeldung quittiert – analog zu Fehlerbehandlungen in einer Benutzeroberfläche.
206	Die Lösung bietet API-Funktionen für administrative Zwecke (z.B. Anlegen von Benutzern).
207	Callbackfunktionalität
208	Die Lösung erlaubt den Aufruf einer REST-API über eine dynamische Konfiguration (ohne zusätzliche Programmierung). Das externe System meldet dazu über einen spezifischen API-Aufruf seinen Wunsch an, dass ihm Änderungen an bestimmten Geschäftsobjekten mitgeteilt werden.
209	Im Falle der Änderung wird das externe System automatisch durch die Lösung informiert. Damit können wechselnde Workflowsysteme ohne Änderungen an der Lösung in den Gesamtprozess integriert werden.
210	Anbieten und Nutzung von SFTP-Schnittstellen
211	Die Lösung bietet Schnittstellen zum Austausch von Dateien an, kann aber auch Dateien auf fremden SFTP-Servern auslesen und dort ablegen können.
212	Für jeden relevanten Schnittstellenpartner ermöglicht die Lösung einen getrennt abgesicherten Austausch.
213	Die Lösung erlaubt es, diese Dateien aus dem eigenen Datenbestand heraus zu erzeugen bzw. in den eigenen Datenbestand integrieren zu können.
214	Die Lösung bietet sowohl die Möglichkeit den Datei-basierten Datenaustausch automatisiert (z.B. zeitgesteuert) durchzuführen oder ihn durch den Benutzer anzustoßen.
215	E-Mail Versand über internen E-Mail-Provider des Auftraggebers
216	Die Lösung stellt sicher, dass für den Versand von E-Mails ein Mailservice des Auftraggebers konfiguriert werden kann.
217	Authentifizierung und Schutz vor unerlaubten Zugriffen
218	Alle Schnittstellen werden durch Authentifizierungs- und Autorisierungsverfahren vor unerlaubten Zugriffen geschützt. Mögliche Verfahren sind z.B., abhängig vom konkreten Anwendungsfall, „Basic Authentication“, JWT, Bearer Token.
219	Die Lösung ist in der Lage, die Authentifizierung/Autorisierung von technischen Nutzern gegen zentrale Verzeichnisdienste (z.B. Microsoft Azure Active Directory (Azure AD)) des Auftraggebers zu nutzen.
220	Die Lösung ist in der Lage, die Authentifizierung/Autorisierung von technischen Nutzern durch SSO mit aktuellen Protokollen (SAML / OAuth 2.0 / OIDC) gegen zentrale Verzeichnisdienste des Auftraggebers für eingehende und ausgehende Schnittstellenaufrufe zu nutzen. Zusätzlich ist eine separate Kennwort-Authentifizierung erforderlich.
221	Die Lösung ermöglicht eine Zwei-Faktor-Authentifizierung bei API-Aufrufen.
222	Beim Zugriff auf die APIs der Deutschen Bahn kann die Lösung mit rollierenden Credentials (bspw. durch wechselnd eingesetzte Credentials-Paare) umgehen, so dass der API-Betrieb nicht unterbrochen wird.
223	Die Lösung kann Credentials aus einem Credentials Store der Deutschen Bahn automatisiert über eine API
224	Ankündigung Anpassungen an Schnittstellen und Release-Abwärtskompatibilität
225	Der Auftragnehmer kündigt die Änderung einer API / Schnittstelle mindestens drei Monate im Voraus an.
226	Die Lösung stellt sicher, dass die Abwärtskompatibilität von Schnittstellen zu Fremdsystemen unterstützt und ermöglicht wird Releases (aller Art), wenn von dem Auftraggeber keine Änderungen an den Schnittstellen oder Schnittstellen(-Web-)Services gefordert wurden, sind weiterhin abwärtskompatibel.
227	Es wird mindestens, ausgehend von der Hauptversion „n“, die Hauptversion „n-1“ unterstützt.
228	Änderungen werden in der Dokumentation der Software sowie in den Releasenotes vollständig dokumentiert.
229	Definition und Dokumentation aller Schnittstellen
230	Der Auftragnehmer verfügt über eine ausführliche Definition und Dokumentation der im Standard enthaltenen Schnittstellen (APIs und Massendatenschnittstellen), aller Webservices sowie sonstiger Schnittstellen und stellt diese dem Auftraggeber bei initialer Lieferung und anschließend auf Anfrage bereit.
231	Unter anderem sind diese Inhalte in der Dokumentation aufgeführt:
232	Technische Parameter: Endpunkte, Sicherheitsprotokolle, Datenformate (z.B. XML, JSON, CSV inklusive Zeichensatz)
233	Dateninhalte: Namen und Beschreibung der Felder und Strukturen, Bezug zu den Geschäftsobjekten, Wertgrenzen, Beispielinhalte
234	Rahmenbedingungen zum Einsatz der Schnittstelle: Paginierung, Mengengrenzen, Fehlercodes, Muss- und Kann-Felder
235	Übersicht: Alle Felder und Strukturen werden in Form eines Daten- oder Geschäftsobjektmodells zueinander in Bezug gesetzt. Die Übersicht dient auch als Glossar, um die genutzten Begriffe zu verstehen und Nachschlagen zu können.
236	Der Auftragnehmer stellt die Aktualisierung der Dokumentation nach jedem Update bzw. jeder Änderung sicher.
237	Die Schnittstellendokumentation für REST-Schnittstellen werden im Swagger Format und für SOAP-Schnittstellen im WSDL Format geliefert.
238	Anforderungen zu Operationen der Schnittstellen
239	Schreibende Operationen in Richtung der Lösung verhalten sich grundsätzlich idempotent.
240	Fehlerhafte Operationen per HTTP werden durch den entsprechenden HTTP Statuscode beantwortet.
241	Schreibende Operationen aus Sicht der Lösung in ein anderes System bzw. Synchronisationsvorgänge der Lösung mit anderen Systemen weisen eine Fehlerbehandlung auf, die sicherstellt, dass es zu keinem Datenverlust kommt, falls eine Operation fehlschlägt.
242	Ist ein Zielsystem längere Zeit nicht erreichbar bzw. scheitert eine Operation dauerhaft, wird ein Eskalationsmechanismus ausgelöst (z.B. Mail oder SMS an Administratoren o.ä.).
243	Monitoring und Logfiles
244	In der Lösung ist ein Monitoring für die Zugriffe auf die Schnittstellen vorhanden. Im Monitoring wird aufgeführt, wenn eine Schnittstelle nicht verfügbar ist.
245	Die in der Lösung vorhandenen Monitoring-Informationen und Protokollierungs-Informationen der Schnittstellen sind in Near-Realtime ausleitbar.
246	Die Lösung stellt sicher, dass Logfiles in einem Datei-Format, mindestens in TXT oder CSV, durch definierte Benutzer (fachliche Betriebsführung) lesbar exportiert werden können.
247	Die Lösung stellt sicher, dass die fachliche Betriebsführung des Auftraggebers Zugriff auf das Monitoring der Schnittstellen und auf die Protokollierung der Schnittstellenzugriffe hat.
248	Integrierbarkeit externer Systeme und Schnittstellen für Import
249	Die Lösung ist dazu in der Lage, externe Systeme in seine Abläufe zu integrieren.
250	Die API des externen Systems kann dazu z.B. aus einer Benutzerbedienung her direkt aufgerufen werden.
251	Die Lösung benutzt dazu REST als Aufrufstandard und kann darüber eigene Daten im JSON-Format an das externe System schicken und Antworten im JSON-Format interpretieren. Die erhaltenen Daten werden dann in weiteren Verlauf durch die Lösung zur Aktualisierung der Geschäftsobjekte verwendet. Die Fähigkeit ist sowohl im Batchbetrieb aber insbesondere auch in dialogorientierten Prozessen nutzbar.
252	Die Lösung ermöglicht, dass ein Datei-Import im (Datei-) Format CSV mit den Daten des Auftraggebers in die Software eingespielt werden kann.
253	Versionierung von Schnittstellen zu Fremdsystemen
254	Die Lösung stellt sicher, dass die Versionierung von Schnittstellen zu Fremdsystemen unterstützt und ermöglicht wird.
255	Schnittstellen der Veröffentlichung zu Fremdsystemen werden zum Zwecke der Entkopplung der Anwendungen versioniert und die Gültigkeit der einzelnen Versionen wird vermerkt.
256	Änderungen werden in der Dokumentation der Lösung sowie in den Releasenotes vollständig dokumentiert.
257	Wiederwendbarkeit und Versionierung von Webservices
258	Der Auftragnehmer stellt sicher, dass Webservices der der Lösung derart standardisiert sind, dass einzelne Webservices innerhalb und außerhalb des Systems wiederverwendet werden können und die Abhängigkeiten zwischen einzelnen Webservices minimal sind.
259	Die Lösung stellt sicher, dass die Versionierung von Webservices unterstützt und ermöglicht wird.
260	Erweiterbarkeit von Schnittstellen für zukünftige Anforderungen
261	Die Lösung stellt sicher, dass die Erweiterbarkeit von Schnittstellen (zu Fremdsystemen) für zukünftige Anforderungen möglich ist.
262	Dies schließt auch Schnittstellen mit ein, die auf Webservices basieren.
263	Der Auftragnehmer ist dazu bereit, die Schnittstellen nach den Anforderungen und Vorgaben des Auftraggebers entsprechend anzupassen und zu erweitern. Hinweis: Eine Beauftragung erfolgt nicht im Rahmen der Vergabe, sondern bei Bedarf nachgelagert und ist daher nicht im Rahmen dieser Ausschreibung im Preisblatt berücksichtigt worden. Eine Beauftragung erfolgt zu den im Rahmenvertrag vereinbarten Tagessätzen oder als Festpreis.
264	Falls eine Schnittstelle nicht angepasst werden kann, macht der Auftragnehmer Vorschläge, die zu einer Umsetzung der Anforderungen des Auftraggebers führen (z.B. Uploadmöglichkeiten schaffen, falls fachlich sinnvoll).
265	Exportfunktion und Importfunktion für Massendaten
266	Die Lösung bietet die Möglichkeit an, alle Geschäftsobjekte und deren Historie als Massendaten aus der Lösung zu extrahieren.
267	Über geeignete Technologien stellt die Lösung einen ausreichenden Durchsatz sicher, um auch den vollständigen Datenbestand inklusive Änderungshistorie an maximal einem Wochenende in die Systeme des Auftraggebers in der AWS-Cloud zu übertragen.
268	Die Lösung stellt übliche Filter zur Eingrenzung auf Geschäftsobjekttypen (z.B. Planung) und Zeiträume (z.B. aktuelles Jahr) bereit, so dass auch Delta Abzüge ermöglicht werden.
269	Massendaten sind automatisiert abrufbar, indem z.B. eine Datenbankanbindung oder ein Streaming der Daten angeboten wird.
270	Die Lösung unterstützt den konfigurierbaren Import von Massendaten ähnlich zum Export.
271	Darüber lassen sich sowohl Änderungen als auch Ergänzungen des Datenbestandes durchführen. Diese sind u.a.:
272	Initiale Migration der Bestandsdaten
273	Relevante Änderungen bei Umstrukturierungen von Gesellschaften
274	Änderungen von Kostensätzen
275	Schnittstellen
276	Anbindung an Office 365 (ggf. über Add-On oder Drittanbieter)
277	Anbindung an Gitlab (ggf. über Add-On oder Drittanbieter)
278	Usability und Dokumentation [UDO]
279	Barrierefreiheit
280	Die Softwarelösung stellt sicher, dass die WCAG Richtlinien (Web Content Accessibility Guidelines) in der mindestens Version 2.1 des W3C eingehalten werden können. Hierbei wird mindestens die Konformitätsstufe „AA“ erreicht.
281	Die Barrierefreiheit der Softwarelösung berücksichtigt, abhängig vom Nutzungskontext, die Erfordernisse der folgenden Nutzergruppen:
282	Menschen ohne Sehvermögen
283	Menschen mit eingeschränktem Sehvermögen
284	Menschen ohne Farbwahrnehmung
285	Menschen ohne Hörvermögen
286	Menschen mit eingeschränktem Hörvermögen
287	Menschen ohne Sprachvermögen
288	Menschen mit eingeschränkter Handhabung oder Kraft
289	Menschen mit eingeschränkter Reichweite
290	Menschen mit kognitiven Einschränkungen
291	Für Menschen mit Photosensibilität werden Anfallsauslöser verhindert.
292	Hilfefunktionen, Benutzerhandbücher und Schulungsunterlagen sind barrierefrei. Bei ihrer Gestaltung werden die in Abschnitt 12 der DIN EN 301 549 (V2.1.2) aufgeführten Anforderungen zur Barrierefreiheit eingehalten.
293	Anforderungen an die Barrierefreiheit werden in der gesamten Vertragslaufzeit erfüllt, also auch bei Weiterentwicklung eines Service, Versionswechsel, Wartung und Pflege der Softwarelösung.
294	Der Nachweis der Barrierefreiheit wird vom AN erbracht und ist dem AG auf dessen Verlangen während der gesamten Vertragslaufzeit vorzulegen.
295	Ergänzende Anforderungen an die Barrierefreiheit
296	Benutzeroberfläche
297	Kontrast und Lesbarkeit: Ein ausreichend hoher Kontrast zwischen Text und Hintergrund ist sichergestellt. Schriftarten sind klar und gut lesbar, und Optionen zur Anpassung der Textgröße und -farbe sind gegeben.
298	Alternativtexte: Alle visuellen Elemente (Bilder, Diagramme, Videos) sind mit beschreibenden Alternativtexten versehen.
299	Farbschemen: Die Softwarelösung bietet neben Farben zusätzliche Unterscheidungsmerkmale und stellt Farbschemen bereit, die für farbenblinde Benutzer geeignet sind.
300	Interaktive Elemente
301	Formularfelder: Alle Formularfelder sind korrekt gekennzeichnet und beschriftet, um eine einfache Bedienung und Eingabe zu ermöglichen. Eingabefehler sind deutlich beschrieben und leicht zu korrigieren.
302	Steuerelemente: Buttons, Links und andere interaktive Elemente sind ausreichend groß abgebildet und leicht zu identifizieren.
303	Medieninhalte
304	Untertitel und Transkripte: Videos und Audioinhalte sind mit Untertiteln und schriftlichen Transkripten versehen.
305	Audiodeskription: Eine Option für Audiodeskriptionen für visuelle Inhalte ist vorhanden.
306	Kompatibilität und Interoperabilität
307	Plattformunabhängigkeit: Die Softwarelösung ist auf verschiedenen Betriebssystemen (Windows, macOS, Linux) und Geräten (Desktop, Laptop, Tablet, Smartphone) barrierefrei nutzbar.
308	Usability
309	Vorgaben für Benutzeroberfläche und Design
310	Die Lösung ermöglicht es technisch, mindestens die Designvorgaben des Auftraggebers für Farben und Logos umzusetzen. Hierzu erhält der Auftragnehmer/Bieter einen Zugang zum Marketing-Portal (https://marketingportal.extranet.deutschebahn.com/marketingportal) der Deutschen Bahn.
311	Zusätzlich bietet die Lösung auch die Möglichkeit, dass die (Bedien-) Oberflächen des Webclients des Systems die Website-Prinzipien des Auftraggebers gemäß UX-Guide erfüllen. Das heißt, dass zusätzlich zu den Logos und Farben, auch die UX-Prinzipien wie Icons, Typografie, Puls, Layout, Navigation und Usability angepasst werden können. Hierzu erhält der Auftragnehmer/Bieter einen Zugang zum Marketing-Portal (https://marketingportal.extranet.deutschebahn.com/marketingportal) der Deutschen Bahn.
312	Die Lösung ermöglicht die Anpassung der im System benutzten Begriffe an das Unternehmens-Glossar bzw. die Begriffe des Auftraggebers.
313	Alle Funktionalitäten der Lösung können über eine graphische Oberfläche entsprechend dem Rollen- und Berechtigungskonzept genutzt werden.
314	Bedienbarkeit
315	Die Benutzeroberfläche der Lösung ist ergonomisch gestaltet.
316	Die Lösung ist zusätzlich intuitiv bedienbar.
317	Die Userexperience mit der Oberfläche fördert die Arbeit mit der neuen Lösung und behindert diese nicht.
318	Die Lösung besitzt neben einem intuitiven UX-Aufbau Bedienfunktionen wie Automatisierung, Vorlagen oder Assistenten, die es Benutzern erleichtern, bestimmte Aufgaben auszuführen.
319	Die Lösung ermöglicht es, mehrere Prozesse parallel zu bearbeiten. Eine parallele Bearbeitung kann z.B. in Form von mehreren Tabs erfolgen.
320	Die Lösung bietet eine Block- und Multiselektion in Listen an. Per Block- und Multiselektion ausgewählte Objekte können durch den Benutzer bearbeitet werden.
321	Die Lösung verwendet Windows-übliche Standards wie Tastenkürzel/ Tastenkombinationen, wie z.B. Kopier- sowie Ausschneide-Funktionalitäten. Dies gilt auch für tabellarische Darstellungen.
322	Unterstützte Browser
323	Die Lösung unterstützt Microsoft Edge in der jeweils aktuellen mobilen und Desktop-Version auf allen Endgerätetypen und -größen.
324	Die Lösung unterstützt ebenfalls weitere gängige Browser auf Endgeräten. Zu den gängigen Browsern zählen: Google Chrome, Safari und Firefox in der jeweils aktuellen mobilen und Desktop-Version.
325	Ferner ist die Lösung auch auf älteren Vorgängerversionen der genannten Browser lauffähig (mind. N-1 Hauptversion) und kann korrekt dargestellt und genutzt werden.
326	Responsive Design
327	Die Lösung folgt dem gestalterischen und technischen Paradigma "Responsive Design".
328	Das Design der Lösung passt sich automatisch an Bildschirmgröße, -format und -auflösung an.
329	Die Funktionen für Standard-Benutzer sind auf mobilen Apps bzw. kleineren Displaygrößen identisch mit den Desktop-Funktionen. Dies gilt nicht für Funktionen der fachlichen Administration.
330	Die Bedienung ist per Touchscreen möglich.
331	Die Lösungbietet jedem Benutzer die Möglichkeit, im Browser die Skalierung (Vergrößerung/Zoomstufe) für die Bildschirmanzeige festlegen und verändern zu können.
332	Rückmeldung des Systems
333	Die Lösung stellt sicher, dass bei Fehleingaben eines Benutzers ein Hinweis an den Benutzer erscheint und dass der weitere Prozess bis zur Korrektur des Fehlers nicht fortgeführt werden kann.
334	Die Lösung stellt sicher, dass beim Verlassen von Bearbeitungsmasken, in denen sich seit dem Öffnen etwas geändert hat, ein Warnhinweis an den Benutzer erscheint.
335	Die Lösung stellt sicher, dass dem Benutzer beim Auftreten von Fehlern, inkl. schwerer Fehler (z.B. 'Fatal Errors') und Systemkomponenten-Abstürzen eine verständliche Meldung ausgegeben wird.
336	Die Fehlermeldung ist referenziert und im Fehlerhandbuch dokumentiert. Wesentlich ist, dass ein Benutzer nachlesen kann, was im Fehlerfall unternommen werden kann (z.B. mindestens eine Aufforderung, sich an den Support zu wenden oder sich noch einmal anzumelden). Fehlermeldungen sind klar und verständlich formuliert und bieten alternative Lösungsvorschläge.
337	Das System loggt Benutzer, die über einen einstellbaren Zeitraum im System inaktiv sind, automatisch aus.
338	Sprachunterstützung
339	Die Lösung unterstützt im Frontend (Ansichten für Endanwender) Deutsch und Englisch (Sprache und Darstellungsformate) vollständig.
340	Insbesondere folgende Punkte werden systemweit auf Deutsch und Englisch und für alle Rollen, Tabellen und Masken bereitgestellt:
341	Alle (Bedien-)Oberflächen
342	System- und Fehlermeldungen
343	Tastatureingaben und Zeichensätze
344	Zahlenformat
345	Datums- und Uhrzeitformat
346	Währung / Währungsdarstellung
347	Jegliche Korrespondenz wie ausgehende Email
348	Hilfestellung für Benutzer
349	Die Lösung ermöglicht, dass die Landing Pages (z.B. Startseite) rollenspezifisch konfiguriert werden können.
350	Die Lösung bietet beim ersten Login eines Benutzers eine Art von Userguide an, welches den Nutzer durch die Software führt und dabei die Funktionen/ Inhalte erklärt.
351	Die Lösung bietet allen Benutzern eine Hilfestellung und Hinweise zu Arbeitsschritten und über die Ursache von inaktiven Funktionalitäten in der gewählten Systemsprache bei der Bedienung der Software an.
352	Die Lösung speichert Änderungen in Echtzeit automatisch.
353	Die Lösung stellt allen Benutzern über Tooltipps in der gewählten Systemsprache Informationen und Hinweise zu Systemfunktionen und über die Ursache von inaktiven Funktionalitäten bereit.
354	Informationen und Hinweise zu Arbeitsschritten und Ursachen von inaktiven Funktionen sind in die Bedienoberfläche in Form von Infoboxen integriert. Der Benutzer kann die Infobox durch "aktives" Klicken - z.B. in Form eines Okay Buttons oder vergleichbar - entfernen/ausblenden.
355	Die Lösung stehlt den Benutzern ein Kontextmenü in der gewählten Systemsprache bereit.
356	Die Lösung ist in der Lage, die Benutzer intelligent entlang der Prozesse führen, u.a. durch Fokussierung und moderne, intuitive UX, die ein effizientes und fehlerarmes Arbeiten erlaubt.
357	Der Auftragnehmer beschreibt im Benutzerhandbuch fach- und herstellerspezifische Begriffe sowie Symbole und Piktogramme in einem Glossar.
358	Die Lösung bietet die Möglichkeit, dass der Systemadministrator für alle Eingabefelder Pattern zur Eingabe hinterlegen kann, die bei der Befüllung geprüft werden. Für das Feld "dienstliche E-Mail-Adresse" gilt beispielsweise, dass E-Mail-Adressen ein "@"-Zeichen beinhalten müssen und keine Leerzeichen oder Zeilenumbrüche beinhalten dürfen.
359	Weiterhin kann der Systemadministrator Pflichtfelder definieren.
360	Die Lösung stellt die Beschriftung von Feldern zur optionalen und verpflichtenden Eingabe durch Schrifttyp, Hintergrundfarbe oder vergleichbare Maßnahmen deutlich erkennbar dar.
361	Die Lösung bietet dem Benutzer die Möglichkeit, alle Oberflächen über Tastatureingaben zusätzlich zur Maus-Nutzung zu bedienen, z.B. Nutzung von Shortcuts oder Tab-Taste.
362	Die Lösung ermöglicht, dass für geeignete Eingabe- und Auswahlfelder eine Auto-Suggest Funktion bereitgestellt wird, um eine explorative Suche für den Anwender zu ermöglichen, bzw. um eingegebene Suchbegriffe zu vervollständigen.
363	Navigationsbereich
364	Der Benutzer kann in der Lösung jederzeit erkennen, wo er sich befindet und der Benutzer kann auch zu anderen Aktivitäten springen (demnach keine mehreren Tabs).
365	Offline-Funktionalität
366	Die Lösung stellt Funktionen und/oder Inhalte offline zur Verfügung. Eine Offline-Funktion ist mindestens in der mobilen App (iOS & Android) verfügbar sein
367	UTF-8 Konformität / Formatvorgaben
368	Alle Eingabe- bzw. Ausgabeformate sind UTF-8 konform.
369	Die Lösung unterstützt den Codec UTF 8/16 oder Unicode, um deutsche Zeichen (z.B. Umlaute), Zahlen und Formate (z.B. Datum) zu unterstützen.
370	Bereitstellung einer URL mit Bezug zu DB
371	Die Lösung stellt sicher, dass Benutzer eine URL mit Bezug zur IT-Umgebung der DB nutzen, z. B. https://.... anwendung.deutschebahn.com oder https://... .deutschebahn.com/anwendung.
372	Dieser Bezug zur URL bleibt während der Arbeit in der Anwendung in der Adresszeile bestehen.
373	Mobile Anwendung / App
374	Zusätzlich werden die Funktionen als mobile Anwendung (native App oder auch als Progressive Web App (PWA)) zur Verfügung gestellt (genauere Details siehe Anforderung „XY“)
375	Die App kann die Audiowiedergabe eines Inhaltes bei gesperrtem Bildschirm des mobilen Endgeräts (IOS/Android) fortsetzen.
376	Die App kann die Videowiedergabe auf mobilen Endgeräten (IOS/Android) bei Wechsel in eine andere App in einem eigenen Fenster fortsetzen (Picture-in-Picture).
377	App im Hintergrund laufen lassen: Video wird in eigenem Fenster wiedergegeben, wenn eine andere App geöffnet wird.
378	Dokumentation
379	Dokumentationen / Benutzerhandbücher
380	Der Auftragnehmer stellt zielgruppenspezifische Dokumentationen im digitalen Format zur Verfügung. Diese sind vor allem, aber nicht ausschließlich:
381	Benutzerhandbuch für die Endnutzer
382	Betriebsführungshandbuch für die fachliche Betriebsführung
383	Schulungshandbuch für die fachliche Betriebsführung (inkl. Erläuterung zu Logeinträgen und Fehlermeldungen)
384	Schnittstellendokumentation
385	Alle Dokumentationen sind mindestens auf Deutsch verfügbar.
386	Bei Versions- oder Releasewechsel der Lösung wird der Auftragnehmer die entsprechend aktualisierten Dokumentationen spätestens zur Produktivsetzung zur Verfügung stellen.
387	Alle Dokumente in Textform erfüllen durchgängig die genannten formalen Kriterien:
388	Klare inhaltliche Struktur
389	Inhaltliche Vollständigkeit und / oder voller inhaltlicher Abdeckungsgrad
390	Inhaltliche Widerspruchsfreiheit
391	Semantische Konsistenz und einheitliche Fachbegriffe
392	Die Softwarelösung bietet eine detaillierte Dokumentation zur Barrierefreiheit, die beschreibt, wie die barrierefreien Funktionen genutzt und welche Standards eingehalten werden.
393	Erweiterbarkeit und Ergänzung der fachlichen Dokumentation
394	Der Auftragnehmer stellt sicher, dass die fachliche Dokumentation durch die fachliche Betriebsführung des Auftraggebers an beliebiger Stelle durch kundenspezifische Ergänzungen erweitert und gepflegt werden kann.
395	Wenn der Auftragnehmer ein Update oder eine neue fachliche Dokumentation liefert, kann eine im System integrierte Übernahmefunktion diese kundenspezifischen Erweiterungen in die andere/neue Dokumentation automatisch übernehmen und verwalten, wenn die entsprechenden Abschnitte in der anderen/neuen Dokumentation auch vorhanden sind.
396	Der Auftragnehmer autorisiert den Auftraggeber zusätzlich im Kontext der Nutzung des Systems die Dokumentation des Systems für konzerninterne Zwecke zu übernehmen, anzupassen und zu ergänzen.
397	Dateiformate der Dokumentation
398	Der Auftragnehmer stellt sicher, dass die gesamte Dokumentation inkl. Handbüchern und Fehlerhandbuch in elektronischer Form in einem gängigen Dateiformat wie z.B. Word, Excel, PDF geliefert wird.
399	Service-Level, Support, Wartung und Fehlerbehebung [SUP]
400	Verfügbarkeit
401	Unter Verfügbarkeit wird das Verhältnis aus der tatsächlichen Dauer zu der geplanten Dauer, während der die Lösung genutzt werden kann, verstanden.
402	Zu beachten ist im Zusammenhang der Verfügbarkeit der Unterschied zwischen einer geplanten und einer ungeplanten Nichtverfügbarkeit. Da zur Berechnung der Verfügbarkeit nur die Ausfallzeit innerhalb des vereinbarten Zeitraums gerechnet wird, liegt eine geplante Nichtverfügbarkeit, beispielsweise aufgrund von Wartungsaufgaben, außerhalb des vereinbarten Zeitraums. Nur eine ungeplant auftretende Nichtverfügbarkeit wird als Ausfallzeit gerechnet.
403	Die Verfügbarkeit wird innerhalb eines definierten Zeitraums gemessen. Geplante Wartungsfenster werden bei der Ermittlung der Verfügbarkeit nicht berücksichtigt. Es gilt die folgende Formel: Die Verfügbarkeit der SaaS-Lösung berechnet sich in Minuten pro Monat. Verfügbarkeit (in %) = (Verfügbare Servicezeit – Ausfallzeit) / Verfügbare Servicezeit
404	Verfügbare Servicezeit entspricht der gesamten Anzahl von Minuten in einem Monat, in der eine unterbrechungsfreie Verfügbarkeit vom Auftragnehmer zugsichert wird, d.h. ohne Störungen der Fehlerklasse „Kritisch / Wichtig“ (gemäß Kapitel 5.3). Berechnungsgrundlage: Servicezeit = 30 Tage x 24h x 60min = 43.200 Minuten pro Monat; Einer Verfügbarkeit von 99,5% entsprechen maximal 216 Minuten Ausfallzeit pro Monat.
405	Ausfallzeit: Zeitraum, innerhalb dem die Anwendung bzw. ein Teilbereich der Anwendung wegen einer Störung/eines Fehlers nicht genutzt werden kann. Nicht als Ausfallzeit und damit auch nicht als SLA-Verletzung gelten die Zeiten, in denen das System dem Anwender aus den im Folgenden genannten Gründen nicht oder nur teilweise zur Verfügung steht:
406	Ausfallzeiten während geplanter Wartung (Wartungsfenster)
407	Ausfallzeiten auf Grund höherer Gewalt
408	Fehler / Störungen im Verantwortungsbereich des Auftraggebers
409	Wartungsfenster ist ein Zeitraum, in dem die SaaS-Lösung zu Wartungszwecken außer Betrieb genommen werden kann. Sollte es für den Erhalt und die Sicherheit des laufenden Betriebs des Systems oder für die Durchführung von wichtigen oder kritischen Updates oder Upgrades erforderlich sein, dass periodische, geplante oder ungeplante Wartungsarbeiten am System durchgeführt werden müssen, so kann ein Wartungsfenster in Abstimmung mit dem Auftraggeber vereinbart werden. Wartungsfenster müssen gegenüber dem Auftraggeber mit Termin, Uhrzeit und geplanter Dauer mindestens 10 Werktage vorher per E-Mail angekündigt werden.
410	Die monatliche Verfügbarkeit der SaaS-Lösung beträgt mindestens 98,8 Prozent. Erfüllt der Auftragnehmer die genannte Verfügbarkeit nicht, greifen die Regelungen gemäß Ziffer 5.6.
411	Die Verfügbarkeit der SaaS-Lösung und der einzelnen Funktionalitäten wird vom Auftragnehmer in einer monatlichen Statistik berichtet (siehe Ziffer 5.5).
412	Support
413	Der 1st und 2nd Level Support liegen in der Verantwortung des Auftraggebers.
414	Basissupport: Der Support ist Montag bis Freitag zu den üblichen Bürozeiten zwischen 08:00 – 17:00 Uhr MEZ erreichbar (Supportzeit). Innerhalb der Supportzeit gelten die definierten Reaktions- und Fehlerbehebungszeiten.
415	Erweiterter Support: Auf Anfrage des Auftraggebers stellt der Auftragnehmer einen 3rd Level Support mit einer Verfügbarkeit von 24x7 für den Auftraggeber (nicht für Endnutzer des Systems) über die gesamte Vertragslaufzeit bereit. Innerhalb der Supportzeit gelten die definierten Reaktions- und Fehlerbehebungszeiten.
416	Der Support wird in deutscher Sprache geleistet.
417	Während der „Supportzeit“ wird ein persönlicher Support durch den Auftragnehmer zur Verfügung gestellt.
418	Der Auftraggeber hat die Möglichkeit, über folgende Kontaktwege mit dem Auftragnehmer in Kontakt zu treten: Telefon, E-Mail, Webformular, persönlicher Kontakt.
419	Vorfälle können vom Auftraggeber beim AN priorisiert eingesteuert werden. Eine Einstufung der Prioritätsstufe erfolgt durch den Auftraggeber. Eine Änderung durch den Auftragnehmer ist nur in Abstimmung mit dem Auftraggeber möglich.
420	Der Auftraggeber hat die Möglichkeit, jederzeit den Status seiner Vorfälle einzusehen (z. B. über ein eigenes Portal).
421	Es gibt umfangreiche FAQs, Wissensdatenbanken und Best Practices sowie Foren zur Lösung, die dem Auftraggeber zusätzlich selbst eine schnelle Lösungsfindung ermöglichen. Der Auftragnehmer stellt auch Nutzungs- und Lösungsempfehlungen für bestimmte Themen zur Verfügung.
422	Incident-Prioritäten, Reaktionszeiten und Fehlerbehebungszeiten / Wiederherstellungszeiten
423	Es werden folgende Fehlerklassen, Reaktionszeiten und Fehlerbehebungszeiten / Wiederherstellungszeiten für Test- und Produktivumgebung vereinbart.
424	Incident Priorität 1 (Kritisch): Eine zweckentsprechende wirtschaftlich sinnvolle Nutzung der vertragsgegenständlichen Leistung ist nicht möglich oder unzumutbar eingeschränkt bzw. die Lösung ist Ursache für einen Produktionsstillstand. Das sind zum Beispiel: Totale Systemausfälle, Ausfall einzelner Komponenten bzw. Module, keine Möglichkeit der Anmeldung durch den Nutzer sowie Fehler, die eine vollständige Durchführung und Verarbeitung der Ergebnisse durch den Nutzer verhindern: Betriebsverhindernd. Sofern für eine für die Geschäftstätigkeit des Auftraggebers kritische Anwendung durch einen Incident beeinträchtigt ist, behält sich der Auftraggeber vor, die Incident Priorität 1 festzulegen.
425	Reaktionszeit: Innerhalb von 2 Stunden innerhalb der Supportzeit
426	Fehlerbehebungszeit / Wiederherstellungszeiten: Unverzüglich, Workaround oder Hotfix längstens innerhalb von 2 Arbeitstagen
427	Incident Priorität 2; (Wichtig): Eine zweckentsprechend wirtschaftlich sinnvolle Nutzung der vertragsgegenständlichen Leistung ist nur mit Einschränkungen möglich, ohne dass dadurch die Nutzung der Lösung insgesamt unmöglich ist, bzw. die Lösung ist Ursache für erhebliche Produktionseinschränkungen. Es existieren Workarounds zur Überbrückung der Fehlerbehebungsdauer. Beispiele sind: Nach Durchführung eines Moduls durch den Nutzer werden die Eingaben zwar gespeichert, die Ergebnisse werden aber nicht errechnet, die Übermittlung von Daten an den Auftraggeber kann nicht vollständig umgesetzt werden: Betriebsbehindernd
428	Reaktionszeit: Innerhalb von 4 Stunden innerhalb der Supportzeit
429	Fehlerbehebungszeit / Wiederherstellungszeiten: Unverzüglich, Workaround oder Hotfix längstens innerhalb von 6 Arbeitstagen
430	Incident Priorität 3 (Weniger wichtig): Die vertragsgegenständliche Leistung ist trotz des Fehlers zweckentsprechend und wirtschaftlich sinnvoll nutzbar. Die Nutzung der Lösung im Geschäftsbetrieb ist beeinträchtigt, Kerngeschäftsprozesse sind davon jedoch nur unwesentlich betroffen. Dennoch entsteht Zusatzaufwand im Vergleich zur Nutzung einer fehlerfreien Lösung.
431	Reaktionszeit: Innerhalb von 1 Arbeitstag innerhalb der Supportzeit
432	Fehlerbehebungszeit / Wiederherstellungszeiten: Unverzüglich, Workaround oder Hotfix längstens innerhalb von 12 Arbeitstagen
433	Behebung und Dokumentation von Fehlern
434	Alle vom Auftraggeber bzw. einem vom Auftraggeber beauftragten Dienstleister während der Testphase oder im laufenden Betrieb identifizierten Fehler werden durch den Auftraggeber in Fehlerklassen eingeteilt, dokumentiert und an den Auftragnehmer zur Behebung übermittelt.
435	Der Auftragnehmer stellt dem Auftraggeber bzw. dem beauftragten Dienstleister hierzu ein Service Portal zur Verfügung, in dem der Auftraggeber bzw. ein beauftragter Dienstleister identifizierte Fehler dokumentieren kann.
436	Ein Fehler (unabhängig von der Fehlerklasse) gilt als vollständig im Tool dokumentiert, wenn mindestens folgende Angaben zu einem Fehler gemacht werden:
437	Betroffene Module
438	Uhrzeit (Beginn der Störung)
439	User (betroffene Benutzer)
440	Status
441	Verständliche Beschreibung des Fehlverhaltens der Software
442	Messung und Reporting von Service-Leveln
443	Die Einhaltung der Service Levels wird vom Auftragnehmer regelmäßig gemessen. Darüber hinaus wird der Auftragnehmer dem Auftraggeber über die Einhaltung der Service Levels regelmäßig berichten. Soweit keine abweichenden Vereinbarungen getroffen werden, erfolgt die Berichterstattung über die Einhaltung der Service Levels auf monatlicher Basis.
444	Der Auftraggeber kann bei wiederholter Nichteinhaltung der vereinbarten Servicequalität (Verfügbarkeit, Reaktions- oder Wiederherstellzeiten) die Vorlage einer angemessenen Root-Cause-Analyse und eines Abhilfeplans seitens des Auftragnehmers verlangen.
445	Kompensation / Auswirkung bei Nicht-Einhaltung der SLA
446	Kompensationen können hinsichtlich der vereinbarten Verfügbarkeit der SaaS-Lösung als auch aus Verletzungen der Reaktionszeit und Fehlerbehebungszeit / Wiederherstellungszeit sowie maximalen Störungsausfallzeit resultieren.
447	Die Kompensation wird pro Kalenderjahr und SaaS-Lösung auf 15% der jährlichen Auftragssumme begrenzt.
448	Die Feststellung, ob die vereinbarte Servicequalität eingehalten wurde, erfolgt jeweils im Rahmen der vom Auftragnehmer zu liefernden Berichte. Soweit dem Auftraggeber ein Anspruch auf Minderung der Vergütung (Kompensation) zusteht, wird der Auftragnehmer diesen Betrag auf der nächsten Rechnung als Gutschrift ausweisen und den Rechnungsbetrag entsprechend kürzen.
449	Soweit die Vertragsparteien für den Fall der Nichteinhaltung von Service Levels eine finanzielle Kompensation vereinbaren, werden weitergehende Rechte des Auftraggebers, insbesondere die Geltendmachung von Schadensersatzansprüchen, hierdurch nicht ausgeschlossen. Eine gezahlte Vertragsstrafe wird auf einen Schadensersatzanspruch wegen Verzuges angerechnet. §§ 340 Abs. 1, 341 Abs. 3 und § 343 BGB finden keine Anwendung.
450	Für die Berechnung einer Kompensation bei Verletzung der Verfügbarkeit wird folgende Formel herangezogen: Kompensation = S * (Vzugesagt – Vist)
451	S = Auftragssumme im Monat
452	Vzugesagt = Laut SLA vereinbart minimale Verfügbarkeit im Monat in Prozent
453	Vist = Ist-Verfügbarkeit im Monat in Prozent
454	Für die Berechnung einer Kompensation bei Verletzung der Reaktionszeit gilt Folgendes: Überschreitet der Auftragnehmer die vereinbarte Reaktionszeit, so zahlt der Auftragnehmer an den Auftraggeber für jeden Fall der Überschreitung eine Kompensation in Höhe von € 300 pro angefangene Stunde.
455	Allgemeine Anforderungen zu Service-Leveln
456	Soweit für einzelne Leistungen keine Service Levels vereinbart werden, wird der Auftragnehmer zu jeder Zeit zumindest die Qualität sicherstellen, die von einem professionellen IT-Dienstleister im Zusammenhang mit den betreffenden Leistungen erwartet werden kann. Auf Wunsch des Auftraggebers werden die Vertragsparteien in einem solchen Fall nach Treu und Glauben über die Vereinbarung weiterer Service Levels verhandeln.
457	Die Service Levels stellen eine qualitative Konkretisierung der vom Auftragnehmer zu erbringenden Leistungen dar und schränken die Pflicht des Auftragnehmers zur kontinuierlichen Leistungserbringung nicht ein. Für schuldhafte Pflichtverletzungen im Rahmen der Leistungserbringung hat der Auftragnehmer unabhängig vom Erreichen der Service Levels einzustehen.
458	Wartung / Weiterentwicklung
459	In Bezug auf die Wartung und Weiterentwicklung gelten die folgenden Definitionen:
460	Release: Die Kennzeichnung einer konkreten Softwareversion, die Anwendern zusätzliche Optionen durch neue Features und Funktionen bietet.
461	Update: Die Aktualisierung vorhandener Software und deren Funktionalitäten
462	Patch: Die zeitnahe Behebung eines Fehlers oder einer Sicherheitslücke in einer in Betrieb befindlichen Software.
463	Der AN verpflichtet sich zur kontinuierlichen Weiterentwicklung seiner Lösung und stellt regelmäßig Releases zur Verbesserung der bestehenden Funktionalität sowie für die Lieferung neuer Standard-Funktionalitäten bereit. Diese werden mindestens vier Wochen vor Installation beim Auftraggeber (z.B. per E-Mail) angekündigt und deren Inhalt kommuniziert, sodass der Auftraggeber die Möglichkeit hat, diese zu testen.
464	Das regelmäßige Release erfolgt mind. 2-mal pro Jahr. Geplante und ungeplante Updates erfolgen nach Bedarf und Notwendigkeit. Der Auftragnehmer ermöglicht, diese in verschiedenen Stages (z. B. Entwicklungs-, Test- und Abnahmeumgebung-, Produktionsumgebung) zu verschiedenen Zeitpunkten nacheinander erstmals zu installieren, um die Prüfung seitens des Auftraggebers zu ermöglichen.
465	Releases, Updates und Patches erfolgen so, dass vom AG implementierten Funktionalitäten nach deren Inbetriebnahme weiter funktionieren (Aufwärtskompatibilität).
466	Für die Bereitstellung von Releases und Software-Updates fallen keine zusätzlichen Kosten für den AG an, sie sind mit den vorhandenen Preispositionen abgedeckt.
467	Der Auftragnehmer stellt sicher, dass während der Vertragslaufzeit im Falle von auftretenden relevanten gesetzlichen Änderungen eventuell notwendige Anpassungen in der SaaS-Lösung so umgesetzt werden, dass der Auftraggeber diese ab Inkrafttreten der gesetzlichen Änderung weiterhin konform nutzen kann.
468	Der Auftragnehmer stellt sicher, dass Änderungen der Workflows aufgrund interner Prozessänderungen oder Umstrukturierungen beim Auftraggeber jederzeit, auch durch den Auftraggeber selbst, umgesetzt werden können.
469	Releases / Updates und Patches werden vorab durch den Auftragnehmer hinsichtlich Schwachstellen geprüft und erst nach vorherigem Testen und einem formalen Freigabeprozess durch den Auftraggeber bzw. durch den vom Auftraggeber beauftragten Dienstleister eingespielt. Software-Releases, Updates und Patches sind durch den Auftragnehmer auf der Test-/ Abnahmeumgebung durchzuführen. Erst nach Freigabe zur Produktivsetzung durch den Auftraggeber dürfen die Updates auf der Produktivumgebung eingespielt werden.
470	Alle eingesetzten Softwarekomponenten sind durch den Auftragnehmer auf einem Stand zu halten, für den vom jeweiligen Lieferanten Security Patches zur Verfügung gestellt werden. Der Auftragnehmer stellt sicher, dass Security Patches zeitnah und in einem regelmäßigen Zyklus eingespielt werden. Diese sind bei geplanten Patches) dem Auftraggeber mit ausreichender Vorlaufzeit anzukündigen.
471	Falls Veränderungen in den bestehenden Funktionen eine Migration in diese neuen Funktionen erfordern, wird vom Auftragnehmer ein Migrationspfad bereitgestellt, sodass der AG eine Beschreibung darüber erhält, was für die Migration zu erledigen ist.
472	Die in der SaaS-Lösung gehaltenen Daten werden durch Releases, Updates oder Patches nicht verändert.
473	Diese Anforderungen gelten nicht nur für die SaaS-Lösung selbst, sondern auch für umstehende Funktionalitäten wie Schnittstellen. Um die SaaS-Lösung als SaaS mit anderen Systemen beim AG zu integrieren, sind diverse Schnittstellen zu implementieren (siehe Kapitel 3). Alle Schnittstellen bzw. die zugehörigen koexistierenden Systeme sind mit ihrer Kompatibilität uneingeschränkt und reibungslos weiterhin im gewohnten Maße bedienbar.
474	Der Auftragnehmer bietet dem Auftraggeber Möglichkeiten an, Vorschläge für die Weiterentwicklung der Standardlösung einzubringen und hat einen implementierten Prozess, wie diese Vorschläge, gemeinsam mit den Vorschlägen anderer Kunden, bei der Weiterentwicklung der Standardlösung berücksichtigt werden.
475	Releasenotes
476	Der Auftragnehmer liefert mit jeder Softwarebereitstellung Release Notes.
477	Diese Release Notes weisen mindestens die folgenden Inhalte auf:
478	eindeutige Versionsnummern für jede Komponente
479	Änderungsumfang
480	Ggf. umgesetzte fachliche Anforderungen
481	Ggf. umgesetzte nicht-fachliche Anforderungen
482	Neue Funktionalitäten, die nicht auf Anforderungen durch den Auftraggeber beruhen
483	Ggf. behobene Fehler
484	Ggf. bekannte Fehler
485	Hinweise und Anmerkungen für die Nutzer
486	Hinweise und Anmerkungen für die fachliche Betriebsführung
487	Der Auftraggeber hat das Recht Auszüge aus diesen Release Notes für die eigene Dokumentation und Nutzerhandbücher zu verwenden.
488	INtegration, Migration und Test [IMT]
489	Anforderungen an die Migration
490	Vorgehen und Konzept für die Einführung, Integration und Migration („Migrationsprojekt“)
491	Unmittelbar nach Vertragsabschluss beginnen Auftraggeber und Auftragnehmer gemeinsam mit dem Projekt zur Einführung und Integration der Softwarelösung inklusive der zugehörigen Migrationen (auch „Migrationsprojekt“).
492	Ziel des Projektes ist, dass die Leistungen des Auftragnehmers innerhalb des vertraglich vereinbarten Zeitraums, bis spätestens März 2029 für den Auftraggeber beziehbar und vollständig nutzbar sind, insbesondere alle dafür notwendigen Prozesse und Schnittstellen implementiert sind und alle relevanten Geschäftsobjekte vom Alt-System in die neue Softwarelösung migriert sind.
493	Das Konzept für das Migrationsprojekt ist so ausgestaltet, dass der Auftraggeber, insbesondere in diesem Kapitel der Leistungsbeschreibung, einen groben inhaltlichen Rahmen und einige Anforderungen vorgibt. Innerhalb dieses Rahmens definiert der Auftragnehmer ein Grobkonzept für die Migration, z.B. einen Projektplan mit Arbeitspaketen, welche für die Umsetzung der Einführung, Integration und Migration notwendig sind. Dieses Grobkonzept ist im Lösungsdokument Migrationsprojekt (Anhang 13.1 (Lösungsdokument Migrationsprojekt)) dargestellt.
494	Nach Vertragsunterschrift wird auf Basis des Grobkonzepts in Anhang 13.1 (Lösungsdokument Migrationsprojekt) eine Detailplanung des Migrationsprojektes zwischen Auftraggeber und Auftragnehmer abgestimmt.
495	Diese Feinplanung erfolgt ab (Teil-)Bestellung zwischen Auftraggeber und Auftragnehmer bis max. 3 Wochen nach Bestellzeitpunkt. Für die Erstellung des Feinplans ist der Auftragnehmer verantwortlich, indem er den in Anhang 13.1 (Lösungsdokument Migrationsprojekt) definierten Inhalte erweitert bzw. ergänzt. Der Auftraggeber und der Auftragnehmer benennen dafür mit dem Bestellzeitpunkt jeweils einen verantwortlichen Ansprechpartner für die Erarbeitung der Feinplanung (z.B. Projektleiter).
496	Auftraggeber und Auftragnehmer übernehmen die im Plan festgehaltenen Verantwortlichkeiten.
497	Anforderungen an das Grobkonzept
498	Im Anhang 13.1 (Lösungsdokument Migrationsprojekt) werden folgende Anforderungen berücksichtigt bzw. bei der Durchführung umgesetzt:
499	Vorgehensmodell und Projektplan mit Meilensteinen und Terminen
500	Der Auftragnehmer stellt für das Projektteam bzw. Migrationsteam des Auftraggebers den Zugang zum System inkl. Dokumentation spätestens 14 Tage nach Abruf über den Rahmenvertrag bereit.
501	Es istdas grundsätzliche Vorgehensmodell des Auftragnehmers für das Migrationsprojekt dargestellt.
502	Ebenso ist der Projektplan mit zugehörigen Phasen dargestellt. Für die einzelnen Phasen sind die beinhalteten Arbeitsschritte sowie Zeiträume, Meilensteine und Termine definiert. In dem Projektplan sind alle notwendigen Aktivitäten und Leistungen von Auftraggeber und Auftragnehmer für einen erfolgreichen Projektabschluss berücksichtigt.
503	Projektstruktur mit Rollen und Eskalationsprozess
504	Es ist die vom Auftragnehmer für das Migrationsprojekt vorgesehene Projektstruktur inkl. zugehöriger Rollen dargestellt.
505	Für diese Rollen sind die grundsätzlichen Verantwortlichkeiten und Aufgaben beschrieben.
506	Das Rollenmodell enthält eine Projektleitungsfunktion bei Auftraggeber und Auftragnehmer und berücksichtigt, dass auf Seiten des Auftragnehmers Ansprechpartner für fachliche und technische Themen sowie eine Koordination der Tests und Fehlermeldungs- und Fehlerbehebungsprozesse sichergestellt ist.
507	Die Ansprechpartner seitens des Auftragnehmers sind auch im Migrationsprojekt entsprechend des Kapitel 5 „Service-Level, Support, Wartung und Fehlerbehebung [SUP]“ erreichbar.
508	Verfügbarkeit von Projektmitarbeitern
509	Bei Besprechungen, z.B. Klärungen zu fachlichen und technischen Fragen, Test- und Freigabebesprechungen sowie Einführungsplanung teilt der Auftraggeber dem Auftragnehmer fallweise die notwendige Anwesenheit von Auftragnehmer-Mitarbeitern an dem vom Auftraggeber benannten Einsatzort (hierzu gehören auch Remoteeinsätze) mit.
510	Innerhalb von fünf Kalendertagen nach der erstmaligen Inbetriebnahme oder innerhalb von zwei Kalendertagen nach der Inbetriebnahme eines neuen Releases stehen Mitarbeiter des Auftragnehmers bereit, um Fehler zu beheben und bei Bedarf einen Roll-Back der Installation zu unterstützen.
511	Der Problemlösungs- und Eskalationsprozess, der die Benennung von konkreten Ansprechpartnern zur Lösung von Problemen vorsieht, ist beschrieben.
512	Umsetzung der relevanten Anforderungen und Leistungen
513	In der Projektplanung und Darstellung der Leistungen einzelnen Phasen im Anhang 13.1 (Lösungsdokument Migrationsprojekt) ist die Umsetzung der folgenden Anforderungen berücksichtigt:
514	Ramp Up und Projektmanagement
515	Der Auftragnehmer initiiert gemeinsam mit dem Auftraggeber alle nötigen Tätigkeiten für ein funktionierendes Projektmanagement und stellt während des gesamten Projekts ein Projektmanagement zur Verfügung.
516	Esist die Vorgehensweise zum Ramp Up der für das Migrationsprojekt benötigten Ressourcen des Auftragnehmers sowie zur Initiierung und Sicherstellung des Projektmanagements während des gesamten Projekts dargestellt.
517	Support im Rahmen der Integration bis zu einer mit Realdaten laufenden Lösung. Hierbei geht es insbesondere, aber nicht ausschließlich um die Planung, Kommunikation, Abstimmung, Vornahme von Mappings, Lösungsfindung, Testen inkl. Testfälle, Projektsteuerung, Durchführung von Schulungen.
518	Der Auftragnehmer nimmt an wöchentlichen Statusmeetings mit dem Auftraggeber teil.
519	Der Auftragnehmer weist unverzüglich auf mögliche Risiken und absehbare Mehraufwände hin und begründet diese.
520	Bereitstellung Stages und Umgebungen sowie initiale Zugänge
521	Der Auftragnehmer stellt sicher, dass die einzelnen Stages in der IT-Infrastruktur des Auftraggebers betriebsfähig zugänglich sind.
522	Auftraggeber und Auftragnehmer stellen gemeinsam die für den Betrieb der Stages notwendigen sicheren Netzwerkverbindungen her.
523	Der Auftragnehmer stellt zeitnah zu Beginn des Integrationsprojekts die Login-Daten und vollständigen Admin-Berechtigungen für Zugänge für eine ausgewählte Anzahl an Mitarbeitern des Auftraggebers Testumgebung sowie zur Produktivumgebung bereit.
524	Die Vorgehensweise bei der Bereitstellung der Stages und Übermittlung der initialen Zugänge sowie die zugehörigen Zeitpunkte der Bereitstellung sind im Anhang 13.1 (Lösungsdokument Migrationsprojekt) beschrieben.
525	Konfiguration der Lösung
526	Der Auftragnehmer stellt bis zu einem in Anhang 13.1 (Lösungsdokument Migrationsprojekt) definierten Zeitpunkt die vorkonfigurierte Anwendung in der Testumgebung bereit. Die vorkonfigurierte Anwendung beinhaltet sämtliche in dieser Leistungsbeschreibung sowie weiteren Dokumenten beschriebenen und zugesagten Anforderungen – sofern nicht anders gekennzeichnet.
527	Der Auftragnehmer nimmt zusammen mit dem Auftraggeber das Customizing und die Parametrisierung an der vorkonfigurierten Anwendung in allen bereitgestellten Stages vor, sodass die auf das Umfeld des Auftraggebers zugeschnittene Funktionsfähigkeit der Anwendung herbeigeführt wird. Dies umfasst unter anderem, aber nicht ausschließlich, das Rollen- und Rechtemodell sowie die Anpassung der Workflows. Darunter fällt auch insbesondere die Umsetzung von Compliance-Anforderungen wie beispielsweise Datenschutz und Informationssicherheit.
528	Schnittstellen
529	Es wird die Umsetzung aller gemäß Kapitel 3 „Fehler! Verweisquelle konnte nicht gefunden werden.“ vereinbarten Schnittstellen im Rahmen des Migrationsprojektes beschrieben und im Projektzeitplan berücksichtigt. Zeitpunkte und grundsätzliche Vorgehensweise zur Umsetzung der Schnittstellen sind in Anhang 13.1 (Lösungsdokument Migrationsprojekt) beschrieben.
530	Der Auftragnehmer liefert für die Betriebsführung des Auftraggebers eine verständliche und vollständige Dokumentation zur Administration und Einweisung.
531	Falls nach Abschluss des Migrationsprojektes weitere Schnittstellen benötigt werden, werden diese durch den Auftraggeber gesondert beauftragt und entsprechend der Position im Preisblatt Anlage 2 (Abschnitt Sonstige IT-Leistungen) sowie der gemeinsamen Aufwandsschätzung vereinbart.
532	Die Freigabe der realisierten Schnittstellen nach erfolgreichem Test (siehe Kapitel 6.2.7 „Test der Schnittstellen“) stellt noch keine Gesamtabnahme des Migrationsprojektes durch den Auftraggeber dar.
533	Die formale Abnahme der im Migrationsprojekt geleisteten Schnittstellen erfolgt im Rahmen der Gesamtabnahme laut Kapitel 6.1.3 der Leistungsbeschreibung.
534	Schulungs- und Trainingsleistungen
535	Im Rahmen des Migrationsprojekts erfolgt die Einweisung, Schulung und Trainings der Mitarbeiter des Auftraggebers, welche das System zukünftig nutzen bzw. die im Rahmen der Integration die Gesamtabnahme unterstützen.
536	Dafür führt der Auftragnehmer Schulungen des Fachteams durch.
537	Hierfür ist Anhang 13.1 (Lösungsdokument Migrationsprojekt) ein grundsätzliches Schulungskonzept des Auftragnehmers und die zugehörigen Trainings- und Schulungsleistungen beschrieben.
538	Die Trainings und Schulungen sind bis zum Ende des Migrationsprojekts abgeschlossen und haben zum Ziel, dass die Mitarbeiter des Auftraggebers ihre Aufgaben im Rahmen des Betriebs und Nutzung der Lösung in der Lage sind, ihre Aufgaben und Verantwortungen zu übernehmen.
539	Die Schulung vermittelt vertieftes Wissen über die technischen Grundlagen, die Möglichkeiten und Grenzen des Systems so, dass die Vertreter des Auftraggebers „auf Augenhöhe“ mit dem Auftragnehmer zu Prozessen und Funktionen diskutieren können.
540	Migration
541	Aus dem Alt-System ist jedes Geschäftsobjekt, das seinen Lebenszyklus im Alt-System noch nicht abgeschlossen hat, in die neue Lösung zu migrieren.
542	Zusätzlich sind Geschäftsobjekte auch bei bereits abgeschlossenen Lebenszyklus aus dem Alt-System zu migrieren, sofern die historischen Daten weiterhin erforderlich sind.
543	Im Anhang 13.1 (Lösungsdokument Migrationsprojekt) ist die grundsätzliche Vorgehensweise zur Umsetzung dieser Migration dargestellt. Eine Konkretisierung erfolgt im Rahmen der Feinplanung.
544	Vorgehen zur Lieferung und Abstimmung von Testfällen sowie Durchführung von Tests
545	Der Auftragnehmer liefert dem Auftraggeber im Rahmen des Migrationsprojektes Testfälle zur Überprüfung der Funktionen der SaaS-Lösung sowie der Schnittstellen.
546	Diese Testfälle können dann durch den Auftraggeber ergänzt werden.
547	Die abgestimmten Testfälle sind Basis für die Abnahme des Gesamtprojekts sowie einzelner Meilensteine.
548	Im Projektplan sind entsprechende Testzeiträume vorgesehen. Im Rahmen von Tests festgestellter Fehler werden entsprechend der Definitionen und Festlegungen im SLA (Kapitel 5 „Service-Level, Support, Wartung und Fehlerbehebung) erfasst, kategorisiert, bearbeitet und behoben.
549	Der Auftraggeber prüft die Nachlieferungen und erteilt nach Beseitigung der Fehler der Fehlerklasse 1 und 2 (vergleiche Kapitel 5), die Freigabe.
550	Abnahme
551	Grundsätzlich wird im Rahmen der Abnahmeprüfung mittels durchgeführter Tests die Funktionsfähigkeit nachgewiesen. Dies betrifft insbesondere die Konfiguration der SaaS-Lösung sowie die Umsetzung der Schnittstellen.
552	Während der Abnahme behält sich der Auftraggeber vor, erneute Tests über den vertraglich vereinbarten Funktionsumfang durchzuführen, um die Funktionsfähigkeit des Liefergegenstands zu prüfen.
553	Der Auftraggeber erklärt die vertragliche Abnahme, wenn der Abnahmegegenstand, wie durch den Auftragnehmer vertraglich zugesichert, auf der Produktivumgebung des Auftraggebers ausgeliefert wurde und die Funktionsfähigkeit der Anwendung in vollem Umfang sichergestellt ist. Die Abnahmeerklärung durch den Auftraggeber erfolgt schriftlich.
554	Vorgehen bei Fehlern bei der Abnahme
555	Der Auftraggeber weist gefunden Fehlern folgende Fehlerklassen (entsprechend Kapitel 5) zu. Fehler führen während der Abnahme zu einer Reaktions- und zu einer Wiederherstellungszeit durch den Auftragnehmer entsprechend definierten Fehlerklassen.:
556	Testabdeckung
557	Der Auftragnehmer stellt sicher, dass alle im System umgesetzten Funktionen und Geschäftsvorfälle sowie alle zugesagten Anforderungen vor der Abnahme des Migrationsprojektes durch den Auftraggeber mit dokumentierten Testfällen getestet werden.
558	Projektabschluss
559	Der Auftragnehmer wird die Systemadministratoren des Auftraggebers nach erfolgreicher Abnahme für einen definierten Zeitraum bis zum Projektabschluss unterstützen, sodass eine reibungslose Inbetriebnahme sowie eine reibungslose Datenmigration in die Produktivumgebung sichergestellt wird, ohne dass Fehler auftreten.
560	Aufwandsschätzung Leistungen Auftragnehmer
561	Für die Leistungen zur Planung und Durchführung des Migrationsprojekteserfolgt die Vergütung gemäß Anlage 2 (Preisblatt) nach Abnahme der Lieferkomponenten in Verantwortung des AN gemäß Anhang 13.1 (Lösungsdokument Migrationskonzept). Anhang 13.1 (Lösungsdokument Migrationsprojekt) enthält für die Leistungen des Auftragnehmers, welche Bestandteil der Festpreise sind, eine Übersicht der Aufwände des Auftragnehmers in Personentagen (PT) pro Phase und ggf. pro Rolle und je Klassifizierung der Komplexität der Instanz.
562	Test
563	Allgemein
564	Der Auftragnehmer orientiert sich an den Anforderungen des Standards International Software Testing Qualifications Board (ISTQB) für alle testrelevanten Rollen und Verfahren.
565	Der Auftragnehmer unterstützt den Auftraggeber bzw. dem vom Auftraggeber beauftragten Dienstleister bei der Durchführung eines Systemintegrationstests, Abnahmetest und (Teil-) Freigabentest.
566	Der Auftragnehmer stellt sicher, dass alle Dokumentationen zu Fehlern, Unstimmigkeiten und Erläuterungen zum gemeldeten Fehler in deutscher Sprache, eindeutig und für Fachkundige des Auftraggebers verständlich beschrieben sind.
567	Testfälle
568	Die Testfälle legen detailliert fest, was zu testen ist und sind so für ein strukturiertes, dokumentiertes Testvorgehen essenziell. Hierbei sind sämtliche Standardsystemfunktionalitäten sowie Customizing- bzw. Individualanteile mit Testfällen abgedeckt. Der Auftragnehmer stellt dem Auftraggeber auf Verlangen die Testfälle zur Sichtung bereit, sowohl für die Standardsystemfunktionalität als auch für den Customizing- bzw. Individualanteil.
569	Dabei enthält die Dokumentation der Testfälle mindestens folgendes:
570	eine eindeutige Kennzeichnung / Test Case ID
571	einen eindeutigen Titel
572	eine ausführliche Testfallbeschreibung
573	die erforderlichen Test-Vorbedingungen, inkl. eventuell erforderlicher Schnittstellen
574	die erforderlichen Testdaten.
575	Durchführung von Tests durch den Auftragnehmer vor Auslieferung
576	Der Auftragnehmer führt vor der Bereitstellung der Software, für die Abnahme der Software, aber auch bei Teilauslieferungen und bei Software-Updates umfassende Tests (Komponenten-, Integrations-, System- und Penetrationstests) durch und stellt sicher, dass die Software frei von Fehlern an den Auftraggeber zur Nutzung bereitgestellt wird. Dies gilt u.a. auch für Releases und Patches.
577	Der Auftragnehmer dokumentiert die durchgeführten Testfälle, sowie die Testergebnisse.
578	Zur Vermeidung von Kapazitätsbindungen und für Zeitersparnisse setzt der Auftragnehmer möglichst automatisierte Tests ein.
579	Durchführung von Software-Tests für funktionale und nicht funktionalen Anforderungen
580	Der Auftragnehmer stellt sicher, dass mit der Durchführung der Tests die ordnungsgemäße und vollständige Funktion der Software inkl. aller geforderten Anforderungen überprüft werden kann.
581	Die durchgeführten Testfälle, sowie die Testergebnisse, werden durch den Auftragnehmer entsprechend dokumentiert.
582	Unterstützung bei den Tests und der Freigabe durch den Auftraggeber
583	Der Auftragnehmer stellt personelle Ressourcen zur Unterstützung (Beantwortungen von Fragen, Fehlerbesprechung, Bug-Fixing) für die Vorbereitung und Durchführung von Tests sowie für Freigaben durch den Auftraggeber bereit.
584	Durchführung von Regressionstests
585	Sobald Software verändert oder angepasst wurde, werden Regressionstests durchgeführt.
586	Hierbei wird überprüft werden, ob bisherige bestehende Sicherheitsmechanismen und -einstellungen durch das Update ungewollt verändert wurden.
587	Regressionstests werden vollständig durchgeführt und umfassen hierbei auch Erweiterungen sowie Hilfsmittel.
588	Werden Testfälle ausgelassen, wird dies begründet und dokumentiert. Die durchgeführten Testfälle und die Testergebnisse werden dokumentiert.
589	Test der Schnittstellen
590	Den Test der Schnittstelle werden Auftragnehmer und Auftraggeber gemeinsam anhand von Testprozessen und Testdaten durchführen, die der Auftragnehmer zur Verfügung stellt und die vom Auftraggeber bei Bedarf ergänzt werden können.
591	Auftragnehmer und Auftraggeber geben die Schnittstelle anschließend gemeinsam frei.
592	Die Freigabe ist möglich, wenn der Datenaustausch zwischen dem System des Auftragnehmers und den Systemen des Auftraggebers fehlerfrei erfolgt.
593	Behobene Fehler werden noch einmal getestet.
594	Umgebungskonzept
595	Der Auftragnehmer setzt ein mindestens zweistufiges Umgebungskonzept (Test und Produktion) ein.
596	Das System ermöglicht, dass für die Anwendungen verschiedene Setups (z.B. Sizing, Software-Version, Berechtigungen, Benutzerkonten) gleichzeitig zur Verfügung stehen.
597	Bereitstellung – Testsystem
598	Der Auftragnehmer stellt für Systemtests und (Teil-) Freigaben vor Produktivsetzung sowie für Software-Updates, eine Testumgebung bereit, die der produktiven Umgebung so nahe wie möglich kommt.
599	Sollte der Auftragnehmer eine weniger leistungsfähige Systemtestumgebung einsetzen, so dürfen dadurch nicht die Ergebnisse der Tests (fachlichen und betrieblichen (Freigabe-)Tests sowie Security-Tests) beeinflusst werden.
600	Betrieb – Testsystem
601	Die Umgebung wird von der Produktivumgebung getrennt betrieben.
602	Die Trennung wird, nach Möglichkeit physisch, mindestens aber logisch umgesetzt.
603	Die in der Testumgebung verwendeten Architekturen und Mechanismen werden dokumentiert.
604	Systemfunktionalität im Verbund - Testsystem
605	Der Auftragnehmer stellt sicher, dass ein Betrieb seiner Systeme auf den bereitgestellten Umgebungen (Integration und Test), angebunden an die Infrastruktur des Auftraggebers, möglich ist.
606	Die Testumgebung ist in ihrer Funktion als auch in den Abläufen und Dateninhalten produktionsvergleichbar und kann mit Datenquellen in der Infrastruktur des Auftraggebers verbunden werden.
607	Der Auftragnehmer stellt somit die prinzipielle Integrationsfähigkeit in ein Gesamtsystem beim Auftraggeber im Verbund mit angrenzenden Systemen sowie notwendige Dritt-Anbieter-Systeme des Auftraggebers sicher.
608	Für die Anbindung der Systeme liefert der Auftraggeber an den Auftragnehmer benötigte Informationen (z. B. Schnittstelleninformationen, Zugangsinformationen), außerdem ist der Auftraggeber für die Anpassung der internen Systeme (z. B. Firewall-Freischaltungen) zuständig.
609	Verfügbarkeit – Testsystem
610	Die Integrations- und Testumgebung stehen gemäß SLA permanent für fachliche Tests und Tagesgeschäftstest der Geschäftsbereiche zur Verfügung.
611	Verfügbarkeit nach Projektende – Testsystem
612	Die Umgebungen stehen auch nach vollständiger Produktionseinführung (Go-Live) für zukünftige Tests (z.B. nach Updates, Patches, Aktualisierungen, etc.) zur Verfügung.
613	Testdaten
614	Vor Implementierung des Produktivsystems werden Daten aus dem aktuellen Systemen des Aufraggebers auf die Testumgebung migriert (siehe Kapitel 6.1.2.3(a)(6) Fehler! Verweisquelle konnte nicht gefunden werden.).
615	Nach dem ersten Go-Live werden die Testdaten auf der Testumgebung durch das regelmäßige Aktualisieren des Datenbestandes (Abgleich mit der neuen Produktivumgebung) zur Verfügung gestellt werden. Der Datenbestand aus dem (neuen) Produktivsystem werden alle 3 Monate in das Testsystem überführt.
616	Testdaten auf dem Testsystem werden nach Einspielung anonymisiert und in Abstimmung mit dem Auftraggeber in unregelmäßigen Abständen aktualisiert.
617	Freigabe/ Freigabeverfahren
618	Teststrategie bis zur Freigabe
619	Der Auftragnehmer stellt zu Beginn der Implementierung eine Standardversion des Systems auf einer Testumgebung zur Verfügung. Danach wird das System nach und nach an die Anforderungen des Auftraggebers angepasst. Das kann einerseits durch Parametrisierung des Systems, anderseits aber auch durch Code-Anpassungen der Software geschehen.
620	Nach den ersten Anpassungen können die ersten Testdurchführungen stattfinden. Das bedeutet, dass sich die Testdurchführungen nach der Reihenfolge der Systemanpassungen richten.
621	Zum Abschluss der Softwarebereitstellung (Softwareänderungen / Fehlerbehebungen) werden fachliche und/ oder betriebliche Freigabetests auf den Systemen durchgeführt.
622	Durchführung des Freigabeverfahrens
623	Die Freigabe des Integrations- und Testsystems erfolgt, wenn alle zugesagten Anforderungen in der Leistungsbeschreibung, bzw. zusätzlich beauftragten Leistungen durch den Auftragnehmer vollumfänglich geliefert wurden.
624	Durch den Auftraggeber erfolgreich abgeschlossene Tests (Tests der Anforderungserfüllung, behobene Fehlertickts) auf der Testumgebung werden im Anschluss über ein geeignetes Medium (vorzugsweise Ticketsystem des Auftragnehmers) mittels eines Kommentares und einem entsprechenden Status freigegeben.
625	Vor jeder Änderung der Systeme ist eine Testumgebung mit der neuen Konfiguration bereitzustellen (mind. 10 Werktage vor Änderung). Hierbei muss eine Abnahme durch den AG erfolgen
626	Durch den Auftraggeber erfolgt separat zu der Freigabe der Tests in Abstimmung mit dem Auftragnehmer eine zusätzliche Freigabe in elektronischer Form zur Überführung der Softwareänderung auf das Produktivsystem.
627	Nach Einspielen von Softwareanpassungen auf dem Produktivsystem behält sich der Auftraggeber vor, in Abstimmung mit dem Auftragnehmer eine Reihe von Funktionstests durchzuführen. Sind diese erfolgreich, erfolgt eine schriftliche Freigabe der erfolgreichen eingespielten Softwareänderungen durch den Auftragnehmer an den Auftragnehmer.
628	Werden innerhalb einer Freigabe betriebsverhindernde und/oder betriebsbehindernde Fehler (gemäß Fehlerklassifizierung und Fehlerpriorisierung) festgestellt, kann der Auftraggeber die Freigabe abbrechen. Der Auftraggeber teilt dem Auftragnehmer in der Regel sofort während der Freigabe die festgestellten Fehler mit.
629	Hat der Auftraggeber die Freigabe auf dem Produktivsystem abgebrochen, setzt er dem Auftragnehmer eine angemessene Frist, die Fehler zu beseitigen. Hier gelten die vereinbarten SLAs. Notfalls muss auch in Abstimmung mit dem Auftraggeber ein Rollback durchgeführt werden.
630	Werden Fehler festgestellt, werden diese gemeinsam durch Auftraggeber und Auftragnehmer dokumentiert und priorisiert. An der Behebung muss der Auftragnehmer direkt und ohne Zeitverzug arbeiten, um den Zeitplan bis zur Produktivsetzung einzuhalten. Behobene Abweichungen oder Fehler werden noch einmal getestet. Dieser Vorgang kann sich wiederholen.
631	Sicherheitsrelevante Anforderungen [SAN]
632	Datenschutzanforderungen
633	Unbeschadet weitergehender datenschutzrechtlicher Anforderungen an anderen Stellen des Rahmenvertrags, insb. Anlage 3 (Vertrag über die Nutzung personenbezogener Daten) sind insbesondere folgende Anforderungen zum Datenschutz einzuhalten.
634	Anforderungen
635	Verpflichtung auf die Vertraulichkeit
636	Der Auftragnehmer stellt sicher, dass die mit der Verarbeitung personenbezogener Daten befugten Personen vor Aufnahme ihrer Tätigkeit zur Vertraulichkeit verpflichtet werden oder einer angemessenen gesetzlichen Verschwiegenheitspflicht unterliegen. Den bei der Datenverarbeitung beschäftigten Personen ist untersagt, personenbezogene Daten unbefugt zu verarbeiten. Die Pflicht besteht auch nach Beendigung ihrer Tätigkeit fort.
637	Unterauftragnehmer (Unterauftragsverarbeiter)
638	Der Auftragnehmer stellt sicher, dass eingesetzten Unterauftragnehmern dieselben Datenschutzpflichten auferlegt werden, die im Wesentlichen, den zwischen Auftraggeber und Auftragnehmer vereinbarten Datenschutzpflichten entsprechen. Verletzt ein Unterauftragnehmer die vereinbarten Datenschutzpflichten in grober Weise, so kann der Auftraggeber verlangen, dass der Auftragnehmer den Unterauftragnehmer unverzüglich gegen einen anderen Unterauftragnehmer austauscht.
639	Ort der Datenverarbeitung
640	Der Auftragnehmer stellt sicher, dass die Daten ausschließlich an den in den Rahmenvertragsanlagen (Leistungsstandorte) in Bezug auf Datenverarbeitung und –verbleib (Serverstandort, Redundanzen, Storage) festgelegten Standorten innerhalb der EU/EWR verbleiben, die der Auftraggeber ggf. in der Administrationskonsole (Self-Service-Portal o.ä.) selbst ausgewählt hat.
641	Eine Veränderung der Leistungsstandorte seitens des Auftragnehmers innerhalb der EU/EWR kann nur nach vorheriger Zustimmung des Auftraggebers erfolgen.
642	Die Erbringung von Support- und/oder Wartungsleistungen sowie den ggf. damit verbundenen Zugriff durch Mitarbeiter des Auftragnehmers und/oder seiner Nachunternehmer außerhalb der EU/EWR ist möglich. Sofern personenbezogene Daten zu Support-, und Wartungsleistungen außerhalb EU/EWR verarbeitet werden, stellt der Auftragnehmer sicher,
643	die in Art. 44 ff. DSGVO niedergelegten Bedingungen einzuhalten, um das durch die DSGVO gewährleistete Schutzniveau für natürliche Personen nicht zu untergraben,
644	einen Nachweis zu erbringen, dass das Schutzniveau der DSGVO objektiv nicht untergraben wird (vgl. Art. 44 ff. DSGVO) und die zwischen dem AN und AG vereinbarten Bestimmungen eingehalten werden,
645	zusätzliche technische und organisatorische Maßnahmen umzusetzen und nachzuweisen, die einen Zugriff Dritter, inklusive Behörden, auf personenbezogene Daten wirksam verhindern, sofern dies aufgrund lokaler Rechtsvorschriften und Gepflogenheiten des Drittlandes erforderlich ist,
646	geeignete Garantien nach Art. 46 Abs. 2 DSGVO, insbesondere EU-Standardvertragsklauseln, vor Beginn der Datenverarbeitung abzuschließen und vorzulegen, sofern für das Drittland, in dem die Verarbeitung personenbezogener Daten stattfinden soll, kein Angemessenheitsbeschluss nach Art. 45 DSGVO vorliegt,
647	sofern eine Datenverarbeitung in den U.S.A. stattfinden soll, in jedem Fall - unabhängig einer Zertifizierung unter dem „EU-U.S. Data Privacy Framework“ - EU-Standardvertragsklauseln abzuschließen und vorzulegen.
648	[Hinweis an die Bieter: Für Datenverarbeitungen außerhalb der EU/EWR, die bereits bei Vertragsschluss bekannt sind, sind die oben genannten Nachweise (z.B. TIA, SCC, Zertifizierungen, Datensicherheitskonzepte) mit dem verbindlichen Angebot einzureichen. Anhand dieser wird der Auftraggeber prüfen, ob ein der Sache nach gleichwertiges Schutzniveau für die Daten, die sie an Drittländer übermitteln, objektiv gewährleistet ist. Sofern ein Bieter bei Vertragsschluss keine Nachunternehmer außerhalb der EU/EWR einsetzt und auch keine Daten in Drittländern selbst verarbeitet, sind auch keine Nachweise einzureichen]
649	Umsetzung der Grundprinzipien Privacy by Design und Privacy by Default
650	Der Auftragnehmer stellt sicher, dass die Verarbeitung technisch und organisatorisch so ausgestaltet oder konfigurierbar ist, dass die gesetzlichen Datenschutzgrundsätze (Art. 5 DSGVO) wirksam umgesetzt werden. Dies umfasst insbesondere die Anforderungen an Privacy by Design und Privacy by Default (Art. 25 DSGVO).
651	Umsetzung Betroffenenrechte
652	Der Auftragnehmer stellt sicher, dass die Verarbeitung so gestaltet, dass Rechte der Betroffenen nach der DSGVO realisiert und umgesetzt werden können. Hierzu zählen insbesondere das Recht auf Auskunft, Berichtigung, Löschung, Einschränkung der Verarbeitung, Datenübertragbarkeit.
653	Datenvermeidung und Datensparsamkeit
654	Der Auftragnehmer stellt sicher, dass die Auswahl und Gestaltung von Datenverarbeitungssystemen an dem Ziel ausgerichtet sind, so wenig personenbezogene Daten wie möglich zu verarbeiten. Dies umfasst insbesondere die Möglichkeit personenbezogene Daten zu anonymisieren oder zu pseudonymisieren, soweit dies nach dem Verwendungszweck möglich ist.
655	Mandantenfähigkeit und Mandantentrennung
656	Der Auftragnehmer stellt sicher, dass Anwendungen und Daten des Auftraggebers logisch und/oder physisch von Daten anderer Kunden des Auftragnehmers getrennt sind. Darüber hinaus stellt er sicher, dass auch innerhalb der Anwendung eine Trennung nach Mandanten für verschiedene Kunden des Auftraggebers erfolgen kann.
657	Technische und organisatorische Maßnahmen zum Datenschutz
658	Der Auftragnehmer stellt sicher, dass angemessene technische und organisatorische Maßnahmen nach dem jeweiligen Stand der Technik getroffen werden, die erforderlich sind, um die Ausführung der Vorschriften der DSGVO, insbesondere zur Vertraulichkeit, Integrität und Verfügbarkeit zu gewährleisten.
659	Nachweis hinreichender Garantien über geeignete technische und organisatorische Maßnahmen
660	Der Auftragsverarbeiter bietet hinreichende Garantien, dass geeignete technische und organisatorische Maßnahmen so durchgeführt werden, dass die Verarbeitung im Einklang mit den Anforderungen der DSGVO erfolgt.
661	[Hinweis an die Bieter: bspw. aktuelle Zertifikate (z.B. ITIL, COBIT, ISO 27001, Zertifikate gemäß/nach BSI-Grundschutz (kann auch die ISO 27001 betreffen), ISO, SOCI/II) sind vor Vergabeentscheidung und während der Vertragslaufzeit vorzulegen.]
662	Anforderungen an die Informationssicherheit und Authentifizierung
663	Die grundsätzlichen Anforderungen an die Informationssicherheit, welche der Auftragnehmer bei der Leistungserbringung einhalten muss, ergeben sich aus der Anlage 4 (EVB Informationssicherheit) und dem zugehörigen Anhang 2 (EVB Informationssicherheit – „SaaS PaaS Cloud Services RZ-Betrieb“). In diesem Abschnitt werden ergänzende Anforderungen zur Informationssicherheit geregelt.
664	Schutzbedarf
665	Der Auftragnehmer stellt sicher, dass sein System die Voraussetzung bereitstellt, um im Produktivbetrieb mindestens die folgenden Sicherheitsanforderungen entsprechend der Definitionen des Bundesamtes für Sicherheit in der Informationstechnik erfüllen zu können (Schutzwerte und Schutzklasse):
666	Vertraulichkeit: hoch
667	Integrität: hoch
668	Verfügbarkeit: hoch
669	Die im Rahmen der gesamten Vertragserfüllung verarbeiteten Informationen und Anwendungen unterliegen somit einem hohen Schutzbedarf. Hieraus leiten sich die Anforderungen/Maßnahmen zur Informationssicherheit gemäß Anlage EVB Informationssicherheit inklusive aller Anhänge und ggf. aus weiteren Vertragsanlagen ab.
670	Grundsätzliche Sicherheitsanforderungen
671	Für alle Leistungen wird der AN Sicherheitsleistungen erbringen, die von einem professionellen AN nach dem jeweiligen aktuellen Stand der Technik sowie unter Berücksichtigung von allgemein anerkannten Sicherheitsrichtlinien und Standards (insbesondere ISO-Standards, BSI Grundschutzkataloge) erwartet werden dürfen.
672	Der AN verfügt während der Vertragslaufzeit über aktuelle Zertifizierungen zur Informationssicherheit von unabhängigen Zertifizierungsstellen zu
673	dem Informations-Sicherheitsmanagement (ISO/IEC 27001 oder BSI IT-Grundschutz)
674	dem/den von ihm eingesetzten Rechenzentrum/Rechenzentren (ISO, SOCI/II, etc.)
675	den von ihm bereitgestellten Cloud-Services (BSI - Cloud Computing Compliance Controls Catalogue C5).
676	Prüfberichte zur Informationssicherheit werden mindestens jährlich zur Verfügung gestellt.
677	Bei Sicherheitsvorfällen unterstützt der AN forensische Analysen des AG mindestens durch folgende Aktivitäten: Bereitstellung relevanter Protokolldaten, Zurverfügungstellen forensischer Abbilder von virtuellen Ressourcen oder Bereitstellen einer entsprechenden Schnittstelle, um diese selbst erstellen zu können.
678	Der AN verfügt über ein Sicherheitskonzept entsprechend des Schutzbedarfes, welches die Maßnahmen beschreibt, die der AN im Bereich der Informationssicherheit und der von ihr zu erbringenden Leistungen implementiert hat. Der AN wird dies dem AG auf Anfrage erläutern.
679	Das Sicherheitskonzept wird vom AN regelmäßig überprüft und – soweit erforderlich – an aktuelle, sicherheitsrelevante Entwicklungen angepasst.
680	Die Softwarelösung selbst wird durch den AN risikoorientiert einem Penetrations-Test unterzogen. Die Häufigkeit der Penetrations-Tests bestimmt sich also unter anderem daraus, welche Veränderungen an der Softwarelösung vorgenommen wurden und welcher Bedrohungslage das System unterliegt. Generell ist aber mindestens einmal alle zwei Jahre ein Penetrationstest zu gewährleisten. Dabei erkannte Schwachstellen werden durch den AN behoben und entsprechende Berichte werden dem AG bereitgestellt.
681	Ergänzend unterstützt der AN den Auftraggeber bei der Durchführung eigener abgestimmter Penetrationstests. Der AG wird den AN hierüber grundsätzlich mit einer Frist von mindestens 6 Kalenderwochen im Voraus informieren.
682	Der AN ist verpflichtet, geeignete und aktuelle Sicherheitsmaßnahmen gegen Malware (Virenschutz, Trojaner-Detektion, Spam-Schutz, etc.) auf allen – durch den AN für Supportfälle genutzten – Client-Systemen sowie Serversystemen zu betreiben.
683	Die Softwarelösung kann sowohl auf stationären als auch auf mobilen Endgeräten mit gängigen Lösungen zum Schutz vor Schadsoftware zusammenarbeiten und ohne Einschränkungen betrieben werden.
684	Verschlüsselung
685	Der AN darf keinen inhaltlichen Zugriff auf die Daten des Auftraggebers und der Leistungsbezieher erhalten, um eine Veränderung der Daten oder einen Abfluss von Daten unmöglich zu machen. Daher wird der AN folgende Anforderungen einhalten:
686	Der Auftragnehmer stellt sicher, dass sämtliche Verbindungen zum System durch das Internet ausschließlich über eine sichere Verbindung erfolgen kann. Die Übertragung erfolgt über HTTPS verschlüsselt. Hierzu wird mindestens TLS 1.2 oder höher und Perfect Forward Secrecy unterstützt. Der Auftragnehmer ist verpflichtet, die Sicherheit der verschlüsselten Kommunikation regelmäßig gegen bekannte Schwachstellen zu prüfen und diese unverzüglich zu beseitigen.
687	Während der Vertragslaufzeit wird der AN die angewendete Version der Verschlüsselung auf dem Stand der Technik halten und dem AG mit angemessenem Vorlauf einem von ihm geforderten Stand der Verschlüsselung anbieten. Ein einfacher Wechsel ist zu ermöglichen. Im Bedarfsfall sind Auswirkungen auf ggf. gespeicherte Daten darzustellen (darzustellen ist wahlweise die Rückwärtskompatibilität oder ein Migrationskonzept).
688	Der AN unterstützt Verschlüsselungsmechanismen die den aktuellen Empfehlungen der NIST (National Institute of Standards and Technology) bzgl. Verschlüsselungsalgorithmen gerecht werden.
689	Die Datenablage erfolgt anwendungsseitig verschlüsselt.
690	Ebenso hat die Kommunikation zwischen Services / Anwendungs-Funktionalitäten mit Bezug zum AG gemäß Stand der Technik verschlüsselt zu erfolgen.
691	Jegliche Daten, die beim AN abgelegt / gespeichert werden, müssen mit einem Key des AG in Echtzeit verschlüsselt werden, unabhängig davon, ob die Daten bereits verschlüsselt wurden. Der AN stellt eine Möglichkeit zur Erzeugung von kundenspezifischen Schlüsseln bereit. Der AG hat die Möglichkeit, selbst verwaltete und generierte Schlüssel in das System einzubringen und zur Verschlüsselung der Daten zu nutzen (Bring-your-own-Key).
692	Bei der Wiederherstellung werden die zuvor durch die Softwarelösung verschlüsselten Daten entsprechend entschlüsselt.
693	Der Auftragnehmer stellt ebenso sicher, dass das verwendete Hashverfahren (inkl. Salt) aktuell ist (dem Stand der Technik entspricht). SHA-1 und MD5 sind nicht zugelassene Verfahren und dürfen daher nicht genutzt werden.
694	Die Verwendung eigener, proprietärer Verschlüsselungen ist nicht zulässig.
695	Die Softwarelösung stellt sicher, dass Daten die bei der Nutzung auf mobilen Endgeräten lokal gespeichert werden, verschlüsselt abgelegt werden.
696	Falls eine direkte Datenweitergabe durch die Softwarelösung vorgesehen ist, besteht die Möglichkeit, sensitive Daten verschlüsselt zu übertragen.
697	Authentifizierung an der Serviceschnittstelle
698	Bezüglich Identitymanagement erfüllt der AN folgende Anforderungen:
699	Die Lösung muss per Microsoft Active Directory Gruppenmitgliedschaften für Rollen-, Berechtigungs- und Ressourcenzuweisungen abfragen und im System provisionieren können.
700	Die Lösung kann per API an ein Identity-Management System angebunden werden, um darüber die freigegebenen Rollen-, Berechtigungs- und Ressourcenzuweisungen im System zu provisionieren.
701	Die Lösung muss kompatibel sein mit Microsoft Active Directory zur internen Userverwaltung.
702	Die Lösung muss den SCIM Standard mit Microsoft Entra ID zur internen Userverwaltung nutzen.
703	Bezüglich der Berechtigungsvergabe erfüllt der AN folgende Anforderungen:
704	Die Lösung muss eine rollen- bzw. gruppenbasierte Berechtigungsvergabe unterstützen und dabei die unterschiedlichen Funktionen innerhalb der Applikation rollen- bzw. gruppenscharf trennen.
705	Bezüglich Authentifizierung erfüllt der AN folgende Anforderungen:
706	Die Lösung muss eine SSO Integration über Microsoft Entra ID per SAML oder OAuth/OIDC nutzen können.
707	Sichere Schnittstelle bereitstellen, über die es Services ermöglicht wird, Objekte mittels SAML2.0 oder Standards wie OAUTH2 und OpenID Connect Implementierungen zu authentifizieren.
708	Die Anwender-Authentifikation finden über 2-Faktor-Authentifizierung (2FA) statt.
709	Möglichkeit, mittels Federation die Authentifizierungsdaten des Auftraggebers zu nutzen.
710	Für die Authentifizierung an Services können On-Premise-Benutzeraccounts / Anwenderaccounts aus dem Konzernverzeichnisdienst (derzeit BKU-Active Directory) genutzt werden.
711	Gleichzeitige Anbindung von Benutzern ohne Nutzung des Federation Service (z.B. mittels Standard Login für externe User)
712	Es sollte die Möglichkeit bestehen, Authentifizierungsdaten (Tokens) von Anwender- und Admin-accounts zu verwerfen.
713	Darüber hinaus ist der Zugriff auf die Softwarelösung auch für externe Dienstleister der Deutschen Bahn AG möglich, sofern diese im Auftrag der Deutschen Bahn agieren.
714	Die Kommunikation von System zu System (M2M) ist über gegenseitiger Authentifizierung (beispielsweise mTLS), abgesichert.
715	Logging und Protokollierung
716	Security- und Systemevents sind zu protokollieren bzw. zu loggen. Daher wird der AN folgende Anforderungen einhalten:
717	Entsprechende Logging-Funktionen zur Sicherstellung der internen SLAs sowie der Unterstützung in Fehlerfällen bzw. Root Cause Analysis.
718	Möglichkeit für den AG, Logfiles auf Anforderung zu erhalten und zu archivieren.
719	Anbindung der relevanten Logs an die Logserver des AG ist möglich. Alle Logging-Informationen der Anwendung sind vollständig an einer zentralen Stelle für die fachliche und technische Betriebsführung in geeigneter Form für ein automatisiertes Durchsuchen erreichbar und können automatisiert an eine weitere zentrale Stelle beim AG weitergeleitet werden.
720	Die zu loggenden Parameter sind vom AG konfigurierbar. Das Logging unterstützt mindestens folgende Events:
721	Nutzeraktivität inkl. fehlgeschlagene Anmeldungen
722	Systemaktivitäten
723	Nutzung von administrativen Rechten
724	Konfigurationsänderungen
725	Aufrufe von Programmierschnittstellen
726	Aufzeichnung von Kommunikationsverbindungen
727	Aufzeichnungen erfolgreicher und abgelehnter Systemzugriffsversuche
728	Aufzeichnungen erfolgreicher oder abgelehnter Versuche, auf Daten und Informationen zuzugreifen
729	Aktivitäten von Jobs zum Einlesen von Datenquellen
730	Alarmierung bei Auftreten definierbarer Logging-Werte: Das System ermöglicht bei Auftreten von selbst definierten Mustern in den Logging-Informationen (z.B. "ERROR:") eine automatische Alarmierung an die technische oder fachliche Betriebsführung.
731	Schutz Logging Informationen: Das System schützt die Logging-Informationen vor Veränderung (z.B. durch Administratoren). Änderungen können im Nachhinein nachgewiesen werden. Es werden alle sicherheitsrelevanten Vorkommnisse (z.B. fehlerhafte Anmeldeversuche) protokolliert. Bei kritischen Vorkommnissen / Inhalten in den Logging-Informationen erfolgt automatisch eine Alarmierung an einen definierten Empfängerkreis.
732	Der AN ermöglicht, dass aus der Protokollierung hervorgeht, ob und durch wen personenbezogene Daten verändert wurden.
733	Der AN hat einen Prozess etabliert, wann und wie Informationen aus der Protokollierung zur Löschung personenbezogener Daten dem AG verfügbar gemacht werden.
734	Der AN ermöglicht, dass protokollierte Informationen– bevorzugt automatisiert – nach einer vereinbarten Zeitspanne gelöscht werden. Die Zeitspanne und die Art bzw. der Umfang der Protokollinformationen kann durch die Systemadministration des AGs konfiguriert werden.
735	Die SaaS stellt eine Funktion bereit, mit der die Löschung der Historie, bzw. von Teilen der Historie, an Kataloginhalten unter Berücksichtigung von DSGVO Vorgaben ermöglicht wird.
736	Die SaaS erhebt nur so viele Daten, wie für die Funktion benötigt werden. Angebotene Datenfelder, die vom AG nicht benötigt werden, werden ohne Zusatzaufwand unterdrückt, können ersatzweise gegen Benutzung gesperrt werden.
737	Der Auftragnehmer stellt sicher, dass Protokolldateien für eine Dauer von mindestens 6 Monaten sicher aufbewahrt sind und dem Auftraggeber auf Verlangen zur Verfügung gestellt werden.
738	Der Auftragnehmer stellt sichern, dass stets ausreichend Kapazitäten zur Speicherung der Protokollinformationen zur Verfügung stehen.
739	Der Auftragnehmer stellt sicher, dass angemessene Maßnahmen umgesetzt werden, um die Aufzeichnungen und Informationen vor unbefugtem Zugriff, Verlust, Zerstörung und Fälschung/Veränderung zu schützen.
740	Das System unterstützt die sichere Löschung von Aufzeichnungen nach Ablauf der Aufbewahrungsfrist.
741	Schwachstellen Management und Sicherheitspatches
742	Der AN stellt mindestens einen wöchentlichen Schwachstellenscan der Anwendung des AG sicher.
743	Werden dem AN kritische Sicherheitsschwachstellen (Schwachstellen mit einem CVSS-Wert von 7-10) bekannt, die die Instanzen bzw. Daten des AG betreffen, ist der AG unverzüglich innerhalb von 48 Stunden zu unterrichten, wenn diese nicht behoben werden können.
744	Werden dem AN Sicherheitsschwachstellen bekannt, die die Softwarelösung selbst betreffen, wird der Auftraggeber unverzüglich unterrichtet. Dies beinhaltet neben der Schwachstellenbeschreibung und der Risikoeinschätzung auch Informationen zu Workarounds und einen Zeitplan für die Bereitstellung eines Patches / Updates / Releases.
745	Ein Sicherheitspatch ist nach dessen Verfügbarkeit, wenn nicht kritisch, über das Änderungsmanagement einzuspielen; oder, wenn kritisch (Schwachstellen mit einem CVSSv3-Wert von 7-10), als Notfalländerung/Emergency-Changeschnellstmöglich (Maximalfrist: für alle direkt/ ohne VPN aus dem Internet erreichbaren Systeme 48 Stunden und für alle nicht direkt/ mit VPN erreichbaren Systeme innerhalb von 2 Wochen) einzuspielen.
746	Alle eingesetzten Softwarekomponenten sind durch den AN auf einem Stand zu halten, für den vom jeweiligen Lieferanten Security Patches zur Verfügung gestellt werden.
747	Passwörter
748	Das System ermöglicht, dass sowohl Nutzer des Auftraggebers bzw. des DB Konzerns und auch B2B Kunden bzw. Nutzer außerhalb des DB Konzerns in der Softwarelösung angelegt werden und die zugehörigen Login-Daten, insbesondere Passwörter, über die Software vergeben. Diesbezüglich erfüllt der Auftragnehmer folgende Anforderungen:
749	Der Zugang zum System darf nur nach einer eindeutigen Identifikation und Authentifizierung des Nutzers mit (Account- bzw. Konto-)Name und Passwort erfolgen. Der Zugriff ist durch ein (Nutzer-)Konto zu realisieren. Die Nutzer werden mit Passwort im System lokal administriert oder eine AD Anbindung realisiert.
750	Die Softwarelösung stellt sicher, dass Benutzerkonten durch eine starke Authentifizierung (Zwei-Faktor-Authentifizierung) geschützt werden können.
751	Der Zugriff auf die Anwendung übers Internet bzw. unsichere Netze mussdurch eine starke Authentisierung (Zwei-Faktor-Authentisierung) geschützt erfolgen.
752	Der Zugriff auf die Anwendung über das Intranet kann ebenfalls durch eine starke Authentisierung (Zwei-Faktor-Authentisierung) geschützt werden.
753	Die Softwarelösung ermöglicht, dass nach erfolgreichem Anmelden dem Benutzer die folgenden Informationen angezeigt werden:
754	Datum und Uhrzeit der letzten erfolgreichen Anmeldung;
755	Details aller erfolglosen Anmeldeversuche seit der letzten erfolgreichen Anmeldung.
756	Die Softwarelösung stellt sicher, dass sich Dateninhalte weder in der Softwarelösung noch auf dem Weg bei der Bereitstellung und Übertragung unberechtigt ändern oder verfälschen lassen. Die Softwarelösung verfügt über die dem aktuellen Stand der Technik entsprechenden Funktionalitäten oder unterstützt diese.
757	Die Softwarelösung ermöglicht, dass ein technischer Administrator ein Initial-Passwort direkt aus dem System heraus per E-Mail versenden kann (ausschließlich an die für den Anwender hinterlegte E-Mail-Adresse).
758	Die Softwarelösung stellt sicher, dass keine Passwörter im Sourcecode fest verankert sind. Der Auftragnehmer händigt dem Auftraggeber eine vollständige Liste der Standardpasswörter aus.
759	Die Softwarelösung stellt sicher, dass ein Initial-Passwort für lokale Benutzer direkt nach dem ersten Login-Vorgang geändert werden muss. Die Dauer bis zum Ablauf des Initial-Passwortes ist manuell festlegbar.
760	Die Softwarelösung erzwingt für Passwörter folgende Vorgaben:
761	Die Länge des Passworts muss mindestens 12 Zeichen sein.
762	Die Länge des Passworts muss bis zu 32 Zeichen möglich sein, höhere Passwortlängen sind zulässig.
763	Triviale Passwörter sind nicht zulässig. Hierzu zählen Passwörter, die beispielsweise aus Namen, einem Datum, oder wiederkehrenden, aufeinanderfolgenden Zeichenketten, wie „aaaabbbb“ oder „123456abcde“ zusammengesetzt werden.
764	Die Zeichenbasis eines Passwortes soll möglichst unterschiedlich ausfallen und jeweils mindestens ein Zeichen aus folgenden Gruppen zu verwenden:
765	Groß-Kleinschreibung
766	Sonderzeichen
767	Ziffern
768	Die Software ermöglicht, dass abhängig von der Rolle des Benutzers die Mindestlänge des Passworts festgelegt werden kann.
769	Die Softwarelösung stellt sicher, dass ein Passwort-Wechsel mindestens alle zwölf Monate automatisch initiiert wird. Für den Nutzer ist ein Passwort-Wechsel jederzeit möglich. Die Softwarelösung stellt sicher, dass bei Wechsel des Passwortes ein vorher verwendetes Passwort erst nach fünfmaligem Wechsel wiederverwendet werden kann. Die Softwarelösung berücksichtigt hierbei die zuvor genannten Vorgaben.
770	Das Anmeldeverfahren der Softwarelösung stellt sicher, dass die verwendeten Passwörter nicht ungeschützt angezeigt oder unverschlüsselt über das Netz verschickt werden.
771	Die Softwarelösung stellt sicher, dass eine Passwort-Historie implementiert ist. Die Passwort-Historie verhindert bei Passwortänderungen mindestens die Wiederverwendung der letzten 5 Passwörter des Benutzers. Die historischen Passwörter werden nicht im Klartext aufbewahrt.
772	Die Softwarelösung bietet lokalen Benutzern die Möglichkeit, bei Vergessen des Passworts die Passwortrücksetzung anzufordern. In diesem Fall kann die Softwarelösung dem Benutzer ein neues Initialpasswort an die hinterlegte E-Mail-Adresse schicken.
773	Die Softwarelösung stellt sicher, dass Passwörter nicht im Klartext gespeichert werden. Zulässig ist ausschließlich die Speicherung der durch Nutzung von Hashfunktionen nach Stand der Technik irreversibel umgewandelten („gehashten und salted“) Passwörter.
774	Die Softwarelösung stellt sicher, dass lokal in der Softwarelösung gespeicherte Passwörter mit einem hochwertigen Verfahren gespeichert werden. Die Softwarelösung unterstützt daher mindestens eines der folgenden Verfahren zur Passwortspeicherung:
775	Argon2id
776	scrypt
777	bcrypt
778	PBKDF2
779	Die Softwarelösung ermöglicht, dass bei systematischen Passwort-Angriffen (z.B. über eine Brute-Force-Methode) eine Sicherheitsalarmierung an einen zuständigen Verantwortlichen erfolgt, damit zeitnah wirksame Gegenmaßnahmen getroffen werden können.
780	Es wird sichergestellt, dass die Ausgaben von Systemen, die sensitive Informationen verarbeiten, nur die Informationen beinhalten, die für das Verwendungsziel der Ausgabe notwendig sind, und die Ausgabe nur zu autorisierten Endgeräten und Orten geschickt wird. Die Software stellt sicher, dass Reports dahingehend eingeschränkt sind, dass sie nur das ausgeben, was die Berechtigungsgruppe beinhaltet.
781	Anforderungen an das geschäftliche Kontinuitätsmanagement (BCM)
782	Der Auftragnehmer hat ein angemessenes geschäftliches Kontinuitätsmanagement System (BCMS) oder gleichwertige Vorkehrungen zur Gewährleistung der Geschäftsfortführung etabliert und hält diese(s) während der gesamten Vertragslaufzeit aufrecht. Das BCMS des Auftragnehmers entspricht mindestens den nachfolgenden Anforderungen an die Geschäftskontinuität und orientiert sich an der DIN EN ISO 22301, dem Standard BSI 100-4, oder einer gleichwertigen Anforderung.
783	Notfallkommunikation
784	Zwischen Auftraggeber und Auftragnehmer ist zu vereinbaren, in welchen Fällen eine Notfallkommunikation aufzunehmen ist, z.B. produktbezogen unter der Festlegung von Meldeschwellen.
785	Die Vereinbarung sollte einem „Frühwarnsystem“ entsprechen, d.h. eine Aufnahme der Notfallkommunikation bereits bei einer drohenden Gefährdung der Verfügbarkeit der vertraglich geschuldeten Lieferungen und Leistungen.
786	Ansprechpartner
787	Sachkundiger Ansprechpartner geschäftliches Kontinuitätsmanagement
788	Der Auftragnehmer muss dem Auftraggeber mit Vertragsunterzeichnung für alle Aspekte rund um geschäftliches Kontinuitätsmanagement einen sachkundigen Ansprechpartner (z.B. BC-Manager, Notfallbeauftragter) benennen, der gegenüber dem Auftraggeber auskunftsfähig und auskunftsberechtigt ist.
789	Weitere Ansprechpartner Regelkommunikation
790	Der Auftraggeber kann vom Auftragnehmer verlangen, weitere Ansprechpartner für alle die Geschäftskontinuität betreffenden Angelegenheiten im Kontext der beauftragten Leistung zu benennen (z.B. fachlich, technisch oder betrieblich Verantwortliche). Die Aufgabenverteilung und der Verantwortungsübergang in Bezug auf das BCMS des Auftragnehmers sind zweifelsfrei zu klären. Änderungen teilt der Auftragnehmer dem Auftraggeber unverzüglich mit.
791	Ansprechpartner „Notfallmanagement“
792	Der Auftragnehmer und der Auftraggeber benennen jeweils einen zentralen Ansprechpartner (z.B. operativer Notfallmanager) für die Kommunikation im Notfall, der dem Vertragspartner zu den in der Leistungserbringung geregelten Zeiten zur Verfügung steht.
793	Notfallpläne (Business Continuity Pläne, Geschäftsfortführungspläne)
794	Der Auftragnehmer verpflichtet sich, für seine Leistungen Notfallpläne, Business Continuity Pläne, Geschäftsfortführungspläne oder gleichwertige Regelungen vorzuhalten. Diese regeln, wie Situationen bewältigt werden, die zu einer signifikanten Unterbrechung der im Vertrag festgelegten Leistung führen können und welche Maßnahmen vorgesehen sind, um diese schnell, auf einem vordefinierten Niveau dem Auftraggeber wieder bereitstellen zu können
795	Sicherstellung der Fähigkeit der Zusammenarbeit im Notfall
796	Bei eingetretenem oder drohenden Notfall müssen die Notfallorganisationen von Auftragnehmer und Auftraggeber in der Lage sein, den Notfall gemeinsam zu bewältigen.
797	Neben definierten Rollen und Ansprechpartnern sind die Notfallpläne, Business Continuity Pläne, Geschäftsfortführungspläne oder gleichwertige Regelungen des Auftragnehmers bilateral mit denen des Auftraggebers abzustimmen.
798	Zwischen Auftragnehmer und Auftraggeber sind klare Eskalationsstufen und -wege, sowie Reaktions- und Verfügbarkeitszeiten vertraglich festzulegen.
799	Meldepflichten
800	Der Auftragnehmer informiert den Auftraggeber unverzüglich über Vorfälle und Änderungen, sofern diese die Verfügbarkeit der vertraglich geschuldeten Lieferungen und Leistungen gefährden können. Dies gilt insbesondere für
801	Vorfälle, die im Umfeld des Auftragnehmers oder eines seiner Nachunternehmer aufgetreten sind, sowie
802	Änderungen in seinem BCMS bzw. seiner Notfallvorsorge, seinem Notfallmanagement, seinen Notfallkonzepten und bei seinen Ansprechpartnern.
803	PRODUKT- UND PROZESSBEZOGENE RAHMENBEDINGUNGEN [PPR]
804	Anforderungen an die Nachhaltigkeit
805	Der DB-Konzern hat das Selbstverständnis, nachhaltig zu wirtschaften und Vorreiter im umweltgerechten Handeln zu sein und verfolgt den umweltorientierten Ansatz der Green-IT.
806	Neben der Digitalen Transformation verfolgt der DB Konzern auch die Grüne Transformation, mit dem Ziel klimafreundlicher und nachhaltiger zu werden. Klimaschutz und Nachhaltigkeit sind zentrale Bausteine der Strategie des DB Konzerns. Zur Einhaltung der beim DB-Konzern geltenden Standards ist es erforderlich, dass auch der AN diese Politik und Stoßrichtungen kennt und in seinen Prozessen / bei seiner Leistungserbringung berücksichtigt. Zur Erreichung dieser Ziele ist die DB maßgeblich auf die Unterstützung aller Stakeholder und in diesem Rahmen insbesondere auf ihre Lieferanten angewiesen.
807	Der AN informiert regelmäßig auf Anfrage über seine Nachhaltigkeitsaktivitäten und -zielsetzungen und berichtet über den Stand der Maßnahmen zur Zielerreichung. In Lieferantengesprächen können Entwicklungsziele vereinbart werden.
808	Zur Unterstützung der Ziele des AGs stellt der AN im Zuge seiner Leistungserbringung im Kontext der unter dem Rahmenvertrag stehenden Leistungen sicher, dass diese in Inhalt und Umfang der in den folgenden beschriebenen Anforderungen entsprechen. Der AN verpflichtet sich nachhaltig zu handeln und soweit möglich negative Umweltauswirkungen zu vermeiden, Ressourcen zu schonen, Energie zu sparen und regenerative Energie einzusetzen.
809	Der AN beachtet Grundsätze des Green Coding; entsprechende Ansätze einer ressourcenschonenden, energieeffizienten IT-Entwicklung werden berücksichtigt.
810	Der AN berücksichtigt bei der Auswahl der Rechenzentren, ob diese vorrangig erneuerbaren Energien einsetzen. Bis 2030 sollte der Anteil erneuerbarer Energien in genutzten Rechenzentren 100% betragen.
811	Der AN berücksichtigt bei der Auswahl der Rechenzentren, ob diese energieeffizient betrieben werden. Der PUE-Wert (Power Usage Effectiveness) sollte maximal 1,5 betragen.
812	Der AN informiert auf Anfrage über seine Nachhaltigkeitsaktivitäten und -zielsetzungen und berichtet über den Stand der Maßnahmen zur Zielerreichung.
813	Der AN strebt an, der DB den verursachten Energieverbrauch und die verursachten CO2-Emissionen durch den Betrieb der Anwendung in den Rechenzentren zu berichten.
814	Regelungen der Zusammenarbeit
815	Governance
816	Im Rahmen der Zusammenarbeit zwischen Auftraggeber und Auftragnehmer wird nach Vertragsschluss ein Governance-Modell umgesetzt, welches folgende Anforderungen erfüllt bzw. die Erreichung folgender Ziele ermöglicht.
817	Auftraggeber und Auftragnehmer vereinbaren zur Koordination ihrer Zusammenarbeit und zur Steuerung des Auftragnehmers die Einrichtung einer Governance-Struktur mit drei Ebenen der Zusammenarbeit mit folgenden Schwerpunkten: Management, Steuerung und Betrieb
818	Auf der Management-Ebene steht die Durchsetzung von strategischen Zielen und die Schaffung von Werten im Vordergrund.
819	Auf der Steuerungs-Ebene stehen das Pflegen der Vertragsbeziehung zwischen den Vertragsparteien und das Weiterentwickeln der Funktionalitäten im Vordergrund.
820	Auf der Betriebs-Ebene stehen die Dienstleistungen und die Unterstützung von Funktionalitäten durch den Auftragnehmer im Vordergrund.
821	Auftraggeber und Auftragnehmer werden zu Vertragsbeginn für jede Ebene der Zusammenarbeit Gremien in Form von Boards und Meetings sowie Rollen und Verantwortlichkeiten festgelegen.
822	Soweit einzelne Zuständigkeiten nicht ausschließlich einem anderen Gremium zugewiesen sind, sind die Kontaktpersonen auf der Steuerungs-Ebene die zentralen Ansprechpartner für alle Themen, die den Rahmenvertrag betreffen.
823	Darüber hinaus vereinbaren die Vertragsparteien im Rahmen der Governance ein Eskalationsverfahren gemäß Ziffer 8.2.2 Die vorgenannten drei Ebenen dienen im Rahmen des Eskalationsverfahrens zur gütlichen Einigung bei Meinungsverschiedenheiten.
824	Der Auftraggeber und der Auftragnehmer besetzen für die Dauer der Zusammenarbeit die einzelnen Governance-Gremien mit fachlich geeigneten und autorisierten Mitarbeitern. Die Parteien werden darauf achten, dass die jeweilige personelle Besetzung möglichst für die gesamte Dauer der vereinbarten Vertragslaufzeit Bestand hat und nur aus wichtigem Grund verändert wird. Sie verpflichten sich in diesem Zusammenhang zudem, bereits vor Aufnahme der vertragsgegenständlichen Leistungserbringung die zuständigen Mitarbeiter sowie deren jeweilige Stellvertreter namentlich zu benennen. Bei Änderungen der Verantwortlichkeiten werden die Parteien einander unverzüglich darüber informieren.
825	Der Auftragnehmer stellt einen dedizierten Ansprechpartner zur Verfügung, welcher entsprechendes Know-How für das Unternehmen des Auftraggebers mitbringt und sich nicht bei jedem Incident erneut einarbeiten muss (vergleichbar mit einem Technical bzw. Key Account Manager).
826	Die Vertragsparteien tragen dafür Sorge, dass die von ihnen in der Governance eingesetzten Personen die erforderlichen Befugnisse haben, Erklärungen der anderen Vertragspartei entgegenzunehmen, Erklärungen für die jeweilige Vertragspartei abzugeben und Entscheidungen zu treffen bzw., wenn die Einschaltung eines Gremiums erforderlich ist, diese herbeizuführen.
827	Der Auftragnehmer wird den Auftraggeber bei regelmäßigen Zusammenkünften über alle neuen Funktionalitäten, Prozesse, Methoden, Technologien oder technologischen Trends und Entwicklungen informieren, die der Auftragnehmer selbst entwickelt hat, und von denen zu erwarten ist, dass sie einen Einfluss auf den Geschäftsbetrieb des Auftraggebers oder der Leistungsbezieher haben können.
828	Streitbeilegung
829	Ist aus oder im Zusammenhang mit diesem Rahmenvertrag oder einem Einzelabruf unter diesem Rahmenvertrag Streitigkeiten oder Meinungsverschiedenheiten („Streitigkeit“) entstanden, so werden sich die Vertragsparteien bemühen, diese auf gütlichem Wege beizulegen.
830	Basierend auf den Regelungen in Ziffer 8.2.1 ist zunächst stets die Herbeiführung einer einvernehmlichen Lösung auf der jeweiligen Ebene (Management, Steuerung, Betrieb) anzustreben.
831	Kommt es auf der ersten Eskalationsstufe (Betriebs-Ebene) nicht innerhalb einer angemessenen Zeit zu einer einverständlichen Regelung, so ist die Streitigkeit an die zweite Eskalationsstufe weiterzuleiten.
832	Kommt es auf der zweiten Eskalationsstufe (Steuerungs-Ebene) nicht innerhalb einer angemessenen Zeit nach Weiterleitung der Streitigkeit zu einer einverständlichen Regelung, so ist die Streitigkeit an die dritte Eskalationsstufe weiterzuleiten.
833	Kommt es auf der dritten Eskalationsstufe (Management-Ebene) nicht innerhalb einer angemessenen Zeit nach Weiterleitung der Streitigkeit zu einer einverständlichen Regelung, gilt das Eskalationsverfahren als gescheitert.
834	Jede der beiden Vertragsparteien ist berechtigt, eine Frist zur Beilegung der Streitigkeit zu setzen oder direkt die nächsthöhere Eskalationsstufe einzuschalten, wenn eine besondere Dringlichkeit besteht oder Einigung auf der zunächst zuständigen Eskalationsstufe unwahrscheinlich erscheint.
835	Die Vertragsparteien sind berechtigt, im Rahmen des Eskalationsverfahrens die jeweiligen fachlichen Ansprechpartner sowie Ansprechpartner unterer Eskalationsstufen hinzuzuziehen. Die Vertragsparteien sind berechtigt, auf jeder Eskalationsstufe, insbesondere aber für den Fall, dass es auf keiner Eskalationsstufe zu einer Einigung kommt, vor Beschreiten des Rechtswegs einen Mediator mit der Durchführung einer Mediation zu beauftragen. Soweit die Vertragsparteien nichts Abweichendes vereinbaren, werden Auswahl des Mediators und Durchführung der Mediation nach den Regeln des EUCON Europäisches Institut für Conflict Management e.V., Brienner Str. 9, 80333 München erfolgen.
836	Vorbehaltlich nachfolgendem lit. (i) ist jede Vertragspartei erst nach erfolglosem Durchlaufen des Eskalationsverfahrens berechtigt, den ordentlichen Rechtsweg zu beschreiten.
837	Das Recht der Vertragsparteien, um einstweiligen Rechtschutz nachzusuchen, bleibt von der Pflicht, ein Eskalationsverfahren durchzuführen, unberührt.
838	Während der Dauer der gütlichen Beilegung von Streitigkeiten unter diesem Rahmenvertrag oder der Durchführung einer gerichtlichen Auseinandersetzung im Zusammenhang mit diesem Rahmenvertrag wird der Auftragnehmer ungeachtet der bestehenden Streitigkeit weiter die Leistungen erbringen und seine sonstigen Verpflichtungen aus diesem Rahmenvertrag bzw. dem jeweiligen Einzelabruf erfüllen.
839	Exitmanagement
840	Allgemeine Anforderungen an Exitmanagement
841	Allgemeine Anforderungen
842	Der AN wird im Zusammenhang mit der Planung und Durchführung der Überleitung der Leistungen auf den AG oder einen/mehrere Nachfolgedienstleister jegliche angemessene Unterstützung leisten, die von dem AG angefordert wird (insgesamt „Exit Unterstützungsleistungen“). Der AN wird dabei im Rahmen dessen alles Angemessene tun, um eine reibungslose und störungsfreie Überleitung der Leistungen zu ermöglichen. Der AN verpflichtet sich zu proaktiver und professioneller Zusammenarbeit mit dem AG sowie dem bzw. den (möglichen) Nachfolgedienstleister(n).
843	AN erbringt die Exit Unterstützungsleistungen unabhängig vom Grund der Vertragsbeendigung. Dies gilt auch im Fall einer Kündigung aus wichtigem Grund durch den AN oder den AG.
844	Einzelne Unterstützungsleistungen
845	Die vom AN zu erbringenden Exit Unterstützungsleistungen umfassen, je nach Anforderung des AGs, insbesondere das Folgende:
846	AN wird den Zugriff auf alle Daten und Informationen bereitstellen, die für die Überleitung der Leistungen erforderlich sind;
847	AN trifft geeignete Vorkehrungen zur reibungslosen und störungsfreien Überleitung und erstellt vor Vertragsende entsprechende Pläne zum Übergang;
848	Der Auftragnehmer verpflichtet sich, bis zum ersten Leistungsübergabezeitpunkt einen Plan für die Überleitung („Exit-Plan“) zu erstellen und an den Auftraggeber zu übergeben. Jede Fassung des Exit-Plans unterliegt dem Veto-Recht durch den Auftraggeber. Im Fall eines Vetos wird der Auftraggeber dieses detailliert begründen und den Auftragnehmer zur Anpassung auffordern.
849	Ferner ist der Auftragnehmer verpflichtet, dem Auftraggeber innerhalb von fünfzehn (15) Werktagen, nachdem er eine (Teil-)Kündigung erhalten hat oder 6 Monate vor Ende der maximalen Laufzeit des Rahmenvertrages, einen Vorschlag für eine überarbeitete Version des Exit-Plans zu unterbreiten, welche alle Änderungen enthält, die erforderlich sind, um die besonderen Anforderungen der anstehenden Überleitung zu erfüllen. Dies gilt insbesondere bei Teilkündigungen.
850	Der Auftragnehmer muss im Exit-Plan detailliert beschreiben, wie die betroffenen Vertragsleistungen und die ihnen zugrundeliegenden Prozesse des Auftragnehmers im Falle einer Beendigung von (Teil-)Leistungen aus der Sphäre des Auftragnehmers herausgelöst und an den Auftraggeber oder an Folgeanbieter übergeben werden können; dies schließt ein Migrationskonzept ein. Der Auftraggeber sowie ein etwaiger Folgeanbieter muss mit diesem Plan in die Lage versetzt werden, die endenden Vertragsleistungen in seine Sphäre zu übernehmen. Daraus dürfen sich nur unwesentliche Einschränkungen hinsichtlich der Kontinuität und Qualität der ausgegliederten Aktivitäten und Prozesse ergeben. Der Exit-Plan enthält, neben weiteren Inhalten entsprechend den Anforderungen des Auftraggebers, insbesondere Folgendes:
851	eine Beschreibung der zu übergebenden endenden Vertragsleistungen
852	eine detaillierte Beschreibung der von dem Auftragnehmer zum Zwecke der Überleitung zu erbringenden Vertragsleistungen
853	eine Beschreibung von Mitwirkungsobliegenheiten des Auftraggebers oder des Folgeanbieters
854	einen detaillierten Meilensteinplan für die Überleitung
855	einen detaillierten Ressourcenbedarf, aufgeteilt nach Ressourcen, die von dem Auftragnehmer, dem Auftraggeber, etwaigen Folgeanbietern oder einem sonstigen vom Auftraggeber benannten Dritten zu stellen sind
856	eine Beschreibung der erforderlichen Zusammenarbeit (z.B. Zeitrahmen, Rollen, Skills) zwischen den an der Überleitung beteiligten Parteien
857	alle Daten, Verträge mit Unterauftragnehmern des Auftragnehmers und/oder anderen Dritten sowie alle anderen Gegenstände, die vom Auftragnehmer für die Erbringung der endenden Vertragsleistungen genutzt werden und deren Übertragung an den Auftraggeber im Hinblick auf die Überleitung erforderlich oder nützlich sein könnten (Asset-Liste)
858	jegliche andere, wesentlichen Informationen in Bezug auf die Überleitung
859	das Format aller vom Auftragnehmer im Zuge der Überleitung zur Verfügung gestellten Informationen.
860	Der AN verpflichtet sich, sämtliche Aufgaben zu erledigen, die ihm im Exit-Plan zugewiesen werden, und zwar zu den in der jeweils aktuellen Fassung des Plans vorgesehenen Terminen. Die Überleitung ist so auszuführen, dass (i) etwa damit verbundene operationelle Risiken soweit wie möglich ausgeschlossen oder minimiert werden, (ii) die Qualität der überzuleitenden Leistungen vor und nach dem Überleitungszeitpunkt unbeeinträchtigt bleibt und (iii) der AG bzw. der/die Nachfolgedienstleister in der Lage ist/sind, die überzuleitenden Leistungen ab dem Überleitungszeitpunkt in einem stabilen Zustand zu übernehmen.
861	Überleitungszeitpunkt wird der AN dem AG und, soweit vom AG gewünscht, dem/den Nachfolgedienstleister(n) sämtliche dem AG und den Leistungsbeziehern gehörenden oder zustehenden Daten, soweit diese nicht bereits in geeigneter Form in Systeme des AGs oder eines Nachfolgedienstleisters überspielt worden sind, in einem vereinbarten oder – wenn nichts vereinbart wurde – in einem marküblichen Format zur Verfügung stellen, das es dem AG und dem/den Nachfolgedienstleistern ermöglicht, die Daten des AGs und der Leistungsbezieher in ein marktgängiges System zu übertragen.
862	an Exitmanagement für Saas („Außerbetriebnahme“)
863	Die Außerbetriebnahme, auch als Stilllegung oder Deaktivierung bezeichnet, bezieht sich auf den Prozess des Abbaus oder der Entfernung von IT-Systemen oder Teilen von diesen.
864	Anforderungen an Exitmanagement für SaaS
865	Allgemeine Regelungen
866	Der Auftragnehmer garantiert die Erfüllung der geschuldeten Liefer- und Leistungsverpflichtung über die gesamte Laufzeit des Rahmenvertrages hinweg einschließlich der vom Auftraggeber etwaig gezogener Verlängerungsoptionen.
867	Der Auftragnehmer sichert dem Auftraggeber zu, dass er nach Aufforderung durch den Auftraggeber entsprechend dem Außerbetriebnahme-Konzept (siehe Ziffer 8.3.2.4) seine Liefer- und Leistungsverpflichtung fortführt, wenn dies für eine geordnete Ablösung des Produktes im Interesse einer Sicherstellung der Geschäftstätigkeit des Auftraggebers erforderlich ist. Hinweis: Eine Beauftragung erfolgt nicht im Rahmen dieser Ausschreibung, sondern bei Bedarf nachgelagert und darf daher nicht im Rahmen dieser Ausschreibung im Preisblatt berücksichtigt werden. Für die Beauftragung dienen die im Preisblatt hinterlegten Positionen.
868	Migrations- und Verifikations-Funktion
869	Der Auftragnehmer stellt dem Auftraggeber spätestens sechs Monate vor dem ihm zuvor benannten Außerbetriebnahme-Termin eine softwarebasierte Migrations- und Verifikations-Funktion (ggf. als eigenes Tool) für den vollständig automatisierten Export sämtlicher Datenbestände, Geschäftsregeln (Business Rules), etc. des Produkts bereit. Zwischen Auftraggeber und Auftragnehmer werden dazu abzustimmende, neutrale Datenformate definiert, die auf einem vom Auftraggeber beizustellenden Datenträger bereitgestellt werden.
870	Dieses Migrations- und Verifikationstool erfüllt die Anforderungen der Norm RTCA DO-330/EUROCAE ED-215.
871	Unterstützung durch qualifiziertes Personal
872	Der Auftragnehmer stellt auf gesonderte Aufforderung des Auftraggebers für den vollständig automatisierten Export sämtlicher Datenbestände, Geschäftsregeln (Business Rules), etc. des Produkts mittels des Migrations- und Verifikationstools qualifiziertes Personal zur Unterstützung der Außerbetriebnahme an einem oder mehreren vom Auftraggeber zuvor zu benennenden Einsatzort(en) bereit.
873	Außerbetriebnahme-Konzept
874	Der Auftragnehmer übergibt dem Auftraggeber zwölf Monate vor dem ihm zuvor benannten Außerbetriebnahme-Termin ein detailliertes Konzept für die Planung, Vorbereitung, Durchführung und den Abschluss der Außerbetriebnahme des Produkts. Hierbei muss ein unterbrechungsfreier Betrieb gewährleistetet werden. Der Auftraggeber prüft das Außerbetriebnahme-Konzept und erteilt bei korrekter und qualitätsgerechter Umsetzung dafür die Freigabe.
875	Löschung von Daten nach Rückführung
876	Ergänzend zur Ziffer 5.18 der EVB Informationssicherheit gelten folgende Anforderungen:
877	Nach vom Auftraggeber bestätigter erfolgreicher Rückführung gewährleistet der Auftragnehmer, dass unverzüglich sämtliche im Zusammenhang mit dem Auftragsverhältnis stehenden Daten an allen primären und sekundären Standorten des Auftragnehmers und seiner Subdienstleister nachhaltig und sicher gelöscht und vernichtet werden, sodass diese nicht wiederhergestellt werden können.
878	Ausnahmen bestehen nur bei Daten, zu deren Aufbewahrung der Auftragnehmer gesetzlich verpflichtet ist. Der Auftragnehmer weist dies auf Verlangen des Auftraggebers nach.
879	Unterlagenvernichtung
880	Bei Vertragsbeendigung muss der AN alle Unterlagen, Belege, Datenträger und Daten des AG in einem zugänglichen und lesbaren elektronischen Format bzw. archivierte Belege im Original an den AG herausgeben oder nach entsprechender schriftlicher Aufforderung durch den AG unwiederbringlich löschen/vernichten. Gesetzliche Aufbewahrungspflichten des AN bleiben unberührt.
881	Anforderungen an Exitmanagement für IT-Dienstleistungen („Vorgaben Leistungsende“ / „Transition“)
882	Der Auftragnehmer stellt sicher, dass der Erfüllungsgehilfe am letzten Einsatztag einer Beauftragung alle zur Verfügung gestellten Betriebsmittel (z.B. PC, Laptop, Telefon, Zugangskarten, Kantinenkarten, Ausweise) unaufgefordert an den jeweiligen AG übergibt und sämtliche eingesetzte Lizenzen/Softwareprodukte abmeldet, sofern nichts anderes mit dem AG vereinbart worden ist.
883	Erfolgt eine Übergabe der Leistungen des Auftragnehmers an interne Mitarbeiter des AG oder an einen anderen Dienstleister (Transition), ist der AN verpflichtet, diese Transition zu unterstützen und alle relevanten Arbeitsergebnisse, Methoden und Prozesse entsprechend zu übergeben. Die Übergabe ist vom AN zu dokumentieren und vom AG zu bestätigen. Das Übergabeformat wird vom AG im Vorfeld definiert.
884	Der AN verpflichtet sich, den AG und ggf. den vom AG benannten Dritten bei dem Übergang der Vertragsleistung umfassend zu unterstützen, insbesondere bei der Erledigung aller im Zeitpunkt der Vertragsbeendigung noch offenen Vorgänge. Der AN erteilt erforderliche Auskünfte.
885	Bei Vertragsbeendigung wird der AN alle vom AG erhaltenen bzw. für diesen erstellte Unterlagen, Belege, Datenträger und Daten des AG in einem zugänglichen und lesbaren elektronischen Format bzw. archivierte Belege im Original an den AG herausgeben oder nach entsprechender schriftlicher Aufforderung durch den AG unwiederbringlich löschen/vernichten. Ein Zurückbehaltungsrecht besteht nicht. Gesetzliche Aufbewahrungspflichten des AN bleiben unberührt.
886	Der AN weist die ordnungsgemäße Löschung bzw. Vernichtung gegenüber dem AG nach. Dem AG entstehen für die definierten Unterstützungs- und Mitwirkungsleistungen des AN gemäß während der Überleitungsphase keine zusätzlichen Kosten.
887	Leistungen des AN, die über die hier definierten Unterstützungs- und Mitwirkungsleistungen hinausgehen, werden mit angemessenem Vorlauf vom AG definiert und vom AN gegen Vergütung gemäß den vereinbarten Tagessätzen angeboten.
888	Produktbezogene Schulung und unterstützende Dienstleistungen
889	Schulungsleistungen
890	Neben den Schulungen im Rahmen des Migrationsprojektes (siehe Kapitel6) kann der Auftraggeber Schulungsleisten während der Vertragslaufzeit mit angemessenem Vorlauf zu den Konditionen aus dem Preisblatt (Anlage 2, Position 4.3)) bestellen. Die in diesem Kapitel definierten Anforderungen gelten sowohl für die Schulungen im Rahmen des Integrationsprojekt als auch für die weiteren Schulungen während der Vertragslaufzeit. Der Auftragnehmer stellt hierbei sicher, dass in den Schulungsinhalten und Schulungsunterlagen der aktuelle Stand der Anwendung berücksichtigt ist.
891	Der Auftragnehmer verfügt über ein Schulungskonzept und Schulungsangebot über die fach- und sachgerechte Nutzung der Lösung, welches der Auftraggeber in Anspruch nehmen kann. Das Schulungsangebot des Auftragnehmers umfasst mindestens
892	Basisschulungen für Anwender, welche eine allgemeine Einführung in die Lösung beinhalten, Kenntnisse der Grundlegenden Funktionalitäten vermitteln und Mitarbeiter des AG mit der Struktur, der Navigation und dem Layout vertraut machen.
893	Schulungen für fachliche Administratoren (Fachliche Betriebsführung des Auftraggebers), die zusätzlich zur Basisschulung noch erweiterte Funktionen einer fachlichen Betriebsführung erlernen sollen, wie das Anlegen oder Löschen von Usern und Mandanten sowie die Vergabe von Rechten, das Löschen oder Archivieren bestimmter Daten usw.
894	Schulungen für Multiplikatoren / Key-User des Auftraggebers (Train-the-Trainer), die in die Lage versetzt werden, Schulungen mit gleichem Inhalt durchzuführen, wie Trainer des Auftragnehmers. Hierzu ist die Vermittlung zusätzlicher Inhalte notwendig, wie Musterlösungen von Übungsbeispielen usw.
895	Mit den genannten Schulungen müssen die Teilnehmer grundsätzlich befähigt sein, alle definierten Funktionalitäten der Bedienoberfläche, der definierten Prozessschritte, der dazugehörigen Anwendungsfälle sowie der Betriebssystemoperationen (für die technische Betriebsführung relevant) selbstständig durchführen zu können. Der Auftragnehmer stellt hierzu geeignete Trainer bereit.
896	Dabei werden folgende Schulungsarten angeboten:
897	Remote-Schulungen
898	Alle Schulungen werden nach Form, Inhalt, Reihenfolge, Zielgruppe, Umfang sowie Durchführungstermin zwischen Auftraggeber und Auftragnehmer spätesten zwei Wochen vor dem Schulungsbeginn feinabgestimmt.
899	Alle Schulungsmaßnahmen, die sich an Anwender des Systems richten, sind in deutscher Sprache (C1 Niveau) - gemäß dem gemeinsamen europäischen Referenzrahmen für Sprachen (GER) - abzuhalten. Schulungsmaßnahmen, die sich an Administratoren oder Key-User richten, sind in deutscher Sprache abzuhalten.
900	Die in den Schulungsmaßnahmen verwendeten Schulungsunterlagen werden in deutscher Sprache C1 - gemäß dem gemeinsamen europäischen Referenzrahmen für Sprachen (GER) - zur Verfügung gestellt. Dies umfasst vor allem, aber nicht ausschließlich:
901	Folien
902	Handreichungen
903	Handbücher
904	Aufgabenblätter aus den praktischen Übungen und Tutorials
905	Der Auftragnehmer stellt sicher, dass die Schulungsunterlagen durch den Auftraggeber an beliebiger Stelle durch kundenspezifische Ergänzungen erweitert und gepflegt werden sowie in Auftraggeber-internen Schulungen weiterverwendet werden können. Hierzu stellt der Auftragnehmer dem Auftraggeber die Schulungsunterlagen zeitnah nach deren Verwendung bzw. Aktualisierung in einem veränderbaren Format (z.B. DOC/DOCX- oder PPT/PPTX-Format) zur Verfügung. Die Verwertungsrechte an den Schulungsunterlagen werden dem Auftraggeber übertragen.
906	Der Auftragnehmer stellt zu seinem System Informationsmaterialien für die Anwendungsunterstützung der Anwender zur Verfügung. Die Informationsmaterialien liegen in Form von Arbeitshilfen, Handlungsanweisung, Schritt-für-Schritt Anleitungen o.Ä. für die wichtigsten Standardprozesse vor. Der Zugriff auf die Informationsmaterialien soll Endgeräte- und Betriebssystem unabhängig sein und gängige Endgeräte werden unterstützt.
907	Bei Änderungen an der Benutzeroberfläche und Ergänzungen des Systems mit zusätzlichen Funktionalitäten werden die Informationsmaterialien durch den Auftragnehmer aktualisiert und die aktualisierte Fassung dem Auftraggeber frei zur Verfügung gestellt.
908	Das System des Auftragnehmers verfügt über die Möglichkeit einer Wissensdatenbank. Die Datenbank gibt den Benutzern über einen Katalog mit Fragen und zugehörigen Antworten/Lösungen die Möglichkeit, Fragen oder Probleme selbstständig zu klären. Dem Benutzer steht hierzu eine Hilfefunktion und / oder eine Suchfunktion zur Verfügung stehen, mit deren Hilfe er über Schlagwörter die Datenbank durchsuchen kann.
909	Die Wissensdatenbank steht über den gesamten Nutzungszeitraum zur Verfügung. Bei Änderungen an der Benutzeroberfläche und Ergänzungen des Systems mit zusätzlichen Funktionalitäten wird die Wissensdatenbank durch den Auftragnehmer aktualisiert und die aktualisierte Fassung dem Auftraggeber frei zur Verfügung gestellt.
910	Der Auftragnehmer führt für seine Kunden Veranstaltungen (z.B. „Anwenderforen“) durch, bei denen er seine Kunden über durchgeführte und geplante Neuerungen informiert und den Kunden Möglichkeiten zu Vernetzung und Austausch untereinander bietet.
911	IT-Dienstleistungen
912	Neben dem Integrationsprojekt sind in Bezug auf die Software im Laufe der Zusammenarbeit ggf. ergänzende und produktbezogene Dienstleistungen des AN erforderlich. Dies können auch spezifische Weiterentwicklungsleistungen an der Software für den Auftraggeber sein, z.B. zusätzliche Schnittstellen.
913	Es besteht die Möglichkeit, im Bedarfsfall beim Auftragnehmer zu dem im Preisblatt (Anlage 2, Positionen 4.1-4.3 & 4.4) vereinbarten Tagessätzen Unterstützungsleistungen auf dienstvertraglicher Basis oder auf werkvertraglicher Basis zu beziehen, z.B. für die Planung, Implementierung und Validierung einer funktionsfähigen Lösung oder produktbezogene Beratung.
914	Im Bedarfsfall stellt der Auftraggeber eine entsprechende Anfrage beim Auftragnehmer und der Auftragnehmer sendet dem AG innerhalb einer Woche oder einer vom AG definierten angemessenen Frist ein entsprechendes Angebot zu.
915	Der Auftraggeber kann auf Basis dieses Angebots die Dienstleistungen bestellen und der Auftragnehmer stellt den Start der Dienstleistungen durch entsprechend qualifizierter Fachkräfte innerhalb von zwei Wochen sicher.
916	Der Auftragnehmer stellt sicher, dass er mindestens die nachfolgend genannten Rollen mit den erforderlichen Qualifikationen und Kenntnissen bereitstellt:
917	Fachlicher Berater (fachlicher Experte, ähnliches): Der „Fachliche Berater“ ist zentraler Ansprechpartner für die Fachkonzeption auf Seiten des Auftragnehmers und koordiniert inhaltlich die Erarbeitung fachlicher Lösungen und deren Dokumentation. Er hat einen umfassenden fachlichen Überblick über die Softwarelösung (Workflows, prozessuale Schnittstellen bspw. zwischen verschiedenen Modulen innerhalb des Systems, Konfigurationsmöglichen). Der Fachliche Berater besitzt umfassende Kenntnisse in den Fachdomänen der Lösung. Er bringt die Fähigkeit mit, die Funktionen des Systems auszuschöpfen und den Auftraggeber hinsichtlich aller fachlichen Umsetzungsmöglichkeiten zu beraten und achtet darauf, dass die Dokumentationsstandards hinsichtlich Form und Tiefe eingehalten werden.
918	Technischer Berater (technischer Architekt, technischer Experte, ähnliches): Der „Technische Berater“ unterstützt den Auftraggeber bei der Erstellung und Umsetzung von technischen Konzepten und der Erarbeitung technischer Lösungen. Er hat einen umfassenden Überblick über die technische Architektur, Schnittstellen, Plattformen und technischem Design auf Seiten des Auftragnehmers. Der technische Berater ist zudem in der Lage, den Auftraggeber bei der initialen Bereitstellung der angebotenen Softwarelösung zu unterstützen. Der Technische Berater berät den Auftraggeber bei der Nutzung der vom System angebotenen Schnittstellen und bei der Erarbeitung der technischen Cloud-Lösungsarchitektur und des technischen Designs gemäß den Anforderungen und der Erstellung technischer Cloud-Architekturkonzepte im Projektkontext (wie Datenbankdesign, Komponentenspezifikationen, technische Schnittstellen- und Servicebeschreibungen) gemäß den Standards des Auftraggebers.
919	Zusätzliche Betriebsunterstützung (Betriebsberater, Service-Experte, Application Support Experte, ähnliches): Die „Zusätzliche Betriebsunterstützung“ unterstützt den Auftraggeber bei der Sicherstellung eines stabilen, sicheren und performanten Betriebs der bereitgestellten Softwarelösung. Sie ergänzt die regulären Support- und Betriebsleistungen bei erhöhtem Unterstützungsbedarf, betrieblichen Sondersituationen, komplexen Fragestellungen oder temporären Ressourcenengpässen auf Seiten des Auftraggebers.
920	Die Zusätzliche Betriebsunterstützung verfügt über fundierte Kenntnisse der eingesetzten Softwarelösung, ihrer Betriebsprozesse, Konfigurationen, Schnittstellen sowie der zugrundeliegenden technischen und organisatorischen Betriebsabläufe. Sie unterstützt den Auftraggeber bei der Analyse und Behebung von Betriebsstörungen, bei der Ursachenanalyse von Fehlerbildern, bei der Durchführung von Wartungs- und Anpassungsmaßnahmen sowie bei der Umsetzung betrieblicher Anforderungen.
921	Darüber hinaus berät die Zusätzliche Betriebsunterstützung den Auftraggeber hinsichtlich bewährter Vorgehensweisen für den Applikationsbetrieb, die Serviceerbringung, das Monitoring, das Incident-, Problem- und Changemanagement sowie die kontinuierliche Optimierung des Betriebs. Sie wirkt bei Bedarf an Betriebsbesprechungen, technischen Abstimmungen, Release- und Deploymentszenarien, Migrationen sowie der Erstellung und Fortschreibung betrieblicher Dokumentationen mit.
922	Die Zusätzliche Betriebsunterstützung ist in der Lage, kurzfristig betriebliche Zusatzaufgaben zu übernehmen, den Wissenstransfer sicherzustellen und den Auftraggeber bei der Gewährleistung der vereinbarten Service- und Qualitätsanforderungen zu unterstützen. Sie arbeitet eng mit den fachlichen und technischen Ansprechpartnern des Auftraggebers sowie den beteiligten Support- und Betriebseinheiten des Auftragnehmers zusammen.
923	Alle Fachkräfte des Auftragnehmers, welche in den Rollen Projektleiter oder Fachlicher Berater beauftragt sind, verfügen mindestens über das Sprachvermögen C1 in deutscher Sprache - gemäß dem gemeinsamen europäischen Referenzrahmen für Sprachen (GER).

Anlage_ 1_Leistungsbeschreibung_AiM_Tab.docx