| Anlage 1 Anforderungen und Vorgaben zur Leistungserbringung | |
| EU Vergabe CMS Verhandlungsverfahren | |
| ID: | Anlage 1 |
| Erste Vertragspartei: | DB Systel GmbH |
| Zweite Vertragspartei: | Auftragnehmer - Bietername [Bitte eintragen] |
| Datum: | 24.08.2026 |
| Version: | 1.0 |
| Autor: | Auftraggeber |
| Status: | Zur Abstimmung / Veröffentlicht / Final |
Instruktionen an die Bieter
Das vorliegende Dokument dient als Antwortvorlage für die Anlage „Lesitungsbeschreibung“ 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.3 und 11.4.2 der Bewerbungsbedingungen.
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 15.3.2.1 und 15.3.2.2.1 der Bewerbungsbedingungen 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 Vertragspassage im Rahmen der verbindlichen Angebote hingewiesen – siehe insb. Ziffer 15.3.2.2.1 der Bewerbungsbedingungen.
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.1 Kurzvorstellung Auftraggeber 6
1.2 Ausgangssituation und Leistungsgegenstand 6
1.3 Funktionen und Leistungen des Auftragnehmers 7
1.4 Eigenleistung des Auftraggebers 8
2 Funktionale Anforderungen an die Sofwarelösung [FAN] 9
2.1 Allgemeine Anforderungen an das System 9
2.2 Benutzerfreundlichkeit und Redaktionskomfort 16
2.3 Flexibilität und Modularität 22
2.4 Workflow‑ und Lifecycle‑Management 24
2.5 Mehrsprachigkeit und Lokalisierung 27
2.6 Integration und Anbindung externer Quellen 28
2.7 Sicherheit, Datenschutz und Compliance 29
2.8 Analyse, Optimierung und Qualitätssicherung 33
2.9 Personalisierung und Interaktion 37
3 Architektur und Schnittstellen [AST] 40
3.1 IST- und Zielarchitektur 40
3.2 Anforderungen an die Architektur 42
3.3 Allgemeine Anforderungen an Schnittstellen 48
3.4 Anforderungen an bahninterne Schnittstellen 56
4 Usability und Dokumentation [UDO] 56
5 Service-Level, Support, Wartung und Fehlerbehebung [SUP] 64
5.3 Fehlerklassen / Incident-Prioritäten, Reaktionszeiten und Fehlerbehebungszeiten 67
5.4 Behebung und Dokumentation von Fehlern 71
5.5 Messung und Reporting von Service-Leveln 72
5.6 Kompensation / Auswirkung bei Nicht-Einhaltung der SLA 72
5.7 Allgemeine Anforderungen zu Service-Leveln 74
5.8 Wartung / Weiterentwicklung 75
6 INtegration, Migration und Test [IMT] 79
6.1 Integrationsanforderungen 79
6.2 Flexible Migrationsanforderungen 80
7 Sicherheitsrelevante Anforderungen [SAN] 82
7.1 Datenschutzanforderungen 83
7.2 Anforderungen an die Informationssicherheit und Authentifizierung 90
7.3 Anforderungen an das geschäftliche Kontinuitätsmanagement (BCM) 101
8 PRODUKT- UND PROZESSBEZOGENE RAHMENBEDINGUNGEN [PPR] 103
8.1 Anforderungen an die Nachhaltigkeit 103
8.2 Regelungen der Zusammenarbeit 104
8.4 Produktbezogene Schulung und unterstützende Dienstleistungen 114
8.5 KI-spezifische Leistungsanforderungen für KI-Technologie 120
| 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 | Ausgangssituation und Leistungsgegenstand | ||
| 7 | Der AG stellt heute bereits über sein Portfolio eine Softwarelösung (Anbieter CoreMedia) im Bereich Consent Management (OnPremise) allen Konzerngesellschaften der Deutschen Bahn AG zur Verfügung. Ein Consent Management System soll auch zukünftig den Konzerngesellschaften über das Portfolio der DB Systel GmbH zur Verfügung gestellt werden | ||
| 8 | 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. | ||
| 9 | Die Leistungen, welche nicht Gegenstand der zu erbringende Leistungen des ANs sind und sich in der Hoheit des AG befinden, sind Ziffer 1.4 („Eigenleistungen des Auftraggebers“) zu entnehmen. | ||
| 10 | Funktionen und Leistungen des Auftragnehmers | ||
| 11 | 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. | ||
| 12 | 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. | ||
| 13 | Der Auftragnehmer stellt eine kontinuierliche Weiterentwicklung der Softwarelösung, insbesondere Anpassungen an gesetzliche Änderungen, sicher und stellt sie dem Auftraggeber zur Verfügung. | ||
| 14 | 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) mit Anhängen 13.1 bis 13.2 beschrieben. | ||
| 15 | Der AN erbringt Dienstleistungen im Rahmen des Einführungs-/Integrationsprojekts und des Migrationsprojekts (siehe Kapitel 7). | ||
| 16 | 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. | ||
| 17 | Der AN stellt eine umfangreiche Dokumentation seiner Softwarelösung zur Verfügung, die alle Funktionalitäten ausführlich und transparent beschreibt. | ||
| 18 | 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. | ||
| 19 | Eigenleistung des Auftraggebers | ||
| 20 | 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: | ||
| 21 | Fachliche Betriebsführung: Vollständiger Anwenderbetrieb inkl. Rollen- und Rechteverwaltung | ||
| 22 | First-Level Support innerhalb des Konzern Deutsche Bahn AG | ||
| 23 | Lesehinweise | ||
| 24 | Die nachfolgenden Lesehinweise sollen die Verständlichkeit und Nachvollziehbarkeit des Dokuments fördern. | ||
| 25 | Gender Disclaimer | ||
| 26 | 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. | ||
| 27 | Funktionale Anforderungen an die Sofwarelösung [FAN] | ||
| 28 | Allgemeine Anforderungen an das System | ||
| 29 | Ausspielung von Inhalten im Web | ||
| 30 | Das System muss Inhalte zuverlässig und performant auf Websites bereitstellen und eine flexible Veröffentlichung unterschiedlicher Inhaltsformate unterstützen. | ||
| 31 | Das System leistet eine performante Nutzbarkeit für Redakteure sowie Nutzer von mindestens 200 Websites. | ||
| 32 | Unterstützung verschiedener Dokument- und Inhaltstypen | ||
| 33 | Das System soll unterschiedliche Inhalts‑ und Dokumenttypen wie zum Beispiel Texte, Bilder, Downloads und strukturierte Inhalte verwalten und ausspielen können. | ||
| 34 | Das System soll erlauben, dass weitere Inhaltstypen integriert werden können. Der Auftragnehmer stellt neue standardisierte Inhaltstypen in einer geeigneten Zeit bereit. | ||
| 35 | Das System erlaubt, dass der Auftraggeber Inhaltstypen integriert. | ||
| 36 | Das System erlaubt, dass bestehende Inhaltstypen modifiziert und erweitert werden können. | ||
| 37 | Das System erlaubt die Integration von Medieninhalten externer Quellen, Das System muss die Einbindung, Verwaltung und Ausspielung von Audio‑ und Videoinhalten unterstützen. | ||
| 38 | Responsives Verhalten und Multi‑Channel‑Fähigkeit | ||
| 39 | Das System | ||
| 40 | Die Nutzung des Systems muss responsiv dargestellt und über verschiedene Endgeräte nutzbar sein. (Mobile / Desktop) | ||
| 41 | Die Nutzung des Systems erfolgt webbasiert. Es ist kein separater Client o.ä. sowie keine Installation erforderlich. | ||
| 42 | Platzierung und Darstellung von Inhalten | ||
| 43 | Inhalte sollen flexibel positioniert und strukturiert dargestellt werden können. | ||
| 44 | Tagging, Kategorisierung und Metadaten | ||
| 45 | Die Website | ||
| 46 | Das System muss Inhalte durch Tags, Kategorien und Metadaten strukturiert beschreiben, um Auffindbarkeit, Pflege und Auswertung auf der Website zu unterstützen. | ||
| 47 | Das System unterstützt eine automatisierte Kategorisierung von Modulen. | ||
| 48 | Das System unterstützt eine automatisierte Befüllung von Metadaten. | ||
| 49 | Das System erlaubt Verschachtelung von Kategorien oder Tags. | ||
| 50 | Das System | ||
| 51 | Das System muss Inhalte durch Tags, Kategorien und Metadaten strukturiert beschreiben, um Auffindbarkeit, Pflege und Auswertung zu unterstützen. | ||
| 52 | Das System erlaubt eine Recherche mit Kategorien / Tags Metadaten, usw. | ||
| 53 | Formular‑Funktionalitäten | ||
| 54 | Das System muss eine Möglichkeit zur Erstellung, Verwaltung und Auswertung von Formularen bereitstellen. | ||
| 55 | Das System erlaubt eine Weiterverarbeitung der Daten (z.B. via Mailversand, Datenexport). | ||
| 56 | Das System unterstützt einen Import sowie die Verarbeitung externer Informationen eines Drittsystems in den Formulardaten (z. B. Auswahloptionen im Formularelement Auswahlliste) | ||
| 57 | Das System unterstützt einen Export an Drittsysteme. Die Verarbeitung dieser Daten vor dem Export muss möglich sein. | ||
| 58 | Die Formularfunktion auf der Website ist barrierefrei. | ||
| 59 | Die Formularfunktion unterstützt weiterführende Funktionen wie Uploads | ||
| 60 | Die Formularfunktion unterstützt Sicherheitsstandards. (z.B. Captcha) | ||
| 61 | Die Formularfunktion ist modifizierbar und erweiterbar. | ||
| 62 | Seitenschutz und Zugriffsbeschränkungen von Inhalten | ||
| 63 | Das System muss Mechanismen zur Zugriffsbeschränkung und zum Schutz von Inhalten im Rahmen der Auslieferung durch ein Rollen‑ oder Login‑Konzept bieten. | ||
| 64 | Die betroffenen Inhalte müssen durch den Auftraggeber wähl- und differenzierbar sein. | ||
| 65 | Die Inhalte können anhand unterschiedlicher technischer Merkmale geschützt werden. | ||
| 66 | Das System kann externe Identity Management Systeme zur Zugriffsbeschränkung anbinden (Authentifizierung und Autorisierung). | ||
| 67 | Das System kann interne Identity Management Systeme zur Zugriffsbeschränkung anbinden (Authentifizierung und Autorisierung). | ||
| 68 | Das System unterstützt unterschiedliche Möglichkeiten der Konfiguration der Autorisierung der User (z. B. Ausnahmen, Einschränkung von Zugriffen). | ||
| 69 | Suchfunktionen (z. B. Studio‑/Website‑Suche) | ||
| 70 | Das System muss leistungsfähige Suchfunktionen für Redaktionssystem und Website zur Verfügung stellen. | ||
| 71 | Die Website | ||
| 72 | Die Suchfunktion ist in der Lage Standards zu berücksichtigen. Dazu gehören unter anderem: Type ahaed, Auto Suggest, Volltextsuche, Ähnlichkeitssuchen usw. Das System soll eine fehlertolerante Suche unterstützen, z. B. bei Tippfehlern oder Varianten von Suchbegriffen. Die Berücksichtigung von Synonymen soll möglich sein. | ||
| 73 | Die Suchfunktion ist in der Lage mit Dritttools (SEO / GEO / KI) kombiniert zu werden. | ||
| 74 | Das System unterstützt eine intelligente bzw. semantische Suchfunktionalität mithilfe von KI. | ||
| 75 | Die Suchfunktion ist in der Lage Dateiformate zu durchsuchen (pdf, csv, usw) | ||
| 76 | Es gibt webstandardisierte Möglichkeiten die Suche zu beeinflussen (z.B. Anführungsstriche für spezifische Suche) | ||
| 77 | Das System muss Metadaten, Kategorien, Tags und strukturierte Informationen in die Suche einbeziehen können. Das System muss Filter und Facettenfunktionen unterstützen, um Suchergebnisse nach definierten Kriterien (Zeiten, Kategorien, Schlagworte usw.) einzugrenzen. Die verfügbaren Filter müssen konfigurierbar sein. | ||
| 78 | Die Suche berücksichtigt mögliche Einschränkungen in der Inhaltsfreigabe durch beispielsweise Rechte- / Rollen oder auch Schutzmechanismen. | ||
| 79 | Die Suche ist in der Lage, dem Nutzer relevante, verwandte Suchergebnisse vorzuschlagen. | ||
| 80 | Das System muss die such- und antwortsystemgerechte Ausspielung mehrsprachiger Inhalte unterstützen. Sprachvarianten müssen eindeutig zuordenbar und konsistent gepflegt werden können. | ||
| 81 | Das System | ||
| 82 | Die Suchfunktion ist in der Lage diverse fachliche- / technische Parameter zu kombinieren. Die Suchergebnisse können in geeigneter Form exportiert werden. | ||
| 83 | Das System erlaubt eine Konfigurierbarkeit der Suche durch den Auftraggeber. Das System muss Suchparameter, Indizes und Konfigurationen so bereitstellen, dass Anpassungen ohne unverhältnismäßigen Aufwand möglich sind. | ||
| 84 | Der Auftraggeber hat die Möglichkeit eine Steuerung der Suchergebnisse auf seinen Inhalten zu beeinflussen. (z. B. Relevanz, Ranking, Gewichtung der Treffer) Die Gewichtung von Inhalten, Metadaten oder Strukturmerkmalen muss steuerbar sein. | ||
| 85 | Das System muss Suchanfragen performant verarbeiten, auch bei hohen Zugriffszahlen und großen Inhaltsmengen. | ||
| 86 | Das System muss nachvollziehbar darstellen, welche Inhalte indexiert sind und nach welchen Kriterien Suchergebnisse ermittelt werden. Die Darstellung der Ergebnisse ist rechte- rollenbasiert einstellbar (vgl. Kapitel 2.7.1). | ||
| 87 | Einsatz von KI‑Funktionalitäten | ||
| 88 | Das System soll KI‑basierte Funktionen unterstützen. | ||
| 89 | Die Website | ||
| 90 | KI basierte Empfehlungen für Content / Produkte können auf der Website ausgegeben werden. | ||
| 91 | Das System erlaubt dem Nutzer der Websites eine Kommunikation durch z.B. Chatbots. | ||
| 92 | Das System | ||
| 93 | Das System bietet nativ KI-Tools an. Die Tools halten gesetzliche Regularien und den aktuellen Stand der Technik ein. | ||
| 94 | Das System bietet die Möglichkeit, dass KI-Tools auf freiwilliger Basis genutzt werden können und jederzeit für die zu gestaltende Website abschaltbar sind. | ||
| 95 | Das System soll KI‑gestützte Funktionen bereitstellen, die in der Lage sind, definierte Aufgaben eigenständig zu übernehmen und so redaktionelle Arbeitsprozesse zu unterstützen. | ||
| 96 | Der Auftraggeber kann Einfluss auf die genutzten KI-Szenarien nehmen. Die KI-Tools erlauben eine Anpassbarkeit auf z.B. Tonalität, Sprachgebrauch (LLM Konfig). | ||
| 97 | Das System erlaubt ein datenschutzkonformes fachliches Monitoring der KI-Tools. | ||
| 98 | Die KI-Tools können Teilmengen des Systems (Pfade, Inhaltstypen, usw.) berücksichtigen oder ausschließen. | ||
| 99 | Die KI-Tools geben den Nutzern konkrete Lösungsvorschläge für fachliche- oder technischen Problemstellungen. Der Auftraggeber kann die Lösungsvorschläge auf seine Bedarfe optimieren. | ||
| 100 | Die KI-Tools können im Rahmen von redaktionellen Workflows eingebunden werden. Siehe auch Übersetzungsworkflow | ||
| 101 | Die KI kann bedarfsorientierte Prüfungen vornehmen wie z.B. Barrierefreiheit, Sicherheit, Datenschutz usw. | ||
| 102 | Erkennung von Redundanzen und Vorschläge zur Content Wiederverwendung (Content Reuse) | ||
| 103 | Möglichkeit zur redaktionellen Kontrolle, Freigabe und Korrektur aller KI-Ergebnisse | ||
| 104 | Externe KI-Modelle (z.B. Bahn GPT, Copilot) können an das System angebunden und mehrere Tools simultan (Tool A in Bereich A und Tool B in Bereich B in Benutzung) genutzt werden. | ||
| 105 | Benutzerfreundlichkeit und Redaktionskomfort | ||
| 106 | Allgemeine Anforderungen hinsichtlich der Usability werden unter Kapitel 4.2 angeführt. | ||
| 107 | Editoren und Content‑Bearbeitung | ||
| 108 | Das System soll einen Editor für eine einfache, direkte Bearbeitung von Inhalten bereitstellen (z. B. WYSIWYG). | ||
| 109 | Die Benutzerführung ist benutzerfreundlich, klar verständlich und fehlertolerant. | ||
| 110 | Das System muss klare Rückmeldungen auf Benutzerinteraktionen zu Status, Fehlern oder erforderlichen Aktionen geben. | ||
| 111 | Benutzeraktionen müssen nachvollziehbar sein und rückgängig gemacht werden können. | ||
| 112 | Das System unterstützt eine Vorlagen- bzw. Template-Funktion, um vorgefertigte Layouts oder Contentobjektstrukturen zu erstellen. | ||
| 113 | Wiederkehrende Benutzerinteraktionen müssen effizient und ohne unnötige Zwischenschritte ausführbar sein. Zentrale Funktionen des Systems sollen mit möglichst wenigen Interaktionen ausführbar sein (z. B. Publikation größerer Assets). | ||
| 114 | Der Auftraggeber kann die User in unterschiedliche Erfahrungslevel gruppieren. Die Bedienoberfläche lässt sich anhand dieser Erfahrungslevel rollenbasiert konfigurieren (z. B. nur notwendige Felder zeigen, kontextuelle Hilfen). | ||
| 115 | Das System zeigt an, sofern ein Inhalt durch einen User in Bearbeitung ist. Die Darstellung zeigt den Nutzernamen. | ||
| 116 | Während ein User einen Inhalt bearbeitet, ist dieser Inhalt für andere User sichtbar, jedoch für die Bearbeitung gesperrt. Ausnahmen der Sperre können durch das Rechte- / Rollenkonzept durch den Auftraggeber definiert werden. | ||
| 117 | Einfaches Onboarding neuer Redakteur:innen | ||
| 118 | Der Auftragnehmer muss neue Redakteur:innen mit geringem Schulungsaufwand und unterstützenden Funktionen schnell arbeitsfähig machen. | ||
| 119 | Der User muss keine Programmierkenntnisse besitzen, um den redaktionellen Arbeitsprozess durchführen zu können. | ||
| 120 | Das System muss kontextbezogene Hilfen, Tooltips, Hilfe-Bots oder Assistenzfunktionen unterstützen. | ||
| 121 | Die in b) genannten Unterstützungsmöglichkeiten können durch den Auftraggeber modifiziert und erweitert werden. | ||
| 122 | Vorschau‑ und Freigabefunktionen | ||
| 123 | Inhalte sollen vor Veröffentlichung überprüft und freigegeben werden können, inklusive realistischer Vorschaufunktionen. | ||
| 124 | Das System bietet eine Vorschau-Funktion der Inhalte für alle unterstützten Ausspielungswege und -Möglichkeiten (z. B. unterschiedliche Web-Viewports, Headless-Preview) | ||
| 125 | Das System unterstützt das Bearbeiten der Inhaltsobjekte in der Vorschau. | ||
| 126 | Die Vorschau-Ansicht ist mit Personen außerhalb des Systems teilbar, z. B. zu Freigabe- und Review-Zwecken. | ||
| 127 | Die Vorschau kann durch Schutzmechanismen eingeschränkt werden (z. B. Passwortschutz, Einmallinks, zeitbasierte Links). | ||
| 128 | Im Rahmen der Vorschau können berechtigte User kontextuelles Feedback geben, z. B. in Form von Kommentaren zu redaktionellen Änderungswünschen. | ||
| 129 | Versionierung, Wiederherstellung und Vergleich von Inhalten | ||
| 130 | Das System muss Versionen von allen Inhalten speichern, vergleichen und bei Bedarf wiederherstellen können. | ||
| 131 | Das System unterstützt eine Vergleichs-Ansicht von Versionen (z. B. Side-by-Side). Die Änderungen zwischen den Versionen müssen dem User deutlich sichtbar gemacht werden. | ||
| 132 | Das System unterstützt eine Versionierung von Inhaltsobjekten. Die Versionierung muss chronologisch dargestellt werden. | ||
| 133 | Versionen müssen eindeutig identifizierbar sein. Mindestens durch bearbeitende Person, Uhrzeit, Datum, Publikationsstatus. | ||
| 134 | Alte Versionen können wiederhergestellt werden. | ||
| 135 | Contentobjekte unterstützen verschiedene Statūs, z.B. Bearbeitung, Freigabe, Veröffentlichung. | ||
| 136 | Das System unterstützt eine zeitgesteuerte Löschung alter Versionen. Grundsätzlich soll eine vollständige Versionierung bis zurück zu Version 1 möglich sein. | ||
| 137 | Eine Kompatibilität der Versionen ist sichergestellt. | ||
| 138 | Vermeidung von Redundanzen und Content‑Reuse | ||
| 139 | Das System soll Mehrfachpflege vermeiden und die Wiederverwendung von Inhalten unterstützen. | ||
| 140 | Gleiche Inhaltsobjekte können in mehreren Kontexten verwendet werden. | ||
| 141 | Das System erkennt redundante Inhaltsobjekte und gibt dem User Feedback. | ||
| 142 | Inhaltsobjekte können in unterschiedlichen Ausspielungswegen verwendet werden. (z.B. Headless) | ||
| 143 | Das System zeigt dem User an, in welchen Kontexten ein Inhaltsobjekt verwendet wird, und ermöglicht den Zugriff darauf. | ||
| 144 | Unterstützung von Medien | ||
| 145 | Allgemeine Aspekte | ||
| 146 | Das System unterstützt gängige Medientypen, u. a. Bilder und Videos in modernen Formaten. | ||
| 147 | Das System unterstützt moderne Bild- und Videoformate (z. B. webp) und automatisierte Kompressions- bzw. Rendering-Möglichkeiten (z. B. Downscaling auf mobilen Geräten) | ||
| 148 | Das System unterstützt die Möglichkeit für technische Validatoren zur fachlichen Steuerung (z. B. Limitierung Dateigröße) | ||
| 149 | Das System unterstützt die Angabe und/oder das Auslesen von Metadaten der Medieninhalte (z. B. KI-generierte Medien, Copyright) | ||
| 150 | Bilder | ||
| 151 | Das System unterstützt durch den Auftraggeber definierte Bildzuschnitte. | ||
| 152 | Der Redakteur kann für jedes Bild und jeden Bildzuschnitt einen Bildbereich auswählen. | ||
| 153 | Das System unterstützt die Möglichkeit, einen Fokuspunkt auf dem Bild zu setzen, wonach der Bildzuschnitt durch das System angepasst wird. | ||
| 154 | Das System gibt dem Nutzer motivbezogenes Feedback zu der Wahl des Bildausschnittes (z. B. kein „Abschneiden von Köpfen“, zu geringe Auflösung) | ||
| 155 | Video- und Audioinhalte | ||
| 156 | Das System unterstützt die Möglichkeit, einen Fokuspunkt auf dem Video zu setzen, wonach der Videozuschnitt durch das System angepasst wird. | ||
| 157 | Das System gibt dem Nutzer motivbezogenes Feedback zu der Wahl des Videoausschnittes (z. B. kein „Abschneiden von Köpfen“, zu geringe Auflösung) | ||
| 158 | Das System unterstützt die Möglichkeit, mehrere Videodateien in einem Inhaltsobjekt zu gruppieren, um diese kontextabhängig und kanalübergreifend zu nutzen. | ||
| 159 | Das System unterstützt das Hosting bzw. die Speicherung von Video- und Audiodateien. | ||
| 160 | Das System unterstützt den Bezug von Video- und Audiodateien aus Drittquellen (z. B. DB Mediathek, YouTube). | ||
| 161 | Im System vorhandene Video- und Audio-Contentobjekte können hinsichtlich ihrer Eigenschaften konfiguriert werden (z. B. Loopvideo, Lautstärke, Autoplay, Fullscreen, usw). | ||
| 162 | Das System muss die barrierearme Einbindung von Video und Audio unterstützen, indem u. a. Transkripte und Untertitel hochgeladen oder generiert werden können. | ||
| 163 | Unterstützung der Redakteur:innen bei der Inhaltserstellung hinsichtlich der Barrierefreiheit | ||
| 164 | Redakteur:innen werden bei der Erstellung barrierearmer Inhalte systemseitig unterstützt. | ||
| 165 | Das System macht inhaltliche Vorschläge für redaktionelle Assets (z. B. Alternativtexte, Untertitel). | ||
| 166 | Das System gibt Feedback hinsichtlich der korrekten Nutzung von Überschriftenhierarchien, Listen und Strukturelementen sowie weiteren Aspekten der Barrierefreiheit. | ||
| 167 | Der Auftraggeber kann im System definieren, welche Aspekte der Barrierefreiheit durch das System berücksichtigt werden sollen. | ||
| 168 | Redakteur:innen müssen vor Veröffentlichung erkennen können, ob Inhalte vollständig barrierefrei sind oder Nachbesserungsbedarf besteht. | ||
| 169 | Benachrichtigungen und Feedback‑Mechanismen | ||
| 170 | Das System soll Benachrichtigungen und Feedbackfunktionen zur Unterstützung redaktioneller Prozesse enthalten. | ||
| 171 | Benachrichtigungen und Feedback sollen zielgerichtet und rollenbasiert erfolgen. Diese sollen selbsterklärend sein. | ||
| 172 | Benachrichtigungen sollen durch den User und/oder zentral an- und abschaltbar sein. | ||
| 173 | Flexibilität und Modularität | ||
| 174 | Das System unterstützt unterschiedliche Formatierungs- und Strukturierungsmöglichkeiten. | ||
| 175 | Einsatz und Verwaltung von Content‑Templates | ||
| 176 | Das System muss Content‑Templates zur strukturierten Erstellung von Inhalten bereitstellen und verwalten können. | ||
| 177 | Layout | ||
| 178 | Das System unterstützt mehrere Gestaltungsraster bzw. Layout-Vorlagen. Dies bedeutet, dass es einen oder mehrere Bereiche gibt, welche in strukturierter Form angeordnet werden können. | ||
| 179 | Templates müssen verschiedene Inhaltstypen unterstützen. Ziel ist die Standardisierung von Struktur, Layout und Pflichtfeldern bei gleichzeitiger redaktioneller Flexibilität. | ||
| 180 | Einzelne Module müssen flexibel kombinierbar, austauschbar und wiederverwendbar sein. | ||
| 181 | Templates müssen mehrfach wiederverwendbar sein. | ||
| 182 | Nutzer können im System Module im Template platzieren. | ||
| 183 | Templates müssen im System anpassbar sein. | ||
| 184 | Templates müssen im System durch den Auftraggeber zentral verwaltet werden können. | ||
| 185 | Templates müssen für Multi‑Channel‑Ausspielung (z. B. Web, mobil, App, Social Media, Headless) geeignet sein. | ||
| 186 | Templates müssen die Pflege mehrsprachiger Inhalte unterstützen (z. B. Sprachversionen je Modul, Verknüpfung von mehrsprachigen Assets). | ||
| 187 | Eine konsistente Struktur über alle Sprachversionen hinweg ist sicherzustellen. | ||
| 188 | Theming | ||
| 189 | Das System muss mehrere Themes unterstützen, um die Ausspielung des Contents zu definieren. Ein Theme beschreibt die Designvorlage, wie Websiteinhalte dargestellt werden (z. B. mittels CSS). | ||
| 190 | Der Auftraggeber muss das Theme bedarfsspezifisch wechseln können. | ||
| 191 | Der Auftraggeber kann beliebig viele Themes eigenständig erstellen. | ||
| 192 | Eigenschaften der Themes sind im System konfigurierbar. | ||
| 193 | Nutzbarkeit von Templates und Layouts im Redaktionssystem | ||
| 194 | Die Nutzung von Templates und Themes ist für den Redakteur ohne Programmierkenntnisse auswählbar und nutzbar | ||
| 195 | Der Redakteur kann wahlweise kuratierte Inhalte nutzen oder eigenständig erstellen. | ||
| 196 | Die Auswahl von Templates und Themes ist abhängig von Rechten und Rollen und kann durch den Auftraggeber eigenständig gesteuert werden (vgl. Kapitel 2.7.1). | ||
| 197 | Modularer Aufbau von Inhaltskomponenten | ||
| 198 | Inhalte sollen aus modularen Komponenten bestehen, die flexibel kombiniert und wiederverwendet werden können. | ||
| 199 | Templates müssen modulare Inhaltskomponenten zulassen. | ||
| 200 | Unterstützung headless bzw. Content‑Hub‑basierter Architekturen | ||
| 201 | Das System soll headless‑fähige Architekturen bzw. Content‑Hub‑Konzepte nach aktuellem Stand der Technik unterstützen. | ||
| 202 | Workflow‑ und Lifecycle‑Management | ||
| 203 | Workflow‑Management für redaktionelle Prozesse | ||
| 204 | Das System muss Workflows zur Steuerung redaktioneller Abläufe unterstützen. | ||
| 205 | Die Workflows sind Rechte- / Rollenabhängig (vg. Kapitel 2.7.1). | ||
| 206 | Der Auftraggeber kann Workflows im System eigenständig definieren und installieren. | ||
| 207 | Die Ausführung der Workflows wirkt sich nicht negativ auf die Performance des Systems aus. | ||
| 208 | Das System stellt Möglichkeiten bereit, dass ein Workflow abgebrochen wird. | ||
| 209 | Das System stellt Möglichkeiten bereit, dass unmittelbar ausgeführte Workflows rückgängig gemacht werden können. | ||
| 210 | Beteiligte Personen müssen über Statusänderungen, Rückfragen oder Freigaben informiert werden. | ||
| 211 | Das System muss aussagefähige Benachrichtigungsfunktionen im Rahmen der Workflows bereitstellen. | ||
| 212 | Redakteur:innen müssen Fortschritt, Zuständigkeiten und offene Schritte einsehen können. | ||
| 213 | Das System erlaubt, dass der Auftraggeber definieren kann, ob Prozessschritte des Workflows händisch durch einen Nutzer oder automatisch durch das System erfolgen. | ||
| 214 | Zeitgesteuerte Veröffentlichung und Deaktivierung von Inhalten | ||
| 215 | Das System erlaubt eine zeitliche Steuerung der Sichtbarkeit von Inhaltskomponenten. Es kann ein Gültigkeitsstart und/oder Gültigkeitsende definiert werden, in dem die Inhaltskomponente sichtbar ist. | ||
| 216 | Das System erlaubt eine zeitliche Steuerung des Publikationsstatus der Inhaltskomponenten. | ||
| 217 | Content Lifecycle Workflow / Publikationsworkflow | ||
| 218 | Das System bietet einen Workflow an, der mindestens folgende Schritte enthält: | ||
| 219 | Erstellung, Prüfung, Veröffentlichung, Depublikation (von Inhaltskomponenten) | ||
| 220 | Das System erlaubt eine Zuweisung der definierten Prozessschritte innerhalb des Workflows. | ||
| 221 | Die Nutzung von Workflows ist ohne Programmierkenntnis möglich. | ||
| 222 | Das System erlaubt Benachrichtigungen über Statuswechsel, Zuständigkeiten im Workflow an Nutzer des Systems sowie an Nutzer außerhalb des Systems (z.B. via Email). | ||
| 223 | Das System erlaubt ein Feedback / Kommentarfunktion innerhalb eines Workflows. | ||
| 224 | Das System erlaubt die Anwendung von Workflows auf beliebig viele Inhaltskomponenten gleichzeitig. | ||
| 225 | Übersetzungs‑ und Lokalisierungs‑Workflows | ||
| 226 | Das System soll strukturierte Workflows für Übersetzungen und Lokalisierungen bereitstellen. | ||
| 227 | Das System soll die Übersetzung von Inhalten durch geeignete (Workflow-)Funktionen unterstützen und eine einfache Anwendung gewährleisten. | ||
| 228 | Der Übersetzungsworkflow arbeitet mit der Zielstellung einer modularmen Abbildung neuer Sprachvarianten der bestehenden Inhaltskomponenten. | ||
| 229 | Das System erlaubt dem Auftraggeber die Wahl des zu nutzenden Übersetzungsdienstes über standardisierte Schnittstellen. | ||
| 230 | Das System bietet die Möglichkeit eines eigenen Übersetzungsdienstes. | ||
| 231 | Das System erlaubt dem Übersetzungsdienst, dass komplexe Kombinationen von strukturierten Inhaltskomponenten in eine neue Sprachversion überführt werden. Formatierungen bleiben dabei erhalten. | ||
| 232 | Das System erlaubt, dass der Redakteur die zu übersetzenden Inhaltskomponenten frei wählt. | ||
| 233 | Wenn mehrere Inhaltskomponenten aufeinander referenzieren und übersetzt werden sollen, werden die Referenzen in der neuen Sprachversion beibehalten. | ||
| 234 | Das System soll Hinweise oder Markierungen bereitstellen, wenn Übersetzungen aufgrund von Änderungen überprüft oder aktualisiert werden müssen. | ||
| 235 | Mehrsprachigkeit und Lokalisierung | ||
| 236 | Das System erlaubt dem Nutzer zu wählen, ob die Systemtexte der Bedienoberfläche mindestens in Deutsch und Englisch dargestellt werden. Der Auftraggeber hat die Möglichkeit die Systemtexte eigenständig zu modifizieren. | ||
| 237 | Das System unterstützt die Nutzung und Ausspielung aller Sprachen / Zeichensysteme / locale innerhalb der Inhaltskomponenten. | ||
| 238 | Das System stellt bei mehreren Sprachen gleichzeitig innerhalb einer Struktur einen logischen Kontext zwischen den Inhaltskomponenten her. | ||
| 239 | Redakteur:innen müssen effizient zwischen Sprachversionen wechseln können, ohne Kontext oder Struktur zu verlieren. | ||
| 240 | Das System stellt die Sprachvarianten den Ausspielungswegen in geeigneter Form zur Verfügung. | ||
| 241 | Das System bietet eine Textprüfung hinsichtlich Rechtschreibung und Grammatik und zeigt Fehler eindeutig an. | ||
| 242 | Integration und Anbindung externer Quellen | ||
| 243 | Das System muss externe Content‑Quellen integrieren können. | ||
| 244 | Das CMS muss die Anbindung gängiger externer Systeme unterstützen, insbesondere aus den Bereichen: | ||
| 245 | Das CMS ist so ausgelegt sein, dass zukünftige Systeme und Services ohne grundlegende Systemanpassungen angebunden werden können (z. B. neue Marketing Tools, KI-Services, Portale). | ||
| 246 | Das CMS muss Redakteur:innen und Administrator:innen ermöglichen, Integrationen transparent zu verwalten (z. B. Status, Fehler, Datenflüsse), ohne tiefgehende technische Eingriffe. | ||
| 247 | Alle Integrationen müssen den geltenden Sicherheits- und Datenschutzanforderungen entsprechen. Zugriffe externer Systeme sind rollen- und rechtebasiert zu steuern und revisionssicher zu protokollieren (vgl. Kapitel 2.7.1). | ||
| 248 | Das CMS muss sicherstellen, dass Inhalte, Metadaten und Medien in offenen, weiterverwendbaren Formaten exportiert werden können, um einen System- oder Anbieterwechsel zu ermöglichen. | ||
| 249 | Eine interaktive Integration von Schnittstellen im Browser / Frontend und im Backend soll möglich sein. | ||
| 250 | Ein Import von Daten als Stapelverarbeitung soll möglich sein. | ||
| 251 | Das CMS muss Automatisierungen anbieten, die eine synchronisierte kanalübergreifend Ausspielung von Social Media Inhalten ermöglicht. | ||
| 252 | Das CMS muss standardisierte Content APIs (z. B. REST/JSON) bereitstellen, über die Inhalte, Metadaten und Medien strukturiert gelesen, geschrieben und aktualisiert werden können. | ||
| 253 | Das System muss die Nutzung von etablierten (Web-)Standards im Hinblick auf die Integration von Content-Quellen ermöglichen. Insbesondere aus den Bereichen: | ||
| 254 | CRM- und Marketing-Automation-Systeme | ||
| 255 | Newsletter-Systeme | ||
| 256 | E-Commerce | ||
| 257 | Analyse- und Tracking-Tools | ||
| 258 | SEO-/GEO-Tools | ||
| 259 | Mediatheken | ||
| 260 | Identity-Management (DeBI) | ||
| 261 | Sicherheit, Datenschutz und Compliance | ||
| 262 | Die technisch organisatorischen Maßnahmen müssen immer dem aktuellen Stand der Technik entsprechen. | ||
| 263 | Rechte und Rollenkonzepte sowie Benutzerverwaltung | ||
| 264 | Rollenkonzept und Granularität | ||
| 265 | Das System muss die Definition und Verwaltung granularer Rollen unterstützen. Rechte sind mindestens auf Ebene von: | ||
| 266 | Inhalten und Inhaltstypen | ||
| 267 | Seiten und Sub Bereichen | ||
| 268 | Funktionen (z. B. Lesen, Bearbeiten, Freigeben, Veröffentlichen) | ||
| 269 | System- und Administrationsfunktionen | ||
| 270 | steuerbar umzusetzen. | ||
| 271 | Es muss ausgeschlossen sein, dass Nutzer:innen Inhalte oder Medien außerhalb der ihnen zugewiesenen Verantwortungsbereiche einsehen oder bearbeiten können. | ||
| 272 | Trennung fachlicher, organisatorischer und technischer Rollen | ||
| 273 | Das System muss die Trennung von fachlicher Verantwortung (z. B. Redaktion, Inhalte), organisatorischer Verantwortung (z. B. Seiten- oder Bereichsverantwortliche) sowie technischer Verantwortung (z. B. Systemadministration) unterstützen. | ||
| 274 | Mehrstufige Rollenmodelle und Delegation | ||
| 275 | Das System soll die Abbildung mehrstufiger Rollenmodelle ermöglichen, einschließlich der Möglichkeit zur Delegation von Rechten innerhalb definierter organisatorischer Grenzen (z. B. je Website, Mandant oder Bereich). | ||
| 276 | Zugriff für interne und externe Nutzer:innen | ||
| 277 | Das System muss sichere Rollenmodelle für interne Nutzer:innen sowie für externe Dienstleister, Agenturen oder Partner unterstützen. Externe Zugriffe sind funktional eingeschränkt, zeitlich steuerbar und eindeutig zuordenbar umzusetzen. | ||
| 278 | Temporäre und zeitlich begrenzte Berechtigungen | ||
| 279 | Das System soll die Vergabe zeitlich befristeter Zugriffsrechte ermöglichen (z. B. für Projekte, Kampagnen oder externe Mitarbeitende). Das System ermöglicht eine automatische Entziehung der jeweiligen Rechte. | ||
| 280 | Das System ermöglicht eine automatisierte Verarbeitung der User / Rechte / Rollen aus dem externen Identity Management System. | ||
| 281 | Nachvollziehbarkeit und Protokollierung | ||
| 282 | Das System muss sämtliche Änderungen an Rollen, Rechten und Benutzerzuordnungen revisionssicher protokollieren. Die Protokolle müssen auswertbar sein und in angemessener Zeit für berechtigte Rollen einsehbar zur Verfügung stehen. | ||
| 283 | Integration in bestehende Authentifizierungs- und Berechtigungssysteme | ||
| 284 | Das System soll die Anbindung an bestehende Identitäts- und Berechtigungssysteme (z. B. zentrale Verzeichnis- oder SSO-Lösungen) unterstützen, ohne dabei die interne Rollenlogik zu unterlaufen. | ||
| 285 | Benutzerfreundliche Administration | ||
| 286 | Das System soll eine benutzerfreundliche Administration von Rollen und Rechten bereitstellen. Die Pflege des Rechte- und Rollenkonzepts soll ohne Programmierkenntnisse möglich sein. | ||
| 287 | Benutzerverwaltung für Login-Bereiche | ||
| 288 | Allgemein | ||
| 289 | Das System muss die Anlage, Änderung, Deaktivierung und Löschung interner Benutzerkonten durch berechtigte Personen (Admins, Redakteure, der spezifische Nutzer) unterstützen. Es dürfen ausschließlich solche personenbezogenen Daten verarbeitet werden, die für den Login und die Ausübung der jeweiligen Systemfunktionen erforderlich sind. | ||
| 290 | Rollen und rechtebasierter Zugriff auf Webseitenbereiche | ||
| 291 | Der Login für Webauftritte muss an ein rollen- und rechtebasiertes Zugriffskonzept gekoppelt sein. Das System muss sicherstellen, dass interne Benutzerinnen und Benutzer nach dem Login ausschließlich die ihnen zugewiesenen Webseitenbereiche inklusive Rechtevererbung, Inhaltstypen – insbesondere Downloads – sowie Funktionen nutzen können. | ||
| 292 | Verwaltung datenschutzrelevanter Zusatzinformationen | ||
| 293 | Das System muss in der Lage sein, bedarfsgerechte Zusatzinformationen zu Benutzerkonten zu speichern und zu verwalten. Hierzu zählen insbesondere Einwilligungen oder vergleichbare Nachweise innerhalb des Zielprodukts. Das System unterstützt dabei die Erfüllung möglicher Folgepflichten, insbesondere in den Bereichen Datenschutz und Sicherheit, zum Beispiel durch Exportfunktionen oder strukturierte Kommunikation an Benutzerinnen und Benutzer. | ||
| 294 | Deaktivierung und Löschung interner Benutzerkonten | ||
| 295 | Das System muss die zeitnahe Deaktivierung und regelkonforme Löschung interner Benutzerkonten für den Webseiten Login unterstützen. Personenbezogene Daten sind gemäß definierter Lösch- und Aufbewahrungsfristen zu behandeln. | ||
| 296 | Transparenz und Prüfunterstützung | ||
| 297 | Das System soll berechtigten internen Stellen nachvollziehbare Übersichten zu aktiven Benutzerkonten, Rollen und Zugriffsrechten für den Webseiten Login bereitstellen, um Datenschutz-, Sicherheits- und Compliance Prüfungen zu unterstützen. | ||
| 298 | Datenschutz‑ und DSGVO‑konforme Inhaltsverwaltung | ||
| 299 | Die Verwaltung von Inhalten muss DSGVO‑konform erfolgen. | ||
| 300 | Revisionssicherheit und Protokollierung | ||
| 301 | Alle relevanten Änderungen und Zugriffe müssen revisionssicher protokolliert werden. | ||
| 302 | Analyse, Optimierung und Qualitätssicherung | ||
| 303 | Das System muss Funktionen zur Unterstützung der Suchmaschinen‑ und generativen Auffindbarkeit von Webinhalten bereitstellen. Ziel ist die nachhaltige Auffindbarkeit von Inhalten in klassischen Suchsystemen sowie in KI‑gestützten Antwort‑ und Empfehlungssystemen. | ||
| 304 | SEO‑ und GEO‑Unterstützung | ||
| 305 | Das System muss Funktionen zur Suchmaschinen‑ und GEO‑Optimierung bereitstellen. | ||
| 306 | Der Auftraggeber kann die SEO- / GEO-Funktionalitäten gemäß seiner strategischen Ziele anpassen. | ||
| 307 | Das System unterstützt redaktionelle Qualitätsprüfungen. Hierzu zählen Prüfungen auf Vollständigkeit, Aktualität, Konsistenz, Mehrfachverwendung von Inhalten sowie formale Kriterien. | ||
| 308 | Das System muss grundlegende Prüffunktionen zur Bewertung der SEO Eignung von Inhalten bereitstellen. Dazu zählen Hinweise zu fehlenden oder unvollständigen SEO relevanten Angaben. | ||
| 309 | Das System muss die dauerhafte Erreichbarkeit von Inhalten durch eine konsequente Sicherstellung der Linkstabilität gewährleisten – sowohl im laufenden Betrieb als auch bereits im Rahmen der initialen Migration bzw. Überführung vom Alt- in das Neusystem. Hierzu sind stabile, persistente und sprechende URLs bereitzustellen, deren Struktur auch bei inhaltlichen oder technischen Änderungen nicht zu Erreichbarkeitsverlusten führt. Insbesondere im Migrationskontext muss sichergestellt werden, dass bestehende URLs, Deep Links sowie externe Verlinkungen vollständig erhalten bleiben und über geeignete Weiterleitungsmechanismen korrekt aufgelöst werden, sodass kein Verlust von Auffindbarkeit, Reichweite oder Zugriffspfaden entsteht. | ||
| 310 | Das System muss die Erstellung und Verwaltung suchmaschinenfreundlicher Inhalte unterstützen. Hierzu zählen strukturierte Inhalte, sprechende URLs sowie eine klare semantische Struktur von Seiten und Inhalten. | ||
| 311 | Das System muss die redaktionelle Pflege und systematische Auswertung von suchrelevanten Metadaten ermöglichen. Metadaten müssen in strukturierter Form hinterlegt, gepflegt und für unterschiedliche Inhalte nutzbar sein. | ||
| 312 | Das System ermöglicht dem Redakteur eine Unterstützung bei der Pflege von SEO- / GEO-relevanten Feldern in den Inhaltstypen. Hierzu zählen unter anderem Vorschläge für Metadaten. | ||
| 313 | Sitemap‑ und RSS‑Funktionen | ||
| 314 | Das System soll automatische Sitemaps und RSS‑Feeds erzeugen können. | ||
| 315 | Sitemaps können in standardisierten Formaten exportiert werden. | ||
| 316 | Das System ermöglicht eine automatisierte Ausspielung von Sitemaps und RSS-Feeds an standardisierte Techniken. (z.B. Google Search Console) | ||
| 317 | Das System muss Funktionen zur Steuerung der Indexierbarkeit von Inhalten bereitstellen. Dazu gehören Möglichkeiten zur gezielten Freigabe, Einschränkung oder Ausschließung von Inhalten für Such und Antwortsysteme (z. B. durch robots). Diese Steuerung muss rollenbasiert und nachvollziehbar erfolgen können (vgl. Kapitel 7.1). | ||
| 318 | Das System muss die Erstellung und Verwaltung von Sitemaps für mehrsprachige Webauftritte unterstützen. Sprachvarianten von Inhalten müssen eindeutig zuordenbar sein. | ||
| 319 | Das System bietet eine Exportmöglichkeit der hierarchischen Informationsarchitektur. | ||
| 320 | Link‑Checker und Qualitätsprüfungen | ||
| 321 | Das System muss Werkzeuge zur Prüfung von Links und zur Qualitätssicherung enthalten. | ||
| 322 | Das System soll Fehler direkt im Redaktionskontext (z. B. im Editor oder in der Seitenstruktur) anzeigen und verortbar machen. | ||
| 323 | Das System soll Prüfergebnisse in redaktionelle Workflows integrieren (z. B. Freigabe nur bei fehlerfreien Inhalten). | ||
| 324 | Das System muss interne und externe Verlinkungen überprüfen können. Der Auftraggeber kann die Prüfung beliebig oft durchführen und ein Intervall zur automatisierten Ausführung festlegen. Fehlerhafte, veraltete oder ungültige Verweise müssen identifizierbar sein, um die Qualität und Vertrauenswürdigkeit von Webauftritten sicherzustellen. Dies inkludiert auch die Nutzbarkeit von Redirects und Vanity-Urls. | ||
| 325 | Das System muss dem Redakteur eine Rückmeldung geben, ob der Linkaufbau SEO-/GEO-freundlich ist. | ||
| 326 | Das System prüft die URLs auf die Einhaltung der Nomenklatur der Deutschen Bahn. | ||
| 327 | Das System unterstützt eine stabile Ausspielung von URLs für alle Inhaltstypen (inklusive Bilder und Downloads) | ||
| 328 | Das System muss Qualitätsprüfungen abhängig vom Veröffentlichungsstatus von Inhalten ermöglichen und daraus differenzierte Reports generieren können. | ||
| 329 | Das System muss redaktionell einrichtbare Redirects für alle Inhaltstypen ermöglichen (301-Weiterleitung). Doppelungen von bereits vorhandenen Redirect-URLs werden auftrittsübergreifend erkannt. | ||
| 330 | Das System muss übersichtliche Reports zu fehlerhaften Links und Qualitätsmängeln bereitstellen, inklusive Filter- und Exportfunktionen. | ||
| 331 | Analyse‑ und Tracking‑Funktionen | ||
| 332 | Das System muss Analyse- und Tracking-Dritttools über standardisierte Schnittstellen integrieren können (mindestens Matomo, Adobe Analytics). | ||
| 333 | Das System muss aggregierte Auswertungen auf Global, Website-, Bereichs- oder Themenebene ermöglichen. Einzelne Nutzungsdaten müssen aus Drittquellen (z. B. Adobe, Matomo) zu übersichtlichen Kennzahlen zusammengeführt werden können. | ||
| 334 | Das System muss sicherstellen, dass Analyse- und Tracking Funktionen datenschutzkonform eingesetzt werden können. | ||
| 335 | Bei Systemupdates sollen die Links stabil bleiben, um ein konsistentes und durchgehendes Tracking möglich sein, ohne dass Daten verloren gehen (vgl. Kapitel 9.1 e)). | ||
| 336 | Tracking- und Analysedaten können für die Personalisierung von Inhalten genutzt werden (vgl. Kapitel 10). | ||
| 337 | A/B‑Testing | ||
| 338 | Das System unterstützt die Erstellung und Ausführung von A/B-Tests mithilfe von Matomo und Adobe Analytics (siehe 9.4). | ||
| 339 | Das System muss die parallele Ausspielung unterschiedlicher Varianten von Inhalten, Layouts oder Funktionen unterstützen. | ||
| 340 | Das System muss eine Vorschau-Ansicht der unterschiedlichen Varianten unterstützen. | ||
| 341 | Das System muss die redaktionelle Erstellung unterschiedlicher Varianten innerhalb des gleichen Inhaltstyps unterstützen. | ||
| 342 | Das System soll die zeitliche Steuerung sowie die Definition von Laufzeiten für Tests ermöglichen. | ||
| 343 | Personalisierung und Interaktion | ||
| 344 | Personalisierungsfunktionen im System/Studio | ||
| 345 | Das System muss Funktionen zur Personalisierung von Inhalten bereitstellen. | ||
| 346 | Das System muss mehrere Varianten eines Inhaltsobjektes unterstützen. | ||
| 347 | Das System unterstützt eine Vorschau-Darstellung der Varianten. | ||
| 348 | Das System muss die Definition und Anwendung regelbasierter Mechanismen zur Personalisierung ermöglichen (z. B. nach Zielgruppen, Kontext oder Attributen). | ||
| 349 | Das System muss die Bildung und Verwaltung von Zielgruppen und Segmenten unterstützen. | ||
| 350 | Das System unterstützt den Redakteur hinsichtlich der Erstellung mehrerer Varianten und gibt Vorschläge. | ||
| 351 | Das System muss Personalisierungslogiken auf Basis von Tracking-, Nutzungs- oder Kontextdaten ermöglichen. | ||
| 352 | Das System soll die gleichzeitige Anwendung mehrerer Personalisierungsregeln unterstützen. | ||
| 353 | Das System muss es Redakteur:innen ermöglichen, Personalisierungsregeln eigenständig im System zu konfigurieren und zu steuern. | ||
| 354 | Das System soll Personalisierungsfunktionen mit A/B Testing kombinieren können, um Varianten zielgruppenspezifisch zu testen. | ||
| 355 | Das System soll die Anpassung von Inhalten in Echtzeit auf Basis von Nutzerinteraktionen ermöglichen. | ||
| 356 | Das System muss Personalisierungsregeln und deren Auswirkungen nachvollziehbar dokumentieren können. Das System soll nachvollziehbar darstellen können, nach welchen Kriterien Inhalte an Nutzer ausgespielt werden. | ||
| 357 | Das System muss Personalisierungsfunktionen unter Einhaltung geltender Datenschutzanforderungen umsetzen. | ||
| 358 | Das System muss sicherstellen, dass bei fehlenden oder unzureichenden Daten Fallback-Inhalte ausgespielt werden. | ||
| 359 | Zielgruppen‑ und bedarfsgerechte Ausspielung von Inhalten | ||
| 360 | Inhalte sollen zielgruppen‑ und situationsbezogen ausgespielt werden können. | ||
| 361 | Das System unterstützt die Auslieferung von Inhalten je nach Nutzerkontext. | ||
| 362 | Das System muss Inhalte abhängig von Kontextfaktoren wie Nutzungsverhalten, Endgerät, Zeitpunkt oder Nutzungssituation ausspielen können. | ||
| 363 | Das System muss eine konsistente personalisierte Ausspielung über verschiedene Kanäle hinweg ermöglichen | ||
| 364 | Das System soll Inhalte dynamisch und in Echtzeit an den aktuellen Nutzungskontext ausspielen können. | ||
| 365 | User‑Generated‑Content | ||
| 366 | Das System soll Funktionen für nutzergenerierte Inhalte wie Feedback oder Kommentare unterstützen. | ||
| 367 | Das System muss Funktionen zur Erfassung, Verwaltung und Ausspielung von nutzergenerierten Inhalten wie Feedback, Kommentaren oder Beiträgen bereitstellen. | ||
| 368 | Das System muss Interaktionsmöglichkeiten wie Kommentarfunktionen, Bewertungen oder Feedbackmechanismen auf der Website unterstützen. | ||
| 369 | Das System muss Funktionen zur Moderation, Prüfung, Freigabe und Löschung von nutzergenerierten Inhalten bereitstellen. | ||
| 370 | Das System muss die Steuerung von nutzergenerierten Inhalten über ein differenziertes Rollen- und Rechtekonzept ermöglichen (vgl. Kapitel 7.1). | ||
| 371 | Das System muss Mechanismen zur Erkennung und Vermeidung von Spam, Missbrauch oder unerwünschten Inhalten bereitstellen (z. B. Filterregeln, KI gestützte Klassifizierung). | ||
| 372 | Das System soll Nutzer:innen und Redakteur:innen über neue Beiträge, Kommentare oder Statusänderungen informieren können. | ||
| 373 | Das System muss Änderungen, Freigaben und Löschungen von nutzergenerierten Inhalten nachvollziehbar dokumentieren. | ||
| 374 | Das System soll die Analyse sowie Auswertung durch Drittsysteme (s. Kapitel 9) von nutzergenerierten Inhalten ermöglichen. | ||
| 375 | Das System soll den Export von nutzergenerierten Inhalten ermöglichen. | ||
| 376 | Das System muss die Verarbeitung nutzergenerierter Inhalte unter Einhaltung geltender Datenschutzanforderungen sicherstellen, insbesondere hinsichtlich personenbezogener Daten. | ||
| 377 | Das System muss Funktionen zur Verwaltung von Einwilligungen sowie zur regelkonformen Löschung nutzergenerierter Inhalte bereitstellen. | ||
| 378 | Das System muss eine klare Trennung und Kennzeichnung zwischen redaktionellen und nutzergenerierten Inhalten ermöglichen. | ||
| 379 | Architektur und Schnittstellen [AST] | ||
| 380 | IST- und Zielarchitektur | ||
| 381 | IST-Architektur | ||
| 382 | Aktuell basiert das ECM-System auf der Anwendung Core Media Content Cloud. Es wird On-Premise in einem Open-Shift-Cluster innerhalb der AWS-Cloud betrieben. Ca. 180 Webseiten der Deutschen Bahn basieren auf der Lösung. | ||
| 383 | Die aktuelle Systemlandschaft, ihre Umsysteme sowie relevante Schnittstellen und Komponenten sind im nachfolgenden Schaubild dargestellt |
| Ref # | Auftraggeber | J/N | Auftragnehmer |
|---|---|---|---|
| 384 | Zielarchitektur | ||
| 385 | Als Zielarchitektur wird eine SaaS-Lösung angestrebt. | ||
| 386 | Die konkreten Anforderungen zu Architektur und Schnittstellen und die spezifischen Anforderungen zu den relevanten Schnittstellen sind in den nachfolgenden Kapiteln beschrieben. | ||
| 387 | Anforderungen an die Architektur | ||
| 388 | Bereitstellung und Betrieb der Lösung als SaaS (Software as a Service) | ||
| 389 | Das System steht inklusive der benötigten IT-Infrastruktur für die Durchführung der Anwendung (Server, Online-Plattform etc.) als SaaS-Dienst zur Verfügung. | ||
| 390 | Alle nötigen Aktivitäten zur Implementierung und Testung von Funktionen werden auf Basis dieser IT-Infrastruktur durchgeführt. | ||
| 391 | Um ein robustes System zur Verfügung zu stellen, werden mindestens die Anforderungen umgesetzt: | ||
| 392 | Der Auftragnehmer betreibt das System redundant in mindestens zwei Rechenzentren. Bei Ausfall eines Rechenzentrums wird das System automatisch, ohne Unterbrechung und ohne Datenverlust im zweiten Rechenzentrum betrieben. | ||
| 393 | 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. | ||
| 394 | Umgebungen / Stages | ||
| 395 | Der Auftragnehmer stellt mindestens folgende Umgebungen / Stages zur Verfügung: | ||
| 396 | Test- und Entwicklungsumgebung | ||
| 397 | Abnahmeumgebung | ||
| 398 | Produktivumgebung | ||
| 399 | Die Abnahmeumgebung kann als Schulungsumgebung genutzt werden | ||
| 400 | 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. | ||
| 401 | Standardarchitektur, Architekturprinzip und Architekturbeschreibung | ||
| 402 | Alle Anforderungen sind vom Auftraggeber als System-Standards ausgelegt, deren Erfüllung über alle Versionen der Vertragslaufzeit hinweg sichergestellt wird. | ||
| 403 | Für die Nutzung von Web-Clients wird das Client/Server Architekturprinzip verwendet. Es darf keine monolithische Architektur verwendet werden. | ||
| 404 | Für das System verfügt der Auftragnehmer über eine fachliche Architekturbeschreibung. Diese enthält die fachliche Konzeption der Anforderungen in Bezug auf die Funktionen des beschriebenen Systems. Sie dokumentiert ausführlich und detailliert jede Anforderung und deren Umsetzung als Programmfunktion. Diese Beschreibung wird dem Auftraggeber auf Anfrage zur Verfügung gestellt. | ||
| 405 | Für das System 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 des beschriebenen Systems und ist dazu geeignet, dass sich Chefarchitekten, Architekturprüfer, Entwickler, Designer oder Release Manager einen Überblick verschaffen können. | ||
| 406 | Skalierbarkeit | ||
| 407 | Das System ermöglicht eine bedarfsgerechte Skalierbarkeit. Hierfür ist sichergesellt, dass bei steigenden Eingabemengen bzw. Verarbeitungsaufwand, die Antwortzeiten für Programmfunktionen oder Algorithmen konstant gehalten werden können. | ||
| 408 | Sollten hierfür in besonderen Lastsituationen zusätzliche Ressourcen benötigt werden, stellt das System unmittelbar Mechanismen zur automatischen Skalierung bereit. | ||
| 409 | 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. | ||
| 410 | Das System nimmt unmittelbar selbständig eine Skalierung vor, wenn die Anzahl der Schnittstellenaufrufe wächst. | ||
| 411 | Das System stellt im Überlastfall einen uneingeschränkten Durchsatz von fehlerfrei durchgeführten Aktionen. Die Überlast darf nicht zu Fehlermeldungen und zu Timeouts von Aktionen führen. | ||
| 412 | Der Auftragnehmer verfügt über eine Dokumentation zu den folgenden Themengebieten und stellt diese auf Anfrage bereit | ||
| 413 | wie das System bei steigenden Eingabemengen bzw. Verarbeitungsaufwand und Zuwächse zeitgleich mit dem System arbeitender Anwender skaliert und eine gleichbleibend gute Performance sichergestellt wird. | ||
| 414 | wie das System sich im Überlastfall verhält und einen hohen Durchsatz von fehlerfrei durchgeführten Aktionen sicherstellt. | ||
| 415 | Daten und Struktur | ||
| 416 | Dokumentation Datenmodell und Erweiterbare Datenstruktur | ||
| 417 | Das zugrunde liegende Standard-Geschäftsdatenmodell, welches alle Geschäftsobjekte auflistet inkl. ihrer Attribute und Beschreibungen wird durch den Auftragnehmer bei Bedarf an den Auftraggeber übergeben. | ||
| 418 | Das System ermöglicht die Definition zusätzlicher, Auftraggeber-spezifischer Attribute in Geschäftsobjekten des Systems. | ||
| 419 | Diese Attribute können sowohl in Oberflächen als auch über APIs und Ex/Import-Funktionen gepflegt werden. | ||
| 420 | Diese Attribute sind sowohl in Konfiguration als auch im Customizing wie Standard-Attribute nutzbar. | ||
| 421 | Datenverlust und Datenkorruption | ||
| 422 | Das System 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. | ||
| 423 | Das System ist bleibt unabhängig von der Last stets konsistent. | ||
| 424 | Das System ist in der Lage, den Ausfall einzelner technischer Infrastrukturkomponenten zu verkraften, ohne dass hierbei ein Datenverlust entsteht. | ||
| 425 | Das System 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. | ||
| 426 | Mandantentrennung / Datentrennung | ||
| 427 | 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. Das System stellt sicher, dass eine Datentrennung und Steuerung der Sichtbarkeit u.a. | ||
| 428 | von unterschiedlichen Geschäftsfeldern des DB Konzerns, | ||
| 429 | von unterschiedlichen Regionen eines Geschäftsfeldes, | ||
| 430 | von unterschiedlichen Zielgruppen, | ||
| 431 | von unterschiedlichen Rollen, | ||
| 432 | oder von unterschiedlichen Abteilungen eines Geschäftsfeldes | ||
| 433 | möglich ist. | ||
| 434 | Benutzer können durch administrative Benutzerrollen des Auftraggebers für den Zugriff auf einen oder mehrere Mandantendaten zugelassen werden. | ||
| 435 | Das System 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 überhaupt keine Datensätze vorhanden sind. | ||
| 436 | Datenanonymisierung und Datenlöschung | ||
| 437 | Es 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. | ||
| 438 | Die finale Datenlöschung wird protokolliert und die Log-Dateien durch den Auftragnehmer aus dem System extrahiert. | ||
| 439 | Datenqualität | ||
| 440 | Um eine hohe Datenqualität sicherzustellen, beinhaltet das System Funktionen, um folgende Anforderungen umzusetzen: | ||
| 441 | 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: | ||
| 442 | Sicherstellung der Qualität händischer Dateneingaben | ||
| 443 | Vermeidung von Eingabefehlern durch Drop-Down-Felder, Checkboxen oder Autovervollständigung | ||
| 444 | Prüfung freier Eingabefelder auf Korrektheit und Plausibilität (z.B. Wertgrenzen) | ||
| 445 | Maßnahmen zum Management der Qualität an den Eingangsschnittstellen | ||
| 446 | Durchführung der gleichen Korrektur- und Plausibilitätsprüfungen, wie im händischen Fall | ||
| 447 | Erkennen und Zurückweisen doppelter und unplausibler Datensätze | ||
| 448 | Protokollierung von Zurückweisungen | ||
| 449 | Handling von Dateninkonsistenzen zwischen verschiedenen Geschäftsobjekten | ||
| 450 | Möglichkeiten zum Erkennen „ähnlicher“ Datensätze | ||
| 451 | Prüfung von Kausalketten | ||
| 452 | Zurückweisungen von Datensätze mit falschen Referenzen auf nicht (mehr) vorhandene Objekte | ||
| 453 | Allgemeine Anforderungen an Schnittstellen | ||
| 454 | Unterstützung Standard API-Technologien und Standard-Schnittstellen | ||
| 455 | Das System besitzt API-Funktionalitäten (bevorzugtREST), um Schnittstellen von und zu anderen Systemen anbinden zu können. | ||
| 456 | Das Abrufen/ Erstellen/ Bearbeiten und Löschen der Daten ist per API möglich. | ||
| 457 | Der Datenaustausch mittels APIs wird mindestens über gängige Datenformate wie XML oder JSON ermöglicht. | ||
| 458 | Über Standardschnittstellen können Funktionalitäten des Systems von außen gestartet und somit Prozesse automatisiert ausgeführt werden. Hierzu zählt das Anstoßen eines Workflows, das Berechnen von Werten oder das Ausführen von Funktionen. | ||
| 459 | Alle APIs erreichen mindestens die gleiche Verfügbarkeit wie der Rest des Systems. | ||
| 460 | Die APIs können zu üblichen Bedienzeiten ohne Einschränkung der Performance der Benutzer-Oberflächen genutzt werden. | ||
| 461 | Die automatische Skalierbarkeit gemäß Kapitel 3.2.4 greift auch für APIs. | ||
| 462 | Das System 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 des Systems ermittelt. | ||
| 463 | Bedienoberflächen und API-Aufrufe zeigen Daten mit der gleichen Aktualität an. | ||
| 464 | Alle Aufträge und Datenänderungen, die über Oberflächen des Systems eingegeben werden können, sind auch per API erstellbar, änderbar und stornierbar. | ||
| 465 | Ä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. | ||
| 466 | Das System bietet API-Funktionen für administrative Zwecke (z.B. Anlegen von Benutzern). | ||
| 467 | Callbackfunktionalität | ||
| 468 | Das System 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. | ||
| 469 | Im Falle der Änderung wird das externe System automatisch durch das System informiert. Damit können wechselnde Workflowsysteme ohne Änderungen an dem System in den Gesamtprozess integriert werden. | ||
| 470 | Anbieten und Nutzung von Datentransfer-Schnittstellen | ||
| 471 | Das System bietet Schnittstellen zum Austausch von Dateien an, kann aber auch Dateien auf fremden Servern auslesen und dort ablegen können. | ||
| 472 | Für jeden relevanten Schnittstellenpartner ermöglicht das System einen getrennt abgesicherten Austausch. | ||
| 473 | Das System erlaubt es, diese Dateien aus dem eigenen Datenbestand heraus zu erzeugen bzw. in den eigenen Datenbestand integrieren zu können. | ||
| 474 | Das System bietet sowohl die Möglichkeit den Datei-basierten Datenaustausch automatisiert (z.B. zeitgesteuert) durchzuführen oder ihn durch den Benutzer anzustoßen. | ||
| 475 | E-Mail Versand über internen E-Mail-Provider des Auftraggebers | ||
| 476 | Das System stellt sicher, dass für den Versand von E-Mails ein Mailservice des Auftraggebers konfiguriert werden kann. | ||
| 477 | Authenifizierung und Schutz vor unerlaubten Zugriffen | ||
| 478 | Alle Schnittstellen werden durch Authentifizierungs- und Autorisierungsverfahren vor unerlaubten Zugriffen geschützt. Mögliche Verfahren sind abhängig vom konkreten Anwendungsfall. | ||
| 479 | Das System ist in der Lage, die Authentifizierung/Autorisierung von Nutzern gegen zentrale Verzeichnisdienste des Auftraggebers zu nutzen. | ||
| 480 | Das System 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. | ||
| 481 | Das System ermöglicht eine Zwei-Faktor-Authentifizierung bei API-Aufrufen. | ||
| 482 | Beim Zugriff auf die APIs der Deutschen Bahn kann das System mit rollierenden Credentials (bspw. durch wechselnd eingesetzte Credentials-Paare) umgehen, so dass der API-Betrieb nicht unterbrochen wird. | ||
| 483 | Ankündigung Anpassungen an Schnittstellen und Release-Abwärtskompatibilität | ||
| 484 | Der Auftragnehmer kündigt die Änderung einer API / Schnittstelle mit geeignetem Vorlauf, mindestens jedoch drei Monate, im Voraus an. | ||
| 485 | Das System 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. | ||
| 486 | Es wird mindestens, ausgehend von der Hauptversion „n“, die Hauptversion „n-2“ unterstützt. | ||
| 487 | Änderungen werden in der Dokumentation der Software sowie in den Releasenotes vollständig dokumentiert. | ||
| 488 | Definition und Dokumentation aller Schnittstellen | ||
| 489 | 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. | ||
| 490 | Unter anderem sind diese Inhalte in der Dokumentation aufgeführt: | ||
| 491 | Technische Parameter: Endpunkte, Sicherheitsprotokolle, Datenformate (z.B. XML, JSON, CSV inklusive Zeichensatz) | ||
| 492 | Dateninhalte: Namen und Beschreibung der Felder und Strukturen, Bezug zu den Geschäftsobjekten, Wertgrenzen, Beispielinhalte | ||
| 493 | Rahmenbedingungen zum Einsatz der Schnittstelle: Paginierung, Mengengrenzen, Fehlercodes, Muss- und Kann-Felder | ||
| 494 | Ü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. | ||
| 495 | Der Auftragnehmer stellt die Aktualisierung der Dokumentation nach jedem Update bzw. jeder Änderung sicher. | ||
| 496 | Die Schnittstellendokumentation für REST-Schnittstellen werden im Swagger Format und für SOAP-Schnittstellen im WSDL Format geliefert. | ||
| 497 | Anforderungen zu Operationen der Schnittstellen | ||
| 498 | Schreibende Operationen in Richtung des Systems verhalten sich grundsätzlich idempotent. | ||
| 499 | Fehlerhafte Operationen per HTTP werden durch den entsprechenden HTTP Statuscode beantwortet. | ||
| 500 | Schreibende Operationen aus Sicht des Systems in ein anderes System bzw. Synchronisationsvorgänge des Systems mit anderen Systemen weisen eine Fehlerbehandlung auf, die sicherstellt, dass es zu keinem Datenverlust kommt, falls eine Operation fehlschlägt. | ||
| 501 | 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.ä.). | ||
| 502 | Monitoring und Logfiles | ||
| 503 | In dem System ist ein Monitoring für die Zugriffe auf die Schnittstellen vorhanden. Im Monitoring wird aufgeführt, wenn eine Schnittstelle oder Komponente nicht verfügbar ist. | ||
| 504 | Die in dem System vorhandenen Monitoring-Informationen und Protokollierungs-Informationen der Schnittstellen sind in Near-Realtime ausleitbar. | ||
| 505 | Das System stellt sicher, dass Logfiles in einem Datei-Format, mindestens in TXT oder CSV, durch definierte Benutzer (fachliche Betriebsführung) lesbar exportiert werden können. | ||
| 506 | Das System stellt sicher, dass die Betriebsführung des Auftraggebers Zugriff auf das Monitoring und auf die Protokollierung hat. | ||
| 507 | Integrierbarkeit externer Systeme und Schnittstellen für Import | ||
| 508 | Das System ist dazu in der Lage, externe Systeme in seine Abläufe zu integrieren. | ||
| 509 | Die API des externen Systems kann dazu z.B. aus einer Benutzerbedienung her direkt aufgerufen werden. | ||
| 510 | Das System 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 das System zur Aktualisierung der Geschäftsobjekte verwendet. Die Fähigkeit ist sowohl im Batchbetrieb aber insbesondere auch in dialogorientierten Prozessen nutzbar. | ||
| 511 | Das System ermöglicht, dass ein Datei-Import im offenen, strukturierten Format (z.B. XML, JSON,CSV)mit den Daten des Auftraggebers in die Software eingespielt werden kann. | ||
| 512 | Versionierung von Schnittstellen zu Fremdsystemen | ||
| 513 | Das System stellt sicher, dass die Versionierung von Schnittstellen zu Fremdsystemen unterstützt und ermöglicht wird. | ||
| 514 | Schnittstellen der Veröffentlichung zu Fremdsystemen werden zum Zwecke der Entkopplung der Anwendungen versioniert und die Gültigkeit der einzelnen Versionen wird vermerkt. | ||
| 515 | Änderungen werden in der Dokumentation des Systems sowie in den Releasenotes vollständig dokumentiert. | ||
| 516 | Wiederwendbarkeit und Versionierung von Webservices | ||
| 517 | Der Auftragnehmer stellt sicher, dass Webservices des Systems 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. | ||
| 518 | Das System stellt sicher, dass die Versionierung von Webservices unterstützt und ermöglicht wird. | ||
| 519 | Erweiterbarkeit von Schnittstellen für zukünftige Anforderungen | ||
| 520 | Das System stellt sicher, dass die Erweiterbarkeit von Schnittstellen (zu Fremdsystemen) für zukünftige Anforderungen möglich ist. | ||
| 521 | Dies schließt auch Schnittstellen mit ein, die auf Webservices basieren. | ||
| 522 | 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. | ||
| 523 | Exportfunktion und Importfunktion für Massendaten | ||
| 524 | Das System bietet die Möglichkeit an, alle Geschäftsobjekte und deren Historie als Massendaten aus dem System zu extrahieren. | ||
| 525 | Über geeignete Technologien stellt das System einen ausreichenden Durchsatz sicher, um auch den vollständigen Datenbestand inklusive Änderungshistorie an maximal einem Wochenende in die Systeme des Auftraggebers zu übertragen. | ||
| 526 | Das System stellt übliche Filter zur Eingrenzung auf Geschäftsobjekttypen und Zeiträume (z.B. aktuelles Jahr) bereit, so dass auch Delta Abzüge ermöglicht werden. | ||
| 527 | Massendaten sind automatisiert abrufbar, indem z.B. eine Datenbankanbindung oder ein Streaming der Daten angeboten wird. | ||
| 528 | Das System unterstützt den konfigurierbaren Import von Massendaten ähnlich zum Export. | ||
| 529 | Darüber lassen sich sowohl Änderungen als auch Ergänzungen des Datenbestandes durchführen. Diese sind u.a.: | ||
| 530 | Initiale Migration der Bestandsdaten | ||
| 531 | Relevante Änderungen bei Umstrukturierungen von Gesellschaften | ||
| 532 | Anforderungen an bahninterne Schnittstellen | ||
| 533 | Das System bietet die Möglichkeit bahninterne Schnittstellen anzubinden. | ||
| 534 | Die Möglichkeit der Anbindung von bahninternen Schnittstellen wird durch den Bieter exemplarisch im Lösungsdokument „Architektur und Schnittstellen“ Anhang 13.1) genauer beschrieben. | ||
| 535 | Usability und Dokumentation [UDO] | ||
| 536 | Die Anforderungen der nachfolgenden Unterkapitel beziehen sich sowohl auf die Seite der Redaktion, als auf die Endnutzenden der Webseiten. | ||
| 537 | Barrierefreiheit | ||
| 538 | Das System muss die Erstellung, Verwaltung und Ausspielung barrierefreier Inhalte unterstützen. Ziel ist die Einhaltung der aktuellen Anforderungen (Konformitätsstufe AA der WCAG in der jeweils aktuellen Version). | ||
| 539 | 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. | ||
| 540 | Anforderungen an die Barrierefreiheit werden in der gesamten Vertragslaufzeit erfüllt, also auch bei Weiterentwicklung eines Service, Versionswechsel, Wartung und Pflege der Softwarelösung. | ||
| 541 | Der AN stellt dem AG regelmäßig einen aktuellen Nachweis über den Barrierefreiheitsstatus des Systems zur Verfügung. | ||
| 542 | Ergänzende Anforderungen an die Barrierefreiheit | ||
| 543 | Benutzeroberfläche | ||
| 544 | Navigation: Die Softwarelösung bietet eine einfache und intuitive Navigation, die komplett über die Tastatur bedient werden kann. Tastenkombinationen sind nachvollziehbar dokumentiert. | ||
| 545 | 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. | ||
| 546 | Alternativtexte: Alle visuellen Elemente mit Informationsgehalt (Bilder, Diagramme, Videos) sind mit beschreibenden Alternativtexten versehen. Dekorative visuelle Elemente werden für assistive Technologien versteckt. | ||
| 547 | Farbschemen: Die Softwarelösung bietet neben Farben zusätzliche Unterscheidungsmerkmale und stellt Farbschemen bereit, die für farbenblinde Benutzer geeignet sind. | ||
| 548 | Das System stellt dem Redakteur Hinweise, Prüfmechanismen oder unterstützende Funktionen zur Erkennung möglicher Barrieren während der Inhaltserstellung bereit. | ||
| 549 | Das System selbst soll so gestaltet sein, dass zentrale Funktionen barrierearm nutzbar sind. Dies betrifft insbesondere Bedienbarkeit, Verständlichkeit und die Nutzung mit unterstützenden Technologien. | ||
| 550 | Das System soll Funktionen oder Übersichten bereitstellen, die eine Prüfung und Nachvollziehbarkeit des barrierefreien Zustands von Inhalten unterstützen. Es besteht die Möglichkeit eines Exports bzw. Übergabe an Drittsysteme. | ||
| 551 | Interaktive Elemente | ||
| 552 | 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. | ||
| 553 | Steuerelemente: Buttons, Links und andere interaktive Elemente sind ausreichend groß abgebildet und leicht zu identifizieren. | ||
| 554 | Fehlermeldungen: Fehlermeldungen sind klar und verständlich formuliert und bieten alternative Lösungsvorschläge. | ||
| 555 | Medieninhalte | ||
| 556 | Untertitel und Transkripte: Videos und Audioinhalte sind mit Untertiteln und schriftlichen Transkripten versehen. | ||
| 557 | Audiodeskription: Eine Option für Audiodeskriptionen für visuelle Inhalte ist vorhanden. | ||
| 558 | Kompatibilität und Interoperabilität | ||
| 559 | Plattformunabhängigkeit: Die Softwarelösung ist auf verschiedenen Betriebssystemen (Windows, macOS,) barrierefrei nutzbar. | ||
| 560 | Browserkompatibilität: Die Softwarelösung ist mit den gängigsten Webbrowsern (MS Edge, Chrome, Safari) kompatibel und deren Barrierefreiheitsfunktionen werden unterstützt. | ||
| 561 | Test- und Validierungsprozesse | ||
| 562 | Kontinuierliche Verbesserung: Die Softwarelösung wird regelmäßig entsprechend der geltenden Rechtsgrundlage aktualisiert, um neuen Barrierefreiheitsstandards und Rückmeldungen der Nutzer gerecht zu werden. | ||
| 563 | Das System ist so ausgelegt, dass Anpassungen bei veränderten gesetzlichen oder normativen Anforderungen zur Barrierefreiheit ohne grundlegende Systemablösung möglich sind. Dies betrifft sowohl das System selbst als auch die Erstellung, Verwaltung und Ausspielung von Inhalten. | ||
| 564 | Usability | ||
| 565 | Vorgaben für Benutzeroberfläche und Usability | ||
| 566 | Das Redaktionssystem muss eine benutzerfreundliche Oberfläche gemäß gängiger Usability‑Standards bieten. Der Zielzustand muss sich an anerkannte Usability- und User-Experience-Standards orientieren, insbesondere DIN EN ISO 9241, u.a. Teil 110 „Interaktionsprinzipien zur Gestaltung nutzerfreundlicher interaktiver Systeme“. | ||
| 567 | Das System bietet die Möglichkeit zur userspezifischen Optimierung der Arbeitsprozesse. (z. B. durch Favoriten, Lesezeichen) | ||
| 568 | Das System ermöglicht es, mehrere Prozesse parallel zu bearbeiten. Eine parallele Bearbeitung kann z. B. in Form von mehreren Tabs erfolgen. | ||
| 569 | Das System bietet die Möglichkeit von Statusmeldungen auf der Startseite oder Login Screen. | ||
| 570 | Das System bietet den Usern die Möglichkeit, Feedback in Hinblick auf die Bedienoberfläche an den Auftraggeber zu geben. | ||
| 571 | Zusätzlich bietet das System 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. | ||
| 572 | Alle Funktionalitäten des Systems können über eine graphische Oberfläche entsprechend dem Rollen- und Berechtigungskonzept genutzt werden. | ||
| 573 | Bedienbarkeit | ||
| 574 | Das System bietet eine Block- und Multiselektion in Listen an. Per Block- und Multiselektion ausgewählte Objekte können durch den Benutzer bearbeitet werden. | ||
| 575 | Das System verwendet Standards wie Tastenkürzel/ Tastenkombinationen, wie z. B. Kopier- sowie Ausschneide-Funktionalitäten. Dies gilt auch für tabellarische Darstellungen. | ||
| 576 | Unterstützte Browser | ||
| 577 | Das System unterstützt Microsoft Edge, Safari und Google Chrome in der jeweils aktuellen mobilen und Desktop-Version auf allen Endgerätetypen und -größen. | ||
| 578 | Ferner ist das System auch auf älteren Vorgängerversionen der genannten Browser lauffähig und kann korrekt dargestellt und genutzt werden. | ||
| 579 | Rückmeldung des Systems | ||
| 580 | Das System 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. | ||
| 581 | Das System stellt sicher, dass vor dem Verlassen von Bearbeitungsmasken, in denen sich seit dem Öffnen etwas geändert hat, ein Warnhinweis an den Benutzer erscheint, ob die Änderungen übernommen werden sollen. | ||
| 582 | Das System 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. Es gehen keine Benutzereingaben verloren. | ||
| 583 | Die Fehlermeldung ist für Redakteure selbsterklärend und die Fehlermeldung wird im Kontext des Fehlers im System ausgegeben. Die Nutzung eines Fehlerhandbuches ist nicht erforderlich. 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). | ||
| 584 | Das System loggt Benutzer, die über einen einstellbaren Zeitraum im System inaktiv sind, automatisch aus. | ||
| 585 | Hilfestellung für Benutzer | ||
| 586 | Das System ermöglicht, dass die Landing Pages (z.B. Startseite) rollenspezifisch konfiguriert werden können. | ||
| 587 | Das System bietet 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. | ||
| 588 | Das System verfügt über eine Rechtschreib-und Grammatikprüfung in deutscher und englischer Sprache, welche den Anwender auf Rechtschreib- und Grammatikfehler aufmerksam macht. | ||
| 589 | Das System bietet die Möglichkeit, dass der AG für Eingabefelder Bedingungen 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. | ||
| 590 | Weiterhin kann der AG Pflichtfelder in der Bedienoberfläche definieren. | ||
| 591 | Das System stellt die Beschriftung von Feldern zur optionalen und verpflichtenden Eingabe durch Schrifttyp, Hintergrundfarbe oder vergleichbare Maßnahmen deutlich erkennbar dar. | ||
| 592 | Das System 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. | ||
| 593 | Navigationsbereich | ||
| 594 | Der Benutzer kann im System jederzeit erkennen, wo er sich befindet und der Benutzer kann auch zu anderen Aktivitäten springen. | ||
| 595 | UTF-8 Konformität / Formatvorgaben | ||
| 596 | Alle Eingabe- bzw. Ausgabeformate sind UTF-8 konform. | ||
| 597 | Das System unterstützt den Codec UTF 8/16 oder Unicode, um deutsche Zeichen (z.B. Umlaute), Zahlen und Formate (z.B. Datum) zu unterstützen. | ||
| 598 | Bereitstellung einer URL mit Bezug zu DB | ||
| 599 | Das System ermöglicht dem AG, dass dieser für das System eine URL mit Bezug zur IT-Umgebung der DB einrichten kann, z. B. https://.... anwendung.deutschebahn.com oder https://... .deutschebahn.com/anwendung. | ||
| 600 | Dieser Bezug zur URL bleibt während der Arbeit in der Anwendung in der Adresszeile bestehen. | ||
| 601 | Dokumentation | ||
| 602 | Dokumentationen / Benutzerhandbücher | ||
| 603 | Der Auftragnehmer stellt Dokumentationen im digitalen Format zur Verfügung. Diese sind vor allem, aber nicht ausschließlich: | ||
| 604 | Benutzerhandbuch für die Endnutzer | ||
| 605 | Betriebsführungshandbuch für die fachliche Betriebsführung | ||
| 606 | Schulungshandbuch für die fachliche Betriebsführung | ||
| 607 | Schnittstellendokumentation | ||
| 608 | Alle Dokumentationen sind mindestens auf Deutsch / Englisch verfügbar. | ||
| 609 | Bei Versions- oder Releasewechsel des Systems wird der Auftragnehmer die entsprechend aktualisierten Dokumentationen spätestens zur Produktivsetzung zur Verfügung stellen. | ||
| 610 | Erweiterbarkeit und Ergänzung der fachlichen Dokumentation | ||
| 611 | 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. | ||
| 612 | 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. | ||
| 613 | Dateiformate der Dokumentation | ||
| 614 | 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. | ||
| 615 | Service-Level, Support, Wartung und Fehlerbehebung [SUP] | ||
| 616 | Verfügbarkeit | ||
| 617 | Unter Verfügbarkeit wird das Verhältnis aus der tatsächlichen Dauer zu der geplanten Dauer, während der das System genutzt werden kann, verstanden. | ||
| 618 | 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. | ||
| 619 | 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 | ||
| 620 | 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 x24h x60min = 43.200 Minuten pro Monat; Einer Verfügbarkeit von 99,91% entsprechen maximal 39 Minuten Ausfallzeit pro Monat. | ||
| 621 | 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: | ||
| 622 | Ausfallzeiten während geplanter Wartung (Wartungsfenster) | ||
| 623 | Fehler / Störungen im Verantwortungsbereich des Auftraggebers | ||
| 624 | 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. Dabei bedarf es der Mitbestimmung des AG. | ||
| 625 | Trotz des Wartungsfensters muss die Auslieferung der Websites sichergestellt sein. | ||
| 626 | Die monatliche Verfügbarkeit der SaaS-Lösung beträgt mindestens 99,91 Prozent. Erfüllt der Auftragnehmer die genannte Verfügbarkeit nicht, greifen die Regelungen gemäß Ziffer 5.6. | ||
| 627 | Die Verfügbarkeit der SaaS-Lösung und der einzelnen Funktionalitäten wird vom Auftragnehmer in einer monatlichen Statistik berichtet (siehe Ziffer 5.5). | ||
| 628 | Support | ||
| 629 | Der Auftragnehmer stellt einen 2nd Level Support und 3rd Level Support für den Auftraggeber (nicht für Endnutzer des Systems) über die gesamte Vertragslaufzeit bereit. Innerhalb der Supportzeit gelten die definierten Reaktions- und Fehlerbehebungszeiten. | ||
| 630 | Der Auftragnehmer stellt den 2nd Level Support mit einer Verfügbarkeit von 24/7 für den Auftraggeber bereit. | ||
| 631 | Der Auftragnehmer stellt den 3rd Level Support zu den üblichen Bürozeiten von 8:00 bis 17:00 bereit. | ||
| 632 | Der 1st Level Support liegt in der Verantwortung des Auftraggebers. | ||
| 633 | Der Support durch den AN wird in deutscher Sprache geleistet. | ||
| 634 | Der Auftraggeber hat die Möglichkeit, über folgende Kontaktwege mit dem Auftragnehmer in Kontakt zu treten: Telefon, E-Mail, Webformular als Teil eines Ticketsystems, persönlicher Kontakt, z.B. dem Success Manager. | ||
| 635 | Der Auftragnehmer stellt bei Bedarf einen zentralen Ansprechpartner für den Auftraggeber bereit. | ||
| 636 | 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. | ||
| 637 | Der Auftraggeber hat die Möglichkeit, jederzeit den Status seiner Vorfälle einzusehen (z. B. über ein eigenes Portal). | ||
| 638 | Es gibt umfangreiche FAQs, Wissensdatenbanken und Best Practices sowie Foren zum System , 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. | ||
| 639 | Fehlerklassen / Incident-Prioritäten, Reaktionszeiten und Fehlerbehebungszeiten | ||
| 640 | Erfolgt eine Fehlermeldung, wird die Fehlerklasse auf Grundlage des nachfolgenden Schemas durch den Auftraggeber bestimmt. Ein Fehler kann einer von vier Fehlerklassen zugeordnet werden. | ||
| 641 | Die Fehlerklasse ergibt sich aus den Faktoren der Auswirkung und Dringlichkeit. | ||
| 642 | Auswirkung bezieht sich auf die potenziellen Auswirkungen, die ein nicht gelöstes Problem / Fehler auf die Fähigkeit der DB hat, ihre Geschäftsprozesse effektiv auszuführen. | ||
| 643 | Dringlichkeit ist die Geschwindigkeit, die für die Lösung eines Problems / eines Fehlers mit einer bestimmten Auswirkung als angemessen erachtet wird. | ||
| 644 | Die nachfolgende Tabelle erläutert die einzelnen Kategorien der Auswirkung im Detail: |
| Auswirkung | Beschreibung der Auswirkung: |
| Hoch | * Eine große Anzahl von Mitarbeitern ist betroffen und/oder kann ihre Aufgaben nicht mehr erfüllen. * Eine große Anzahl von Kunden ist betroffen und/oder ist in irgendeiner Weise akuten Nachteilen ausgesetzt. * Benutzer mit VIP-Status sind betroffen. * Der finanzielle Schaden durch die Störung ist voraussichtlich hoch. * Eine Beschädigung der Reputation des Unternehmens in großem Umfang ist wahrscheinlich. * Es besteht Gefahr für Leib und Leben. |
| Mittel | * Eine mäßige Anzahl von Mitarbeitern ist betroffen und/oder kann ihre Aufgaben nicht wie vorgesehen erfüllen. * Eine mäßige Anzahl von Kunden ist betroffen und/oder erfährt Einschränkungen beim Komfort. * Der finanzielle Schaden durch die Störung liegt voraussichtlich im mittleren Bereich. * Eine Beschädigung der Reputation des Unternehmens in mäßigem Umfang ist wahrscheinlich. |
| Niedrig | * Eine geringe Anzahl von Mitarbeitern ist betroffen und/oder kann ihre Aufgaben erfüllen, jedoch nur mit zusätzlichem Aufwand. * Eine geringe Anzahl von Kunden ist betroffen und/oder erfährt Einschränkungen beim Komfort, jedoch nur in geringem Umfang. * Der finanzielle Schaden durch die Störung ist voraussichtlich gering. * Eine Beschädigung der Reputation des Unternehmens ist nur in geringem Umfang zu erwarten. |
Tabelle 1 Auswirkungskategorien
| Ref # | Auftraggeber | J/N | Auftragnehmer |
|---|---|---|---|
| 645 | Die nachfolgende Tabelle erläutert die einzelnen Kategorien der Dringlichkeit im Detail: |
| Dringlichkeit | Beschreibung der Dringlichkeit: |
| Hoch | * Der von der Störung verursachte Schaden nimmt immens schnell zu. * Die Aufgaben, die von den Mitarbeitern nicht erfüllt werden können, sind zeitkritisch. * Durch schnelles Handeln kann verhindert werden, dass aus einem Minor-Incident ein Major-Incident wird. * Benutzer mit VIP-Status sind betroffen. |
| Mittel | * Der von der Störung verursachte Schaden nimmt im Verlauf der Zeit substanziell zu. * Die Aufgaben, die von den Mitarbeitern nicht erfüllt werden können, sind nur mäßig zeitkritisch. |
| Niedrig | * Der von der Störung verursachte Schaden nimmt im Verlauf der Zeit nur unwesentlich zu. * Die Aufgaben, die von den Mitarbeitern nicht erfüllt werden können, sind nicht zeitkritisch. |
Tabelle 2 Dringlichkeitskategorien
| Ref # | Auftraggeber | J/N | Auftragnehmer |
|---|---|---|---|
| 646 | Die nachfolgende Tabelle zeigt die Berechnung der Fehlerklasse auf, die sich aus der Kombination von Auswirkung und Dringlichkeit ergibt: |
| Auswirkung | Dringlichkeit | Fehlerklasse |
| 1 – Hoch | 1 – Hoch | 1 - Kritisch |
| 1 – Hoch | 2 – Mittel | 2 - Hoch |
| 1 – Hoch | 3 – Niedrig | 3 - Mittel |
| 2 – Mittel | 1 – Hoch | 2 - Hoch |
| 2 – Mittel | 2 – Mittel | 3 - Mittel |
| 2 – Mittel | 3 – Niedrig | 4 - Niedrig |
| 3 – Niedrig | 1 – Hoch | 3 - Mittel |
| 3 – Niedrig | 2 – Mittel | 4 - Niedrig |
| 3 – Niedrig | 3 – Niedrig | 4 - Niedrig |
Tabelle 3 Berechnung Fehlerklasse
| Ref # | Auftraggeber | J/N | Auftragnehmer |
|---|---|---|---|
| 647 | Die nachfolgende Tabelle enthält die Reaktions- und Fehlerbehebungszeiten in Abhängigkeit der Fehlerklasse: |
| Fehlerklasse | Reaktionszeit | Fehlerbehebungszeit |
| 1 – kritisch | ≤ 30 Min | Unverzüglich, maximal 4 Stunden |
| 2 – hoch | ≤ 60 Min | Unverzüglich, maximal 24 Stunden |
| 3 – mittel | ≤ 1 Arbeitstag | ≤ 3 Arbeitstage |
| 4 – niedrig | ≤ 2 Arbeitstage | ≤ 6 Arbeitstage |
Tabelle 4 Reaktions- und Fehlerbehebungszeiten
| Ref # | Auftraggeber | J/N | Auftragnehmer |
|---|---|---|---|
| 648 | Die Reaktionszeit ist die Zeit zwischen dem Eingang einer Störungs-/Fehlermeldung und der ersten Kontaktaufnahme zwischen der mit der Fehlerbehebung betrauten Stelle und der Stelle/Person, die den Fehler gemeldet hat. | ||
| 649 | Eine Eskalation des Vorfalls erfolgt, wenn die Reaktionszeit überschritten ist oder wenn SLA-Verletzungen entstehen. | ||
| 650 | Die Fehlerbehebungszeit ist die Zeit zur Behebung von Störungen. Sie beginnt mit der vollständigen Störungs-/Fehlermeldung und endet mit der Meldung der erfolgreichen Behebung der Störung/des Fehlers durch den Auftragnehmer. Störungen werden innerhalb der definierten Supportzeit behoben. | ||
| 651 | Die SaaS-Lösung ermöglicht es, dass sie auf Basis von regelmäßig, mindestens alle 24 Stunden, durchgeführten Sicherungen binnen 4 Stunden erfolgreich vollständig wiederhergestellt werden kann. | ||
| 652 | Behebung und Dokumentation von Fehlern | ||
| 653 | 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. | ||
| 654 | 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. | ||
| 655 | Ein Fehler (unabhängig von der Fehlerklasse) gilt als vollständig im Tool dokumentiert, wenn mindestens folgende Angaben zu einem Fehler gemacht werden: | ||
| 656 | Uhrzeit (Beginn der Störung) | ||
| 657 | Status | ||
| 658 | Verständliche Beschreibung des Fehlverhaltens der Software, mit Fehlerursache, sofern diese dem AG gesichert bekannt ist. | ||
| 659 | Messung und Reporting von Service-Leveln | ||
| 660 | 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. | ||
| 661 | Der Auftraggeber kann die Vorlage einer angemessenen Root-Cause-Analyse und eines Abhilfeplans seitens des Auftragnehmers verlangen. | ||
| 662 | Kompensation / Auswirkung bei Nicht-Einhaltung der SLA | ||
| 663 | Kompensationen können hinsichtlich der vereinbarten Verfügbarkeit der SaaS-Lösung als auch aus Verletzungen der Reaktionszeit und Fehlerbehebungszeit sowie maximalen Störungsausfallzeit resultieren. | ||
| 664 | Die Kompensation wird pro Kalenderjahr und SaaS-Lösung auf 15% der jährlichen Auftragssumme begrenzt. | ||
| 665 | 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 ausweisen und den Rechnungsbetrag entsprechend kürzen. | ||
| 666 | 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. | ||
| 667 | Für die Berechnung einer Kompensation bei Verletzung der Verfügbarkeit wird folgende Formel herangezogen: Kompensation = S * (Vzugesagt – Vist) | ||
| 668 | S = Auftragssumme im Monat | ||
| 669 | Vzugesagt = Laut SLA vereinbart minimale Verfügbarkeit im Monat in Prozent | ||
| 670 | Vist = Ist-Verfügbarkeit im Monat l in Prozent | ||
| 671 | Für die Berechnung einer Kompensation bei Verletzung der Reaktionszeit gilt Folgendes: Überschreitet der Auftragnehmer die vereinbarte Reaktionszeit der Fehlerklassen 1 und 2, so zahlt der Auftragnehmer an den Auftraggeber für jeden Fall der Überschreitung eine Kompensation in Höhe von € 300 pro angefangene Stunde. | ||
| 672 | Für die Berechnung einer Kompensation bei Verletzung der Fehlerbehebungszeit gilt Folgendes: Überschreitet der Auftragnehmer die vereinbarte Fehlerbehebungszeitt, so zahlt der Auftragnehmer an den Auftraggeber für jeden Fall der Überschreitung eine Kompensation nach der folgenden Logik. | ||
| 673 | Fehlerklasse 1: 2.500€ für jede überschrittene 4 Stunden-Einheit (d.h. 2.500€ nach 4 Stunden, 5.000€ nach 8 Stunden, 7.500€ nach 12 Stunden usw.) | ||
| 674 | Fehlerklasse 2: 2.500€ für jede überschrittene 24 Stunden-Einheit (d.h. 2.500€ nach 24 Stunden, 5.000€ nach 48 Stunden, 7.500€ nach 72 Stunden usw.) | ||
| 675 | Fehlerklasse 3: einmalig 2.500€ für die Überschreitung der vereinbarten Fehlerbehebungszeit | ||
| 676 | Fehlerklasse 4: einmalig 2.500€ für die Überschreitung der vereinbarten Fehlerbehebungszeit | ||
| 677 | Allgemeine Anforderungen zu Service-Leveln | ||
| 678 | 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. | ||
| 679 | 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. | ||
| 680 | Wartung / Weiterentwicklung | ||
| 681 | In Bezug auf die Wartung und Weiterentwicklung gelten die folgenden Definitionen: | ||
| 682 | Release: Die Kennzeichnung einer konkreten Softwareversion, die Anwendern zusätzliche Optionen durch neue Features und Funktionen bietet. | ||
| 683 | Update: Die Aktualisierung vorhandener Software und deren Funktionalitäten | ||
| 684 | Patch: Die zeitnahe Behebung eines Fehlers oder einer Sicherheitslücke in einer in Betrieb befindlichen Software. | ||
| 685 | Der AN verpflichtet sich zur kontinuierlichen Weiterentwicklung seines Systems und stellt regelmäßig Releases zur Verbesserung der bestehenden Funktionalität sowie für die Lieferung neuer Standard-Funktionalitäten bereit. Diese werden rechtzeitig, mindestens drei Monate, 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. | ||
| 686 | 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. | ||
| 687 | Releases, Updates und Patches erfolgen so, dass vom AG implementierten Funktionalitäten nach deren Inbetriebnahme weiter funktionieren (Aufwärtskompatibilität). | ||
| 688 | 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. | ||
| 689 | 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. | ||
| 690 | 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. | ||
| 691 | 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. | ||
| 692 | Der Auftragnehmer verpflichtet sich, gelieferte Softwarekomponeten (z. B. Bibliotheken von Drittherstellern), die ihren EOSL (End of Service Life) erreicht hat, durch eine lauffähige Alternative zu ersetzen. Dem Auftraggeber dürfen hierbei keine zusätzlichen Kosten entstehen. | ||
| 693 | 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. | ||
| 694 | 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. | ||
| 695 | Die in der SaaS-Lösung gehaltenen Daten werden durch Releases, Updates oder Patches inhaltlich nicht verändert. | ||
| 696 | Diese Anforderungen gelten nicht nur für die SaaS-Lösung selbst, sondern auch für umstehende Funktionalitäten wie Schnittstellen. Alle Schnittstellen bzw. die zugehörigen koexistierenden Systeme sind mit ihrer Kompatibilität uneingeschränkt und reibungslos weiterhin im gewohnten Maße bedienbar. | ||
| 697 | 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. | ||
| 698 | Releasenotes | ||
| 699 | Der Auftragnehmer liefert mit jeder Softwarebereitstellung Release Notes. | ||
| 700 | Diese Release Notes weisen mindestens die folgenden Inhalte auf: | ||
| 701 | eindeutige Versionsnummern für jede Komponente | ||
| 702 | Detailierter Änderungsumfang | ||
| 703 | Ggf. umgesetzte fachliche Anforderungen | ||
| 704 | Ggf. umgesetzte nicht-fachliche Anforderungen | ||
| 705 | Neue Funktionalitäten, die nicht auf Anforderungen durch den Auftraggeber beruhen | ||
| 706 | Ggf. behobene Fehler | ||
| 707 | Ggf. bekannte Fehler | ||
| 708 | Hinweise, Anmerkungen und Handlungsempfehlungen für die Nutzer | ||
| 709 | Hinweise, Anmerkungen und Handlungsempfehlungen für weitere relevante Stakeholder (z.B. Betriebsführung, Entwicklung) | ||
| 710 | Der Auftraggeber hat das Recht Auszüge aus diesen Release Notes für die eigene Dokumentation und Nutzerhandbücher zu verwenden. | ||
| 711 | INtegration, Migration und Test [IMT] | ||
| 712 | Integrationsanforderungen | ||
| 713 | Unmittelbar nach Vertragsabschluss beginnen AG und AN gemeinsam mit dem Projekt zur Herstellung der Lieferfähigkeit (auch „Integrationsprojekt“). | ||
| 714 | Für die Leistungen zur Planung und Durchführung dieses Projekts erfolgt die Vergütung gemäß Anlage 2 (Preisblatt) nach Abnahme der Lieferkomponenten in Verantwortung des AN gemäß Anhang 13.2 (Lösungsdokument Integration und Migration). | ||
| 715 | Ziel des Projektes ist, dass die vertraglich vereinbarten Leistungen des AN innerhalb möglichst kurzer Zeit, spätestens jedoch bis Dezember 2029, für den AG beziehbar und nutzbar sind, sowie alle dafür notwendigen Prozesse und Schnittstellen implementiert sind. Dazu gehören insbesondere: | ||
| 716 | Validierungsunterstützung: Sowohl während der Implementierungsphase als auch bei der Durchführung von Änderungen sind umfangreiche funktions- und technische Tests, sowie User Acceptance Tests, erforderlich. | ||
| 717 | Implementierung der Schnittstellen beim AG hinsichtlich Tests und Validierungen mit einer produktionsgleichen Testumgebung einer funktional identischen Softwarelösung | ||
| 718 | Der Aufbau einer Providergovernance-Struktur inkl. Reporting für den Vertrag und die Zusammenarbeit zwischen AG und AN | ||
| 719 | Die Umsetzung möglicher Vorgaben aus Compliance-Anforderungen wie beispielsweise Datenschutz und Informationssicherheit | ||
| 720 | Hierfür wird unmittelbar nach Vertragsabschluss ein detaillierter Plan zwischen den Vertragsparteien abgestimmt, welcher die vereinbarte Planung gemäß Anhang 13.2 (Lösungsdokument Integration und Migration) verfeinert und operationalisiert. | ||
| 721 | AG und AN übernehmen die im Plan festgehaltenen Verantwortlichkeiten. | ||
| 722 | Die Abnahme der Leistungen in Verantwortung des AN richtet sich nach Anhang 13.2 (Lösungsdokument Integration und Migration). Das genaue Abnahmeprocedere wird nach Vertragsschluss vereinbart. | ||
| 723 | Flexible Migrationsanforderungen | ||
| 724 | Im Falle eines Wechsels von dem Bestandssystem („Alt-System“) auf ein neues System („Neu-System“) ist eine Migration zwingend erforderlich. | ||
| 725 | Für die Leistungen zur Planung und Durchführung dieses Projekts erfolgt die Vergütung gemäß Anlage 2 (Preisblatt) nach Abnahme der Lieferkomponenten in Verantwortung des AN gemäß Anhang 13.2 (Lösungsdokument Integration und Migration). | ||
| 726 | Ziel der Migration ist, dass binnen kürzester Zeit, spätestens jedoch bis Dezember 2029, ein möglichst nahtloser und unterbrechungsfreier fachlicher und technischer Betrieb des Systems durch den AG möglich ist. | ||
| 727 | Der AN verantwortet die Planung und Durchführung des Migrationsprojekts. Der Auftraggeber hat die finale Entscheidungshoheit über den Ablauf des Migrationsprojekts und unterstützt den Auftragnehmer bei der Durchführung der Migration mit der Bereitstellung der notwendigen Beistellleistungen. Des Weiteren behält sich der AG vor, Teile der Migration eigenständig umzusetzen. | ||
| 728 | Die Vorgehenswese zur Durchführung der Migration durch den Auftragnehmer ist im Lösungsdokument Anhang 13.2 (Lösungsdokument Integration und Migration ) beschrieben. | ||
| 729 | Im Rahmen der Migration sind die folgenden Punkte vom Auftragnehmer in seinem Migrationskonzept berücksichtigt: | ||
| 730 | Die Migration beginnt nach Vertragsschluss mit der Beauftragung der Migration. | ||
| 731 | Der AG gibt die Reihenfolge der Migration aller Bestandlösungen vor. | ||
| 732 | Projektmanagement: Der AN stellt das Migrationsprojekt inklusive Projektleiter. Dieser ist für die Feinplanung und Durchführung der Migration nach Abstimmung mit dem AG verantwortlich. | ||
| 733 | Bereitstellung der Umgebungen: Es werden für die Migration mindestens Entwicklungs-, Test- und Produktivumgebungen für das zu migrierende System bereitgestellt. | ||
| 734 | Customizing & Entwicklung: Der AG führt gemeinsam mit dem AN die Konfiguration, das Customizing und die Entwicklung in dem System durch, um eine 1:1 Ablösung der jeweils bestehenden Lösung zu gewährleisten. | ||
| 735 | Datenmigration: Der AN führt für jedes System die Datenmigration der bestehenden Daten durch und kontrolliert diese auf Vollständigkeit und Korrektheit der Datenübernahme. | ||
| 736 | Einrichtung von Rollen und Rechten: Der AN richtet in der neuen dem neuen System die Mitarbeiter entsprechend ihren Rollen ein. Der AN stellt dabei sicher, dass die Rechte und Sichtbarkeiten der Mitarbeiter in der neuen dem neuen System identisch der Rechte und Sichtbarkeiten der alten des alten .Systems sind. | ||
| 737 | Test & Abnahme: Vor einem GoLive wird die Softwarelösung durch Tests freigegeben. Der AN prüft das System auf die vollständige Umsetzung der technischen, fachlichen und nicht-funktionalen Anforderungen. Vor einem produktiven GoLive werden Testdaten vom AG bereitgestellt und vom AN in das Produktivsystem eingespielt. Das System wird vom AG vor einem Go-Live geprüft und getestet (Abnahmetest) und seitens AN und AG für den GoLive freigegeben. . | ||
| 738 | Die Mitarbeiter des AG werden am neuen System vom AN geschult. Hierfür stellt der AN folgende Schulungsleistungen zur Verfügung: | ||
| 739 | Schulungskonzept für die Rollen: Anwender, Betriebsführer, Architekten, Entwickler, Fachadministratoren, Qualitätssicherung | ||
| 740 | Schulungsdurchführung für die Rollen: Anwender, Betriebsführer, Architekten, Entwickler, Fachadministratoren, Qualitätssicherung | ||
| 741 | Sicherheitsrelevante Anforderungen [SAN] | ||
| 742 | Datenschutzanforderungen | ||
| 743 | 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 und nachzuweisen. Die in der Leistungsbeschreibung verwendeten datenschutzrechtlichen Begriffe entsprechen den Begriffsbestimmungen des Art. 4 DSGVO. | ||
| 744 | Anforderungen | ||
| 745 | Verpflichtung auf die Vertraulichkeit | ||
| 746 | 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. | ||
| 747 | Nachweis der Verpflichtung auf die Vertraulichkeit | ||
| 748 | Unterauftragnehmer (Unterauftragsverarbeiter) | ||
| 749 | Der Auftragnehmer stellt sicher, dass eingesetzten Unterauftragnehmern dieselben Daten-schutzpflichten 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. | ||
| 750 | Ort der Datenverarbeitung | ||
| 751 | 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. | ||
| 752 | Eine Veränderung der Leistungsstandorte seitens des Auftragnehmers innerhalb der EU/EWR kann nur nach vorheriger Zustimmung des Auftraggebers erfolgen. | ||
| 753 | 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, | ||
| 754 | 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, | ||
| 755 | 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, | ||
| 756 | 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, | ||
| 757 | 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, | ||
| 758 | 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. | ||
| 759 | [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] | ||
| 760 | Umsetzung der Grundprinzipien Privacy by Design und Privacy by Default | ||
| 761 | 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). | ||
| 762 | Umsetzung Betroffenenrechte | ||
| 763 | 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. | ||
| 764 | Datenvermeidung und Datensparsamkeit | ||
| 765 | 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. | ||
| 766 | Der Auftragnehmer stellt sicher, dass die vorhandene Darstellung von personenbezogenen Daten auf das benötigte Maß beschränkt werden kann, bspw. durch Weglassen, Aggregation sowie selektive Detaildarstellung von Daten. | ||
| 767 | Der Auftragnehmer stellt sicher, dass die Voreinstellungen so konfiguriert sind, dass die Anzeige personenbezogener Daten ohne Eingriffe des Auftraggebers nur die für die jeweilige Rolle minimal benötigten Datenfelder, Berechtigungen und Detaildarstellungen vorhanden sind. Angebotene Datenfelder, die vom Auftraggeber nicht benötigt werden, können ohne Zusatzaufwand unterdrückt werden. | ||
| 768 | Mandantenfähigkeit und Mandantentrennung | ||
| 769 | 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. | ||
| 770 | Technische und organisatorische Maßnahmen zum Datenschutz | ||
| 771 | 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. | ||
| 772 | Nachweis hinreichender Garantien über geeignete technische und organisatorische Maßnahmen | ||
| 773 | 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. | ||
| 774 | [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.] | ||
| 775 | Weitere Produktbezogene Datenschutzanforderungen | ||
| 776 | Systemdokumentation: Der Auftragnehmer stellt sicher, dass alle verwendeten Systeme und Services sowie alle Zugriffsberechtigungen und Schnittstellen abschließend und vollständig beschrieben sind. | ||
| 777 | Eingabeprotokollierung: Der Auftragnehmer ermöglicht, dass aus der Protokollierung hervorgeht, ob und durch wen Daten verändert wurden. | ||
| 778 | Datenmigration/-portabilität: Die Daten des Auftraggebers können zur Übertragung in ein anderes System vollständig in einem Schritt ohne Zusatzaufwand unter Wahrung der vollen Datenintegrität exportiert werden. | ||
| 779 | Konfigurierbarkeit: Vorhandene Softwaremodule sind dahingehend konfigurierbar, dass dem Auftraggeber oder dem Anwender eine Wahlmöglichkeit hinsichtlich des Nutzungsumfangs am Gesamtprodukt eingeräumt wird. Hierzu sind administrativ oder im Benutzerprofil Konfigurationsmöglichkeiten vorzusehen und durch Hinweistexte verständlich darzustellen. | ||
| 780 | Voreinstellungen Konfiguration: Die Voreinstellungen werden so bereitgestellt, dass ohne Eingriffe des Auftraggebers nur die zu erwartenden Grundfunktionen freigeschaltet sind. Die zu erwartenden Grundfunktionen bilden den Bedarf ab, der durch den Auftraggeber angefordert wird. Darüberhinausgehende Mehrfunktionen werden auf Modulebene ausgeblendet. | ||
| 781 | Datensparsamkeit und -sichtbarkeit: Das System erhebt nur so viele Daten, wie für die Funktion benötigt werden. Angebotene Datenfelder, die vom Auftraggeber nicht benötigt werden, können ohne Zusatzaufwand unterdrückt oder ersatzweise gegen Benutzung gesperrt werden. | ||
| 782 | Die vorhandene Darstellung von personenbezogenen Daten wird auf das benötigte Maß beschränkt, durch Weglassen, Aggregation sowie selektive Detaildarstellung. | ||
| 783 | Voreinstellungen zur Datensichtbarkeit: Das System stellt die Voreinstellungen so bereit, dass bzgl. der Anzeige personenbezogener Daten ohne Eingriffe des Auftraggebers nur die für die jeweilige Rolle minimal benötigten Datenfelder, Berechtigungen und Detaildarstellungen vorhanden sind. | ||
| 784 | Pseudonymisierung: Das System nutzt Pseudonymisierung, um den Anforderungen der DSGVO zu genügen und die Rechte der betroffenen Personen zu schützen. | ||
| 785 | Mandantentrennung intern: Das System ermöglicht, dass mindestens eine logische Trennung innerhalb der Anwendung besteht, damit sich darin Daten mehrerer DB-Einheiten (z.B. von Abteilungen oder Konzernunternehmen) getrennt verarbeiten lassen. | ||
| 786 | Mandantentrennung extern: Die Datenverarbeitung wird durch anerkannte technische Trennung sicher der Zugriffsmöglichkeit anderer Kunden und der Öffentlichkeit entzogen. | ||
| 787 | Löschmodalitäten: Das System ist darauf eingerichtet, ein DSGVO konformes Konzept zur Löschung bzw. Anonymisierung personenbezogener Daten des Auftraggebers umzusetzen. Hierbei sieht das System zeit- und ereignisgesteuerte Auslöser vor. Ereignissteuerung bedeutet, dass auf Aktionen in der Software oder Änderungen im Datenbestand reagiert werden muss. Die (zeitgesteuerte) Umsetzung erfolgt im Regelfall in einem mindestens monatlichen Modus, bedarfsweise wird eine unverzügliche Löschung zum nächsten Werktag sichergestellt. | ||
| 788 | Verschlüsselte Datenablage: Die Datenablage erfolgt anwendungsseitig verschlüsselt. | ||
| 789 | Verschlüsselte Datenübertragung: Die Datenübertragung durch das System erfolgt verschlüsselt | ||
| 790 | Berechtigungsdesign: Berechtigungen sind gemäß eines Rollen-unterscheidenden Konzepts konfigurierbar und Zugriffe entsprechend wirksam beschränkt. Der Auftragnehmer ermöglicht, dass aus der Protokollierung hervorgeht, ob und durch wen personenbezogene Daten verändert wurden. | ||
| 791 | Protokollweitergabe: Der Auftragnehmer hat einen Prozess etabliert, wann und wie Informationen aus der Protokollierung zur Löschung personenbezogener Daten dem Auftraggeber verfügbar gemacht werden. | ||
| 792 | Protokoll-Löschung: Der Auftragnehmer 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 Auftraggebers konfiguriert werden. | ||
| 793 | Change Protokoll - Löschung der Historie: Das System 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. | ||
| 794 | Anforderungen an die Informationssicherheit und Authentifizierung | ||
| 795 | 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. | ||
| 796 | Schutzbedarf | ||
| 797 | 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): | ||
| 798 | Vertraulichkeit: hoch | ||
| 799 | Integrität: hoch | ||
| 800 | Verfügbarkeit: hoch | ||
| 801 | 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. | ||
| 802 | Grundsätzliche Sicherheitsanforderungen | ||
| 803 | 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. | ||
| 804 | Der AN verfügt während der Vertragslaufzeit über aktuelle Zertifizierungen zur Informationssicherheit von unabhängigen Zertifizierungsstellen zu | ||
| 805 | dem Informations-Sicherheitsmanagement (ISO 27001, IT-Grundschutz oder vergleichbar) | ||
| 806 | dem/den von ihm eingesetzten Rechenzentrum/Rechenzentren (ISO, SOCI/II, etc.) | ||
| 807 | den von ihm bereitgestellten Cloud-Services (BSI - Cloud Computing Compliance Controls Catalogue C5). | ||
| 808 | Prüfberichte des AN sowie seiner Nachunternehmen und Subdienstleister zur Informationssicherheit (ISO-27001-Standardberichte oder vergleichbar und Liste der verwendeten Komponenten [SBOM]) werden mindestens jährlich zur Verfügung gestellt. | ||
| 809 | 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. | ||
| 810 | 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. Zu diesen Maßnahmen zählen insbesondere die nachfolgenden Punkte sowie die an anderen Stellen des Rahmenvertrags und dieser Anlage geforderten Maßnahmen. | ||
| 811 | Das Sicherheitskonzept wird vom AN regelmäßig überprüft und – soweit erforderlich – an aktuelle, sicherheitsrelevante Entwicklungen angepasst. | ||
| 812 | Der Auftragnehmer stellt sicher, dass alle verwendeten Systeme und Funktionalitäten sowie alle Zugriffsberechtigungen und Schnittstellen abschließend und vollständig als Systemdokumentation beschrieben sind. Der AN stellt dies dem AG auf Anfrage zur Verfügung. | ||
| 813 | 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. | ||
| 814 | 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. | ||
| 815 | Der AN ist verpflichtet, geeignete und aktuelle Sicherheitsmaßnahmen gegen Malware (Virenschutz, Trojaner-Detektion, Spam-Schutz, etc.) auf allen zur Leistungserbringung eingesetzten Systemen zu betreiben. | ||
| 816 | 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. | ||
| 817 | Verschlüsselung | ||
| 818 | 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: | ||
| 819 | 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.3 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. | ||
| 820 | 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). | ||
| 821 | Der AN unterstützt Verschlüsselungsmechanismen die den aktuellen Empfehlungen der NIST (National Institute of Standards and Technology) bzgl. Verschlüsselungsalgorithmen gerecht werden. | ||
| 822 | Die Datenablage erfolgt anwendungsseitig verschlüsselt. | ||
| 823 | Ebenso hat die Kommunikation zwischen Services / Anwendungs-Funktionalitäten mit Bezug zum AG gemäß Stand der Technik verschlüsselt zu erfolgen. | ||
| 824 | Jegliche Daten, die beim AN abgelegt / gespeichert werden, müssen mit einem Schlüssel 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). | ||
| 825 | Bei der Wiederherstellung werden die zuvor durch die Softwarelösung verschlüsselten Daten entsprechend entschlüsselt. | ||
| 826 | Der Auftragnehmer stellt ebenso sicher, dass das verwendete Hashverfahren aktuell ist. SHA-1 und MD5 sind nicht zugelassene Verfahren und dürfen daher nicht genutzt werden. | ||
| 827 | Die Verwendung eigener, proprietärer Verschlüsselungen ist nicht zulässig. | ||
| 828 | Die Softwarelösung stellt sicher, dass Daten bei der Nutzung auf mobilen Endgeräten lokal gespeichert werden, verschlüsselt abgelegt werden. | ||
| 829 | Falls eine direkte Datenweitergabe durch die Softwarelösung vorgesehen ist, besteht die Möglichkeit, sensitive Daten verschlüsselt zu übertragen. | ||
| 830 | Authentifizierung an der Serviceschnittstelle | ||
| 831 | Bezüglich Identitymanagement erfüllt der AN folgende Anforderungen: | ||
| 832 | Das System muss per Microsoft Active Directory/ Entra ID Gruppenmitgliedschaften für Rollen-, Berechtigungs- und Ressourcenzuweisungen abfragen und im System provisionieren können. | ||
| 833 | Das System kann per API an ein Identity-Management System angebunden werden, um darüber die freigegebenen Rollen-, Berechtigungs- und Ressourcenzuweisungen im System zu provisionieren. | ||
| 834 | Das System muss kompatibel sein mit Microsoft Active Directory/ Entra ID zur internen Userverwaltung. | ||
| 835 | Das System kann den SCIM Standard mit Microsoft Entra ID zur internen Userverwaltung nutzen. | ||
| 836 | Bezüglich der Berechtigungsvergabe erfüllt der AN folgende Anforderungen: | ||
| 837 | Das System muss eine rollen- bzw. gruppenbasierte Berechtigungsvergabe unterstützen und dabei die unterschiedlichen Funktionen innerhalb der Applikation rollen- bzw. gruppenscharf trennen. | ||
| 838 | Bezüglich Authentifizierung erfüllt der AN folgende Anforderungen: | ||
| 839 | Das System muss eine SSO Integration über Microsoft Entra ID per SAML oder OAuth/OIDC nutzen können. | ||
| 840 | Die Anwender-Authentifikation finden über 2-Faktor-Authentifizierung (2FA) bereitstellen, über die es Services ermöglicht wird, Objekte mittels SAML2.0 oder Standards wie OAUTH2 und OpenID Connect, Implementierungen zu authentifizieren. statt. | ||
| 841 | Möglichkeit, mittels Federation die Authentifizierungsdaten des Auftraggebers zu nutzen. | ||
| 842 | Für die Authentifizierung an Services können On-Premise-Benutzeraccounts / Anwenderaccounts aus dem Konzernverzeichnisdienst genutzt werden. | ||
| 843 | Gleichzeitige Anbindung von Benutzern ohne Nutzung des Federation Service (z.B. mittels Standard Login für externe User) | ||
| 844 | 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. | ||
| 845 | Die Kommunikation von System zu System (M2M) ist über gegenseitiger Authentifizierung (beispielsweise mTLS), abgesichert. | ||
| 846 | Logging und Protokollierung | ||
| 847 | Security- und Systemevents sind zu protokollieren bzw. zu loggen. Daher wird der AN folgende Anforderungen einhalten: | ||
| 848 | Entsprechende Logging-Funktionen zur Sicherstellung der internen SLAs sowie der Unterstützung in Fehlerfällen bzw. Root Cause Analysis. | ||
| 849 | Möglichkeit für den AG, Logfiles auf Anforderung zu erhalten und zu archivieren. | ||
| 850 | Anbindung der relevanten Logs an die Logserver des AG ist möglich | ||
| 851 | Die zu loggenden Parameter sind vom AG konfigurierbar. Das Logging unterstützt mindestens folgende Events: | ||
| 852 | Nutzeraktivität inkl. fehlgeschlagene Anmeldungen | ||
| 853 | Systemaktivitäten | ||
| 854 | Nutzung von administrativen Rechten | ||
| 855 | Konfigurationsänderungen | ||
| 856 | Aufrufe von Programmierschnittstellen | ||
| 857 | Aufzeichnung von Kommunikationsverbindungen | ||
| 858 | Aufzeichnungen erfolgreicher und abgelehnter Systemzugriffsversuche | ||
| 859 | Aufzeichnungen erfolgreicher oder abgelehnter Versuche, auf Daten und Informationen zuzugreifen | ||
| 860 | Aktivitäten von Jobs zum Einlesen von Datenquellen | ||
| 861 | 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. | ||
| 862 | 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. | ||
| 863 | Der Auftragnehmer stellt sicher, dass Protokolldateien für eine Dauer von mindestens 1 Monat sicher aufbewahrt sind und dem Auftraggeber auf Verlangen zur Verfügung gestellt werden. | ||
| 864 | Der Auftragnehmer stellt sichern, dass stets ausreichend Kapazitäten zur Speicherung der Protokollinformationen zur Verfügung stehen. | ||
| 865 | 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. | ||
| 866 | Das System unterstützt das sichere Löschen von Aufzeichnungen nach Ablauf der Aufbewahrungsfrist. | ||
| 867 | Schwachstellen Management und Sicherheitspatches | ||
| 868 | Der AN stellt einen täglichen Schwachstellenscan der Anwendung des AG sicher. | ||
| 869 | 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 24 Stunden zu unterrichten, wenn diese nicht behoben werden können. | ||
| 870 | 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. | ||
| 871 | 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), schnellstmöglich einzuspielen (Maximalfrist: 48 Stunden ). | ||
| 872 | 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. | ||
| 873 | Passwörter | ||
| 874 | 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: | ||
| 875 | 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. | ||
| 876 | Die Softwarelösung stellt sicher, dass Benutzerkonten durch eine starke Authentifizierung (Zwei-Faktor-Authentifizierung) geschützt werden können. | ||
| 877 | 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. | ||
| 878 | 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. | ||
| 879 | Die Softwarelösung erzwingt für Passwörter ausreichende Komplexität, die dem Stand der Technik entspricht. | ||
| 880 | 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. | ||
| 881 | Das Anmeldeverfahren der Softwarelösung stellt sicher, dass die verwendeten Passwörter nicht ungeschützt angezeigt oder unverschlüsselt über das Netz verschickt werden. | ||
| 882 | 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. | ||
| 883 | 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“) Passwörter. | ||
| 884 | 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. | ||
| 885 | Krypto-Agilität | ||
| 886 | Für verwendete kryptographische Algorithmen ist vorgesehen, dass diese schnell und effektiv umkonfiguriert oder ausgetauscht werden können. Dies betrifft in besonderem Maße Algorithmen zur asymmetrischen Verschlüsselung und Hash-Algorithmen. Hierbei ist nicht nur ein Wechsel von z. B. RSA zu ECC oder von SHA1 zu SHA256 zu ermöglichen, sondern auch weitere, heute noch nicht abschließend spezifizierte Algorithmen lassen sich integrieren, um bei Bedarf auf Algorithmen aus der Post-Quanten-Kryptographie zurückgreifen zu können. Im Bedarfsfall sind Auswirkungen auf ggf. gespeicherte Daten darzustellen (darzustellen ist wahlweise die Rückwärtskompatibilität oder ein Migrationskonzept). Die Verwendung eigener, proprietärer Verschlüsselungen ist nicht zulässig. | ||
| 887 | Anforderungen an das geschäftliche Kontinuitätsmanagement (BCM) | ||
| 888 | 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. | ||
| 889 | Notfallkommunikation | ||
| 890 | Zwischen Auftraggeber und Auftragnehmer ist zu vereinbaren, in welchen Fällen eine Notfallkommunikation aufzunehmen ist, z.B. produktbezogen unter der Festlegung von Meldeschwellen. | ||
| 891 | 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. | ||
| 892 | Ansprechpartner | ||
| 893 | Sachkundiger Ansprechpartner geschäftliches Kontinuitätsmanagement | ||
| 894 | 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. | ||
| 895 | Ansprechpartner „Notfallmanagement“ | ||
| 896 | 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. | ||
| 897 | Notfallpläne (Business Continuity Pläne, Geschäftsfortführungspläne) | ||
| 898 | 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 | ||
| 899 | Sicherstellung der Fähigkeit der Zusammenarbeit im Notfall | ||
| 900 | Bei eingetretenem oder drohenden Notfall müssen die Notfallorganisationen von Auftragnehmer und Auftraggeber in der Lage sein, den Notfall gemeinsam zu bewältigen. | ||
| 901 | Zwischen Auftragnehmer und Auftraggeber sind klare Eskalationsstufen und -wege, sowie Reaktions- und Verfügbarkeitszeiten vertraglich festzulegen. | ||
| 902 | Meldepflichten | ||
| 903 | 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 | ||
| 904 | Vorfälle, die im Umfeld des Auftragnehmers oder eines seiner Nachunternehmer aufgetreten sind, sowie | ||
| 905 | Änderungen in seinem BCMS bzw. seiner Notfallvorsorge, seinem Notfallmanagement, seinen Notfallkonzepten und bei seinen Ansprechpartnern. | ||
| 906 | Bewertung des geschäftlichen Kontinuitätsmanagements beim Auftragnehmer | ||
| 907 | Der Auftragnehmer hat auf Verlangen dem Auftraggeber gegenüber einen geeigneten Nachweis zu erbringen, der eine Bewertung eines eingerichteten geschäftlichen Kontinuitätsmanagements zulässt. | ||
| 908 | PRODUKT- UND PROZESSBEZOGENE RAHMENBEDINGUNGEN [PPR] | ||
| 909 | Anforderungen an die Nachhaltigkeit | ||
| 910 | 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. | ||
| 911 | 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. | ||
| 912 | Der AN strebt Grundsätze des Green Coding an; entsprechende Ansätze einer ressourcenschonenden, energieeffizienten IT-Entwicklung werden berücksichtigt. | ||
| 913 | Der AN strebt bis 2030 einen Anteil von 100% erneuerbaren Energien in den genutzten Rechenzentren an. | ||
| 914 | Der AN strebt bei der Auswahl der Rechenzentren hohe Energieeffizienz und einen PUE-Wert von maximal 1,5 an. | ||
| 915 | Der AN berichtet, auf Verlangen des AG, in einem gemeinsamen Austauschformat über seine Nachhaltigkeitsaktivitäten- und Zielsetzungen sowie den Stand der Maßnahmen zur Zielerreichung. (u.a. auch über die durch den Betrieb der Anwendung in Rechenzentren verursachten Emissionen). | ||
| 916 | Regelungen der Zusammenarbeit | ||
| 917 | Governance | ||
| 918 | 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. | ||
| 919 | 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 | ||
| 920 | Auf der Management-Ebene steht die Durchsetzung von strategischen Zielen und die Schaffung von Werten im Vordergrund. | ||
| 921 | Auf der Steuerungs-Ebene stehen das Pflegen der Vertragsbeziehung zwischen den Vertragsparteien und das Weiterentwickeln der Funktionalitäten im Vordergrund. | ||
| 922 | Auf der Betriebs-Ebene stehen die Dienstleistungen und die Unterstützung von Funktionalitäten durch den Auftragnehmer im Vordergrund. | ||
| 923 | Auftraggeber und Auftragnehmer werden zu Vertragsbeginn für jede Ebene der Zusammenarbeit Gremien in Form von Boards und Meetings sowie Rollen und Verantwortlichkeiten festgelegen. | ||
| 924 | 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. | ||
| 925 | 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. | ||
| 926 | 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. | ||
| 927 | 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). | ||
| 928 | 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. | ||
| 929 | 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. | ||
| 930 | Streitbeilegung | ||
| 931 | 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. | ||
| 932 | 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. | ||
| 933 | 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. | ||
| 934 | 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. | ||
| 935 | 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. | ||
| 936 | 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. | ||
| 937 | 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. | ||
| 938 | Vorbehaltlich nachfolgendem lit. (i) ist jede Vertragspartei erst nach erfolglosem Durchlaufen des Eskalationsverfahrens berechtigt, den ordentlichen Rechtsweg zu beschreiten. | ||
| 939 | Das Recht der Vertragsparteien, um einstweiligen Rechtschutz nachzusuchen, bleibt von der Pflicht, ein Eskalationsverfahren durchzuführen, unberührt. | ||
| 940 | 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. | ||
| 941 | Exitmanagement | ||
| 942 | Allgemeine Anforderungen an Exitmanagement | ||
| 943 | Allgemeine Anforderungen | ||
| 944 | 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“), so dass die Rückabwicklungszeit auf Seiten des Auftragnehmers eingehalten wird. 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). | ||
| 945 | 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. | ||
| 946 | Einzelne Unterstützungsleistungen | ||
| 947 | Die vom AN zu erbringenden Exit Unterstützungsleistungen umfassen, je nach Anforderung des AGs, insbesondere das Folgende: | ||
| 948 | Der AN wird den Zugriff auf alle Daten und Informationen bereitstellen, die für die Überleitung der Leistungen erforderlich sind; | ||
| 949 | Der AN trifft geeignete Vorkehrungen zur reibungslosen und störungsfreien Überleitung und erstellt vor Vertragsende entsprechende Pläne zum Übergang; | ||
| 950 | 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 Falles eines Vetos wird der Auftraggeber dieses detailliert begründen und den Auftragnehmer zur Anpassung auffordern. | ||
| 951 | Der Auftragnehmer ist verpflichtet, den Exit-Plan jederzeit auf Anforderung des Auftraggebers zu aktualisieren und die so aktualisierte Fassung dem Auftraggeber zur Kenntnis vorzulegen, der Auftragnehmer hat hierbei ein Veto-Recht. Der Auftragnehmer hat detaillierte Maßnahmen vorzuschlagen, um den Exit-Plan auf dem neuesten Stand zu halten. Der Auftragnehmer wird dem Auftraggeber den Vorschlag für den aktualisierten Exit-Plan zur Prüfung und Kommentierung durch den Auftraggeber vorlegen. | ||
| 952 | 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. | ||
| 953 | 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: | ||
| 954 | eine Beschreibung der zu übergebenden endenden Vertragsleistungen | ||
| 955 | eine detaillierte Beschreibung der von dem Auftragnehmer zum Zwecke der Überleitung zu erbringenden Vertragsleistungen | ||
| 956 | eine Beschreibung von Mitwirkungsobliegenheiten des Auftraggebers oder des Folgeanbieters | ||
| 957 | einen detaillierten Meilensteinplan für die Überleitung | ||
| 958 | einen detaillierten Ressourcenbedarf, aufgeteilt nach Ressourcen, die von dem Auftragnehmer, dem Auftraggeber, etwaigen Folgeanbietern oder einem sonstigen vom Auftraggeber benannten Dritten zu stellen sind | ||
| 959 | eine Beschreibung der erforderlichen Zusammenarbeit (z.B. Zeitrahmen, Rollen, Skills) zwischen den an der Überleitung beteiligten Parteien | ||
| 960 | alle Daten, Hardware, Software, Lizenzen, 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) | ||
| 961 | jegliche andere, wesentliche Informationen in Bezug auf die Überleitung | ||
| 962 | das Format aller vom Auftragnehmer im Zuge der Überleitung zur Verfügung gestellten Informationen. | ||
| 963 | 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. | ||
| 964 | Zum Ü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 marktü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. | ||
| 965 | Anforderungen an Exitmanagement für SaaS | ||
| 966 | Allgemeine Regelungen | ||
| 967 | 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. | ||
| 968 | 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. | ||
| 969 | Migrations- und Verifikations-Funktion | ||
| 970 | 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. | ||
| 971 | Unterstützung durch qualifiziertes Personal | ||
| 972 | 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. | ||
| 973 | Außerbetriebnahme-Konzept | ||
| 974 | Der Auftragnehmer übergibt dem Auftraggeber spätestens 18 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. | ||
| 975 | Löschung von Daten nach Rückführung | ||
| 976 | Ergänzend zur Ziffer 5.18 der EVB Informationssicherheit gelten folgende Anforderungen: | ||
| 977 | Nach vom Auftraggeber bestätigter erfolgreicher Rückführung gewährleistet der Auftragnehmer, dass gemäß den gesetzlichen Anforderungen 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. | ||
| 978 | Ausnahmen bestehen nur bei Daten, zu deren Aufbewahrung der Auftragnehmer gesetzlich verpflichtet ist. Der Auftragnehmer weist dies auf Verlangen des Auftraggebers nach. | ||
| 979 | Unterlagenvernichtung | ||
| 980 | 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. | ||
| 981 | Anforderungen an Exitmanagement für IT-Dienstleistungen | ||
| 982 | 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. | ||
| 983 | Erfolgt eine Übergabe der Leistungen des Auftragnehmers an interne Mitarbeiter des AG oder an einen anderen Dienstleister, ist der AN verpflichtet, diese 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. | ||
| 984 | 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. | ||
| 985 | 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. | ||
| 986 | Produktbezogene Schulung und unterstützende Dienstleistungen | ||
| 987 | Schulungsleistungen | ||
| 988 | Neben den Schulungen im Rahmen des Migrationsprojekts (siehe Kapitel6) kann der Auftraggeber Schulungsleisten während der Vertragslaufzeit mit angemessenem Vorlauf zu den Konditionen aus dem Preisblatt (Anlage 2, Position 3.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. | ||
| 989 | Der Auftragnehmer verfügt über ein Schulungskonzept und Schulungsangebot über die fach- und sachgerechte Nutzung der des Systems, welches der Auftraggeber in Anspruch nehmen kann. Das Schulungsangebot des Auftragnehmers umfasst mindestens: | ||
| 990 | Basisschulungen für Anwender, welche eine allgemeine Einführung in das Systems beinhalten, Kenntnisse der Grundlegenden Funktionalitäten vermitteln und Mitarbeiter des AG mit der Struktur, der Navigation und dem Layout vertraut machen. | ||
| 991 | 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. | ||
| 992 | Schulungen für die technische Betriebsführung des Auftraggebers, welche die betreffenden Mitarbeiter des AG in die Lage versetzt, die Software technisch auf der (Cloud)-Infrastruktur des Auftraggebers zu betreiben und den fehlerfreien Betrieb sicherzustellen. Hierzu gehören Themen wie insbesondere Installation und Konfiguration, Verwaltungs- und Administrationsaufgaben., Benutzer- und Zugriffsmanagement, Fehlerbehebung und Problemlösungsansätze. | ||
| 993 | 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. | ||
| 994 | 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 selbstständig durchführen zu können. Der Auftragnehmer stellt hierzu geeignete Trainer bereit. | ||
| 995 | Dabei werden folgende Schulungsarten angeboten: | ||
| 996 | Vor-Ort Schulungen beim Auftraggeber (Präsenzschulungen) | ||
| 997 | Remote-Schulungen | ||
| 998 | Digitale Lerneinheiten / Webinare | ||
| 999 | Lernvideos | ||
| 1000 | Präsenzschulungen finden in Räumen des Auftraggebers statt. Die Schulung findet in Abstimmung mit dem Auftragnehmer an einem Standort der DB statt. | ||
| 1001 | Digitale Lerneinheiten / Webinare und Lernvideos sind in gängigen Browsern durchführbar (mind. MS Edge) und in einem gängigen Dateiformat vorhanden (HTML5 in Scorm-Standard, Videos in mp4 o.Ä.). | ||
| 1002 | 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. | ||
| 1003 | 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: | ||
| 1004 | Folien | ||
| 1005 | Handreichungen | ||
| 1006 | Handbücher | ||
| 1007 | Aufgabenblätter aus den praktischen Übungen und Tutorials | ||
| 1008 | 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. | ||
| 1009 | 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. | ||
| 1010 | 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. | ||
| 1011 | 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. | ||
| 1012 | 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. | ||
| 1013 | 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. | ||
| 1014 | Der Auftragnehmer stellt ein Schulungssystem zur Verfügung, welches ausschließlich für Qualifizierungen genutzt wird. Das Schulungssystem verfügt über den gleichen Entwicklungsstand wie die Abnahmeumgebung und wird im Rahmen von Standardreleases automatisch auf den aktuellen Stand gehoben. Auf der Schulungsumgebung können durch den Auftraggeber beliebig viele lizenzfreie Testuser und Testdaten angelegt und verwaltet werden. Das Schulungssystem ermöglicht eine realitätsnahe und simulierte Bearbeitung aller Funktionalitäten der Anwendung anhand von Praxisfällen. Das Schulungssystem steht dem Auftraggeber über die gesamte Vertragsdauer zur Verfügung (auch während der Nutzungsphase des Produktivsystems). Sollte eine Schulungsumgebung nicht bereitgestellt werden können, so sind die Qualifizierungen/Schulungen auf der Abnahmeumgebung durchzuführen. | ||
| 1015 | IT-Dienstleistungen | ||
| 1016 | 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. | ||
| 1017 | Es besteht die Möglichkeit, im Bedarfsfall beim Auftragnehmer zu dem im Preisblatt (Anlage 2, Position 3.1 & 3.2) 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. | ||
| 1018 | 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. | ||
| 1019 | Der Auftraggeber kann auf Basis dieses Angebots die Dienstleistungen bestellen und der Auftragnehmer stellt den Start der Dienstleistungen durch entsprechend qualifizierte Fachkräfte sicher. | ||
| 1020 | Alle Fachkräfte des Auftragnehmers verfügen mindestens über das Sprachvermögen C1 in deutscher Sprache - gemäß dem gemeinsamen europäischen Referenzrahmen für Sprachen (GER). | ||
| 1021 | KI-spezifische Leistungsanforderungen für KI-Technologie | ||
| 1022 | Sachlicher Anwendungsbereich | ||
| 1023 | Die nachfolgenden KI-spezifischen Leistungsanforderungen gelten, wenn und soweit es sich bei dem Gegenstand des Beschaffungsvertrages um eine KI-Technologie oder ein sonstiges Produkt handelt, das KI-Technologie integriert. | ||
| 1024 | „KI-Technologie“ bezeichnet alle KI-Systeme und KI-Modelle (einschließlich, aber nicht beschränkt auf KI-Modelle mit allgemeinem Verwendungszweck) im Sinne der Verordnung (EU) 2024/1689 des Europäischen Parlaments und des Rates vom 13. Juni 2024 zur Festlegung harmonisierter Vorschriften für künstliche Intelligenz („KI-VO“) in ihrer jeweils gültigen Fassung. Soweit in den nachfolgenden KI-spezifischen Leistungsbedingungen der Begriff „Daten“ verwendet wird, gilt hierfür das Begriffsverständnis der KI-VO, unabhängig von einer gegebenenfalls abweichenden Definition in einem anderen Bestandteil des Beschaffungsvertrages. | ||
| 1025 | Technische Dokumentation und Betriebsanleitung | ||
| 1026 | Die Lieferung der KI-Technologie durch den Auftragnehmer umfasst die Aushändigung einer technischen Dokumentation und einer Betriebsanleitung im Sinne der KI-VO. Die im Beschaffungsvertrag hinsichtlich der Nutzungsrechte getroffene Regelung gilt für die technische Dokumentation und die Betriebsanleitung entsprechend. | ||
| 1027 | Der Auftragnehmer aktualisiert die technische Dokumentation und die Betriebsanleitung bei jeder wesentlichen Änderung während der Laufzeit des Beschaffungsvertrages und stellt sie dem Auftraggeber bzw. jeweiligen Besteller zur Verfügung. | ||
| 1028 | Die technische Dokumentation enthält mindestens die folgenden Angaben: | ||
| 1029 | die Zweckbestimmung der KI-Technologie, | ||
| 1030 | die für die Nutzung der KI-Technologie erforderliche Hardware/Software, | ||
| 1031 | die Merkmale/integrierten Funktionen der Benutzerschnittstelle, soweit anwendbar, und | ||
| 1032 | die für die Nutzung der KI-Technologie geltenden Restriktionen. | ||
| 1033 | Die Betriebsanleitung enthält präzise, vollständige, korrekte und eindeutige Informationen in einer für den Auftraggeber bzw. jeweiligen Besteller relevanten, barrierefrei zugänglichen und verständlichen Form. Die in der Betriebsanleitung enthaltenen Informationen orientieren sich an Art. 13 Abs. 3 KI-VO. | ||
| 1034 | Der Auftragnehmer stellt dem Auftraggeber bzw. jeweiligen Besteller zudem hinreichende Informationen zur Verfügung (z.B. als Teil der Betriebsanleitung), die geeignet und derart ausgestaltet sind, dass sie dem Personal des Auftraggebers bzw. jeweiligen Bestellers ermöglichen, ein ausreichendes Maß an KI-Kompetenz für die spezifische KI-Technologie zu erlangen und die KI-Technologie sicher und effektiv einzusetzen. | ||
| 1035 | Datensätze | ||
| 1036 | Die bei der Entwicklung der KI-Technologie verwendeten Trainings-, Validierungs- und Testdatensätze im Sinne der KI-VO („Datensätze“) sind im Hinblick auf die Zweckbestimmung der KI-Technologie im Kontext des Beschaffungsvertrages relevant, hinreichend repräsentativ und diskriminierungsfrei und so weit wie möglich fehlerfrei und vollständig. | ||
| 1037 | Die bei der Entwicklung der KI-Technologie verwendeten Datensätze sollen im Hinblick auf die Zweckbestimmung der KI-Technologie im Kontext des Beschaffungsvertrages die geeigneten statistischen Merkmale haben, gegebenenfalls auch bezüglich der Personen oder Personengruppen, auf die die KI-Technologie bestimmungsgemäß angewandt werden soll. Diese Merkmale der Datensätze werden durch einzelne Datensätze oder eine Kombination solcher Datensätze erfüllt. | ||
| 1038 | Die bei der Entwicklung der KI-Technologie verwendeten Datensätze, soweit dies unter Berücksichtigung der Zweckbestimmung erforderlich ist, berücksichtigen die entsprechenden Merkmale oder Elemente, die für die besonderen geografischen, kontextuellen, verhaltensbezogenen oder funktionalen Rahmenbedingungen, unter denen die KI-Technologie bestimmungsgemäß verwendet werden soll, typisch sind. | ||
| 1039 | Filter-Technologien | ||
| 1040 | Die KI-Technologie verfügt über technische Mechanismen, die der Erkennung und erforderlichenfalls Filterung der in den folgenden Bestimmungen beschriebenen Inhalte dienen („Filter“). | ||
| 1041 | Sie sind durch den Auftraggeber bzw. jeweiligen Besteller oder auf dessen Weisung hin konfigurierbar und ermöglichen es ihm, Inhalte nach Schweregrad zu kategorisieren und zu filtern. Den Auftragnehmer trifft die laufende Verpflichtung sicherzustellen, dass die Filter der KI-Technologie dem jeweiligen Stand der Technik entsprechen. | ||
| 1042 | Inhaltsfilter | ||
| 1043 | Die KI-Technologie verfügt über wirkungsvolle technische Mechanismen, durch die (potenziell) rechtswidrige, unangemessene oder sonstige schädliche Inhalte erkannt und vor der Ausgabe herausgefiltert werden können („Inhaltsfilter“). | ||
| 1044 | Hinsichtlich der zu filternden Inhalte sind der vom Auftraggeber bzw. Besteller beabsichtigte Zweck der Verwendung der KI-Technologie und die Art der Inhalte zu berücksichtigen, die von dieser verarbeitet werden. Der Inhaltsfilter soll dem Auftraggeber bzw. jeweiligen Besteller insbesondere ermöglichen, Inhalte zu erkennen und herauszufiltern, die | ||
| 1045 | Hass vermitteln oder diskriminierende Sprache aus Gründen der Rasse, ethnischen Herkunft, des Geschlechts, der Religion oder Weltanschauung, einer Behinderung, des Alters oder der sexuellen Identität verwenden; | ||
| 1046 | sexuelle Handlungen, Prostitution, Nacktheit, Pornografie, Missbrauch und die Ausbeutung von Minderjährigen beschreiben; | ||
| 1047 | physische Gewalt, Waffen oder terroristischen Extremismus beschreiben; oder | ||
| 1048 | körperliche Selbstverletzung, Essstörungen, Mobbing, Stalking oder Suizidhandlungen beschreiben. | ||
| 1049 | PII-Filter | ||
| 1050 | Die KI-Technologie verfügt über wirksame technische Mechanismen, um personenbezogene Daten, einschließlich, aber nicht beschränkt auf Namen, Adressen, Kontaktdaten, Geburtsdaten und sonstige Identifizierungsmerkmale jedenfalls bei der Ausgabe zu erkennen und optional herauszufiltern („PII-Filter“). | ||
| 1051 | Copyright-Filter | ||
| 1052 | Die KI-Technologie verfügt über wirksame technische Mechanismen, um urheberrechtlich geschützte Werke sowie Inhalte, an denen Schutzrechte Dritter bestehen, bei der Ausgabe zu erkennen und entsprechend zu kennzeichnen oder – abhängig von einer entsprechenden Konfiguration des Auftraggebers bzw. Bestellers – herauszufiltern („CopyrightFilter“). Dabei sind der vom Auftraggeber bzw. Besteller beabsichtigte Zweck der Verwendung der KI-Technologie sowie die Art der im In- und Output enthaltenen Inhalte zu berücksichtigen. | ||
| 1053 | Codetracker | ||
| 1054 | Die KI-Technologie verfügt über wirkungsvolle technische Mechanismen, durch die identifizierte Codes (insb. aus öffentlich zugänglichen Repositories), die erkennbar Schutzrechten Dritter unterliegen, bei der Ausgabe erkannt und entsprechend gekennzeichnet (z.B. mit einer Repository-URL und Lizenzinformationen) oder – abhängig von einer entsprechenden Konfiguration des Auftraggebers bzw. jeweiligen Bestellers – herausgefiltert werden („Codetracker“). Die KI-Technologie verfügt über wirkungsvolle technische Mechanismen, durch die identifizierte Codes (insb. aus öffentlich zugänglichen Repositories), die erkennbar Schutzrechten Dritter unterliegen, bei der Ausgabe erkannt und entsprechend gekennzeichnet (z.B. mit einer Repository-URL und Lizenzinformationen) oder – abhängig von einer entsprechenden Konfiguration des Auftraggebers bzw. jeweiligen Bestellers – herausgefiltert werden („Codetracker“). |