📊 Übersicht

Unnamed: 1	Unnamed: 2	Unnamed: 3	Unnamed: 4	Unnamed: 5	Unnamed: 7	Unnamed: 9	Unnamed: 10
ANLAGE 2 – ANFORDERUNGSKATALOG – TELEFONANLAGE, ACD und UC
Anbieter:

						WERTUNG SOLL-ANFORDERUNGEN
Gesamt Anforderungen	Anzahl MUSS-Kriterien	MUSS - Anforderung nicht, nur teilweise erfüllt oder nicht beantwortet		Anzahl SOLL-Kriterien	SOLL: Anzahl der Punkte	Gewichtung dieses Katalogs in der Gesamtwertung	0.25
						Maximal erreichbare SOLL-Punkte (Gewichtung × 10)	2240
						Mindestquote	0.5
249	142	142		107	0	Mindestpunktzahl	1120
						Erreichte SOLL-Punkte	0
						Mindestpunktzahl erreicht?	nein – Ausschluss
		Hinweis: Die leere Vorlage zählt alle nicht ausgefüllten MUSS-Zeilen als nicht erfüllt (Ausschluss). Aussagekräftig sind die Werte erst nach vollständiger Beantwortung.				Hinweis: Gesamtwertung Preis 50 %, Anforderungskatalog TK/ACD 25 %, Anforderungskatalog Sicherheit 25 %. Ein Angebot, das in diesem Katalog weniger als 50 % der erreichbaren SOLL-Punkte (Mindestpunktzahl) erreicht, wird ausgeschlossen. Die SOLL-Punkte vergibt die ALDB in der Wertung; in der Bieterdatei bleibt die erreichte Punktzahl daher 0. Gelb: Vorgaben der ALDB.


KATEGORIEN IM ÜBERBLICK
Kategorie	Key	Anforderungen	Beschreibung
Telefonie & Sprache	T-001	27	Basisfunktionen Telefonie, Chef/Sekretariat, Sammelgruppen
ACD & Customer Experience	CX-001	45	CallCenter, Hotline, Callflows und Routing, Agents und Supervisoren
Wallboard & Reporting	W-001	24	Hotline-Reports und -Monitoring, Statusanzeigen, Signalisierung
Unified Communication	UC-001	17	Chat, Messaging,(Video)Konferenzen, Präsenzstatus
Client Interface & Endgeräte	C-001	27	Geräte und Oberflächen, über die Nutzer direkt telefonieren
Architektur & Technik	A-001	68	Technischer Aufbau, Hosting-Modell und Systemstruktur, Bestandssysteme
Betrieb & Wartung	B-001	41	Konfiguration, Administration, Monitoring und Verwaltung im laufenden Betrieb, Dokumentation, Release Management/Patches, Schulung für Admin und Nutzer
		249

Anforderungen

ANFORDERUNGSKATALOG – TELEFONANLAGE / ACD	Unnamed: 1	Unnamed: 2	Unnamed: 3	Unnamed: 4	Unnamed: 5	Unnamed: 6	Unnamed: 7	Unnamed: 8	Unnamed: 9	Unnamed: 11	Unnamed: 12	Unnamed: 13	Unnamed: 14	Unnamed: 15	Unnamed: 16
			Bewertung ALDB					Anbieter
			MUSS - zwingend erforderlich, K.O.-Kriterium SOLL - wird bewertet, einzeln kein K.O.-Kriterium	SOLL Wichtigkeit: 1 - niedrig 2 - mittel 3 - hoch	SOLL Erfüllungsgrad: 0 - nicht erfüllt 5 - teilweise erfüllt 10 - voll erfüllt Ausschluss bei < 50 % der SOLL-Punkte		SOLL Gewichtung x Punkte	erfüllt - Anforderung wird vollständig erfüllt teilweise - Anforderung wird mit Einschränkungen erfüllt (K.O.-Kriterium bei MUSS) nicht erfüllt - Anforderung wird nicht erfüllt (K.O.-Kriterium bei MUSS)

ID	Kapitel LB	Kategorie	Erfüllungs-kriterium	Gewichtung (1-3)	Anforderung / Beschreibung	Punkte (0/5/10)	Gesamt-punkte	Antwort	kurze Erläuterung/Beschreibung/Alternative Lösung/Verweis auf Herstellerunterlagen(Dokument, Seite), wenn verlangt, ZWINGEND ERFORDERLICH bei SOLL-Anforderungen, wenn sie NICHT ERFÜLLT oder TEILWEISE erfüllt werden	muss	nicht erfüllt	teilweise	muss und nicht erfüllt	muss und teilweise	muss ohne Antwort
A-001	2.1	Architektur & Technik	MUSS	n.a.	Die Lösung ist ohne Veränderung der bei der ALDB gesetzten Plattformen betreibbar.	./.				1	0	0	0	0	1
A-002	2.1.1	Architektur & Technik	MUSS	n.a.	Die Lösung ist vollständig ohne direkten Internetzugang betreibbar. Dies gilt uneingeschränkt für den Produktivbetrieb und für die Referenz-IT. Das schließt z.B. ein, dass Containerabbilder, Lizenzen (inkl. Lizenzprüfung) und Softwarepakete lokal bezogen werden, ohne dass hierfür eine Verbindung zu Diensten des Herstellers oder dem Internet erforderlich ist.	./.				1	0	0	0	0	1
A-003	2.1.2	Architektur & Technik	MUSS	n.a.	Die Lösung wird auf virtuellen Maschinen betrieben, die die ALDB auf VMware vSphere 8 bereitstellt. Als Betriebssystem wird Red Hat Enterprise Linux ab Version 9 eingesetzt; die ALDB stellt es einschließlich der Lizenzen bereit. Höhere Versionen werden abwärtskompatibel unterstützt. Liefert der Anbieter Komponenten als virtuelle Appliance mit einem eigenen Betriebssystem aus, ist dies in der Projektphase zu deklarieren und zu begründen. In diesem Fall gilt: Das Image ist auf VMware vSphere 8 lauffähig. Der Anbieter benennt das eingesetzte Betriebssystem einschließlich Version und Supportzeitraum, verantwortet dessen Pflege über die gesamte Vertragslaufzeit und übernimmt das Patchen dieses Betriebssystems einschließlich der Sicherheitsupdates innerhalb der vereinbarten Fristen. Die Appliance ist in Monitoring, Protokollierung und Datensicherung der ALDB einbindbar und kommt ohne Internetzugang aus.	./.				1	0	0	0	0	1
A-004	2.1.2	Architektur & Technik	MUSS	n.a.	Die Lösung ist auf VMware vSphere 8 mit Standard-Cluster-Management lauffähig und für diese Plattform herstellerseitig freigegeben.	./.				1	0	0	0	0	1
A-005	2.1.2	Architektur & Technik	SOLL	3	Sofern die Lösung Containertechnologie verwendet, soll Podman eingesetzt werden. Docker ist alternativ zulässig.		0			0	0	0	0	0	0
A-006	2.1.2	Architektur & Technik	MUSS	n.a.	Sofern die Lösung containerisierte Komponenten enthält, müssen diese unter OpenShift lauffähig sein.	./.				1	0	0	0	0	1
A-007	2.1.2	Architektur & Technik	SOLL	2	Installation und Konfiguration der Lösung sollen sich mit Ansible automatisieren lassen. Der Anbieter beschreibt in der Projektphase, welche Schritte automatisierbar sind und welche manuell erfolgen müssen.		0			0	0	0	0	0	0
A-008	2.1.2	Architektur & Technik	MUSS	n.a.	Die Lösung unterstützt Veritas Netbackup ab Version 10.3.0.1. und lässt sich über das Sicherungsverfahren im laufenden Betrieb sichern. Komponenten, die hiervon ausgenommen werden müssen, benennt der Anbieter in der Projektphase einzeln und schlägt für diese ein geeignetes Sicherungsverfahren vor.	./.				1	0	0	0	0	1
A-009	2.1.2	Architektur & Technik	SOLL	3	Benötigt die Lösung Quorum Devices oder vergleichbare Schiedsinstanzen, sind diese als virtuelle Maschine auf einem ESX-Cluster am dritten Standort der ALDB betreibbar. Der Anbieter benennt in der Projektphase den Bedarf und die Anforderungen an die Anbindung.		0			0	0	0	0	0	0
A-010	2.1.3	Architektur & Technik	MUSS	n.a.	Der Anbieter erstellt eine vollständige Kommunikationsmatrix aller Komponenten der Lösung im von der ALDB bereitgestellten Format. Sie umfasst Quelle, Ziel, Port, Protokoll, Richtung und Zweck jeder Kommunikationsbeziehung, einschließlich der Verbindungen zwischen den Standorten und zu den angebundenen Bestandssystemen.	./.				1	0	0	0	0	1
A-011	2.1.3	Architektur & Technik	MUSS	n.a.	Der Anbieter benennt spätestens 4 Wochen nach Zuschlag die Anforderungen der Lösung an das im Rahmen der Einführung neu aufzubauende Voice-Netzwerk, insbesondere Bandbreite, Priorisierung, Latenz- und Paketverlustgrenzen sowie erforderliche Netzsegmentierung.	./.				1	0	0	0	0	1
A-012	2.1.3	Architektur & Technik	MUSS	n.a.	Die Lösung ist unter IPv4 lauffähig.	./.				1	0	0	0	0	1
A-013	2.1.3	Architektur & Technik	SOLL	2	Die Lösung soll unter IPv6 sowie im Dual-Stack-Betrieb lauffähig sein; eine spätere Umstellung auf IPv6 soll ohne Systemwechsel möglich sein. Der Anbieter benennt in der Projektphase Komponenten, die IPv6 nicht oder nur eingeschränkt unterstützen, und legt eine Roadmap des Herstellers für die IPv6-Unterstützung vor.		0			0	0	0	0	0	0
A-014	2.1.3	Architektur & Technik	MUSS	n.a.	Die Lösung bezieht die Zeitsynchronisation ausschließlich über den internen NTP-Dienst der ALDB. Öffentliche Zeitserver werden nicht vorausgesetzt.	./.				1	0	0	0	0	1
A-015	2.1.4	Architektur & Technik	MUSS	n.a.	Es muss eine Anbindung an die HA-Cluster der ALDB möglich sein, je nach Datenbanksystem Always-On-Cluster, RAC-Cluster oder vergleichbare Verfahren.	./.				1	0	0	0	0	1
A-016	2.1.4	Architektur & Technik	MUSS	n.a.	Die führende und dauerhafte Datenhaltung erfolgt ausschließlich in der zentralen Datenbankinfrastruktur (Oracle DB, PostgreSQL oder MSSQL). Dies umfasst insbesondere Anruf- und Verbindungsdaten, Agenten- und Statusdaten, Reportingdaten sowie die Konfiguration der Lösung. Eine lokale oder eingebettete Datenhaltung ist nur zur Zwischenspeicherung und für Konfigurationen der Call Control zugelassen, wenn sie deklariert und in Datensicherung, Monitoring und Redundanzkonzept einbezogen sind. Der Anbieter deklariert jede lokale Datenhaltung mit Zweck, Datenart und maximaler Vorhaltedauer.	./.				1	0	0	0	0	1
A-017	2.1.4	Architektur & Technik	MUSS	n.a.	Der laufende Betrieb der Lösung erfordert keine dauerhaften Administrationsrechte auf Instanz- oder Serverebene. Erhöhte Rechte, die für Installation, Update oder Migration benötigt werden, deklariert der Anbieter in der Projektphase; sie werden auf Antrag zeitlich begrenzt eingeräumt.	./.				1	0	0	0	0	1
A-018	2.1.4	Architektur & Technik	MUSS	n.a.	Der Anbieter weist nach, dass der Hersteller der Lösung den Betrieb mit den bei der ALDB eingesetzten Versionsständen des gewählten Datenbanksystems freigegeben hat und hierfür Support leistet. Das sind bei Microsoft SQL Server die Versionen 2019, 2022 und 2025 jeweils in der Enterprise Edition, bei PostgreSQL die Hauptversion 18 und bei Oracle die Version 19c.	./.				1	0	0	0	0	1
A-019	2.1.4	Architektur & Technik	MUSS	n.a.	Kumulative Updates, Service Packs und Patch Sets müssen unterstützt werden. Herstellerfreigabe neuer kumulativer Updates und Sicherheitsupdates innerhalb einer definierten Frist (max.30 Tage); Sicherheitsupdates dürfen bis zur Freigabe eingespielt werden, soweit der Hersteller keinen dokumentierten Ausschluss benennt. Abhängigkeiten von herstellerseitig abgekündigten Datenbankfunktionen oder von herabgesetzten Kompatibilitätsstufen sind unzulässig.	./.				1	0	0	0	0	1
A-020	2.1.4.1	Architektur & Technik	MUSS	n.a.	Der Hersteller unterstützt den Betrieb der Lösung in einer georedundanten, über mehrere IP-Subnetze verteilten Clusterumgebung mit synchroner Replikation. Bei synchroner Replikation tritt darüber hinaus kein Datenverlust ein. Abgebrochene Transaktionen werden konsistent zurückgerollt und, soweit fachlich erforderlich, identisch wiederholt. Der Anbieter weist dies nach. Supportfälle dürfen nicht unter Verweis auf diese Konfiguration abgelehnt werden.	./.				1	0	0	0	0	1
A-021	2.1.4.1	Architektur & Technik	MUSS	n.a.	Die Lösung unterstützt einen Active-Active Betrieb. Die Lösung ist an beiden Standorten betreibbar, während z.B. die Datenbank zu jedem Zeitpunkt nur an einem Standort aktiv ist. Applikationskomponenten am jeweils anderen Standort greifen über die Standortverbindung auf die aktive Datenbank zu. Der Anbieter beschreibt die hierfür erforderlichen Voraussetzungen.	./.				1	0	0	0	0	1
A-022	2.1.4.1	Architektur & Technik	MUSS	n.a.	Die Lösung verwendet ausschließlich Clientbibliotheken, die der Datenbankhersteller aktuell unterstützt. Abgekündigte oder aus dem Support genommene Treiber werden nicht eingesetzt.	./.				1	0	0	0	0	1
A-023	2.1.4.1	Architektur & Technik	MUSS	n.a.	Ein Failover, z.B. automatisch innerhalb eines Standorts oder manuell zwischen den Standorten, erfordert weder einen Neustart von Diensten oder Servern noch eine Neuanmeldung von Benutzern oder Endgeräten noch einen manuellen Eingriff in die Lösung. Eine kurze funktionale Unterbrechung ist zulässig; Call Control und Anrufverteilung sind davon ausgenommen (A-058).	./.				1	0	0	0	0	1
A-024	2.1.4.1	Architektur & Technik	MUSS	n.a.	Die Lösung erkennt unterbrochene Datenbankverbindungen selbsttätig, verwirft sie, entfernt sie aus dem Verbindungspool und baut sie über den logischen Zugriffspfad neu auf. Der Wiederaufbau erfolgt mit Wiederholungsversuchen und ansteigenden Wartezeiten.	./.				1	0	0	0	0	1
A-025	2.1.4.1	Architektur & Technik	MUSS	n.a.	Verbindungsverlust, Wiederholungsversuche und erfolgreicher Wiederaufbau werden protokolliert und über die Monitoring-Schnittstelle der Lösung meldefähig ausgegeben.	./.				1	0	0	0	0	1
A-026	2.1.4	Architektur & Technik	MUSS	n.a.	Die Lösung unterstützt TLS 1.2 vollständig. Der Betrieb ist uneingeschränkt möglich, wenn die Protokolle SSL 3.0, TLS 1.0 und TLS 1.1 betriebssystemseitig deaktiviert sind. Soweit das eingesetzte Datenbanksystem TLS 1.3 zulässt, unterstützt die Lösung auch dieses. Andernfalls benennt der Anbieter in der Projektphase eine verbindliche Roadmap.	./.				1	0	0	0	0	1
A-027	2.1.4	Architektur & Technik	MUSS	n.a.	Zugangsdaten zur Datenbank werden nicht im Klartext gespeichert, weder in Konfigurationsdateien noch in der Registry noch in der Datenbank selbst. Der Anbieter beschreibt in der Projektphase das eingesetzte Verfahren zur geschützten Ablage.	./.				1	0	0	0	0	1
A-028	2.1.4.2	Architektur & Technik	SOLL	3	Die Lösung soll mit verschlüsselten Datenbanksicherungen kompatibel sein.		0			0	0	0	0	0	0
A-029	2.1.4.1	Architektur & Technik	MUSS	n.a.	Ergänzend zu B-019 legt der Anbieter in der Projektphase ein Konzept für einen koordinierten Standortschwenk von Applikations- und Datenbankebene vor, einschließlich der Möglichkeit, Applikationsknoten standortlokal zur jeweils aktiven Datenbankreplik zu betreiben.	./.				1	0	0	0	0	1
A-030	2.1.4.1	Architektur & Technik	MUSS	n.a.	Die Applikation ist multi-subnet-fähig.	./.				1	0	0	0	0	1
A-031	2.1.4.3	Architektur & Technik	SOLL	3	Sofern SQL gewählt wird: – Freigabe neuer SQL-Server-Hauptversionen spätestens 12 Monate nach deren allgemeiner Verfügbarkeit. Verbindliche Zusage in der Projektphase. – sind instanzweite Sonderkonfigurationen (Trace Flags, MAXDOP, Serverkonfiguration, abweichende Server-Collation) in der Projektphase vollständig zu deklarieren und zu begründen. – ist die benötigte Collation in der Projektphase zu benennen. Eine von der Instanz abweichende Collation muss auf Datenbankebene abbildbar sein. – ist die Applikation mit einem Datenbank-Kompatibilitätsgrad von mindestens 150 betreibbar. Sie ist weder auf niedrigere Kompatibilitätsgrade noch auf von Microsoft abgekündigte Funktionen angewiesen. – legt der Anbieter eine schriftliche Freigabe des Herstellers für den Betrieb in Always On Availability Groups mit synchronem Commit vor, mit automatischem Failover innerhalb eines Standorts und manuellem Schwenk zwischen den Standorten. – nutzt die Applikation die Mechanismen Connection Resiliency bzw. Transient Fault Handling der Microsoft-Treiber (z. B. ConnectRetryCount/ConnectRetryInterval sowie MultiSubnetFailover=True). Das allgemeine Verhalten beim Verbindungsverlust regelt A-024. – liegen sämtliche Datenbanken der Applikation in einer gemeinsamen Availability Group und bilden damit eine gemeinsame Failover-Einheit. Die Applikation ist funktional nicht von Datenbanken außerhalb dieser Availability Group abhängig, insbesondere nicht von master, msdb oder Fremddatenbanken. – baut die Applikation Verbindungen ausschließlich über den DNS-Namen des AG-Listeners auf, auch bei Verwendung eines nicht standardmäßigen TCP-Ports und ohne den SQL Server Browser Service. Sie wertet weder @@SERVERNAME noch SERVERPROPERTY noch HOST_NAME aus und speichert keine daraus abgeleiteten Werte. – werden der SQL Server Native Client und SQLOLEDB nicht eingesetzt; zulässig sind aktuelle, von Microsoft unterstützte Treiber wie ODBC Driver for SQL Server, Microsoft.Data.SqlClient oder JDBC Driver (allgemein siehe A-022). – unterstützt die Applikation Encrypt=True, optional Encrypt=Strict beziehungsweise TDS 8.0, bei gesetztem TrustServerCertificate=False und Validierung des Serverzertifikats gegen die Unternehmens-PKI. Den im Subject Alternative Name hinterlegten Listener-DNS-Namen verarbeitet sie korrekt. – nutzt die Applikation integrierte Windows-Authentifizierung über Kerberos gegen Active Directory mit korrekter SPN-Nutzung über den Listener-Namen. Ein Rückfall auf NTLM findet nicht statt. – beschränken sich die Rechte der Applikation im laufenden Betrieb auf db_owner an den eigenen Datenbanken; sysadmin- oder sonstige serverweite Rechte werden nicht benötigt, auch nicht für Installations-, Update- und Migrationsskripte (allgemein siehe A-017). – toleriert die Applikation Online-Index-Reorganisation und -Rebuild, Statistikaktualisierung, DBCC CHECKDB und Transaktionslogsicherungen im laufenden Betrieb. Sie setzt weder AUTO_CLOSE noch AUTO_SHRINK noch deaktivierte Seitenprüfsummen voraus. Die Datenbankoptionen entsprechen den Empfehlungen von Microsoft.		0			0	0	0	0	0	0
A-032	2.1.4.3	Architektur & Technik	SOLL	3	Sofern PostgreSQL gewählt wird, muss die Lösung kompatibel mit einem HA-Cluster der PostgreSQL Datenbank mit Patroni sein. Die Zugriffe müssen über HA-Proxy erfolgen.		0			0	0	0	0	0	0
A-033	2.1.4.3	Architektur & Technik	SOLL	3	Sofern Oracle gewählt wird, ist die Lösung kompatibel mit Oracle Real Application Cluster und Oracle Dataguard.		0			0	0	0	0	0	0
A-034	2.1.5	Architektur & Technik	MUSS	n.a.	Die Lösung ist über eine REST-Schnittstelle an das bestehende Ticketsystem Remedy in der Version 4.4.2+28041 anbindbar. Der Anbieter beschreibt in der Projektphase die vorgesehene Integration einschließlich der übergebenen Datenfelder.	./.				1	0	0	0	0	1
A-035	2.1.5	Architektur & Technik	MUSS	n.a.	Die Datenstruktur der an den bestehenden Rohdatenspeicher der ALDB übergebenen Anruf- und Statusdaten wird in der Projektphase vollständig offengelegt. Umfang der Anrufdaten siehe W-011. Der Übergabeweg an den Rohdatenspeicher wird in der Projektphase gemeinsam mit der ALDB festgelegt, mit dem Ziel eines optimalen Zusammenspiels zwischen der Lösung und den Systemen der ALDB.	./.				1	0	0	0	0	1
A-036	2.1.5	Architektur & Technik	MUSS	n.a.	Die Integrationsschnittstellen sind gesichert und konfigurierbar. Sie werden herstellerseitig unterstützt und sind versionierbar; Änderungen kündigt der Anbieter mindestens 3 Monate vor Wirksamwerden an; sicherheitsbedingte Änderungen spätestens mit ihrer Bereitstellung. Zur Dokumentation siehe B-001.	./.				1	0	0	0	0	1
A-037	2.1.6	Architektur & Technik	MUSS	n.a.	Sämtliche Komponenten, Werkzeuge und Prozesse der Lösung müssen in Icinga 2 integrierbar sein. Der Anbieter stellt die hierfür erforderlichen Konnektoren, Schnittstellen, Prüfroutinen oder MIBs bereit.	./.				1	0	0	0	0	1
A-038	2.1.6	Architektur & Technik	SOLL	3	Die Lösung soll darüber hinaus in Zabbix integrierbar sein, da die ALDB eine Umstellung beabsichtigt. Der Anbieter benennt in der Projektphase, ob vorgefertigte Integrationen vorliegen.		0			0	0	0	0	0	0
A-039	2.1.6	Architektur & Technik	SOLL	3	Überwachbar sind mindestens: Verfügbarkeit jeder Systemkomponente je Standort, aktiver Standort und Failover-Zustand, Auslastung der Sprachkanäle, Anzahl angemeldeter Agenten, Zustand der Schnittstellen zu Bestandssystemen, Zustand der Endgeräte, Datenbankreplikation sowie Laufzeiten eingesetzter Zertifikate.		0			0	0	0	0	0	0
A-040	2.1.6	Architektur & Technik	MUSS	n.a.	Der Anbieter erstellt einen Alarmbehandlungsplan, der je Ereignis Schwellwert, Meldungstext, Priorität, Alarmierungsweg und die vorgesehene Reaktion beschreibt.	./.				1	0	0	0	0	1
A-041	2.1.6	Architektur & Technik	SOLL	3	Die Lösung soll Protokolldaten in einem dokumentierten Format an die zentrale Protokollierung der ALDB liefern. Sicherheitsrelevante Ereignisse und administrative Zugriffe sollen vollständig protokolliert und enthalten sein (vgl. Anforderungskatalog Sicherheit, S-016).		0			0	0	0	0	0	0
A-042	2.1.7	Architektur & Technik	MUSS	n.a.	Die Lösung fügt sich in die zentrale Verzeichnis- und Identitätsverwaltung der ALDB ein. Eine eigenständige, davon getrennte Benutzerverwaltung setzt sie nicht voraus. Das Active Directory ist führend. Zulässig sind lokale Notfallkonten für den Fall, dass das AD nicht verfügbar ist, sowie die Pflege ACD-spezifischer Profile (z. B. Skills, Routing- und Agentenprofile) in der Applikation.	./.				1	0	0	0	0	1
A-043	2.1.7	Architektur & Technik	SOLL	2	Für Windows Komponenten nutzt die Lösung Microsoft Active Directory als Verzeichnisdienst und unterstützt (Group) Managed Service Accounts für ihre Dienstkonten.		0			0	0	0	0	0	0
A-044	2.1.7	Architektur & Technik	MUSS	n.a.	Sämtliche Komponenten der Lösung sind mit Zertifikaten der internen Zertifizierungsstelle der ALDB betreibbar. Verfahren, die öffentlich vertrauenswürdige Zertifikate, den Abruf von Sperrlisten oder Statusabfragen über das Internet voraussetzen, werden nicht eingesetzt.	./.				1	0	0	0	0	1
A-045	2.1.7	Architektur & Technik	MUSS	n.a.	Soweit die Lösung Verzeichnisabfragen über LDAP durchführt, erfolgen diese ausschließlich über eine TLS-gesicherte Verbindung (LDAPS). Eine unverschlüsselte Übertragung ist unzulässig. Die Lösung unterstützt die Hinterlegung mehrerer Verzeichnisserver zur Ausfallsicherheit.	./.				1	0	0	0	0	1
A-046	2.1.7	Architektur & Technik	MUSS	n.a.	Die Lösung muss Single Sign-on gegen die Identitätsverwaltung der ALDB unterstützen, einschließlich des Kommunikationsclients. Die ALDB stellt Single Sign-on über Kerberos bereit.	./.				1	0	0	0	0	1
A-047	2.1.7	Architektur & Technik	MUSS	n.a.	Administrative Rollen werden über Verzeichnisgruppen vergeben; ACD-spezifische Profile gemäß A-042 in der Applikation.	./.				1	0	0	0	0	1
A-048	2.1.8	Architektur & Technik	MUSS	n.a.	Die Lösung ist mit Thin Clients ab IGEL OS Version 11.150.10 sowie mit bootfähigen USB-Systemen der Firma ECOS (ECOS-Sticks, Homeoffice) nutzbar.	./.				1	0	0	0	0	1
A-049	2.1.8	Architektur & Technik	MUSS	n.a.	Die webbasierten Oberflächen der Lösung sind mit Mozilla Firefox ab Version 140.11.0esr (64 Bit) und Microsoft Edge ab Version 146.0.3856.62 (64 Bit) ohne zusätzliche lokale Komponenten, Erweiterungen oder Plugins nutzbar. Lokal zu installierende Desktop-Anwendungen sind ausgeschlossen. HDX-/Virtual-Channel-Plugins auf den IGEL-Clients sind nicht zulässig; die Audioverarbeitung erfolgt vollständig im Citrix-Server. Der Anbieter berücksichtigt dies beim Ressourcenbedarf.	./.				1	0	0	0	0	1
A-050	2.1.10	Architektur & Technik	MUSS	n.a.	Die Lösung unterstützt kabelgebundene Headsets, die lokal am Zugangsgerät betrieben werden. Der Anbieter benennt in der Projektphase unterstützte Modelle beziehungsweise Anschlussarten und etwaige Einschränkungen bei der Anrufsteuerung über das Headset.	./.				1	0	0	0	0	1
A-051	2.1.9	Architektur & Technik	MUSS	n.a.	Der Anbieter benennt unverzüglich Einschränkungen, die einem geplanten Versionswechsel entgegenstehen, und schlägt geeignete Abhilfemaßnahmen vor. Sicherheits- und Fehlerbehebungs-Patches sowie Minor-Versionswechsel der eingesetzten Betriebssysteme, der Virtualisierungsplattform, der Datenbanksysteme, der Verzeichnisdienste, der Arbeitsplatzvirtualisierung und der Browser dürfen den Betrieb der Lösung nicht beeinträchtigen. Ein gesonderter Vergütungsanspruch entsteht hierdurch nicht.	./.				1	0	0	0	0	1
A-052	4.1	Architektur & Technik	MUSS	n.a.	Die Lösung muss einen standortübergreifenden Active/Active-Betrieb unterstützen. Fällt ein Standort aus, übernimmt der verbleibende Standort automatisch den vollständigen Betrieb, ohne dass Service-Rufnummern oder externe Erreichbarkeiten geändert werden müssen. Erreichbarkeit und Routing bleiben für Anrufer im Betrieb und im Notfallbetrieb (Failover/Switchover) unabhängig vom aktiven Standort konsistent; ein Rufnummernbruch tritt nicht auf.	./.				1	0	0	0	0	1
A-053	4.1	Architektur & Technik	MUSS	n.a.	Redundanz ist auf zwei Ebenen herzustellen: innerhalb eines Rechenzentrums (Server-Komponenten, Dienste, Netzwerkpfade) und zwischen den Standorten (Geo-Redundanz).	./.				1	0	0	0	0	1
A-054	4.1	Architektur & Technik	MUSS	n.a.	Die Verfügbarkeit des Gesamtsystems darf 99,99 % nicht unterschreiten. Die Erreichbarkeit der Service-Nummern beträgt > 99,5 %. Die Werte beziehen sich auf die Systemverfügbarkeit; Systemgrenze sind die vom Anbieter gelieferten Komponenten; die Werte gelten für das System, nicht für die von der ALDB beigestellte Umgebung. Messzeitraum ist das Kalenderjahr; die Ermittlung erfolgt über das Monitoring der ALDB.	./.				1	0	0	0	0	1
A-055	4.1	Architektur & Technik	MUSS	n.a.	Bei Ausfall eines Systemknotens übernimmt der verbleibende Knoten ohne manuelle Intervention 100 % der Anruflast. Beim Wechsel in den Einzelknotenbetrieb und bei der Wiederherstellung des redundanten Betriebs dürfen bestehende Gespräche nicht abbrechen. Die Anrufverarbeitung muss auch während eines Upgrades aufrechterhalten werden. Durch die redundante Architektur des Systems wird erreicht, dass Patches, Updates und Upgrades keine Downtime der Erreichbarkeit der Service-Nummern verursachen. Bei Ausfall einer einzelnen vom Anbieter gelieferten Komponente bleibt die Telefonie einschließlich Anrufverteilung ohne Einschränkung verfügbar; für beigestellte Komponenten gelten A-058 und die Vorgaben zum Notfallbetrieb (LB Kap. 4.4.2).	./.				1	0	0	0	0	1
A-056	4.1	Architektur & Technik	MUSS	n.a.	Die Updateprozedur für alle Komponenten ist in der Projektphase vollständig zu beschreiben.	./.				1	0	0	0	0	1
A-057	4.4.2	Architektur & Technik	MUSS	n.a.	Ein Datenverlust ist grundsätzlich auszuschließen, auch bei Datenbankausfall oder Failover (z. B. durch Replikation). Ist die zentrale Datenbank nicht erreichbar, puffert die Lösung die anfallenden Daten und überträgt sie nach Wiederverfügbarkeit vollständig.	./.				1	0	0	0	0	1
A-058	4.4.2	Architektur & Technik	MUSS	n.a.	Call Control und Anrufverteilung arbeiten bei Nichtverfügbarkeit der Datenbank ohne Unterbrechung weiter; laufende Gespräche brechen nicht ab. Bis zur Wiederverfügbarkeit der Datenbank sind folgende Einschränkungen zulässig: keine Konfigurationsänderungen, keine historischen Auswertungen, keine Neuanmeldung von Benutzern und Endgeräten. Nicht eingeschränkt werden dürfen Routing, IVR-Grundfunktion und Statuswechsel angemeldeter Agents; gepufferte Daten (A-057) gehen nicht verloren.	./.				1	0	0	0	0	1
A-059	2.2	Architektur & Technik	MUSS	n.a.	Die Lösung muss die bestehende SBC-Infrastruktur (je Standort zwei aktiv/aktiv betriebene SBC) einschließlich deren Redundanzkonzept sowie die beiden vorhandenen Einwahlknoten der Deutschen Telekom unterstützen und mit den SBC interoperabel sein. Eine Zertifizierung der Interoperabilität ist nicht erforderlich; die SBC werden durch die ALDB konfiguriert.	./.				1	0	0	0	0	1
A-060	2.3	Architektur & Technik	MUSS	n.a.	Die Lösung muss mindestens folgendes Mengengerüst abdecken: mind. 200 Business User (Nebenstellen), 100 ACD-Agents (3-Schicht-Betrieb 24/7), max. 90 gleichzeitig angemeldete Agents, 20 Supervisoren, 5 Administratoren, 80 Arbeitsplätze mit Hardphone, > 60 parallele externe Gespräche. Referenzumgebung mit vollständiger Funktionsfähigkeit: 15 Business User, 5 ACD-Agents, 3 Supervisoren, 2 Administratoren, 5 parallele externe Gespräche. Die Anlage darf keine Engpässe unterhalb der Carrier-Kapazitäten verursachen.	./.				1	0	0	0	0	1
A-061	2.3	Architektur & Technik	MUSS	n.a.	Das Lizenzmodell ist vollständig offenzulegen. Alle für das Gesamtsystem erforderlichen Lizenzarten und Benutzerlizenzen sind transparent und einzeln auszuweisen; Art und Menge der Lizenzen ermittelt der Anbieter nach seinem Lizenzmodell für das Mengengerüst (Nutzer und Systemkomponenten) der Produktiv- und der Referenzumgebung, einschließlich der Dimensionierung gleichzeitiger IVR-Sitzungen und Sprachkanäle. Lizenzen, die für den Betrieb des Mengengerüsts fehlen, liefert der Anbieter ohne Mehrkosten nach. Dies gilt nur für das Mengengerüst gemäß LB Kap. 2.3; Erweiterungen darüber hinaus werden zu den Einheitspreisen (Anlage 4, Pos. D1/D2) beauftragt. Das Lizenzmodell muss eine mengenmäßige Erweiterung ohne Systemwechsel ermöglichen, insbesondere die Integration zusätzlicher Fachbereiche durch Erweiterung von Agentenanzahl, Services/Hotlines und Routing-Szenarien.	./.				1	0	0	0	0	1
A-062	4.2.1	Architektur & Technik	MUSS	n.a.	Die Lösung muss als native, auf offenen SIP-Standards basierende VoIP-Plattform ausgeführt sein und die herstellerunabhängige Anbindung von SIP-Trunks, SIP-Endgeräten, Web-Clients, Session Border Controllern und Drittanwendungen ermöglichen.	./.				1	0	0	0	0	1
A-063	4.2.1	Architektur & Technik	MUSS	n.a.	Die Erfüllung sämtlicher MUSS-Kriterien ist durch Herstellerdokumentation, technische Datenblätter oder vergleichbare Nachweise eindeutig mit Seitenverweis zu belegen. Die Nachweise legt der Anbieter in der Projektphase vor, spätestens mit dem Feinkonzept (Kap. 5.1). Technisch gleichwertige Lösungen sind zulässig; die Gleichwertigkeit ist nachvollziehbar nachzuweisen.	./.				1	0	0	0	0	1
A-064	2.1.2	Architektur & Technik	MUSS	n.a.	Der Anbieter gibt den Ressourcenbedarf (vCPU, RAM, Speicher) je Komponente und Standort in der Projektphase (Feinkonzept) an.	./.				1	0	0	0	0	1
A-065	2.1.4.2	Architektur & Technik	MUSS	n.a.	Replikationsmechanismen, die nicht durch standardisierte Datenbankprozesse (z. B. Export/Import) abgedeckt sind, beschreibt und implementiert der Anbieter.	./.				1	0	0	0	0	1
A-066	2.3	Architektur & Technik	SOLL	2	Sofern ein Einzel-Lizenz-Modell angeboten wird, sollen Lizenzerweiterungen in Schritten von einem Benutzer möglich sein.		0			0	0	0	0	0	0
A-067	4.1	Architektur & Technik	MUSS	n.a.	Die Lösung muss mit der vorgegebenen Architektur betrieben werden können: Call-Control- und Medienkomponenten sind je Standort redundant und über zwei Brandabschnitte verteilt	./.				1	0	0	0	0	1
A-068	4.1	Architektur & Technik	SOLL	3	Lösungs- und Architekturkonzept für die Prüfung der Anforderungen auf höchstens 10 Seiten inkl. Grafiken, das die angebotene Lösung in der Umgebung der ALDB nachvollziehbar beschreibt: (1) Systemarchitektur und Komponenten mit Versionsständen; (2) Verteilung auf die beiden Hauptstandorte und die Referenzumgebung; (3) Redundanz und Verhalten bei Ausfall eines Knotens, eines Standorts und der Datenbank (Anforderungskatalog TK/ACD, A-052, A-053, A-055, A-058); (4) Einbindung in die beigestellte Infrastruktur (Virtualisierung, Betriebssystem, Datenbankcluster, SBC, Citrix, Active Directory); (5) Schnittstellen zu Ticketsystem und Rohdatenspeicher. Das Konzept ist mit dem Angebot einzureichen. Berücksichtigt werden nur die ersten 10 Seiten.		0			0	0	0	0	0	0
B-001	5.4	Betrieb & Wartung	MUSS	n.a.	Dokumentation von Schnittstellen: Der Anbieter muss eine vollständige Schnittstellen- und Datenmodell-Dokumentation liefern, mindestens bestehend aus: o Beschreibung der Schnittstelle (Zugriffsart, Authentifizierung, Formate) o Datenobjekte/Felder inkl. Datentypen o Semantik jedes Feldes o Beispiel-Datensätze o Versionierungs- und Änderungsregeln Abgrenzung: Der Anbieter ist nicht verantwortlich für ESB-Implementierung, Rohdatenspeicher/DWH sowie die darauf aufsetzende SLA-Berechnung und das Reporting der ALDB. Die Verantwortung des Anbieters endet bei der korrekten, vollständigen und zeitnahen Bereitstellung der Schnittstellendaten.	./.				1	0	0	0	0	1
B-002	5.4	Betrieb & Wartung	MUSS	n.a.	Anwenderdokumentation: Bereitstellen einer deutschsprachigen Anwenderdokumentation, gegliedert nach Rollen (Business User, Agent, Supervisor, Administrator), mit Schritt-für-Schritt-Anleitungen und Abbildungen der installierten Version, die Steuerungsmöglichkeiten und typische Nutzungsszenarien beschreibt. Ziel ist eine sichere und einheitliche Nutzung im operativen Betrieb. Betriebsdokumentation siehe B-026, Schulungsunterlagen siehe B-027.	./.				1	0	0	0	0	1
B-003	5.1	Betrieb & Wartung	MUSS	n.a.	Dokumentation von technischen Voraussetzungen: die angebotenen Betriebsarten (Web-Client) sind so dokumentieren, dass klar erkennbar und prüfbar ist, welche technischen Voraussetzungen (Browser, Policies, Ports, Security) gelten.	./.				1	0	0	0	0	1
B-004	4.4.1	Betrieb & Wartung	MUSS	n.a.	Die Verwaltung erfolgt zentral über eine webbasierte Administrationsoberfläche. Standardänderungen brauchen keinen Neustart von Diensten. Sie beinhaltet - zentrale Verwaltung von Benutzern und Rufnummern - Vergabe von Nebenstellen und Berechtigungen - Verwaltung von Rufnummernplänen sowie Service- und Skill-Zuordnungen - Sperr- und Freigaberegeln (z. B. Auslandsgespräche) - Interne Rufnummernverwaltung - Zeitsteuerung (Tag-/Nachtbetrieb) Alle Zuordnungen müssen administrativ konfigurierbar und dokumentiert sein.	./.				1	0	0	0	0	1
B-005	4.4.1	Betrieb & Wartung	MUSS	n.a.	Konfiguration Rufnummernplan: Für alle Standorte muss es einen einheitlichen Rufnummernplan geben, eine Rufnummer ist innerhalb der ALDB standortübergreifend und eindeutig erreichbar. Vom Dienste Anbieter, Deutsche Telekom (nicht ALDB) werden für die externe Erreichbarkeit die Service Nummern bereitgestellt, die übernommen werden müssen. Die Lösung muss außerdem einen separaten Rufnummernplan für Bürokommunikation unterstützen. Bestehende Rufnummernkonzepte (Amtsrufnummern, Durchwahlblöcke/DDI, Service- und Sonderrufnummern) müssen in den unternehmensweiten Rufnummernplan inkl. Gruppen-, Funktions- und Notrufnummern übernommen werden können.	./.				1	0	0	0	0	1
B-006	4.4.1	Betrieb & Wartung	MUSS	n.a.	Der Anbieter muss ein Rollen-/Nutzergruppen-Modell unterstützen, das mindestens die Nutzergruppen Agent, Supervisor/Teamleiter, Administrator und Business-User abbilden kann	./.				1	0	0	0	0	1
B-007	4.4.1	Betrieb & Wartung	MUSS	n.a.	Administration von Usern: Jeder Nutzer erhält unabhängig vom Standort eine eindeutige, fest zugewiesene User-ID mit zugehöriger Nebenstellen-Rufnummer. Für Callcenter-Agenten erfolgt zusätzlich eine Zuordnung zu (mehreren) Services und Skills (z. B. Skill 1st Level Service 1, Skill Bürokommunikation); eine manuelle Standortwahl durch die Agenten ist dabei nicht erforderlich. Agenten werden einheitlich im Rufnummernplan geführt (kein „Doppel-User“-Konstrukt je Standort).	./.				1	0	0	0	0	1
B-008	4.4.1	Betrieb & Wartung	SOLL	3	Die Verwaltung der User soll über bestehende Verzeichnisdienste (z. B. Active Directory) erfolgen. Rollen, Rufnummern und Berechtigungen sollen über Teilnehmerprofile automatisiert zugewiesen werden können. Zentrale Pflege von Benutzern und Konfigurationen siehe B-037.		0			0	0	0	0	0	0
B-009	4.4.1	Betrieb & Wartung	SOLL	3	Administration von Routings: Die Administration (User-Ids und der einzelnen Skills und zugehörigen Standorte, Anlage und Konfiguration der zu den Service-Nummern zugehörigen Call-Routing Szenarien bzw. Sonderfunktionen wie Rufbereitschaft, Sammelrufnummer oder Chef/Sekretariat) erfolgen über eine intuitive Oberfläche. Massenänderungen siehe B-037.		0			0	0	0	0	0	0
B-010	6.1	Betrieb & Wartung	MUSS	n.a.	Softwarewartung: - Sicherheitspatches und -updates innerhalb der vorgegebenen Fristen - Test und Einspielen der Updates durch den Anbieter sind nicht Bestandteil; Unterstützung bei Release-Planung und Release-Wechseln erfolgt auf Abruf über den Support. Bereitstellung der Updates, Releases, Patches und Hotfixes siehe B-030.	./.				1	0	0	0	0	1
B-011	6.1.2	Betrieb & Wartung	MUSS	n.a.	SLAs Sicherheitslücken: Der Anbieter sucht proaktiv nach bekanntwerdenden Schwachstellen und meldet diese spätestens innerhalb von 24 Stunden an die ALDB. Die gemeinsame Bewertung mit der ALDB sowie risikoabhängig Workaround/Mitigation erfolgen innerhalb der Fristen gemäß LB Kap. 6.1.2 (S1: 24 Stunden, S2: 72 Stunden, S3: 120 Stunden); der Patch wird unverzüglich nach Verfügbarkeit beim Hersteller bereitgestellt.	./.				1	0	0	0	0	1
B-012	5.5	Betrieb & Wartung	MUSS	n.a.	Schulung und Einweisung (Administratoren): Die Administration der Systeme im laufenden Betrieb muss durch die ALDB ohne zusätzlichen Hersteller-Support möglich sein. Die Schulung umfasst eine fachlich-technische Einweisung zur Schnittstelle und zum Datenmodell. Umfang, Sprache und Unterlagen siehe B-027.	./.				1	0	0	0	0	1
B-013	5.5	Betrieb & Wartung	MUSS	n.a.	Schulung und Einweisung (Business User, Agents, Supervisoren und Key User): Die Schulungen vermitteln die Bedienung entsprechend der jeweiligen Rolle; die Key-User-Schulung befähigt die Teilnehmenden als Multiplikatoren. Umfang, Sprache und Unterlagen siehe B-027.	./.				1	0	0	0	0	1
B-014	6.2.1	Betrieb & Wartung	MUSS	n.a.	Service Desk: Im Fall von Störungen oder anderen Problemen ist ein deutschsprachiger Service-Desk bereitzustellen für eine Entgegennahme von Störungen und Anfragen per Telefon, E-Mail und nach Absprache anderen Medien: Servicezeiten: 24/7 inkl. Feiertagen Aufgaben: Entgegennahme von Störungen, Eskalationsverfahren bis zum Hersteller, Unterstützung bei Fehleranalyse, Konfigurationsproblemen und Softwarefehlern, Unterstützung bei Sicherheitsvorfällen und kritischen Systemstörungen Für kritische Störungen (P1 und P2) ist eine Rufbereitschaft bereitzustellen	./.				1	0	0	0	0	1
B-015	6.2.4	Betrieb & Wartung	SOLL	3	SLAs zur Behebung von Störungen nach folgenden Prioritäten, Zielwerte: P1 Kritisch (Totalausfall), Reaktionszeit <30min, Lösungsbeginn sofort, Workaround/Wiederherstellung 4h P2 hoch (Ausfall wesentlicher Funktionen), Reaktionszeit <1h, Lösungsbeginn sofort, Lösungszeit 8h P3 mittel (Einschränkung mit Workaround), Reaktionszeit < 4h, Lösungsbeginn Gleicher bzw. nächster Arbeitstag, Lösungszeit 4 Werktage P4 niedrig (Bedienungs- oder Konfigurationsfragen zu IVR, Routing- und Skill-basierte Verteilungen), Reaktionszeit <1 Arbeitstag, Lösungsbeginn nach Vereinbarung), Lösungszeit Nach Vereinbarung, in der Regel spätestens nach 10 Werktagen Lösungszeit ist die Zeit bis zur Wiederherstellung der Betriebsbereitschaft oder einem wirksamen Workaround.		0			0	0	0	0	0	0
B-016	3.1	Betrieb & Wartung	SOLL	2	Der Anbieter soll sicherstellen, dass für den Betrieb der TK/ACD-Lösung eine Möglichkeit zur regelmäßigen Überprüfung und Bewertung der Quality of Service besteht und dokumentiert ist.		0			0	0	0	0	0	0
B-017	5.2.3	Betrieb & Wartung	SOLL	2	Migration: im Übergangsbetrieb sind bestehende ACD- und Reporting-Funktionen weiter nutzbar oder durch gleichwertige ersetzt		0			0	0	0	0	0	0
B-018	5.1	Betrieb & Wartung	MUSS	n.a.	Der Anbieter erstellt in Abstimmung mit der ALDB ein Feinkonzept (Systemarchitektur, Verteilung der Komponenten auf beide Standorte, Redundanz- und Failover-Konzept, Netzwerk- und Sicherheitskonzept), eine Feinspezifikation sowie eine Installationsanleitung „from Scratch“ auf Basis des bereitgestellten Betriebssystems. Das Feinkonzept ist spätestens 6 Wochen nach dem Kickoff vorzulegen; die ALDB gibt es spätestens 2 Wochen nach Vorlage frei.	./.				1	0	0	0	0	1
B-019	5.1	Betrieb & Wartung	MUSS	n.a.	Der Anbieter erstellt ein Failover-, Backup-, Wiederherstellungs- und Desaster-Recovery-Konzept einschließlich Notfall- und Wiederanlaufkonzept und stellt die erforderlichen systemseitigen Unterlagen zur Umsetzung der Redundanz- und Hochverfügbarkeitsanforderungen sowie zum Backup- und Restore-Verfahren bereit.	./.				1	0	0	0	0	1
B-020	5.2.3	Betrieb & Wartung	MUSS	n.a.	Der Anbieter unterstützt die ALDB in der Projektphase bei der Erstellung des Migrationskonzepts, insbesondere durch fachliche und technische Beiträge zu Migrationsschritten, Rückfallszenarien und technischen Abhängigkeiten, und führt die Migration nach diesem Konzept durch. Das Migrationskonzept erstellt die ALDB.	./.				1	0	0	0	0	1
B-021	5.2.3	Betrieb & Wartung	SOLL	3	Die Migration soll ohne Unterbrechung der Erreichbarkeit erfolgen.		0			0	0	0	0	0	0
B-022	5.2	Betrieb & Wartung	MUSS	n.a.	Installations- und Konfigurationsleistungen sowie die Begleitung der Abnahmetests erfolgen an den Standorten der ALDB. Nutzdaten und eingestufte Inhalte werden nicht an Anbieter oder Hersteller übermittelt.	./.				1	0	0	0	0	1
B-023	5.2.1	Betrieb & Wartung	MUSS	n.a.	Die Lösung wird zuerst in der Referenz-IT installiert und nachgewiesen. Die Lösung muss die Nutzung der bestehenden Test- und Referenzarbeitsplätze der ALDB ermöglichen.	./.				1	0	0	0	0	1
B-024	5.2.1	Betrieb & Wartung	MUSS	n.a.	Tests müssen sowohl rein webbasiert, ohne Tischtelefone, als auch mit Tischtelefonen möglich sein.	./.				1	0	0	0	0	1
B-025	5.3	Betrieb & Wartung	MUSS	n.a.	Der Anbieter erstellt einen Entwurf des Test- und Abnahmeplans gemäß Kap. 5.3.2, der in der Projektphase gemeinsam mit der ALDB einschließlich seiner Umsetzung festgelegt wird, und unterzieht die Lösung dem Abnahmeverfahren gemäß Kap. 5.3 (Teilabnahmen, Funktionsprüfungen, Probebetrieb, Gesamtabnahme).	./.				1	0	0	0	0	1
B-026	5.4	Betrieb & Wartung	MUSS	n.a.	Die Betriebsdokumentation wird im Umfang gemäß Kap. 5.4 in deutscher Sprache und ohne VS-NfD-eingestufte Inhalte erstellt. Der Anbieter räumt der ALDB das Recht zur Nutzung und Fortschreibung der erstellten Dokumente ein.	./.				1	0	0	0	0	1
B-027	5.5	Betrieb & Wartung	MUSS	n.a.	Schulungskonzept und Schulungen für Administratoren (5), Business User (200), Call Center Agents (100), Supervisoren (20) sowie eine Key-User-Schulung (max. 10 Teilnehmende) in deutscher Sprache; Schulungen virtuell oder vor Ort, die Einweisung der Administratoren und die Key-User-Schulung (Multiplikatoren) vor Ort; Schulungsunterlagen in elektronischer, druckfähiger Form zur weiteren Nutzung.	./.				1	0	0	0	0	1
B-028	5.5	Betrieb & Wartung	SOLL	1	Bereitstellung eines Webinars bzw. einer Video-Anleitung zum nachträglichen Anlernen neuer Benutzer.		0			0	0	0	0	0	0
B-029	5.6.2	Betrieb & Wartung	MUSS	n.a.	Die Kommunikation erfolgt in deutscher Sprache.	./.				1	0	0	0	0	1
B-030	6.1	Betrieb & Wartung	MUSS	n.a.	Der Wartungsvertrag umfasst die regelmäßige Bereitstellung aller Hersteller-Updates, Standard-Software-Releases, Patches und Hotfixes und ermöglicht der ALDB deren eigenständigen Download über die Download-Plattform des Anbieters (z. B. SharePoint) gemäß Anlage 3 S-012; die Installation in den Systemen der ALDB erfolgt offline. Zu jedem Update stellt der Anbieter Handlungsanleitungen bereit, mit denen die ALDB Updates eigenständig testen und einspielen kann.	./.				1	0	0	0	0	1
B-031	6.1.1	Betrieb & Wartung	SOLL	2	Die bereitgestellten Softwareversionen erfüllen mindestens das Kriterium n-1 (aktuelle oder vorhergehende Hauptversion).		0			0	0	0	0	0	0
B-032	6.1.3	Betrieb & Wartung	SOLL	2	Je Release werden Release Notes/Change Log, CVE-Bezug mit kurzer Einordnung sowie Upgrade-Hinweise und Upgrade-Pfade bereitgestellt.		0			0	0	0	0	0	0
B-033	6.2.1	Betrieb & Wartung	SOLL	1	Bereitstellung eines Kundenportals zur Ticketaufgabe und Einsicht in aktive und abgeschlossene Meldungen; Status-Überwachung und Dokumentation aller Meldungen bis zum Abschluss.		0			0	0	0	0	0	0
B-034	6.2.2	Betrieb & Wartung	MUSS	n.a.	2nd-Level-Support durch vorab benannte Mitarbeitende, die die Zugangs- und Zutrittsvoraussetzungen der ALDB erfüllen, einschließlich Rufbereitschaft für P1 und P2, strukturierter Root-Cause-Analyse, Unterstützung bei Desaster-Recovery-Ereignissen und zeitnaher Bereitstellung von Hotfixes/Workarounds.	./.				1	0	0	0	0	1
B-035	6.2.3	Betrieb & Wartung	SOLL	3	Vor-Ort-Unterstützung durch vorab benannte Mitarbeitende ist innerhalb von 48 Stunden nach Anforderung möglich.		0			0	0	0	0	0	0
B-036	6.2.5	Betrieb & Wartung	MUSS	n.a.	Der Anbieter stellt in der Projektphase einen vierstufigen Eskalationsprozess mit benannten Ansprechpartnern dar. Bei einer kritischen Störung (Major Incident) wird die Störung unmittelbar an einen benannten Incident Manager eskaliert, der ein technisches Notfallteam zusammenstellt und bei Bedarf einen Krisenstab koordiniert – rund um die Uhr.	./.				1	0	0	0	0	1
B-037	4.4.1	Betrieb & Wartung	MUSS	n.a.	Die Administration muss Massenänderungen über Upload-/Download-Funktionen unterstützen. Benutzer und Konfigurationen werden nur einmal zentral gepflegt.	./.				1	0	0	0	0	1
B-038	4.4.2	Betrieb & Wartung	MUSS	n.a.	Alle Schritte für Notfallübungen (Schwenk, Stromabschaltung, Ausfall einzelner Systeme) sind in einem Ausfall- und Schwenkkonzept zu beschreiben und zu testen.	./.				1	0	0	0	0	1
B-039	4.4.3	Betrieb & Wartung	MUSS	n.a.	Die Lösung muss die regelmäßigen Notfallübungen der ALDB (insbesondere jährliche Standortumschaltungen und Testszenarien) ohne produktionskritische Einschränkungen und ohne Ausfallzeit technisch unterstützen.	./.				1	0	0	0	0	1
B-040	6.4	Betrieb & Wartung	MUSS	n.a.	Bei Vertragsende muss der Anbieter auf Anforderung der ALDB (spätestens 6 Monate vor Vertragsende bzw. innerhalb von 4 Wochen nach einer Kündigung) einen Übergabeplan vorlegen, sämtliche Konfigurations- und Inhaltsdaten (u. a. Benutzer, Rufnummernplan, Routings, IVR-Callflows, Ansagen, Skills, Berichtsdefinitionen, Voicemails) in dokumentierten, offenen Formaten bereitstellen, Zugangsdaten, administrative Rechte und die aktuelle Betriebsdokumentation übergeben sowie beim Anbieter vorhandene Daten der ALDB löschen und die Löschung schriftlich bestätigen.	./.				1	0	0	0	0	1
B-041	6.4	Betrieb & Wartung	SOLL	2	Der Anbieter soll die ALDB und einen nachfolgenden Anbieter bis zu 6 Monate nach Vertragsende beim Wechsel unterstützen (Abrechnung über das Abrufkontingent des letzten Vertragsjahres, 24 Personentage, Anlage 4 Pos. B2). Erworbene Lizenzen sollen zeitlich unbegrenzt weiter nutzbar sein; bei Subskriptions- oder Mietmodellen soll ein Übergangsbetrieb von bis zu 12 Monaten zu den bisherigen Konditionen zugesichert werden.		0			0	0	0	0	0	0
C-001	3.5	Client Interface & Endgeräte	MUSS	n.a.	Die Anlage muss in der Citrix-Umgebung externe Sprachekommunikation (VoIP/Telefonie) über Nebenstellen-Nummern oder ACD ermöglichen	./.				1	0	0	0	0	1
C-002	3.5	Client Interface & Endgeräte	SOLL	3	Die Anlage soll in der Citrix-Umgebung interne Sprachekommunikation (VoIP/Telefonie) ermöglichen, Ziel ist, interne Kommunikation in einer gesicherten Umgebung abzubilden.		0			0	0	0	0	0	0
C-003	3.5	Client Interface & Endgeräte	SOLL	1	Die Anlage soll in der Citrix-Umgebung Instant Messaging, Chat und (Video)Conferencing mit Bildschirmfreigabe ermöglichen, um interne Kommunikation in einer gesicherten Umgebung abzubilden.		0			0	0	0	0	0	0
C-004	3.5	Client Interface & Endgeräte	SOLL	1	Virtuelle Hintergründe sollen bereitgestellt werden. Geräuschunterdrückung siehe C-024.		0			0	0	0	0	0	0
C-005	3.5	Client Interface & Endgeräte	SOLL	3	Die Oberfläche berücksichtigt die Grundsätze der Dialoggestaltung nach DIN EN ISO 9241-110. Die Kernfunktionen (Anmelden, Statuswechsel, Anruf annehmen, übergeben, beenden) sind auch per Tastatur bedienbar. Aktive Sitzungen laufen ohne erzwungenen Neustart, erneute Anmeldung oder Leistungseinbruch.		0			0	0	0	0	0	0
C-006	3.5	Client Interface & Endgeräte	MUSS	n.a.	Die Anlage muss den persönlichen Status für alle angemeldeten Nutzer bereitstellen. Aktueller Status (z. B. frei, im Gespräch, Abwesend, hält Präsentation)	./.				1	0	0	0	0	1
C-007	3.5	Client Interface & Endgeräte	SOLL	3	Benutzerfreundlichkeit: die Oberfläche soll intuitive bedienbar sein, Anpassbare Dashboards beinhalten		0			0	0	0	0	0	0
C-008	3.5	Client Interface & Endgeräte	MUSS	n.a.	Benutzerfreundlichkeit: deutschsprachige Oberfläche	./.				1	0	0	0	0	1
C-009	3.5	Client Interface & Endgeräte	SOLL	2	Performance: - Schnelle Reaktionszeiten der Oberfläche (Reaktionszeit bei Statuswechsel max. 2 Sek.) - Echtzeitaktualisierung von Status- und Warteschlangeninformationen		0			0	0	0	0	0	0
C-010	3.5	Client Interface & Endgeräte	MUSS	n.a.	Der Anbieter muss eine eindeutige Signalisierung bereitstellen, die mindestens folgende Aspekte umfasst: - visuelle Signalisierung (z. B. Anzeige eingehender Anrufe, aktiver Gespräche, Sicherheits- und Verbindungsstatus), - akustische Signalisierung (z. B. Klingeltöne, Hinweistöne, sicherheitsrelevante Warnsignale)	./.				1	0	0	0	0	1
C-011	3.1	Client Interface & Endgeräte	MUSS	n.a.	Die Anlage muss den Sprachdienst über Hardphones ermöglichen	./.				1	0	0	0	0	1
C-012	3.6	Client Interface & Endgeräte	SOLL	3	Hardphones sollen folgende Basisfunktionen bereitstellen: - Unterstützung der von der Anlage verwendeten Protokolle (VoIP/SIP) - HD Voice für gute Sprachqualität - kabelgebundene Headset-Unterstützung - mehrere Leitungen und Rufzustände - Funktionstasten - Anzeige von Präsenz- und Statusinformation		0			0	0	0	0	0	0
C-013	3.6	Client Interface & Endgeräte	SOLL	1	Hardphones – Headsets: Hardphones sollen kabelgebundene Headsets mit aktivem Noise Cancelling unterstützen.		0			0	0	0	0	0	0
C-014	3.5	Client Interface & Endgeräte	SOLL	3	Die Anlage soll neben Hardphones die Nutzung über einen browserbasierten Web-Client ermöglichen; zentrale Telefonie-Funktionen werden über den Web-Client und die unterstützten Tischtelefone konsistent und funktional gleichwertig bereitgestellt.		0			0	0	0	0	0	0
C-015	3.5	Client Interface & Endgeräte	SOLL	1	Die Anlage soll die Teilnahme an Konferenzen über unterschiedliche zugelassene Endgeräte ermöglichen (z. B. Web-Client, Tischtelefon, telefonische Einwahl). Die Funktionalität soll dabei nicht wesentlich vom Endgerät abhängen.		0			0	0	0	0	0	0
C-016	3.5	Client Interface & Endgeräte	SOLL	2	Barrierefreiheit gemäß EN 301 549 / WCAG 2.1 AA und Vorlage einer Konformitätserklärung (mit Abweichungsliste) mit dem Angebot		0			0	0	0	0	0	0
C-017	3.5	Client Interface & Endgeräte	SOLL	1	Die Anlage soll die Möglichkeit bereitstellen, dass der Web-Client bzw. das Agenten-Frontend bei eingehenden Anrufen automatisch in den Vordergrund gebracht wird (Focus/Foreground), sodass der Agent den Anruf ohne Suchen/Window-Hopping sofort bedienen kann.		0			0	0	0	0	0	0
C-018	3.5	Client Interface & Endgeräte	SOLL	1	Die Anlage soll diese Vordergrundschaltung konfigurierbar machen (z. B. je Rolle/Nutzergruppe), um Störungen bei Nutzern mit geringer Telefonie-Frequenz zu vermeiden. (opt-in)		0			0	0	0	0	0	0
C-019	3.5	Client Interface & Endgeräte	SOLL	3	Die webbasierten Oberflächen (vgl. A-049) sollen abwärtskompatibel mit mindestens drei vorangegangenen Hauptversionen von Mozilla Firefox (ESR) und Microsoft Edge nutzbar sein.		0			0	0	0	0	0	0
C-020	3.5	Client Interface & Endgeräte	SOLL	2	Web-Client: - CTI-Funktion Click-to-Call für alle Nutzergruppen einschließlich Supervisoren - Integration mit Headsets und Audiogeräten sowie Präsentationsmedien (externe Monitore) Anrufinformationen/Screen-Pop siehe CX-020.		0			0	0	0	0	0	0
C-021	3.3.1	Client Interface & Endgeräte	SOLL	2	Die Anlage soll die Supervisor-Ansichten frei konfigurierbar machen (Spalten/Sortierung/Filter/Zeitraum).		0			0	0	0	0	0	0
C-022	3.5	Client Interface & Endgeräte	MUSS	n.a.	Die Client-Lösung muss in der Citrix-Umgebung der ALDB funktionsfähig sein.	./.				1	0	0	0	0	1
C-023	3.5	Client Interface & Endgeräte	SOLL	3	Der Web-Client soll die Arbeit ohne physisches Telefon vollständig ermöglichen (Audio, Video, Präsenz, Kontakte, Anruflisten/Journal mit Filterfunktionen).		0			0	0	0	0	0	0
C-024	3.5	Client Interface & Endgeräte	SOLL	2	Audioqualität: Breitband-Audiocodec (z. B. Opus oder G.722), Echo- und Rückkopplungsunterdrückung sowie automatische Rauschunterdrückung; Latenz unter 150 ms (einfacher Weg).		0			0	0	0	0	0	0
C-025	3.6	Client Interface & Endgeräte	SOLL	1	Hardphones – erweiterte Merkmale: Headset-Schnittstelle mit elektronischem Hook-Switch (z. B. DHSG/EHS), frei programmierbare Funktionstasten mit mehrfarbiger LED-Signalisierung und Erweiterungsmodulen, Freisprechen im Vollduplex, integrierter Gigabit-Switch, PoE (IEEE 802.3af) und Energy Efficient Ethernet (IEEE 802.3az), grafisches Display, Tisch- und Wandmontage.		0			0	0	0	0	0	0
C-026	3.6.1	Client Interface & Endgeräte	SOLL	2	Hardphones – Lieferung: Mit jeder Gerätelieferung wird eine Datei (Excel/CSV) mit mindestens Seriennummer, Typ-/Modellnummer, Hashwert/Device-ID, ggf. Lizenzschlüssel und MAC-Adresse übergeben. Lieferungen werden mindestens zwei Werktage vorher per E-Mail angekündigt; ab 30 Geräten erfolgt die Anlieferung nach Absprache auf Palette.		0			0	0	0	0	0	0
C-027	3.6	Client Interface & Endgeräte	MUSS	n.a.	Der Anbieter erklärt in der Projektphase, ob und mit welchem Funktionsumfang die vorhandenen Telefone Alcatel IP Desk Phone 8086s mit der angebotenen Lösung weiter genutzt werden können, und benennt Einschränkungen.	./.				1	0	0	0	0	1
CX-001	3.2.1	ACD & Customer Experience	MUSS	n.a.	Die Anlage muss die Call-Routing Szenarien von mehreren Servicenummern über mehrere in Deutschland verteilte Standorte ermöglichen. Hierbei sind unterschiedliche Agenten bzw. Agentengruppen oder sich zeitlich entsprechend Wochentag bzw. Uhrzeit ändernde Szenarien erforderlich.	./.				1	0	0	0	0	1
CX-002	3.2.1	ACD & Customer Experience	SOLL	3	Die Lösung soll mindestens folgende Routing-Mechanismen ermöglichen: - Skill-based bzw. Competence-based Routing - Same-Agent-Routing (Rückführung an zuvor zuständigen Agenten) - Verteilung nach „longest idle“ bzw. „most idle“ - Priorisierung nach Kunde, Anliegen, Wartezeit oder definiertem SLA Die Routing-Logik ist kombinierbar, regelbasiert konfigurierbar und servicebezogen steuerbar		0			0	0	0	0	0	0
CX-003	3.2.1	ACD & Customer Experience	MUSS	n.a.	Die Anlage muss Service-Rufnummern priorisieren und schichten können.	./.				1	0	0	0	0	1
CX-004	3.2.1	ACD & Customer Experience	MUSS	n.a.	Die Anlage muss (beliebig viele) Service-Rufnummern als Routing-Objekte verwalten können	./.				1	0	0	0	0	1
CX-005	3.2.1	ACD & Customer Experience	MUSS	n.a.	Die Anlage muss eine flexible und dynamische Warteschlangensteuerung bereitstellen, die eine regelbasierte Anrufverteilung ermöglicht	./.				1	0	0	0	0	1
CX-006	3.2.1	ACD & Customer Experience	SOLL	3	Die Konfiguration der Regeln und Ansagen soll administrativ steuerbar und nachvollziehbar sein: - Die Lösung unterstützt zeit- und lastabhängige Steuerungsregeln und stellt (personalisierte) Warteschleifenansagen bereit. Überlauf-Mechanismen siehe CX-036.		0			0	0	0	0	0	0
CX-007	3.2.1	ACD & Customer Experience	MUSS	n.a.	Die Anlage muss im Routing/Callflow ermöglichen, dass mehrere Ressourcengruppen mit identischer Priorität konfiguriert werden können	./.				1	0	0	0	0	1
CX-008	3.2.1	ACD & Customer Experience	SOLL	3	Die Anlage soll sicherstellen, dass bei identischer Priorität die Auswahl eines freien Agenten gleichrangig über diese Ressourcengruppen erfolgen kann (ohne technische Workarounds wie zusätzliche „virtuelle Gruppen“ erzwingen zu müssen).		0			0	0	0	0	0	0
CX-009	3.2.1	ACD & Customer Experience	MUSS	n.a.	Die Anlage muss Agenten mehreren Gruppen zuordnen können.	./.				1	0	0	0	0	1
CX-010	3.2.2	ACD & Customer Experience	MUSS	n.a.	Die Anlage muss die Integration und Nutzung bestehender Ansagen/Audiofiles ermöglichen (bereitgestellt in definierten Formaten), sodass diese in Callflows/Routingstrategien eingebunden werden können.	./.				1	0	0	0	0	1
CX-011	3.2.2	ACD & Customer Experience	SOLL	2	Text-to-Speech / Dynamische Ansage vorschalten (ohne Aufsprechen): autorisierte Rollen können kurzfristig eine dynamische Ansage vor eine Servicenummer/Callflow schalten, wobei die Ansage per Texteingabe erzeugt wird (Text-to-Speech) und/oder durch manuelles Aufsprechen nutzbar ist.		0			0	0	0	0	0	0
CX-012	3.2.2	ACD & Customer Experience	SOLL	2	Die Aktivierung/Deaktivierung von Ansagen soll einfach administrierbar sein (schnelles Reagieren auf Störungen/Umleitungen/Standortausfälle).		0			0	0	0	0	0	0
CX-013	3.2.2	ACD & Customer Experience	MUSS	n.a.	Die Anlage muss ein IVR-System (Interactive Voice Response) bereitstellen, das sowohl sprachgesteuerte Eingaben (ASR) in deutscher Sprache als auch DTMF-basierte Eingaben (Tonwahlverfahren) unterstützt. Beide Steuerungsarten müssen parallel nutzbar und konfigurierbar sein. Ansagen müssen per Text-to-Speech in deutscher Sprache erzeugt werden können.	./.				1	0	0	0	0	1
CX-014	3.2.2	ACD & Customer Experience	SOLL	1	Die IVR soll eine (automatisierte) Authentifizierung des Anrufers ermöglichen, z. B. über Rufnummernerkennung, Name, Kennwort/PIN oder kombinierte Verfahren. Folgende Verfahren: - Authentifizierung über Rufnummernerkennung (CLI) - Eingabe von Kennwort/PIN- Namens- oder Identitätsabfrage - Kombination mehrerer Verfahren (mehrstufige Authentifizierung) - Die Authentifizierungslogik soll konfigurierbar und servicebezogen steuerbar sein.		0			0	0	0	0	0	0
CX-015	3.2.4	ACD & Customer Experience	MUSS	n.a.	Die Anlage unterstützt eine ACD-gestützte Bearbeitung von E-Mails aus einem Funktionspostfach,	./.				1	0	0	0	0	1
CX-016	3.2.4	ACD & Customer Experience	SOLL	2	Folgende features sollen erfüllt sein: - automatische Verteilung/Zuweisung von E-Mails an Bearbeiter - regelbasierte Priorisierung (z. B. anhand definierbarer Schlagwörter wie „dringend“) - transparente Pool-/Queue-Sicht (Überblick, welche E-Mails offen sind)		0			0	0	0	0	0	0
CX-017	3.2.3	ACD & Customer Experience	SOLL	1	Die Anlage soll eine Anruf-/Kontakt-Historie („Akte“) kanalübergreifend anzeigen können (Calls, Chat, Mail), auch beim eingehenden Anruf im Agenten-Frontend.		0			0	0	0	0	0	0
CX-018	3.3.3	ACD & Customer Experience	SOLL	1	Die Anlage soll Medienereignisse nachhaltig speichern (nicht wie Voicemail löschbar) und nachverfolgbar machen. Aufbewahrung und Löschung siehe W-021.		0			0	0	0	0	0	0
CX-019	3.2.4	ACD & Customer Experience	MUSS	n.a.	ACD-Ticket-Kopplung: Der Anbieter muss eine Kopplung zwischen ACD/Telefonie und dem Trouble-Ticket-System (TTS, Remedy) ermöglichen (technische Anbindung gemäß A-034), insbesondere: - automatischer Aufruf/Öffnen eines Tickets im TTS aus dem ACD-/Agentenkontext, - Austausch der erforderlichen Ticket- und Call-Informationen.	./.				1	0	0	0	0	1
CX-020	3.2.3	ACD & Customer Experience	MUSS	n.a.	Die Anlage muss im Agenten-Frontend Informationen zum eingehenden Call anzeigen (Service-Rufnummer, Wartezeit, Anrufer Nummer/-name bzw. ANI, gewählte Rufnummer bzw. DNIS, Kontexteingaben/IVR).	./.				1	0	0	0	0	1
CX-021	3.2.3	ACD & Customer Experience	MUSS	n.a.	Die Anlage muss im Agenten-Frontend persönliche Statistiken für den jeweils angemeldeten Agenten bereitstellen: - Eigene Gesprächsanzahl - Eigene Gesprächsdauer - Aktueller Status (z. B. frei, im Gespräch, Pause, Nachbearbeitung)	./.				1	0	0	0	0	1
CX-022	3.2.3	ACD & Customer Experience	MUSS	n.a.	Die Anlage muss im Agenten-Frontend Teamstatistiken bereitstellen, die einen Überblick über die aktuelle Situation der eigenen Ressourcengruppe ermöglichen: - Anzahl angemeldeter Agenten im Team - Anzahl verfügbarer / belegter Agenten - Anzahl wartender Calls. Es dürfen keine personenbezogenen Detaildaten einzelner Agenten offengelegt werden, sofern dies nicht ausdrücklich erlaubt ist. Diese Übersicht muss konsistent zu den zentralen Wallboard-Daten sein	./.				1	0	0	0	0	1
CX-023	3.2.3	ACD & Customer Experience	MUSS	n.a.	Die Anlage muss eine Anzeige der generellen Agentenverfügbarkeit bezogen auf die Servicenummern bereitstellen. Ziel ist, dem einzelnen Agenten zu ermöglichen, auf Basis dieser Übersicht einfache betriebliche Entscheidungen zu treffen (z. B. „Pause möglich“ oder „hohe Auslastung“). Es dürfen keine personenbezogenen Detaildaten einzelner Agenten offengelegt werden, sofern dies nicht ausdrücklich erlaubt ist. Diese Übersicht muss konsistent zu den zentralen Wallboard-Daten sein.	./.				1	0	0	0	0	1
CX-024	3.2.3	ACD & Customer Experience	MUSS	n.a.	Die Anlage muss eine Hilfeanforderungsfunktion ermöglichen, bei der der Agent (z. B. über Taste) ein Signal auslösen kann, das (am Arbeitsplatz sichtbar ist (z. B. Blinken) und) der Schichtleitung signalisiert: „Unterstützung benötigt“. Die Hilfeanfrage ist in der Ansicht des Supervisors sichtbar, je nach Systemlogik als Status oder Alarm.	./.				1	0	0	0	0	1
CX-025	3.2.3	ACD & Customer Experience	MUSS	n.a.	Die Anlage muss ein separates Modul/eine Ansicht bereitstellen, mit der Supervisoren/Schichtleitung mindestens folgende Informationen je Ressourcengruppe und Agent einsehen können: - Ressourcengruppe, in der ein Agent angemeldet ist, - aktueller Agentenstatus (z. B. bereit, im Gespräch, Nachbearbeitung, Pause), - Gesprächsstatus (telefoniert / Gespräch beendet / etc. im Rahmen der zulässigen Statuslogik	./.				1	0	0	0	0	1
CX-026	3.2.3	ACD & Customer Experience	SOLL	1	Die Anlage soll ermöglichen, dass im Callcenter die Funktion der automatischen Rufannahme nach einer definierten Zeit konfigurierbar ist. Sie ist für unterschiedliche Gruppen oder einzelne Nutzer individuell aktivierbar oder deaktivierbar, die Zeitspanne bis zur automatischen Annahme ist administrativ einstellbar.		0			0	0	0	0	0	0
CX-027	3.2.1	ACD & Customer Experience	SOLL	2	Die Anlage soll eine Filterlisten-Funktion mit Blacklisting- und/oder Whitelisting-Mechanismus bereitstellen. Dabei soll es möglich sein, definierte Rufnummern, Rufnummernbereiche oder Identifikatoren gezielt zu sperren (Blacklist) oder ausschließlich freizugeben (Whitelist).Die Verwaltung der Listen ist administrativ konfigurierbar, revisionssicher dokumentierbar und rollenbasiert steuerbar.		0			0	0	0	0	0	0
CX-028	3.2.3	ACD & Customer Experience	MUSS	n.a.	Die Anlage muss automatische Abmeldung/Nicht-Erreichbar-Status des Agenten nach Nicht-Annahme eines Calls unterstützen.	./.				1	0	0	0	0	1
CX-029	3.2.3	ACD & Customer Experience	SOLL	1	Die Anlage soll die automatische Abmeldung/Nicht-Erreichbar-Status des Agenten nach Sperren des Windows-Bildschirms unterstützen.		0			0	0	0	0	0	0
CX-030	3.2.3	ACD & Customer Experience	SOLL	1	Die Anlage soll konfigurierbar machen, ob Supervisor die Wiederfreischaltung nach Auto-Abmeldung bestätigen muss.		0			0	0	0	0	0	0
CX-031	3.2.2	ACD & Customer Experience	SOLL	1	Verwalten von Outbound Kampagnen/ Kampagnenmanagement: Anlegen, Bearbeiten, Starten, Pausieren und Beenden von Outbound-Kampagnen mit folgenden Features: - Verwaltung mehrerer Kampagnentypen: Progressive Dialing (die Anlage wählt erst wenn ein Agent verfügbar ist) und Preview Dialing (der Agent sieht Kundendaten, kann sich vorbereiten und entscheidet dann, wann die Maschine wählt) - Definition von Zielgruppen: Import von Kontaktdaten, z. B. CSV, CRM-Integration- Segmentierung nach Kriterien: Region, Priorität, Status, Skill etc. - Festlegung von Anrufzeiten - Blacklist-/Sperrlistenverwaltung - Dialer-Funktionen: automatisches Wählen mit Erkennung von Besetzt, keine Antwort, Anrufbeantworter (AMD) und falscher Nummer, Retry-Logik mit definierbaren Intervallen sowie Anruf Priorisierung		0			0	0	0	0	0	0
CX-032	3.2.3	ACD & Customer Experience	SOLL	1	Workflow & Automatisierung: - Automatische Wiedervorlagen/Rückrufaufträge - Terminvereinbarungsfunktion - Automatische E-Mail-/SMS-Versendung nach Gespräch		0			0	0	0	0	0	0
CX-033	3.2.3	ACD & Customer Experience	SOLL	1	Die Anlage soll den Status auch nicht-lizenzierte TK-Benutzer anzeigen können, sofern ein Connector zur TK/Plattform existiert.		0			0	0	0	0	0	0
CX-034	3.2.1	ACD & Customer Experience	SOLL	2	Routing auf Basis der Anrufer- und der gewählten Rufnummer (ANI/DNIS) sowie Service-Level-basiertes Routing.		0			0	0	0	0	0	0
CX-035	3.2.1	ACD & Customer Experience	MUSS	n.a.	Die Anlage muss eine kalenderbasierte Steuerung mit Tagestypen und bundeslandspezifischen Feiertagsprofilen bereitstellen.	./.				1	0	0	0	0	1
CX-036	3.2.1	ACD & Customer Experience	SOLL	3	Überlauf- und Interflow-Mechanismen bei Wartezeitüberschreitung oder Erreichen definierter Schwellenwerte an andere Gruppen oder Queues; gleichzeitiges Einreihen in mehrere Gruppen; virtuelle Warteschlangen; standortübergreifende Verteilung mit gemeinsamer Warteschlangensicht.		0			0	0	0	0	0	0
CX-037	3.2.1	ACD & Customer Experience	SOLL	3	Routingprozesse, Callflows und Workflows sollen einfach und ohne Programmierkenntnisse erstellt und gepflegt werden können. Der Callflow-Editor soll Datenintegration einschließlich Datenbankabfragen, Call-Vorbehandlung sowie Self-Service- und Bot-Elemente unterstützen.		0			0	0	0	0	0	0
CX-038	3.2.2	ACD & Customer Experience	MUSS	n.a.	Die IVR muss Backend-Systeme (Ticketsystem Remedy, Workflow-Systeme wie Camunda oder vergleichbare Systeme) in Sprachdialoge einbinden können, z. B. für Abfragen und Statusauskünfte. Die technische Anbindung erfolgt über dokumentierte, gesicherte und konfigurierbare REST-Schnittstellen (vgl. A-034, A-036).	./.				1	0	0	0	0	1
CX-039	3.2.3	ACD & Customer Experience	MUSS	n.a.	Die ACD-Verteilung muss Agenten unabhängig vom Standort und unabhängig davon einbeziehen, ob sie im Büro oder im Homeoffice arbeiten (ortsunabhängiges Arbeiten, Hotdesking).	./.				1	0	0	0	0	1
CX-040	3.2.3	ACD & Customer Experience	MUSS	n.a.	Agenten müssen sich an einzelnen Warteschlangen an- und abmelden können. Nicht-verfügbar- und Pausenstatus müssen mit Grundcodes (Reason Codes) erfasst werden können.	./.				1	0	0	0	0	1
CX-041	3.2.3	ACD & Customer Experience	MUSS	n.a.	Die Nachbearbeitungszeit muss gruppenspezifisch konfigurierbar sein. Abschlusscodes (Wrap-up-/Call-Codes) müssen erfasst werden können.	./.				1	0	0	0	0	1
CX-042	3.2.3	ACD & Customer Experience	SOLL	2	Die Anzeige der Anrufinformationen gemäß CX-020 soll als Screen-Pop konfigurierbar sein (z. B. angezeigte Felder, Zeitpunkt, Rolle).		0			0	0	0	0	0	0
CX-043	3.2.3	ACD & Customer Experience	SOLL	3	Steuerung von Agentenstatus und Anrufen sowohl im Web-Client als auch am Tischtelefon (CTI-Steuerung).		0			0	0	0	0	0	0
CX-044	3.2.3	ACD & Customer Experience	SOLL	1	Kurznachrichten/Laufschrift an Agent-Desktops. Benachrichtigungen und Alarme bei Schwellwertverletzungen siehe W-008, W-010 und W-018.		0			0	0	0	0	0	0
CX-045	3.2.3	ACD & Customer Experience	SOLL	1	Vordefinierte Antwortvorlagen für digitale Kanäle (z. B. E-Mail).		0			0	0	0	0	0	0
T-001	3.1	Telefonie & Sprache	MUSS	n.a.	Die Anlage muss ermöglichen, dass alle angelegten Business Nutzer über eine externe Telefonrufnummer erreichbar sind und über diese Rufnummer auch ausgehend telefonieren können. Die Erreichbarkeit der Service-Nummern des Technischen Büros muss über die zentrale Telefonie-/ACD-Lösung gewährleistet werden.	./.				1	0	0	0	0	1
T-002	3.1	Telefonie & Sprache	MUSS	n.a.	In der externen Kommunikation muss die Anlage folgende grundlegenden Funktionen erfüllen: - Anbindung an das öffentliche Telefonnetz (z. B. ISDN, SIP/VoIP) - Verwaltung von Amtsleitungen- Abgehende und ankommende Gespräche	./.				1	0	0	0	0	1
T-003	3.1	Telefonie & Sprache	MUSS	n.a.	Notfall Routing 112/110: standortgerechte Zustellung an die zuständige Leitstelle für alle Standorte der ALDB (Berlin, Hannover, Bonn); für Homeoffice anhand einer Notfalladresse. Die Anlage ermöglicht, Notfalladressen zentral zu verwalten bzw. dass der Nutzer sie eigenverantwortlich hinterlegt; alternativ Hinweis an die Nutzer.	./.				1	0	0	0	0	1
T-004	3.1	Telefonie & Sprache	MUSS	n.a.	Folgende allgemeine Telefonleistungsmerkmale müssen möglich sein: - Übermittlung der Rufnummer des Anrufers (CLIP) und Namensanzeige - Anzeige der Rufnummer des Angerufenen - Übermittlung kundeneigener Rufnummern (CLIP -no Screening-) - Anzeige kundeneigener Rufnummern (COLP -no Screening-) - Rückruf bei Besetzt (CCBS) - Rückruf bei Nichtmelden (CCNR) - Anklopfen (CW) - Halten, Rückfrage, Makeln (HOLD) - Dreierkonferenz (3PTY) - Anrufweiterschaltung (CF) - Heranholen von Anrufen (Pick-Up) - Wahlwiederholung - Anruf ablehnen (Anrufer hört Besetztton) - MFV:Der Teilnehmer kann Zeichen im Mehrfrequenzwahlverfahren (MFV) senden. - komfortables Wählen über virtuelles Tastenfeld, Kurzwahlen aus dem Telefonbuch oder direktes Klicken auf einen link	./.				1	0	0	0	0	1
T-005	3.1	Telefonie & Sprache	MUSS	n.a.	Die Anlage muss Anruflisten für geführte und entgangene Anrufe bereitstellen. Sie werden Teilnehmerbezogen und Geräteunabhängig gespeichert, sie sind nicht durch Dritte einsehbar, müssen durch den Administrator gelöscht werden können	./.				1	0	0	0	0	1
T-006	3.1	Telefonie & Sprache	MUSS	n.a.	In der Gesprächsvermittlung muss die Anlage folgende grundlegenden Funktionen erfüllen: - Aufbau, Steuerung und Beendigung von Gesprächen - Verbindung zwischen internen Teilnehmern - Weiterleitung externer Anrufe an interne Teilnehmer - Weiterleitung mit kalter und warmer Übergabe, Rückholen eines weitergeleiteten Gesprächs bei erfolgloser kalter Übergabe - Rufumleitung (sofort, bei Besetzt, bei Nichtmelden)	./.				1	0	0	0	0	1
T-007	3.1	Telefonie & Sprache	MUSS	n.a.	Die Anlage muss folgende Zusatzfunktionen bereitstellen: - Anrufbeantworter/Voicemail (weitergehende Merkmale siehe T-024) - Warteschleifen mit Musik und konfigurierbarem Ansagetext Die Funktionen müssen administrativ konfigurierbar und in die bestehende Telefonie- und ACD-Routinglogik integrierbar sein.	./.				1	0	0	0	0	1
T-008	3.1	Telefonie & Sprache	MUSS	n.a.	Die Anlage muss ein integriertes Kontaktverzeichnis bereitstellen. - Die Anlage muss mindestens interne Kontakte anzeigen können. - Das Kontaktverzeichnis muss durchsuchbar und rollenbasiert sichtbar sein	./.				1	0	0	0	0	1
T-009	3.1	Telefonie & Sprache	MUSS	n.a.	Die Anlage muss eine Chef-/Sekretariatsfunktion unterstützen	./.				1	0	0	0	0	1
T-010	3.1	Telefonie & Sprache	SOLL	3	Konfigurierbarkeit der Chef/Sekretariats-Funktion: - Anrufe an die Geschäftsführung werden standardmäßig bei der Assistenz signalisiert/aufgeschaltet, - die Geschäftsführung kann selektiv Anrufe übernehmen bzw. sich (fachlich sinngemäß) „einschalten/rausschalten“, - definierte Anrufer/Anrufarten (im Termin als VIP-/priorisierte Anrufe beschrieben) können direkt zur Geschäftsführung durchgestellt werden (Bypass Assistenz, regelbasiert), - bei Ausfall/Abwesenheit der Assistenzpersonen (z. B. Krankheit, Urlaub, temporäre Unterbesetzung) kann eine Vertretungsperson die Sekretariatsfunktion übernehmen kann, ohne dass die gesamte Logik neu gebaut werden muss. - ein Vertretungsprofil bzw. eine vertretungsfähige Umschaltung (z. B. dritte Person übernimmt Sekretariatsaufgaben) - eine einfache administrative Aktivierung/Deaktivierung der Vertretung (Betriebs-/Admin-seitig) - eine klare Definition, wohin Anrufe gehen, wenn niemand verfügbar ist (z. B. Sprachbox/Überlaufregel)."		0			0	0	0	0	0	0
T-011	3.1	Telefonie & Sprache	MUSS	n.a.	Es müssen zentrale Rufbereitschaftsrufnummern für einzelne Nutzergruppen möglich sein	./.				1	0	0	0	0	1
T-012	3.1	Telefonie & Sprache	SOLL	3	Konfigurierbarkeit der Rufbereitschaftsnummern: - Sie ist über eine Liste administrierbar sind. In dieser Liste wird festgelegt, wohin ein Anruf auf die zentrale Rufbereitschaftsnummer zu welcher Zeit geleitet wird - zeitabhängige Steuerung (Tag, Nacht, Wochenende) - Steuerung nach Eskalationsstufen (1. Dispatcher, 2. Team, usw.) . - Die Einstellung soll durch den Teamleiter und Vertreter administrierbar sein.		0			0	0	0	0	0	0
T-013	3.1	Telefonie & Sprache	MUSS	n.a.	Für Mitglieder eines Teams müssen Sammelgruppen standortübergreifend oder lokal (Usecase: lokale Sammelgruppe als Türklingel) möglich sein: eine Rufnummer, in der das Team erreichbar ist.	./.				1	0	0	0	0	1
T-014	3.1	Telefonie & Sprache	SOLL	3	Konfigurierbarkeit der Sammelgruppen: Wird die Rufnummer angerufen soll der Anruf parallel, zyklisch oder sequentiell an die angemeldeten Teilnehmer weitergeleitet bzw. verteilt werden können: - Bei paralleler Verteilung klingelt der Anrufer bei allen Teilnehmern gleichzeitig. - Bei zyklischer Verteilung wird der Anruf zyklisch auf die Teilnehmer geleitet, nimmt dieser den Anruf nicht entgegen, wird der Anruf zum nächsten Weitergeleitet. - Bei sequentieller Anrufverteilung erfolgt diese Auswahl immer nach der selben Reihenfolge, beginnend immer bei dem selben Teilnehmer zuerst (Dispatcher). Die Reihenfolge soll administrierbar sein. Wird der Anruf durch den Anrufer beendet, bleibt der Anruf in der Liste des zuletzt Gerufenen gespeichert. Dieser sieht in seiner Anrufliste, ob ein dort gespeicherter Anruf zu seiner eigenen Rufnummer oder aus der Verteilung der Sammelanschlussgruppe war. Teilnehmer werden bei Anmeldung automatisch in die Sammelgruppe angemeldet, haben aber die Möglichkeit, sich aus dieser Sammelgruppe ab- und wieder anzumelden. Wer Teilnehmer einer Sammelgruppe werden kann (und sich dann in einer Sammelgruppe anmelden kann), wird zuvor festgelegt und kann nicht durch den Teilnehmer selbst bestimmt werden. Für eine Sammelgruppe soll es möglich sein, einen Überlauf einrichten zu können, wohin der Anruf geleitet wird, wenn kein Teilnehmer der Sammelgruppe erreichbar ist (besetzt, nicht angemeldet, etc.). das Ziel für diesen Überlauf, intern oder extern, soll konfigurierbar/veränderbar sein."		0			0	0	0	0	0	0
T-015	3.1	Telefonie & Sprache	MUSS	n.a.	Der Anbieter muss sicherstellen, dass Kontaktdaten externer Teilnehmer (z. B. Firmen, Kunden oder Mobilnummern) in der Anlage verwaltet werden können: - Die Kontaktdaten müssen sowohl zentral administrierbar sein als auch persönlich durch einzelne Teilnehmer in einer individuellen Kontaktliste gepflegt werden können. - Für Kontakte müssen mindestens folgende Informationen verwaltet werden können: Name, Vorname, Anzeigename, Rufnummer, E-Mail-Adresse, Chat-Kontakt sowie zusätzliche Freitextinformationen. - Die Anlage muss Import- und Exportfunktionen für Kontaktdaten bereitstellen, insbesondere über CSV-Dateien, um eine einfache Pflege oder Migration von Kontaktdaten zu ermöglichen.	./.				1	0	0	0	0	1
T-016	3.1	Telefonie & Sprache	SOLL	3	Konfigurierbarkeit der Kontaktdatenliste: - Berechtigungskonzept für Kontaktdaten, mit dem gesteuert werden kann, welche Teilnehmer welche Kontakte sehen oder nutzen dürfen. Dabei soll unterschieden werden können, ob ein Kontakt ausschließlich bei einem eingehenden Anruf zur Anzeige gebracht wird (Caller Identification) oder aktiv über eine Verzeichnissuche gefunden und kontaktiert werden kann. - über welche Kommunikationswege ist ein Kontakt erreichbar ist (z. B. Sprache/Telefonie, E-Mail oder Chat). - Definition von VIP-Anrufern: VIP-Anrufe sollen bei eingehenden Anrufen besonders behandelt werden, insbesondere durch priorisierte Behandlung bzw. Routing innerhalb der Anlage und/oder eine deutlich erkennbare Signalisierung oder Alarmierung für den angerufenen Teilnehmer. - VIP-Kontakte werden ausschließlich zur Anzeige des Namens bei eingehenden Anrufen in der Kontaktdatenbank geführt und sollen nicht aktiv im Verzeichnis gesucht oder angerufen werden. - Kann ein VIP-Anruf nicht angenommen werden, soll dieser in der Anrufliste des Teilnehmers gesondert gekennzeichnet werden, sodass ein priorisierter Rückruf erfolgen kann.		0			0	0	0	0	0	0
T-017	3.1	Telefonie & Sprache	SOLL	3	Externe Telefonnummern sind für Namenssuche und Kurzwahl nutzbar.		0			0	0	0	0	0	0
T-018	3.1	Telefonie & Sprache	SOLL	2	Erweiterte Leistungsmerkmale (über T-004 und T-006 hinaus): Unterdrückung der Rufnummernanzeige des Gerufenen (COLR), Mehrfachrufnummern je Teilnehmer, Abweisen anonymer Anrufe; Rufumleitung zusätzlich bei Nichterreichbarkeit, zeitgesteuert sowie fernaktivierbar.		0			0	0	0	0	0	0
T-019	3.1	Telefonie & Sprache	SOLL	2	Pick-up-Varianten (über das Heranholen gemäß T-004 hinaus): Gruppen-Pickup, gezielter Pickup einzelner Teilnehmer und abteilungsübergreifender Pickup.		0			0	0	0	0	0	0
T-020	3.1	Telefonie & Sprache	SOLL	3	Teamfunktionen: Anzeige des Telefonstatus anderer Teammitglieder, Signalisierung und Übernahme eingehender Anrufe, individuelle Gruppenkonfiguration.		0			0	0	0	0	0	0
T-021	3.1	Telefonie & Sprache	SOLL	3	Erreichbarkeit unter einer Rufnummer über mehrere Endgeräte/Clients (Tischtelefon, Web-Client, Mobiltelefon, Heimarbeitsplatz) mit parallelem oder seriellem Rufen für alle Nutzergruppen (ACD-Agenten, Supervisoren/Teamleiter, Business-User). Nutzer können selbst entscheiden, über welches Endgerät sie ein Gespräch führen, und ein mobiles Endgerät als bevorzugtes Endgerät („preferred device“) festlegen.		0			0	0	0	0	0	0
T-022	3.1	Telefonie & Sprache	SOLL	2	Hot Desking und User Mobility: Anmeldung eines Nutzers an beliebigen Endgeräten mit persönlichem Profil.		0			0	0	0	0	0	0
T-023	3.1	Telefonie & Sprache	MUSS	n.a.	Die Lösung muss SIP-Trunking zur Anbindung an das öffentliche Telefonnetz unterstützen. Redundanz der Provideranschlüsse siehe A-059.	./.				1	0	0	0	0	1
T-024	3.1	Telefonie & Sprache	SOLL	2	Voicemail (Anrufbeantworter): persönliche und Gruppen-Mailboxen, mehrere persönliche Ansagen, Nachrichtensignalisierung (MWI), Weiterleitung von Sprachnachrichten an das E-Mail-Postfach.		0			0	0	0	0	0	0
T-025	3.1	Telefonie & Sprache	SOLL	3	Die Lösung soll Gesprächsdatensätze (CDR) einschließlich Dienstgüte-(QoS-)Daten erzeugen.		0			0	0	0	0	0	0
T-026	3.1	Telefonie & Sprache	SOLL	2	Die Lösung soll eine CTI-Schnittstelle nach einem offenen, dokumentierten Standard (z. B. CSTA, TAPI/JTAPI oder REST) bereitstellen.		0			0	0	0	0	0	0
T-027	3.1	Telefonie & Sprache	SOLL	2	Einheitliche Präsenzanzeige (verfügbar, beschäftigt, abwesend, DND, …) über alle Kanäle und Endgeräte hinweg mit Möglichkeit einer Kalendersynchronisation.		0			0	0	0	0	0	0
UC-001	3.4.1	Unified Communication	SOLL	2	Die Anlage soll Chat-Funktionen für direkte 1:1-Kommunikation sowie für definierte Gruppenchats bereitstellen. Gruppenchats sollen administrativ anlegbar und steuerbar sein. Ziel ist die strukturierte, dienstliche Textkommunikation zwischen Nutzern."		0			0	0	0	0	0	0
UC-002	3.4.1	Unified Communication	SOLL	1	Die Anlage soll ermöglichen, Chat-Funktionen rollenabhängig zu steuern. Dabei soll festgelegt werden können, wer Chats initiieren, moderieren oder beenden darf. Dies dient der Governance und verhindert unkontrollierte Kommunikationsstrukturen."		0			0	0	0	0	0	0
UC-003	3.4.1	Unified Communication	SOLL	1	Die Anlage soll Moderationsfunktionen für Chat-Räume bereitstellen. Moderatoren sollen Teilnehmer verwalten, Nachrichten einschränken oder Chat-Räume schließen können. Ziel ist die Sicherstellung eines geordneten Betriebs."		0			0	0	0	0	0	0
UC-004	3.4.1	Unified Communication	SOLL	1	Die Anlage soll sicherstellen, dass Chat-Verläufe für berechtigte Rollen nachvollziehbar sind. Dies umfasst die Auffindbarkeit, zeitliche Einordnung und Zuordnung zu Nutzern oder Gruppen. Die Nutzung dient betrieblichen und organisatorischen Zwecken (z. B. Nachvollziehbarkeit, Klärung)."		0			0	0	0	0	0	0
UC-005	3.4.1	Unified Communication	SOLL	2	Die Anlage soll ermöglichen, aus einem Chat heraus kontrolliert in eine Sprach- oder Konferenzkommunikation zu wechseln. Ziel ist eine medienbruchfreie Zusammenarbeit."		0			0	0	0	0	0	0
UC-006	3.4.2	Unified Communication	SOLL	2	Die Anlage soll eine Konferenzmöglichkeit (Besprechungs-Applikation für Sprache, Chat, inkl. Präsentation, Möglichkeit zum Teilen von Dokumenten) mit bis zu 500 eingeladenen Personen bereitstellen.		0			0	0	0	0	0	0
UC-007	3.4.2	Unified Communication	SOLL	2	Die Anlage soll Videokonferenzen bereitstellen (Videoqualität siehe UC-017).		0			0	0	0	0	0	0
UC-008	3.4.2	Unified Communication	SOLL	2	Die Anlage soll ermöglichen, laufende Gespräche kontrolliert um weitere Teilnehmer zu einer Konferenz zu erweitern, ohne bestehende Verbindungen zu unterbrechen. Die Funktion soll sicherheitsdomänenspezifisch arbeiten, sodass Teilnehmer gezielt zugeschaltet werden können; die Erweiterung soll nachvollziehbar erfolgen und die Rollenverteilung klar geregelt bleiben.		0			0	0	0	0	0	0
UC-009	3.4.2	Unified Communication	SOLL	2	Die Anlage soll ein differenziertes Rollen- und Moderationskonzept für Konferenzen bereitstellen. Dieses soll es ermöglichen, Konferenzteilnehmern unterschiedliche Rollen (z. B. Initiator, Moderator, Teilnehmer) zuzuweisen. Abhängig von der Rolle sollen Steuerungsrechte wie Stummschalten, Zulassen/Entfernen von Teilnehmern oder Einschränkung von Wortmeldungen eindeutig geregelt und administrierbar sein. Ziel ist eine kontrollierte, strukturierte Durchführung von Konferenzen insbesondere in fachlich oder organisatorisch sensiblen Kontexten."		0			0	0	0	0	0	0
UC-010	3.4.2	Unified Communication	SOLL	2	Die Anlage soll sicherstellen, dass Konferenzen ausschließlich durch berechtigte Nutzer gestartet und beendet werden können. Unbefugte Teilnehmer sollen weder eigenständig Konferenzen eröffnen noch bestehende Konferenzen beenden. Damit soll verhindert werden, dass Konferenzen unbeabsichtigt gestartet, unterbrochen oder vorzeitig beendet werden."		0			0	0	0	0	0	0
UC-011	3.4.2	Unified Communication	SOLL	2	Die Anlage soll eine Warteraumfunktion für Konferenzen bereitstellen. Teilnehmer sollen vor dem Eintritt in die Konferenz gesammelt oder einzeln durch berechtigte Rollen freigegeben werden können. Die Funktion soll insbesondere dazu dienen, sicherzustellen, dass nur berechtigte Teilnehmer an Konferenzen teilnehmen und der Beginn kontrolliert erfolgt."		0			0	0	0	0	0	0
UC-012	3.4.2	Unified Communication	SOLL	2	Die Anlage soll ermöglichen, Funktionen wie Bildschirmfreigabe, Dokumentenfreigabe oder Medienfreigabe abhängig von Rolle, Konferenztyp oder Sicherheitskontext zu erlauben oder zu unterbinden. Damit soll sichergestellt werden, dass sensible Inhalte nur von autorisierten Personen freigegeben werden können."		0			0	0	0	0	0	0
UC-013	3.4.2	Unified Communication	SOLL	2	Die Anlage soll während einer Konferenz jederzeit eine vollständige und aktuelle Übersicht aller zugeschalteten Teilnehmer bereitstellen. Dabei sollen Name, Rolle und aktueller Status (z. B. aktiv, stummgeschaltet) erkennbar sein. Dies dient der Transparenz, Nachvollziehbarkeit und sicheren Steuerung der Konferenz."		0			0	0	0	0	0	0
UC-014	3.4.2	Unified Communication	SOLL	3	Die Anlage soll sicherstellen, dass Konferenzen bei Zu- oder Abgang von Teilnehmern stabil weiterlaufen. Ein Verlassen oder Hinzukommen einzelner Teilnehmer soll nicht zum Abbruch oder Neustart der Konferenz führen."		0			0	0	0	0	0	0
UC-015	3.4.1	Unified Communication	SOLL	1	Dateianhänge und Hyperlinks im Chat; durchsuchbare Chat-Historie.		0			0	0	0	0	0	0
UC-016	3.4.2	Unified Communication	SOLL	1	Whiteboard, Umfragen/Abstimmungen mit anonymer Auswertung und Konferenz-Chat.		0			0	0	0	0	0	0
UC-017	3.4.2	Unified Communication	SOLL	2	Videoqualität: Mindestauflösung HD (720p), Zielauflösung Full HD (1080p) je Teilnehmerbild; Bildwiederholrate mindestens 25–30 fps, auch bei Bildschirmfreigabe; Unterstützung verbreiteter Codecs wie H.264 sowie neuerer, bandbreiteneffizienter Codecs.		0			0	0	0	0	0	0
W-001	3.3.1	Wallboard & Reporting	MUSS	n.a.	Die Anlage muss ein Echtzeit-Monitoring bereit stellen für: Warteschlangen, Anzahl angemeldete Agenten, Status, Servicelevel, Auslastung	./.				1	0	0	0	0	1
W-002	3.3.1	Wallboard & Reporting	MUSS	n.a.	Die Anlage muss Wallboard-Funktionalität bereitstellen/ unterstützen, mit der verschiedene Statistiken und Kennzahlen auf Großbildschirmen darstellbar sind (skalierbare Darstellung, unterschiedliche Bildschirmgrößen/Layouts).	./.				1	0	0	0	0	1
W-003	3.3.1	Wallboard & Reporting	SOLL	2	Inhalte des Wallboards (Widgets/Fenster) sollen anpassbar sein (skalieren, positionieren, kombinieren).		0			0	0	0	0	0	0
W-004	3.3.1	Wallboard & Reporting	MUSS	n.a.	Die Anlage muss im Wallboard Statistiken zur Anzahl eingehender/angenommener/verlorener Anrufe bereitstellen, mit Bezug zu den externen Services/Rufnummern	./.				1	0	0	0	0	1
W-005	3.3.1	Wallboard & Reporting	MUSS	n.a.	Die Anlage muss im Wallboard eine Übersicht der rollenabhängig angemeldeten Agenten und deren aktuellen Status bereitstellen (Busy/ Ready/ Pause/ Nachbearbeitung etc.), konfigurierbar entsprechend Gesamtbetriebsvereinbarung (GBV) und Datenschutz	./.				1	0	0	0	0	1
W-006	3.3.1	Wallboard & Reporting	MUSS	n.a.	Die Anzeige des Wallboards muss die Anzeige eines konfigurierbaren News-Ticker/Nachrichteneinblendungen unterstützen (interne Hinweise/Alarme/Anweisungen).	./.				1	0	0	0	0	1
W-007	3.3.1	Wallboard & Reporting	MUSS	n.a.	Es muss sichergestellt sein, dass öffentliche Wallboards inkl. Newstickern von entsprechend berechtigten Supervisoren/Administratoren konfiguriert werden können (zur Sicherstellung vom Datenschutz und Vermeidung von Missbrauch), Die Anlage muss hierfür eine geeignete Bedienoberfläche/Prozess unterstützen (ohne technische Spezialkenntnisse), inkl. Rechtevergabe.	./.				1	0	0	0	0	1
W-008	3.3.2	Wallboard & Reporting	SOLL	2	Automatisierte Benachrichtigungen bei Anrufverletzungen (inkl. Eskalationslogik): Die Anlage soll ermöglichen, dass bei definierten Ereignissen (z. B. SLA-/Servicezeit-Verletzungen, „kein Agent verfügbar“, Unterbesetzung) automatisierte Ad-hoc-Berichte erzeugt und an einen dedizierten Verteilerversendet werden (z. B. E-Mail).		0			0	0	0	0	0	0
W-009	3.3.2	Wallboard & Reporting	SOLL	2	Die Anlage unterstützt hierfür eine über Schwellwerte und Trigger konfigurierbare „Eskalations-/Event-Strategie“ im Callflow, die mindestens speichert: - Art der Verletzung / Event Typ, - Zeitpunkt (Datum/Uhrzeit), - betroffene Servicenummer/Callflow, - (optional) beteiligte Ressourcengruppen.		0			0	0	0	0	0	0
W-010	3.3.2	Wallboard & Reporting	SOLL	2	Akustische Alarmierung (Wallboard/Leitstand/Supervisor) bei konfigurierten Schwellwerten/Events unterstützen, mindestens: - Unterbesetzung/Minderbelegung, - Anrufannahmeverletzungen.		0			0	0	0	0	0	0
W-011	3.3.3	Wallboard & Reporting	MUSS	n.a.	Umfang der gelieferten Anrufdaten: Über die Schnittstelle zum Rohdatenspeicher werden alle Gespräche im vereinbarten Scope geliefert: eingehende (über Servicenummern und direkt gewählt), ausgehende und interne Gespräche, jeweils einschließlich abgebrochener, weitergeleiteter und übergelaufener Rufe, damit auch betriebliche Auswertungen über SLA hinaus möglich sind. Über die Schnittstelle zum Rohdatenspeicher werden keine Daten geliefert, die eine Rückverfolgung auf beteiligte Agenten ermöglichen.	./.				1	0	0	0	0	1
W-012	3.3.3	Wallboard & Reporting	MUSS	n.a.	Pflicht-Ereignisse je Ruf (Zeitpunkte): Für jeden einzelnen Ruf müssen mindestens folgende Ereignisse als Zeitstempel über die Schnittstelle bereitgestellt werden, soweit für die Gesprächsart zutreffend: - Rufeingang - Beginn der Agentensuche - Rufannahme durch einen menschlichen Agenten - Rufende Der Anbieter muss sicherstellen, dass diese Ereignisse eindeutig voneinander unterscheidbar sind.	./.				1	0	0	0	0	1
W-013	3.3.3	Wallboard & Reporting	MUSS	n.a.	Zeitauflösung und Messgenauigkeit - Millisekunden Auflösung - keine Rundung auf Sekunden - Zeitbasis dokumentiert	./.				1	0	0	0	0	1
W-014	3.3.3	Wallboard & Reporting	MUSS	n.a.	Zeitnähe und Verfügbarkeit der Daten: die über die Schnittstelle bereitgestellten Daten müssen spätestens 5 Minuten nach Rufende verfügbar sein	./.				1	0	0	0	0	1
W-015	3.3.3	Wallboard & Reporting	MUSS	n.a.	Die Daten müssen persistiert vorliegen und historisch auswertbar sein	./.				1	0	0	0	0	1
W-016	3.3.3	Wallboard & Reporting	MUSS	n.a.	Die Anlage muss Service-Level-Ziele (z. B. Rufannahme innerhalb 10 Sekunden) konfigurierbar unterstützen und on-the-fly auswerten.	./.				1	0	0	0	0	1
W-017	3.3.3	Wallboard & Reporting	SOLL	1	Die Anlage soll - sofern in das System integriert - Medienereignisse (Chat/Mail) in Reports und Echtzeit-Views berücksichtigen können.		0			0	0	0	0	0	0
W-018	3.3.2	Wallboard & Reporting	MUSS	n.a.	Die Anlage muss Ampel-/Schwellwertlogik unterstützen (z. B. Calls vs. angemeldete Agenten).	./.				1	0	0	0	0	1
W-019	3.3.3	Wallboard & Reporting	MUSS	n.a.	Die Anlage muss einen direkten SQL-Datenbankzugriff für eigene BI-Auswertungen unterstützen (inkl. verdichtete Views).	./.				1	0	0	0	0	1
W-020	3.3.3	Wallboard & Reporting	MUSS	n.a.	Die Anlage muss Call-Lookup/Einzel-Call-Analyse mit vollständigem Trace ermöglichen (SIP, Gruppe, IVR).	./.				1	0	0	0	0	1
W-021	3.3.3	Wallboard & Reporting	MUSS	n.a.	Die Anlage muss die Aufbewahrungsdauer der Reportingdaten und gespeicherter Medienereignisse konfigurierbar unterstützen und die Daten nach Ablauf der zulässigen Speicherzeiträume löschen.	./.				1	0	0	0	0	1
W-022	3.3.3	Wallboard & Reporting	MUSS	n.a.	Die Anlage muss historische Berichte auf Agenten-, Team-, Warteschlangen- und Organisationsebene bereitstellen (agentenbezogene Auswertungen gemäß GBV), individuell konfigurierbar, mit Standardberichten u. a. zu Anrufverteilung, Warteschlangen-Performance, abgebrochenen Anrufen und Abschlusscodes. Berichte und Analysen müssen ohne Programmierung erstellt werden können; die zugrunde liegenden Daten werden zur Verfügung gestellt.	./.				1	0	0	0	0	1
W-023	3.3.3	Wallboard & Reporting	SOLL	1	Automatische, zeitgesteuerte Erstellung und Verteilung von Berichten (z. B. per E-Mail); Export mindestens in den Formaten XLSX und PDF.		0			0	0	0	0	0	0
W-024	3.3.3	Wallboard & Reporting	SOLL	2	Lückenlose Verfolgung eines Kontakts über alle Stationen (Cradle-to-Grave) sowie standortübergreifend konsolidiertes Reporting.		0			0	0	0	0	0	0
							0			142			0	0	142

Vg-26-001_Anforderungskatalog_TK-ACD.xlsx

📊 Übersicht

Anforderungen