Anlage 3 Leistungsbeschreibung_Ticketsystem_20260831.pdf

[Seite 1]

Anlage 3

Leistungsbeschreibung

zur Vergabe

„Ticketsystem im Landesamt für Finanzen“

[Seite 2]

INHALT

Anlage 3 1

1. Leistungsbeschreibung 1 1.1. Allgemeine Beschreibung der Anforderungen an das Ticketsystem 1 1.2. Detailbeschreibung der Anforderungen an das Ticketsystem 3 1.2.1. Filtern, klassifizieren und priorisieren eingehender Tickets in Echtzeit 4 1.2.2. Abbildung verschiedener Vorgangsarten (Ticketart, bereichsbezogen) 4 1.2.3. Abbildung von Kategorien und Modulen 4 1.2.4. Abbildung verschiedener Ticketarten (sachverhaltsbezogen) 4 1.2.5. Ticketaufgabe (Aufgabe einer Vorgangsart) 5 1.2.6. Meldungsvorlagen und Massenanlage von Tickets 7 1.2.7. Abbildung von Ticketbearbeitern 8 1.2.8. Priorität 8 1.2.9. Betreff 8 1.2.10. Ticketbeschreibung / Kommunikation 9 1.2.11. Anlagen 9 1.2.12. Verknüpfbarkeit von Tickets / Referenztickets 10 1.2.13. externe Referenztickets 10 1.2.14. Wartungsrelease 10 1.2.15. Status 11 1.2.16. Prozessabbildung und Prozessnachvollziehbarkeit 11 1.2.17. Genehmigungsfunktion 11 1.2.18. Setzen von Tags 12 1.2.19. Suchfunktionen / Ticketsuche / Wissensdatenbank 12 1.2.20. Integration Handbuch/FAQ´s/externe Wissensdatenbank 14 1.2.21. E-Mail-Funktion / Rückfragefunktionalität 17 1.2.22. Ticket Dashboard / Auswertemöglichkeiten 17 1.2.23. Automatisierte Ticketverteilung 18 1.2.24. Anbindung an das SAP-Transportwesen / Transportsteuerung 18 1.2.25. Aufwandsbewertung und Aufwandsplanung 19 1.2.26. Zugriffsbeschränkung / Berechtigungssteuerung 19 1.2.27. Mehrbenutzerfähigkeit 20 1.2.28. Testdokumentation 20 1.2.29. Service-Level-Agreements (SLA´s) 20 1.2.30. Anbindung an externe Systeme, Datenbanken, Tools 21 1.2.31. Änderungshistorie 21 1.2.32. Automatisches Schließen von Tickets 21 1.2.33. Optische Anpassung der Benutzeroberfläche (zentral) 22 1.3. Anforderungen aus dem Bereich Datenschutz und IT-Sicherheit sowie sonstige Anforderungen 22 1.3.1. Darstellung der Möglichkeit des Backup und Restore 22 1.3.2. Möglicher Ausschluss einer Möglichkeit zur Fernwartung 22 1.3.3. Bereitstellung von Softwareaktualisierungen 22 1.3.4. Unterstützungsleistungen 23 1.3.5. Produktschulung der künftigen Administratoren 23 1.3.6. Bereitstellung von Dokumentationen 23

[Seite 3]

INHALT

1.3.7. Möglichkeit der Langzeitspeicherung von Daten 23 1.3.8. Aufbewahrungsfristen 24 1.3.9. Protokollierung 24 1.3.10. Pseudonymisierung und De-Pseudonymisierung von Daten 24 1.3.11. Performance der Anwendung 25 1.3.12. Verschlüsselung 25 1.3.13. Protokollierung von Administratoraktionen auf Applikationsebene 25 1.3.14. Passwortrichtlinien 25 1.3.15. Systemservice 25 1.3.16. Bereitstellung einer deutschsprachigen Hotline 27 1.3.17. Zugriff / Benutzeroberfläche 27 1.3.18. Proxyfähigkeit der Webapplikationen 27 1.3.19. Self-Hosting 27 1.3.20. Leistungen bei Beendigung des Vertrags 28 1.4. Implementierung und Einführungsphase 29

[Seite 4]

1. Leistungsbeschreibung

1.1. Allgemeine Beschreibung der Anforderungen an das Ticketsystem

Zur Abbildung verschiedener Ticketprozesse benötigt das Landesamt für Finanzen (LfF) ein neues Ticketsystem, welches im landeseigenen Rechenzentrum des LDI betrieben werden muss (On Premise bzw. rlp-Cloud). Ziel der Beschaffung ist das Mieten eines Standardprodukts, welches vor der Verwendung an die individuellen Anforderungen des LfF anzupassen ist. So müssen insbesondere eine Integration in die hier betriebene SAP-Landschaft erfolgen (z.B. Anbindung an das SAP Change and Transport System (CTS)), die Abbildung verschiedener Auswertungen und Berichte, der Aufbau von Wissensdatenbanken und Migrationen aus verschiedenen Quellsystemen erfolgen. Die Anforderungen hieran ergeben sich insbesondere aus diesem Dokument.

Die in der Anlage 4 „Systemumgebung“ zum EVB-IT Systemvertrag beschriebenen Vorgaben bzgl. der beim Auftraggeber vorhandenen Systeme und Verfahren sind zwingend zu berücksichtigen.

Das Projekt beginnt mit der Vorlage des vorläufigen Projektplans eine Woche nach Zuschlag, vgl. Nr. 9 Terminplan EVB-IT Systemvertrag. Die vollständige Einführung des neuen Ticketsystems (einschließlich Abnahmeprüfung und Multiplikatorenschulung) muss bis zum 31.07.2027 erfolgt sein. Eine produktive Nutzung des neuen Ticketsystems muss für alle angebundenen Nutzer (auch Nutzer anderer Behörden im Land Rheinland-Pfalz) spätestens ab dem 01.08.2027 gegeben sein.

Die Nutzungsberechtigung des Ticketsystems verteilt sich auf LfF-interne Nutzer sowie Nutzer anderer Behörden des Landes Rheinland-Pfalz. Insgesamt sind ca. 1000 Nutzer an das System anzubinden. Die Zahl der Nutzer des Ticketsystems kann dabei variieren und zukünftig steigen. Ein flexibeles, skalierbares Lizenzmodell ist anzubieten.

Das neue Ticketsystem muss das bisher auf dem Solution Manager (SAP SOLUTION MANAGER 7.2 und mit dem SP Stack 20 -Stand 11/2025-) betriebene Ticketsystem ablösen. Dabei müssen gängige und bereits etablierte Prozesse abgebildet werden. Eine Integration des neuen Ticketsystems in das SAP-Transportwesen ist zwingend erforderlich.

1 (29)

[Seite 5]

Die Einführung des neuen Ticketsystems wird weiterhin dazu genutzt, das im LfF für die Belange der Haus-IT vorhandene Ticketsystem Zammad (Version 6.5.2) ebenfalls abzulösen und in das neue Ticketsystem zu integrieren, so dass im LfF zukünftig nur noch ein Ticketsystem betrieben wird.

Um eine entsprechende Tickethistorie zu erhalten ist es somit notwendig, dass aus beiden vorherigen Ticketsystemen (zzgl. aus dem Vorgängersystem SAP SOLUTION MANAGER 7.1) die Migration der dort vorhandenen Tickets stattfindet. Die Migration muss sich dabei sowohl auf abgeschlossene, als auch noch in Bearbeitung befindliche Tickets beziehen; es sind somit ca. 55.000 bis 60.000 Tickets zu migrieren. Die abgeschlossenen Tickets sind zwingend zukünftig nebst adäquater Recherchemöglichkeit (Volltextsuche) zur Verfügung zu stellen. Dabei muss mindestens die alte Ticket-ID, der Ticketstatus, der Tickettext (betrifft alle im Ticket enthaltenen Texte unterschiedlicher Erfassungsmasken) sowie enthaltene Anlagen vorhanden sein. Tickettexte müssen dabei mit Datum und mit Benutzernamen übernommen werden. Nähere Informationen zu der Art und Menge der Daten sowie Datenfeldern und Datenmodell entnehmen Sie der Anlage 4 EVB-IT Systemvertrag „Systemumgebung“.

Zudem soll dem Bereich Organisationsstelle erstmals ermöglicht werden, ihre Aufgaben über ein Ticketsystem zu organisieren.

Das Ticketsystem muss daher die Möglichkeit bieten, verschiedene Bereiche sowie Nutzerkreise voneinander getrennt abbilden und berechtigen zu können. Dies ist auch insbesondere dafür wichtig, da ein Teil der Tickets für alle IPEMA®- Anwendungsbetreuer im Land Rheinland-Pfalz sichtbar sein muss und der Teil der Tickets, der lediglich das LfF betrifft auch nur durch entsprechende User im LfF eingesehen werden können soll. Die Abbildung verschiedener Bereiche darf nicht dazu führen, dass unterschiedliche voneinander unabhängige Ticketsysteme (ggfs. auch nur auf unterschiedlichen System-Mandanten) entstehen.

Aufgrund der unterschiedlichen Ticketprozesse und Nutzerkreise muss das Ticketsystem daher entsprechende Funktionalitäten zur Verfügung stellen, die unterschiedlich ausgeprägt werden können. Dabei ist es wichtig, dass diese Ausprägungen/Konfigurationen durch den Auftraggeber (AG) selbst erfolgen können. Dies betrifft insbesondere die Prozesse, Statusverwaltung, Module und Kategorien je Vorgangsart sowie Inhalte/Listen/Feldwerte vorhandener Felder. Im Einführungsprojekt muss die Einrichtung des Ticketsystems jedoch durch den Auftragnehmer (AN)

2 (29)

[Seite 6]

erfolgen. Um die zukünftige eigenständige Betreuung gewährleisten zu können, muss daher durch den AN eine entsprechende Dokumentation erstellt sowie gemeinsam mit einer Produktschulung für die Administratoren an den AG für den Regelbetrieb übergeben werden.

Zu jedem Zeitpunkt muss ersichtlich sein, für welche/s Komponente/Modul welche Systemanpassungen geplant sind, wann diese umgesetzt und produktiv gesetzt werden sollen und wie der Status der einzelnen Tickets aussieht.

Die Tickets und deren Einträge müssen als Grundlage für eine interne Wissensdatenbank verwendbar sein. Es müssen jederzeit Auswertungen über den gesamten Ticketbestand möglich sein (einschließlich retrospektiv). Dabei bleiben abgeschlossene Tickets im System und werden als erledigte Tickets dauerhaft bzw. bis zum Erreichen einer vom AG vorgegebenen Löschfrist vorgehalten.

Als ergänzende Funktion muss ein Ticket-Dashboard vorhanden sein, das die relevanten Daten grafisch visualisiert.

Das Ticketsystem muss weiterhin vollständig allein durch den AG auf den Systemen des AG betrieben werden können. Für den Bedarfsfall muss jedoch eine Unterstützungsmöglichkeit angeboten werden, vgl. Option 5 (Nr. 1.1 EVB-IT Systemvertrag, Anlage 11 Sonstige Vereinbaurngen, Anlage 5 Preisblatt). Darüber hinaus sind u.a. Systemupgrades regelmäßig zur Verfügung zu stellen und Sicherheitslücken zeitnah zu schließen. Systemupgrades, die lediglich durch den AN vorgenommen werden können bzw. durch ihn zur Verfügung gestellt werden, sind zeitnah und in terminlicher Absprache mit dem AG vor Ort im LfF vorzunehmen bzw. zum Download zur Verfügung zu stellen. Der AG führt vor Produktivsetzung des Upgrades eine entsprechend umfängliche Abnahmeprüfung durch. Diese muss auf einem beim AG geführten Entwicklungssystem erfolgen. Das Ticketsystem muss somit beim AG als Zwei-System-Landschaft betrieben werden können. Der Bieter hat ein entsprechendes Konzept (Konzept ➔ max. 3 Seiten, Arial 11) vorzulegen.

1.2. Detailbeschreibung der Anforderungen an das Ticketsystem

Folgende Funktionen muss das Ticketsystem gewährleisten:

3 (29)

[Seite 7]

1.2.1. Filtern, klassifizieren und priorisieren eingehender Tickets in Echtzeit Das angebotene System muss in der Lage sein, die eingehenden Tickets in Echtzeit (d. h. in der Geschwindigkeit, in der die Tickets am System eintreffen) entsprechend der erfolgten Konfiguration zu filtern, zu klassifizieren und zu priorisieren. Das System muss frei konfigurierbare Klassifikationen und Prioritäten unterstützen. Die Filter müssen mit regulären Ausdrücken oder einem vergleichbaren Mechanismus konfigurierbar sein. Der angebotene Mechanismus ist entsprechend vom Bieter darzustellen (➔ zwingende Darstellung hierzu erforderlich).

1.2.2. Abbildung verschiedener Vorgangsarten (Ticketart, bereichsbezogen) Es muss möglich sein, verschiedene Vorgangsarten (je Bereich) abbilden zu können. Bei Bedarf müssen die Vorgangsarten unterschiedlich ausgeprägt werden können; dies betrifft Felder, Status sowie Prozesse.

1.2.3. Abbildung von Kategorien und Modulen Innerhalb eines Tickets muss es möglich sein, das Anliegen nach Modulen und Kategorien zu verfeinern. Module, Kategorien und ggfs. Unterkategorien müssen dabei je Vorgangsart individuell eingerichtet werden können.

Diese Abbildung soll im weiteren Ticketverlauf auch zur Differenzierung des Aufgabenempfängers dienen.

1.2.4. Abbildung verschiedener Ticketarten (sachverhaltsbezogen) Zur weiteren Differenzierung der Anliegen und Arbeitsplanung ist es neben der Vorgangsart erforderlich, einzelne Ticketarten wie z.B. Anforderung, Fehler, Sonstiges, etc. im Ticketsystem hinterlegen zu können.

Die Strukturierung aller Tickets muss daher wie folgt abgebildet werden können (spezifische Erweiterungen sind möglich):

4 (29)

[Seite 8]

Vorgangsart

Modul/Kategorie

Ticketart (Fehler, Anforderung)

1.2.5. Ticketaufgabe (Aufgabe einer Vorgangsart) Die Ticketaufgabe erfolgt grundsätzlich manuell durch den Meldenden. Zusätzlich sollte die Ticketaufgabe durch eine Eingangsmail in einem bestimmten Postfach bzw. eine E- Mail direkt an das Ticketsystem ausgelöst werden können. Sofern das Ticketsystem zusätzlich eine Ticketerstellung aus einer Eingangsmail auslösen kann, ist diese Funktion entsprechend vom Bieter darzustellen (Konzept ➔ max. 3 Seiten, Arial 11).

Die Ticketanlage muss geführt bzw. gemäß Option 6.1 assistent- oder dialogbasiert (mittels Einbindung eines KI-Assistenten oder Chat-Dialog) erfolgen können, wenn der Auftraggeber die Option ausübt, vgl. Nr.1.1 EVB-IT Systemvertrag, Anlage 11, Anlage 5. Eine KI darf dabei nur angeboten werden ,wenn diese im Landesnetz ohne Verbindung nach außen betrieben werden kann, und zudem muss diese Funktion deaktivierbar sein (Konzept ➔ max. 15 Seiten, Arial 11).

Das Konzept zur KI-Option 6.1 muss folgende Inhalte umfassen:

Das vom Auftragnehmer vorzulegende Konzept zur Nutzung der KI-gestützten Softwarefunktionen sowie zu deren Systemservice hat insbesondere folgende Inhalte nachvollziehbar darzustellen:

Der Auftragnehmer hat zunächst die angebotenen KI-gestützten Softwarefunktionen im Einzelnen zu beschreiben, einschließlich der Art und Weise,

5 (29)

[Seite 9]

wie die Anforderungen des Auftraggebers aus den Anlagen B9.1 und B9.2 (Unteranlagen zu Anlage 3 Leistungsbeschreibung) in der Lösung umgesetzt werden (Hinweis: Teile der Fragen der Anlage B9. 2 beziehen sich auf den Betrieb der KI beim Auftraggeber. Der AN hat hierzu darzustellen, in wie weit das angebotene Produkt den AG bei der Einhaltung der Anforderungen unterstützt bzw. diesen hierzu ertüchtigt). Ferner hat der Auftragnehmer die eingesetzten KI- Modelle zu benennen, einschließlich der jeweiligen Modellbezeichnungen und Versionen, sowie die Herkunft der genutzten bzw. angebotenen KI offenzulegen (Hersteller, Sitzstaat, Rolle des Auftragnehmers im Wertschöpfungsmodell nach dem EU AI Act, etwa als Provider, Importeur oder Händler). Im Konzept ist zudem die Trainingshistorie der eingesetzten Modelle zu beschreiben.

Weiter hat der Auftragnehmer die technischen Schnittstellen der Lösung zu erläutern sowie die im Rahmen der Implementierung erforderlichen Trainingsmaßnahmen zu beschreiben, einschließlich des voraussichtlichen Aufwands, der praktischen Durchführung und der hierfür vorgesehenen Datenbasis. Der Auftragnehmer hat darzulegen, welche Datenarten im Netz des Auftraggebers genutzt werden (insbesondere Trainings-, Validierungs-, Test- und Inputdaten) und wie die Datenqualität, Repräsentativität, Fehlerfreiheit und Vollständigkeit gewährleistet werden. Hierbei ist auch zu beschreiben, wie Verfahren zur Erkennung und Minderung von Bias ausgestaltet sind.

Darüber hinaus sind die Prozesse für Ersttraining, Retraining und Fine-Tuning darzustellen, einschließlich der Auslösekriterien, zeitlichen Zyklen, internen und externen Freigabeprozesse sowie der technischen Grenzen (insbesondere der Ausschluss jeglicher Nutzung von Daten außerhalb des Netzes des Auftraggebers). Der Auftragnehmer hat zu erläutern, wie das Training protokolliert wird und welche Validierungsschritte vor Inbetriebnahme vorgesehen sind. Dabei ist klarzustellen, dass sämtliches Training und Retraining, soweit es auf Daten des Auftraggebers beruht, ausschließlich im Netz des Auftraggebers und unter Beachtung der Anlagen B9.1 und B9.2 (Unteranlagen zu Anlage 3 Leistungsbeschreibung) erfolgt.

Das Konzept hat außerdem den Umgang mit Fehlern, Störungen und Korrekturmaßnahmen zu beschreiben. Insbesondere ist darzustellen, wie die Performance, Genauigkeit, Robustheit und Cybersecurity der KI-Funktionen überwacht werden, welche Ereignisse geloggt werden und wie die Ergebnisse aus Monitoring und Störungsmanagement datenschutzkonform genutzt werden.

6 (29)

[Seite 10]

Ferner hat der Auftragnehmer die im Rahmen des Systemservices vorgesehenen Maßnahmen zu Retraining, Modellwechseln und sonstigen Anpassungen darzulegen und zu erläutern, wie die Softwarepflege (einschließlich Patches und Versionswechseln) sowie etwaige Modellsubstitutionen durchgeführt werden. Hierbei sind das Test- und Freigabekonzept sowie die Auswirkungen auf die Datenhaltung des Auftraggebers zu beschreiben.

Schließlich hat der Auftragnehmer darzulegen, wie sichergestellt wird, dass alle Komponenten der KI-gestützten Softwarefunktionen ausschließlich in der Infrastruktur des Auftraggebers betrieben werden. Insbesondere sind die technischen und organisatorischen Maßnahmen zu beschreiben, mit denen Datenabflüsse in externe Netze oder Cloud-Infrastrukturen ausgeschlossen werden, sowie die Protokollierungs- und Kontrollmechanismen, die dem Auftraggeber zur Verfügung gestellt werden, um die Einhaltung dieser Vorgaben eigenständig überprüfen zu können.

Die in den Anlagen B9.1 und B9.2 befindlichen Fragestellungen zum Thema Informationssicherheit/Datenschutz für den Einsatz von KI sind zu beantworten (für den Fall, dass KI enthalten ist). Soweit die in den Anlagen B9.1 und B9.2 geforderten Kriterien nicht erfüllt werden, wird das Angebot ausgeschlossen. Der Auftraggeber behält sich unabhängig davon vor, von der Ausübung der Optionen abzusehen bzw. den Einsatz von KI aus anderen Gründen abzulehnen.

Eine Vorgangsart-übergreifende Ticketaufgabe soll nicht möglich sein.

1.2.6. Meldungsvorlagen und Massenanlage von Tickets Insbesondere im IT-Bereich gibt es regelmäßig wiederkehrende Aufgaben, die es jedes Jahr zu planen gilt. Für die Forecastplanung der Folgejahre ist es daher erforderlich, dass das Ticketsystem die Möglichkeit bietet, Vorlagen zu Tickets/Aufgaben anzulegen, aus denen heraus aktuelle Tickets geöffnet und geplant werden können.

Abhängig vom Turnus der Aufgabe, müssen somit ggfs. mehrere Tickets pro Jahr für sie geöffnet werden. Man sollte daher aus der Meldungsvorlage nicht nur ein Ticket, sondern direkt mehrere Tickets (z.B. zwölf Stück bei einer monatlich wiederkehrenden Tätigkeit) öffnen können.

7 (29)

[Seite 11]

Es sollte die Möglichkeit bestehen, bereits bestehende Meldungsvorlagen aus den Altsystemen in das neue Ticketsystem migrieren zu können (➔ zwingende Darstellung hierzu erforderlich).

1.2.7. Abbildung von Ticketbearbeitern Für die Planung von Aufgaben muss das Ticketsystem die Möglichkeit bieten, verschiedene Bearbeiter an einem Ticket zu hinterlegen [z.B. Meldender, zuständiger Ticketbearbeiter, aktueller Ticketbearbeiter, Anwendungsbetreuer, weitere Bearbeiter (z.B. Mehfachbelegung der zuvor genannten oder Dienststelle, Service Team und IPEMA-Autor)]. Dabei kann es erforderlich sein, einzelne Kategorien von Ticketbearbeitern mehrfach am Ticket zu hinterlegen. Es muss daher die Möglichkeit der Festlegung des Hauptverantwortlichen je Kategorie der Ticketbearbeiter geben. Zu jeder Zeit muss erkennbar sein, wer aktuell mit der Aufgabenerledigung beschäftigt ist.

Die Ticketbearbeiter müssen je Vorgangsart konfigurierbar sein. Ebenfalls muss eine automatische Zuordnung von Bearbeitern anhand von weiteren Ticketdaten möglich und je Vorgangsart konfigurierbar sein.

1.2.8. Priorität Tickets muss eine Priorität zugeordnet werden können. Diese müssen frei konfigurierbar sein. Die Priorität soll bei der Ticketanlage automatisiert vorbelegt werden, muss aber im weiteren Verlauf manuell änderbar sein.

1.2.9. Betreff Zur Übersicht und Orientierungshilfe muss es möglich sein, jedem Ticket einen Betreff zuweisen zu können, der kurz und prägnant den Inhalt des Tickets beschreibt. Der Betreff sollte bei Bedarf auch automatisiert generiert werden können (z.B. bei Anlage eines Tickets durch eine E-Mail). Der Betreff sollte zu jeder Zeit änderbar sein.

8 (29)

[Seite 12]

1.2.10. Ticketbeschreibung / Kommunikation Neben der kurzen Inhaltsdarstellung über den Betreff muss das Ticketsystem die Möglichkeit bieten, Anliegen detailliert zu beschreiben und die Kommunikation im Verlauf der Bearbeitung des Tickets über das Ticketsystem zu führen und zu dokumentieren. Dabei ist es erforderlich, dass erkennbar ist, von wem und wann ein Ticketeintrag vorgenommen wurde. Zusätzlich sollte die Kommunikation nach Ticketaufgabe/Beschreibung des Anliegens und Kommunikation während der Ticketbearbeitung getrennt werden können. Je nach Ausgestaltung sollte es weiterhin möglich sein, die Einträge/Dokumentationen bzgl. technischer Systemanpassungen von der allgemeinen Kommunikation während der Ticketbearbeitung trennen zu können. Zudem wäre eine Separierung der Testdokumentation von der restlichen Kommunikation optional anzubieten. Sofern das Ticketsystem zusätzlich die Möglichkeit der getrennten Kommunikationsabbildung anbietet, ist diese Funktion entsprechend vom Bieter darzustellen (Konzept ➔ max. 5 Seiten, Arial 11).

Auch eine manuelle inhaltliche Fixierung und damit Unveränderlichkeit der initialen Ticketaufgabe/Beschreibung des Anliegens kann mit angeboten werden. Diese inhaltliche Fixierung der initialen Ticketaufgabe/Beschreibung sowie eine folgende inhaltliche Freigabe und damit wieder eintretende Veränderlichkeit der Beschreibung darf dabei nur durch entsprechend berechtigte Personen (z.B. das Anforderungsmanagement) vorgenommen werden können. Sofern das Ticketsystem diese Funktion anbietet, ist diese entsprechend vom Bieter darzustellen (Konzept ➔ max. 5 Seiten, Arial 11).

1.2.11. Anlagen Für umfangreiche Anforderungs-/Fehlerbeschreibungen, die ggfs. auch Bildschirmabgriffe enthalten, oder außerhalb des Ticketsystems geführter Kommunikation, muss es zudem möglich sein, entsprechende Dokumente (Protokolle, Listen, Beschreibungen, Mails, etc. jeden Dateiformates) und URLs als Anlage im Ticket beizufügen. Diese Möglichkeit muss direkt bei der initialen Ticketaufgabe sowie im Rahmen der späteren Bearbeitung des Tickets gegeben sein. Die Möglichkeit der Kennzeichnung von Dateien, die personenbezogene Daten enthalten, muss gegeben sein, um diese bei Bedarf filtern und löschen zu können. Die Möglichkeit der Strukturierung der Anlagen in Ordnern kann angeboten werden (➔ zwingende Darstellung hierzu erforderlich).

9 (29)

[Seite 13]

1.2.12. Verknüpfbarkeit von Tickets / Referenztickets Inhaltlich identische bzw. aufeinander aufbauende Tickets müssen über die Angabe eines (bzw. mehrerer) Referenztickets miteinander verknüpft werden können. Die Verknüpfung muss dabei auch Vorgangsart-übergreifend erfolgen können.

Eine Vorgangsart-übergreifende Verknüpfung von Tickets soll zusätzlich dazu führen, dass die jeweiligen Ticketbearbeiter jeweils gegenseitig informatorischen (also lesenden) Zugriff auf das Ticket erlangen. Wenn eine Vorgangsart-übergreifende Verknüpfung von Tickets angeboten wird, ist diese Funktion entsprechend vom Bieter darzustellen (Konzept ➔ max. 3 Seiten, Arial 11).

Durch die Auswahl (z.B. Doppelklick oder Link) eines angegebenen Referenztickets soll ein Absprung in dieses Ticket erfolgen. Das Ticket öffnet sich somit zur Bearbeitung bzw. im lesenden Zugriff (abhängig von der Berechtigung des Ticketbearbeiters).

1.2.13. externe Referenztickets Teilweise sind an technischen Realisierungen auch Dritte, wie z.B. Softwarehersteller beteiligt, die eigene Ticketsysteme verwenden. Es kommt daher vor, dass zu bestimmten Sachverhalten ein Ticket im Ticketsystem des AG sowie ein Ticket in einem weiteren Ticketsystem besteht. Für eine schnellere Zuordnung und effiziente Kommunikation mit Dritten, muss es daher möglich sein, in einem Feld eine oder mehrere Ticketnummern aus anderen Ticketsystemen hinterlegen zu können. Das Feld kann dabei ein auswertbares Freitextfeld sein, über das externe Ticketnummern bzw. Vorgangs-ID´s erfasst und abgefragt werden können. Zusätzlich sollte das Feld jedoch die Möglichkeit der Hinterlegung von ausführbaren Links/URL´s bieten.

1.2.14. Wartungsrelease Das Ticketsystem muss die Möglichkeit bieten, Arbeitspakete und Systemänderungen zu einem Wartungsrelease (bzw.einer vDisk-Version/Patchversion) zusammenfassen und darüber die Arbeitsplanung vornehmen zu können. Die Wartungsrelease müssen dabei je nach Vorgangsart planbar und vom AG frei konfigurierbar sein.

10 (29)

[Seite 14]

1.2.15. Status Zu jeder Zeit muss erkennbar sein, in welchem Status der Bearbeitung sich ein Ticket befindet. Das Ticketsystem muss daher die Möglichkeit bieten, verschiedene Status an einem Ticket abbilden zu können. Auch die Implementierung von Reihenfolgen der Status bzw. Statuswege muss ermöglicht werden. Darüber hinaus muss erkennbar sein, wann welcher Status durch wen gesetzt wurde.

Die Status und Statuswege können dabei je Vorgangsart unterschiedlich sein und müssen entsprechend konfigurierbar sein.

1.2.16. Prozessabbildung und Prozessnachvollziehbarkeit Es muss die Möglichkeit bestehen (je Vorgangsart/Ticketart), Prozesse und Prozessketten definieren, erstellen und anpassen zu können. Dabei sollen im Prozess notwendigerweise zu beteiligende Personen kontextbezogen automatisch angetriggert und dem Ticket hinzugefügt werden können. Es muss weiterhin zu jeder Zeit ersichtlich sein, wann das Ticket in welchem Prozessschritt war.

Einmal am Prozess beteiligte Personen sollen dauerhaft Zugriff auf entsprechende Tickets haben, damit eine Prozessnachvollziehbarkeit gewährleistet ist. Der Zugriff auf das entsprechende Ticket und den Status muss dabei basierend auf konfigurierebaren Zugriffsrechten und Rollen der gesamten Einheit der beteiligten Person gewährt werden können. Ausnahmen von dieser Regelung müssen je Vorgangsart ebenfalls getroffen werden können, d.h. es muss möglich sein, den Zugriff auf bestimmte Vorgangsarten ausschließlich auf bestimmte Personen (ohne dass deren gesamte Einheit Zugriff erlangt) beschränken zu können.

1.2.17. Genehmigungsfunktion Bestimmte Vorgänge / Prozesse können die Genehmigung durch Vorgesetzte oder weitere Funktionsträger (z.B. Kopfstellen, IT-Sicherheit) bedürfen. Hierfür muss das Ticketsystem entsprechende Funktionen zur Verfügung stellen.

11 (29)

[Seite 15]

1.2.18. Setzen von Tags Es muss die Möglichkeit gegeben sein, im Ticket Tags zu bestimmten Schlagworten (z.B. „Briefschreibung“ + „HowTo“) zu hinterlegen.

1.2.19. Suchfunktionen / Ticketsuche / Wissensdatenbank Die im Ticketsystem vorhandenen Tickets dienen als Wissensdatenbank, um insbesondere bei gleichgelagerten Fällen schneller zu einer Lösung der Problematik zu kommen oder aber wiederkehrende Fehler identifizieren zu können. Aus diesem und weiteren Gründen muss das Ticketsystem eine Suchfunktion anbieten. Es muss möglich sein, per Freitext und anderer beliebiger Suchkritierien mittels verschiedener Operatoren sowie der Suche nach gesetzten Tags die im eigenen Zugriff befindlichen Tickets durchsuchen zu können. Die Suche per Freitext muss dabei in Form einer Volltextsuche realisiert sein, die sich über den gesamten Ticketinhalt, also die Kommunikation sowie die Anlagen, ersteckt. Dabei dürfen bei der Suche nur die Tickets im Ergebnis ausgegeben werden, auf deren Vorgangsart/Ticketart der Suchende zugriffsberechtigt ist. Das Ergebnis der Suche wird zeitnah (innerhalb weniger Sekunden) vom System zurückgeliefert. Unabhängig von der Datenmenge die durchsucht werden muss sollte die Ausgabe des Ergebnisses nicht länger als eine Minute benötigen.

Option 6.2:

Zur effizienten Nutzung der Wissensdatenbank muss der Auftragnehmer im Falle der Ausübung der Option eine KI-Anbindung für die Beantwortung von Fragen unter Berücksichtigung gelöster Tickets integrieren. Diese KI-Anbindung muss dabei nach Ermessen des Auftraggebers aktiviert und deaktiviert werden können (Konzept ➔ max. 15 Seiten, Arial 11).

Das Konzept zur KI-Option 6.2 muss folgende Inhalte umfassen:

Das vom Auftragnehmer vorzulegende Konzept zur Nutzung der KI-gestützten Softwarefunktionen sowie zu deren Systemservice hat insbesondere folgende Inhalte nachvollziehbar darzustellen:

Der Auftragnehmer hat zunächst die angebotenen KI-gestützten Softwarefunktionen im Einzelnen zu beschreiben, einschließlich der Art und Weise, wie die Anforderungen des Auftraggebers aus den Anlagen B9.1 und B9.2

12 (29)

[Seite 16]

(Unteranlagen zu Anlage 3 Leistungsbeschreibung) in der Lösung umgesetzt werden. Ferner hat der Auftragnehmer die eingesetzten KI-Modelle zu benennen, einschließlich der jeweiligen Modellbezeichnungen und Versionen, sowie die Herkunft der genutzten bzw. angebotenen KI offenzulegen (Hersteller, Sitzstaat, Rolle des Auftragnehmers im Wertschöpfungsmodell nach dem EU AI Act, etwa als Provider, Importeur oder Händler). Im Konzept ist zudem die Trainingshistorie der eingesetzten Modelle zu beschreiben (Hinweis: Teile der Fragen der Anlage B9. 2 beziehen sich auf den Betrieb der KI beim Auftraggeber. Der AN hat hierzu darzustellen, in wie weit das angebotene Produkt den AG bei der Einhaltung der Anforderungen unterstützt bzw. diesen hierzu ertüchtigt)

Weiter hat der Auftragnehmer die technischen Schnittstellen der Lösung zu erläutern sowie die im Rahmen der Implementierung erforderlichen Trainingsmaßnahmen zu beschreiben, einschließlich des voraussichtlichen Aufwands, der praktischen Durchführung und der hierfür vorgesehenen Datenbasis. Der Auftragnehmer hat darzulegen, welche Datenarten im Netz des Auftraggebers genutzt werden (insbesondere Trainings-, Validierungs-, Test- und Inputdaten) und wie die Datenqualität, Repräsentativität, Fehlerfreiheit und Vollständigkeit gewährleistet werden. Hierbei ist auch zu beschreiben, wie Verfahren zur Erkennung und Minderung von Bias ausgestaltet sind.

Darüber hinaus sind die Prozesse für Ersttraining, Retraining und Fine-Tuning darzustellen, einschließlich der Auslösekriterien, zeitlichen Zyklen, internen und externen Freigabeprozesse sowie der technischen Grenzen (insbesondere der Ausschluss jeglicher Nutzung von Daten außerhalb des Netzes des Auftraggebers). Der Auftragnehmer hat zu erläutern, wie das Training protokolliert wird und welche Validierungsschritte vor Inbetriebnahme vorgesehen sind. Dabei ist klarzustellen, dass sämtliches Training und Retraining, soweit es auf Daten des Auftraggebers beruht, ausschließlich im Netz des Auftraggebers und unter Beachtung der Anlagen B9.1 und B9.2 (Unteranlagen zu Anlage 3 Leistungsbeschreibung) erfolgt.

Das Konzept hat außerdem den Umgang mit Fehlern, Störungen und Korrekturmaßnahmen zu beschreiben. Insbesondere ist darzustellen, wie die Performance, Genauigkeit, Robustheit und Cybersecurity der KI-Funktionen überwacht werden, welche Ereignisse geloggt werden und wie die Ergebnisse aus Monitoring und Störungsmanagement datenschutzkonform genutzt werden. Ferner hat der Auftragnehmer die im Rahmen des Systemservices vorgesehenen

13 (29)

[Seite 17]

Maßnahmen zu Retraining, Modellwechseln und sonstigen Anpassungen darzulegen und zu erläutern, wie die Softwarepflege (einschließlich Patches und Versionswechseln) sowie etwaige Modellsubstitutionen durchgeführt werden. Hierbei sind das Test- und Freigabekonzept sowie die Auswirkungen auf die Datenhaltung des Auftraggebers zu beschreiben.

Schließlich hat der Auftragnehmer darzulegen, wie sichergestellt wird, dass alle Komponenten der KI-gestützten Softwarefunktionen ausschließlich in der Infrastruktur des Auftraggebers betrieben werden. Insbesondere sind die technischen und organisatorischen Maßnahmen zu beschreiben, mit denen Datenabflüsse in externe Netze oder Cloud-Infrastrukturen ausgeschlossen werden, sowie die Protokollierungs- und Kontrollmechanismen, die dem Auftraggeber zur Verfügung gestellt werden, um die Einhaltung dieser Vorgaben eigenständig überprüfen zu können.

Die in der Anlagen B9.1 und B9.2 befindlichen Fragestellungen zum Thema Informationssicherheit/Datenschutz für den Einsatz von KI sind zu beantworten. Soweit die in den Anlagen B9.1 und B9.2 geforderten Kriterien nicht erfüllt werden, wird das Angebot ausgeschlossen. Der Auftraggeber behält sich unabhängig davon vor, von der Ausübung der Optionen abzusehen bzw. den Einsatz von KI aus anderen Gründen abzulehnen.

Migration: Zur Vervollständigung der Wissensdatenbank, muss eine Migration der Tickets aus den Altsystemen erfolgen. Über die beiden bereits genannten Altsysteme hinaus, sind auch Tickets aus dem vorherigen SAP SOLUTION MANAGER 7.1 zu migrieren. Insgesamt ist ein Migrationsvolumen von 55.000 bis 60.000 Tickets anzunehmen. Der Migrationsprozess ist entsprechend in einem Konzept darzustellen (Konzept ➔ max. 5 Seiten Arial 11).

1.2.20. Integration Handbuch/FAQ´s/externe Wissensdatenbank Neben dem Aufbau einer Wissensdatenbank über die Tickethistorie, soll das Ticketsystem auch eine Möglichkeit bieten, Handbücher und FAQ´s zu integrieren und ggfs. aktuell bekannte Probleme zu hinterlegen.

14 (29)

[Seite 18]

Der Ticktersteller sollte beim Eröffnen eines Tickets bzw. der Kategorieauswahl bereits auf passende FAQ´s, Anleitungen oder bekannte Probleme hingewiesen werden. Diese Funktion ist entsprechend vom Bieter darzustellen (Konzept ➔ max. 3 Seiten, Arial 11).

Option 6.3:

Zur effizienten Nutzung der Wissensdatenbank muss der Auftragnehmer im Falle der Ausübung der Option eine KI-Anbindung für die Beantwortung von Fragen unter Berücksichtigung hinterlegter Dokumente (Handbücher, FAQ´s) umsetzen. Diese KI- Anbindung muss dabei im Ermessen des Auftraggebers aktiviert und deaktiviert werden können (Konzept ➔ max. 15 Seiten, Arial 11).

Das Konzept zur Option 6.3 muss folgende Inhalte umfassen:

Das vom Auftragnehmer vorzulegende Konzept zur Nutzung der KI-gestützten Softwarefunktionen sowie zu deren Systemservice hat insbesondere folgende Inhalte nachvollziehbar darzustellen:

Der Auftragnehmer hat zunächst die angebotenen KI-gestützten Softwarefunktionen im Einzelnen zu beschreiben, einschließlich der Art und Weise, wie die Anforderungen des Auftraggebers aus den Anlagen B9.1 und B9.2 (Unteranlagen zu Anlage 3 Leistungsbeschreibung) in der Lösung umgesetzt werden. Ferner hat der Auftragnehmer die eingesetzten KI-Modelle zu benennen, einschließlich der jeweiligen Modellbezeichnungen und Versionen, sowie die Herkunft der genutzten bzw. angebotenen KI offenzulegen (Hersteller, Sitzstaat, Rolle des Auftragnehmers im Wertschöpfungsmodell nach dem EU AI Act, etwa als Provider, Importeur oder Händler). Im Konzept ist zudem die Trainingshistorie der eingesetzten Modelle zu beschreiben.

Weiter hat der Auftragnehmer die technischen Schnittstellen der Lösung zu erläutern sowie die im Rahmen der Implementierung erforderlichen Trainingsmaßnahmen zu beschreiben, einschließlich des voraussichtlichen Aufwands, der praktischen Durchführung und der hierfür vorgesehenen Datenbasis. Der Auftragnehmer hat darzulegen, welche Datenarten im Netz des Auftraggebers genutzt werden (insbesondere Trainings-, Validierungs-, Test- und Inputdaten) und wie die Datenqualität, Repräsentativität, Fehlerfreiheit und Vollständigkeit gewährleistet werden. Hierbei ist auch zu beschreiben, wie Verfahren zur Erkennung und Minderung von Bias ausgestaltet sind.

15 (29)

[Seite 19]

Darüber hinaus sind die Prozesse für Ersttraining, Retraining und Fine-Tuning darzustellen, einschließlich der Auslösekriterien, zeitlichen Zyklen, internen und externen Freigabeprozesse sowie der technischen Grenzen (insbesondere der Ausschluss jeglicher Nutzung von Daten außerhalb des Netzes des Auftraggebers). Der Auftragnehmer hat zu erläutern, wie das Training protokolliert wird und welche Validierungsschritte vor Inbetriebnahme vorgesehen sind. Dabei ist klarzustellen, dass sämtliches Training und Retraining, soweit es auf Daten des Auftraggebers beruht, ausschließlich im Netz des Auftraggebers und unter Beachtung der Anlagen B9.1 und B9.2 (Unteranlagen zu Anlage 3 Leistungsbeschreibung) erfolgt (Hinweis: Teile der Fragen der Anlage B9. 2 beziehen sich auf den Betrieb der KI beim Auftraggeber. Der AN hat hierzu darzustellen, in wie weit das angebotene Produkt den AG bei der Einhaltung der Anforderungen unterstützt bzw. diesen hierzu ertüchtigt).

Das Konzept hat außerdem den Umgang mit Fehlern, Störungen und Korrekturmaßnahmen zu beschreiben. Insbesondere ist darzustellen, wie die Performance, Genauigkeit, Robustheit und Cybersecurity der KI-Funktionen überwacht werden, welche Ereignisse geloggt werden und wie die Ergebnisse aus Monitoring und Störungsmanagement datenschutzkonform genutzt werden. Ferner hat der Auftragnehmer die im Rahmen des Systemservices vorgesehenen Maßnahmen zu Retraining, Modellwechseln und sonstigen Anpassungen darzulegen und zu erläutern, wie die Softwarepflege (einschließlich Patches und Versionswechseln) sowie etwaige Modellsubstitutionen durchgeführt werden. Hierbei sind das Test- und Freigabekonzept sowie die Auswirkungen auf die Datenhaltung des Auftraggebers zu beschreiben.

Schließlich hat der Auftragnehmer darzulegen, wie sichergestellt wird, dass alle Komponenten der KI-gestützten Softwarefunktionen ausschließlich in der Infrastruktur des Auftraggebers betrieben werden. Insbesondere sind die technischen und organisatorischen Maßnahmen zu beschreiben, mit denen Datenabflüsse in externe Netze oder Cloud-Infrastrukturen ausgeschlossen werden, sowie die Protokollierungs- und Kontrollmechanismen, die dem Auftraggeber zur Verfügung gestellt werden, um die Einhaltung dieser Vorgaben eigenständig überprüfen zu können.

Die in der Anlagen B9.1 und B9.2 befindlichen Fragestellungen zum Thema Informationssicherheit/Datenschutz für den Einsatz von KI sind zu beantworten (für den Fall, dass KI enthalten ist). Soweit die in den Anlagen B9.1 und B9.2 geforderten

16 (29)

[Seite 20]

Kriterien nicht erfüllt werden, wird das Angebot ausgeschlossen. Der Auftraggeber behält sich unabhängig davon vor, von der Ausübung der Optionen abzusehen bzw. den Einsatz von KI aus anderen Gründen abzulehnen.

1.2.21. E-Mail-Funktion / Rückfragefunktionalität Für manche Bereiche (insb. IT) stellt das Ticketsystem nahezu den einzigen Arbeitsvorrat dar. Ticketmeldende nutzen das Ticketsystem jedoch nur beim konkreten Anliegen. Das Ticketsystem muss daher eine E-Mail-Funktion enthalten. Der E-Mail- Versand muss dabei anhand von Ticketdaten konfigurierbar sein und automatisiert ausgelöst werden.

o Es muss z.B. möglich sein, abhängig von bestimmten Feldern bzw. vom Erreichen eines bestimmten Status im Ticket eine E-Mail zu versenden.

o Der E-Mail-Empfänger muss aus den verschiedenen Ticketbeteiligten automatisch ermittelt werden können. Hierfür müssen eine Anbindung an das Active Directory (AD) des Landes sowie manuelle Erweiterungen ermöglicht werden.

o Zur Vervollständigung einer Anforderung bzw. zur Klärung von Fragestellungen im Rahmen der Ticketbearbeitung, muss eine Rückfragefunktionalität gegeben sein. Der Meldende muss im Falle einer Rückfrage zudem per E-Mail informiert werden.

Sofern das Ticketsystem auch Feld- und Status-unabhängige E-Mail-Funktionen anbietet, muss es möglich sein, den Empfang dieser zu personalisieren.

1.2.22. Ticket Dashboard / Auswertemöglichkeiten Neben der bereits beschriebenen Suchfunktion, soll das Ticketsystem auch geeignete Auswertemöglichkeiten bzw. ein Ticket Dashboard anbieten. Hierbei sollen anhand von festgelegten Kriterien (und KPI´s) wiederkehrende Reports mit grafischer Darstellung der Ergebnisse entsprechend berechtigten Personenkreisen (mittels eigener Ausführung) zur Verfügung gestellt werden.

mindestens folgende KPI´s:

17 (29)

[Seite 21]

o Anzahl der eingegangen Ticktes in konfigurierbaren Zeitraum, aufgeschlüsselt nach Vorgangsarten, Kategorien, Ticketarten und Ticketerstellern

o Anzahl der erledigten Ticktes in kofigurierbaren Zeitraum, aufgeschlüsselt nach Vorgangsarten, Kategorien, Ticketarten und Ticketerstellern

o Laufzeiten der Tickets aufgeschlüsselt nach Vorgangsarten, Kategorien, Ticketarten und Ticketerstellern

1.2.23. Automatisierte Ticketverteilung Neben einer manuellen Ticketverteilung/-planung muss auch die Möglichkeit gegeben sein, anhand von fest vordefinierten Parametern eine automatische Ticketverteilung und Zuordnung zu Personen vornehmen zu können.

1.2.24. Anbindung an das SAP-Transportwesen / Transportsteuerung Die Anbindung des Ticketsystems an das SAP Change and Transport System (CTS) ist durch den Auftragnehmer zwingend erforderlich. Die Anbindung an SAP muss je nach Vorgangsart steuerbar sein. Es muss die Möglichkeit geben, verschiedene Änderungszyklen mit Aufgabenplänen für die in SAP definierten Transportwege anzulegen. Transportaufträge sollen nur über ein Ticket angelegt werden können. Eine automatische Transportsteuerung bei Wechsel des Ticketstatus muss konfigurierbar sein (hier muss auch ein Transport von Kopien möglich sein). Der Import der Transportaufträge in die verschiedenen SAP-Systeme muss im Fall der Anbindung an das CTS direkt über das Ticketsystem eingeplant werden können (regelmäßige Jobs). Ein manueller Import eines Tickets in bestimmte SAP Systeme sollte direkt aus dem Ticket möglich sein. Es muss jederzeit im Ticket ersichtlich sein, in welche Systeme ein Import bereits erfolgt ist bzw. wo ein Import ansteht. Ein Import aller oder einer Teilmenge der Transporte eines Änderungszyklus sollte direkt aus dem Ticketsystem möglich sein. Cross System Object Lock (CSOL) und Downgrade-Schutz muss konfigurierbar sein und bei Fehlern eine Prüfung der Transporte vor Import ermöglichen. Die Anbindung zum SAP CTS ist ausführlich darzustellen (Konzept ➔ max. 5 Seiten, Arial 11).

18 (29)

[Seite 22]

Alternativ zur direkten Anbindung des SAP Change and Transport System kann die Anbindung auch über SAP Cloud ALM (Feature) erfolgen. Das Anlegen und die Freigabe der Transporte sollte vollständig über das Ticketsystem möglich sein. Es ist zusätzlich zu berücksichtigen, dass auftraggeberseitig ein zusätzlicher Tenant für SAP Cloud ALM gekauft werden und der Speicher des kostenfreien Tenants voraussichtlich erweitert werden muss. Sofern eine Anbindung über SAP Cloud ALM angeboten wird, ist die Funktion und der evtl. zusätzliche Speicherbedarf in einem Konzept darzustellen (Konzept ➔ max. 5 Seiten, Arial 11).

1.2.25. Aufwandsbewertung und Aufwandsplanung Das Ticketsystem muss eine Aufwandsbewertung (Anforderungsbeurteilung, Kosten- Nutzen-Analyse) ermöglichen. Hierfür sollten verschiedene monetäre und nicht monetäre Kennzahlen (z.B. PT, Tagessätze für Externe, Komplexitätsgrade, Anzahl betroffener Fälle) im Ticketsystem hinterlegt werden können.

Darüber hinaus ist es zwingend erforderlich, dass jedem Ticketbearbeiter bzw. jedem Lösungsbereich in einem Ticket ein entsprechender Aufwand zugeordnet werden kann. In der Regel ist dabei nach SOLL- und IST-Aufwand zu unterscheiden.

1.2.26. Zugriffsbeschränkung / Berechtigungssteuerung Das Ticketsystem muss Zugriffsbeschränkungen mittels Rollen und Berechtigungen ermöglichen. Es müssen differenzierbare Zugriffsumfänge z.B. anhand der Vorgangsart und ggfs. Module/Kategorie abgebildet werden können (z.B. Zugriff auf die Tickets der Vorgangsart „Organisationsstelle“ hat nur die zuständige Einheit „Organisationstelle“ zzgl. der Person, die das Ticket geöffnet hat sowie Prozessbeteiligte).

Neben der landesweit einzurichtenden Berechtigungen im Ticketsystem, müssen innerhalb des LfF weitere Unterscheidungen getroffen werden. Es müssen Rollen für jeden User im LfF zur Ticketanlage vorhanden sein und für ausgewählte Bearbeiter im LfF, Rollen, mit welchen die Tickets angelegt und bearbeitet werden dürfen. Ein entsprechendes Berechtigungskonzept ist im Rahmen des Einführungsprojektes zu erstellen und vor der Produktivsetzung dem AG auszuhändigen.

19 (29)

[Seite 23]

1.2.27. Mehrbenutzerfähigkeit Es muss sichergestellt sein, dass alle Nutzer des Ticketsystems (ca. 1000 Personen) gleichzeitig angemeldet sein und das Ticketsystem zeitgleich nutzen können, ohne dass es dabei zu Performanceproblemen kommt. Weiterhin darf dadurch die Konsistenz des Datenbestandes nicht gefährdet sein. Ein Ticket darf somit zum gleichen Zeitpunkt nur durch eine Person aktiv bearbeitet werden. Dies bedeutet, dass geeignete Synchronisationsmechanismen umzusetzen sind, um einen konkurrierenden Zugriff auf den Datenbestand zu ermöglichen. Die implementierten Mechanismen sind entsprechend darzustellen (➔ zwingende Darstellung hierzu erforderlich).

1.2.28. Testdokumentation Es muss eine Möglichkeit geben, den Test einer Anpassung in verschiedenen Stufen (Modultest, Abnahmeprüfung, …) im Ticket zu dokumentieren. Ein entsprechender Lösungsvorschlag ist vom Bieter darzutellen (Konzept ➔ max. 3 Seiten, Arial 11).

1.2.29. Service-Level-Agreements (SLA´s) Das Ticketsystem muss die Möglichkeit bieten, Service-Level-Agreements, die zwischen dem LfF und den an das Ticketsystem angebundenen Nutzern getroffen wurden, abzubilden. Hinweis: Die zwischen dem Bieter / Auftragnehmer und LfF geltenden SLA´s sind nicht im Ticketsystem abzubilden.

Dabei muss eine automatische Berechnung und Bewertung der SLA´s anhand der vergebenen Prioritäten erfolgen.

Weiterhin müssen entsprechende Reportingmöglichkeiten gegeben und eine auf die Erfordernisse des Auftraggebers anpassbare Berichterstellung für die Kunden vorhanden sein.

Die SLA’s müssen je Vorgangsart konfigurierbar sein.

Die Abbildung der SLA-Funktionen muss im Rahmen eines Konzepts (Konzept ➔ max. 5 Seiten Arial 11) beschrieben werden.

20 (29)

[Seite 24]

1.2.30. Anbindung an externe Systeme, Datenbanken, Tools

Schnittstelle zum Active Directory (AD) des Landes Das Ticketsystem muss Schnittstellen zu anderen Systemen anbieten. Es muss eine Schnittstelle zum AD des Landes eingerichtet werden, welche auch ein Single Sign-On (SSO) für integrierte Landes-AD-User ermöglicht.

Schnittstelle zu SAP (allgemein) Anbindung des Change and Transport Systems (CTS) von SAP Systemen (siehe Kapitel 1.2.24).

Schnittstelle zu SAP – Cloud-ALM Alternative zur Anbindung des Change and Transport Systems (CTS): Anbindung von SAP Cloud ALM (Features) zur Transportsteuerung (siehe Kapitel 1.2.24).

Schnittstelle zum Laufzettel LfF (Eigenentwicklung) Es soll durch das Ticketsystem eine Schnittstellen bereitgestellt werden, die über einen WebService abgerufen werden kann und zur Ticketerstellung / Ticket-ID-Abfrage verwendet werden kann (➔ zwingende Darstellung hierzu erforderlich).

1.2.31. Änderungshistorie Für jedes Ticket muss jederzeit in einer Änderungshistorie nachvollziehbar sein, wer, wann, was geändert hat.

1.2.32. Automatisches Schließen von Tickets Das Ticketsystem soll die Funktion des automatischen Schließens von Tickets beinhalten. Diese Funktion muss dabei je Vorgangsart deaktivierbar und konfigurierbar sein. Die Funktion der automatisierten Ticketschließung muss im Rahmen eines Konzepts (Konzept ➔ max. 3 Seiten Arial 11) dargestellt werden.

21 (29)

[Seite 25]

1.2.33. Optische Anpassung der Benutzeroberfläche (zentral) Das Ticketsystem soll die Funktion einer optischen Anpassung und Standardvorgabe der Benutzeroberfläche beinhalten. Hintergrund ist das im Land Rheinland-Pfalz verwendete Coporate Design (CD), welches nach Möglichkeit auf die Oberfläche des Ticketsystems Anwendung finden soll sowie die Anforderungen der Barrierefreiheit . (➔ zwingende Darstellung hierzu erforderlich).

1.3. Anforderungen aus dem Bereich Datenschutz und IT-Sicherheit sowie sonstige Anforderungen

Darüber hinaus müssen folgende Anforderungen aus dem Bereich Datenschutz und IT- Sicherheit durch das Ticketsystem erfüllt werden:

1.3.1. Darstellung der Möglichkeit des Backup und Restore Die vollständige Wiederherstellung des Ticketsystems mit allen Ticketinhalten und Zuordnungen von Tickets zu Benutzerkonten muss durch den Auftraggeber in einer angemessenen Zeit (ca. 4 Stunden) möglich sein. Darüber hinaus muss es auch möglich sein, bei Bedarf einzelne Benutzerkonten wiederherzustellen. Der Auftragnehmer hat hierfür ein entsprechendes technisches Verfahren zur Verfügung zu stellen.

Dieses Verfahren, sowie der Backup- und Restoreprozess müssen im Rahmen eines Konzepts (Konzept ➔ max. 3 Seiten Arial 11) beschrieben werden.

1.3.2. Möglicher Ausschluss einer Möglichkeit zur Fernwartung Eine direkte Fernwartung des Systems durch den Bieter (AN) wird ausgeschlossen. Sollte das System über eine entsprechende Zugangsmöglichkeit ab Werk verfügen, muss diese deaktivierbar sein.

1.3.3. Bereitstellung von Softwareaktualisierungen Der Bieter (AN) muss innerhalb der gesamten Vertragslaufzeit regelmäßig Softwareaktualisierungen (zur Fehlerbehebung und der Entfernung von Sicherheitslücken) zur Verfügung stellen, ergänzend gilt Nr. 5, Nr. 15 EVB-IT Systemvertrag und die „Anlage 7 Mängel, Systemservice“. Eine mögliche automatische

22 (29)

[Seite 26]

Softwareaktualisierung des Systems muss deaktivierbar sein, so dass eine manuelle Aktualisierung möglich ist.

Dem LfF [Dezernat IPEMA®-Service-Center (ISC)] und CERT-rlp sind Security- Advisories für die bereitgestellte Software auf einem abzustimmenden Weg zuzustellen.

1.3.4. Unterstützungsleistungen Vor-Ort-Unterstützung in der Implementierungsphase ( Phase bis zur Herstellung des Gesatmsystems).

Vor-Ort-Unterstützung in der Produktion (bei Bedarf), vgl. Option 5.

1.3.5. Produktschulung der künftigen Administratoren Der Bieter (AN) muss eine Produktschulung für die zukünftigen Administratoren des Ticketsystems resp. das IPEMA®-Service-Center anbieten (insgesamt ca. 30 Personen). Die Schulung ist vor-Ort in den Räumlichkeiten des Auftraggebers durchzuführen. Die Schulungsinhalte müssen mindestens die Konfigurationsmöglichkeiten des Standardprodukts sowie die kundenindividuellen Erweiterungen umfassen.

1.3.6. Bereitstellung von Dokumentationen Für das Ticketsystem sind gängige Dokumentationen zur Verfügung zu stellen: Installationsanleitung, Benutzeranleitung/Handbuch, Konfigurationsanleitung auf Applikationsebene, etc.

1.3.7. Möglichkeit der Langzeitspeicherung von Daten Das System muss in der Lage sein , Tickets und deren Anhänge über einen frei zu definierenden Zeitraum revisionssicher und effizient durchsuchbar zu speichern. Der Bieter (AN) hat zu beschreiben (Konzept ➔ max. 3 Seiten, Arial 11), wie die Langzeitspeicherung mit dem angebotenen System realisiert wird und wie ggf. eine Erweiterung der Speicherkapazität erfolgen kann.

23 (29)

[Seite 27]

1.3.8. Aufbewahrungsfristen Um rechtlichen Rahmenbedingungen des Datenschutzes (DSGVO und Landesdatenschutzgesetz Rheinland-Pfalz) entsprechen zu können, müssen die auf dem System gespeicherten Tickets und Anlagen bzgl. ihrer Anzahl und der zeitlichen Aufbewahrungsfrist frei konfigurierbar und insbesondere begrenzbar sein.

Nach Ablauf der festgelegten Löschfrist müssen die Tickets inklusive Anhänge aus der Datenbank gelöscht werden. Die Löschung der Daten muss protokolliert werden.

Darüber hinaus ist es erforderlich, dass Anhänge, die personenbezogene Daten enthalten, auch unabhängig vom Bestand des Tickets automatisiert gelöscht werden können.

1.3.9. Protokollierung Eine Protokollierung muss möglich sein.

Die lokale Protokollierung der Systeme selbst (auf Betriebssystemebene) ist darzustellen (Konzept ➔ max. 5 Seiten, Arial 11). Insbesondere ist darzustellen, an welcher Stelle das System personenbezogene oder personenbeziehbare Daten verarbeitet.

1.3.10. Pseudonymisierung und De-Pseudonymisierung von Daten Das System soll in der Lage sein, Daten mit Personenbezug DSGVO-konform zu pseudonymisieren und pseudonymisiert zu speichern. Eine De-Pseudonymisierung der Daten muss möglich und durch einen Freigabeprozess abgesichert sein. Der Bieter hat darzustellen (Konzept ➔ max. 5 Seiten, Arial 11), welche Daten pseudonymisiert werden können, wie die Pseudonymisierung implementiert ist, wie der Freigabeprozess realisiert ist und ob die pseudonymisierten Daten durchsucht werden können. Die De- Pseudonymisierung von Daten muss protokolliert werden.

24 (29)

[Seite 28]

1.3.11. Performance der Anwendung Tickets müssen im System angelegt und gespeicherte Tickets aufgerufen werden können. Weiterhin können die im System gespeicherten Daten anhand beliebiger Kriterien durchsucht werden. Ticketanlage, Ticketaufruf und Anzeige der Ergebnisse der Suche müssen zeitnah (innerhalb weniger Sekunden) vom System zurückgeliefert werden.

1.3.12. Verschlüsselung Datenübertragung ausschließlich verschlüsselt (TLS 1.3 oder höher)

Speicherung von Daten sollte AES-256-verschlüsselt erfolgen, Methoden und Möglichkeiten mit entsprechenden Aussagen zu Performance unter Benennung der Messpunkte, bitte ausführlich darstellen (Konzept ➔ max. 5 Seiten, Arial 11).

1.3.13. Protokollierung von Administratoraktionen auf Applikationsebene Administrative Maßnahmen, wie z.B. Rechteänderungen für User, Konfigurationen von Vorgangsarten, Ticketarten, Rücksicherungen, etc. müssen durch das System protokolliert werden, wobei Zeit, User und Maßnahme auswertbar zu speichern sind.

Der Protokollierungsprozess und die Protokollinhalte sowie Protokollauswertungsmöglichkeiten müssen im Rahmen eines Konzepts (Konzept ➔ max. 5 Seiten, Arial 11) beschrieben werden.

1.3.14. Passwortrichtlinien Das System unterstützt die Festlegung von (kundenspezifischen) Passwortrichtlinien.

1.3.15. Systemservice Für das ausgelieferte Produkt wird werktags zwischen 08:00 Uhr und 17:00 Uhr (Zeitzone des Auftraggebers) deutschsprachiger Systemservice bei einer Reaktionszeit von maximal 120 Minuten bereitgestellt.

25 (29)

[Seite 29]

Im Detail gelten folgende Prioritäten und Zeitrahmen:

Die SLAs sind vom Bieter (AN) ausführlich zu erläutern (Konzept ➔ max. 3 Seiten, Arial 11).

26 (29)

[Seite 30]

1.3.16. Bereitstellung einer deutschsprachigen Hotline Der Bieter (AN) stellt eine kostenfreie deutschsprachige Hotline mit einer zu regulären Geschäftszeiten des LfF (Montag bis Donnerstag von 07:00 Uhr bis 18:00 Uhr, Freitag von 07:00 Uhr bis 16:00 Uhr) erreichbaren E-Mail-Adresse sowie Telefonnummer im deutschen Festnetz bereit.

1.3.17. Zugriff / Benutzeroberfläche Das Ticketsystem sollte vorzugsweise webbasiert und über einen aktuellen, modernen Webbrowser nutzbar sein – möglichst ohne zusätzliche Erweiterungen oder Plug-ins.

Falls eine lokale Anwendung oder Installation erforderlich ist, muss diese terminalserverfähig und für den Mehrbenutzerbetrieb geeignet sein.

Wenn der Management-Zugang für das System über eine webbasierte Konsole bereitgestellt wird, ist diese ausschließlich über HTTPS erreichbar und vollständig über einen Internet-Browser zu bedienen. Der Bieter muss darstellen, mit welchen Web Browsern die Applikation genutzt werden kann. Es sollen mindestens die Browser Microsoft Edge, Mozilla Firefox und Google Chrome in der jeweils aktuellen Version unterstützt werden. Die für die Nutzung des Systems eventuell erforderlichen Browser- Plugins und Add-Ons (wie Java etc.) sowie weitere Voraussetzungen sind durch den Bieter entsprechend darzustellen (Konzept ➔ max. 5 Seiten, Arial 11).

1.3.18. Proxyfähigkeit der Webapplikationen Die webbasierten Zugriffe auf das System müssen vollständig proxyfähig, d.h. über die zentrale Proxy-Infrastruktur des LDI nutzbar sein. Insbesondere darf der zugreifende Browser keine direkten IP-Verbindungen benötigen.

1.3.19. Self-Hosting Das Ticketsystem soll vollständig allein durch den AG auf den Systemen des AG betrieben werden können. Das Angebot über eine Public-Cloud ist daher ausgeschlossen.

Die Applikation muss in Twincore Rechenzentren einsetzbar sein.

27 (29)

[Seite 31]

Das Ticketsystem sollte virtualisierbar sein (➔ zwingende Darstellung hierzu erforderlich).

1.3.20. Leistungen bei Beendigung des Vertrags Bei Beendigung des Vertrags muss der AN dem AG Funktionen zur Verfügung stellen, mit welchen Inhalte des Ticketsystems (Tickets, deren Bestandteile und Anlagen, Wissensdatenbank) exportiert und für eine Migration in ein Nachfolgeverfahren bereitgestellt werden können.

28 (29)

[Seite 32]

1.4. Implementierung und Einführungsphase Der Auftragnehmer legt ein Konzept zur Implementierungs- und Einführungsphase vor. Dieses beinhaltet auch ein Termintreuekonzept. Es ist darauf einzugehen, wann und in welchem Umfang die in der Leistungsbeschreibung genannten Voraussetzungen unter Berücksichtigung des vereinbarten Terminplans (Nr.9 EVB-IT Sytemvertrag) umgesetzt werden. Ferner ist zu beschreiben, welcher personelle Beistellungsaufwand vonseiten des Auftraggebers zu erbringen ist und welche Kenntnisse und Fähigkeiten die beigestellten Personen besitzen müssen. (Konzept ➔ max. 10 Seiten, Arial 11).

29 (29)