Anforderungsmatrix
| Unnamed: 0 | Unnamed: 1 | Unnamed: 2 | Unnamed: 3 | Unnamed: 4 | Unnamed: 5 | Unnamed: 6 | Unnamed: 7 | Unnamed: 8 | Unnamed: 9 | Unnamed: 10 | Unnamed: 11 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| C.3 – Anforderungsmatrix FMM NUM | |||||||||||
| Stand vom 04.09.2026 | |||||||||||
| Ausfüllbare Anforderungsmatrix – Fördermittelmanagement-Software NUM v2.18 | |||||||||||
| Die Matrix umfasst 163 Anforderungen: 122 Muss- und 41 Kann-Kriterien. Bitte ausschließlich die orange hinterlegten Felder ausfüllen. Muss-Kriterien sind im Angebotspreis inkludiert anzubieten. Die 41 Kann-Kriterien verteilen sich auf 31 Kriterien für Funktionalität und Prozesspassung, 5 Kriterien für technische Architektur, Sicherheit und Datensouveränität sowie 5 Kriterien für Vorgehensmodell, Migration und Service. In Spalte F ist die Erfüllungsart anzugeben. Bei Kann-Kriterien ist in Spalte G der Leistungsstatus „inkludiert“, „optional“ oder „nicht angeboten“ auszuwählen. Wird eine Kann-Leistung optional angeboten, ist in Spalte H die zugehörige Preisposition aus C.5 – Preisblatt anzugeben; konkrete Preise sind ausschließlich in C.5 einzutragen. Erläuterung beziehungsweise Nachweis gehören in Spalte I, Abweichungen und Voraussetzungen in Spalte J. Die beiden Textfelder sind jeweils auf 500 Zeichen begrenzt. Die Kann-Kriterien werden anhand der im Reiter „Bewertungshinweise“ veröffentlichten Skala mit 0 bis 5 Punkten bewertet. Ihre verbindliche Zuordnung zu den Zuschlagskriterien ergibt sich aus Spalte K. Innerhalb des jeweiligen Zuschlagskriteriums werden die zugeordneten Kann-Kriterien gleich gewichtet. Muss-Kriterien sind verbindliche Mindestanforderungen und werden nicht bepunktet. | |||||||||||
| Legende: M = Muss-Kriterium | K = Kann-Kriterium | Orange = vom Bieter auszufüllen | Rot markierte Eingaben = formaler Plausibilitätskonflikt | ||||||||
| Kapitel | ID | Kategorie | Anforderung | Erfüllungsart | Leistungsstatus | Preisposition in C.5 | Erläuterung / Nachweis des Bieters (max. 500 Zeichen) | Abweichungen / Voraussetzungen (max. 500 Zeichen) | Zuordnung zum Zuschlagskriterium | Fälligkeit / spätester Erfüllungszeitpunkt | |
| 3. Nutzergruppen, Rollen und Berechtigungen | R-01 | M | Die Lösung muss personenbezogene Nutzerkonten mit einer eindeutigen Nutzerkennung und einer optionalen Zuordnung zu Organisation, Standort, Teilprojekt und Rolle unterstützen. Technische Identitäten beziehungsweise Service Clients dürfen ausschließlich für automatisierte Integrationen eingesetzt werden und müssen eindeutig benannt sowie getrennt berechtigt werden können. | inkludiert | Go-Live Phase 1 | ||||||
| 3. Nutzergruppen, Rollen und Berechtigungen | R-02 | M | Die Lösung muss ein Rollen- und Rechtemanagement für mindestens die Geschäftsstelle beziehungsweise Administration, die administrative Bearbeitung und Prüfung, die fachliche Bearbeitung und Prüfung, die administrative und fachliche Qualitätssicherung, Standortnutzende, Teilprojektleitungen und lesende Berichtsnutzende unterstützen. | inkludiert | Go-Live Phase 1 | ||||||
| 3. Nutzergruppen, Rollen und Berechtigungen | R-03 | M | Der Zugriff muss über objektbezogene Rechte auf einzelne Standorte, Teilprojekte, Förderlinien und Vorgänge eingeschränkt werden können. | inkludiert | Go-Live Phase 1 | ||||||
| 3. Nutzergruppen, Rollen und Berechtigungen | R-04 | M | Projektbezogene Zugriffe müssen zeitlich befristet, entzogen oder neu vergeben werden können, ohne dass das Nutzerkonto gelöscht werden muss. | inkludiert | Go-Live Phase 1 | ||||||
| 3. Nutzergruppen, Rollen und Berechtigungen | R-05 | M | Alle relevanten Änderungen müssen mit der jeweiligen Nutzerkennung beziehungsweise technischen Identität, einem Zeitstempel, dem alten und dem neuen Wert oder dem jeweiligen Vorgangsereignis protokolliert werden. Die Protokolldaten müssen zweckgebunden, gegen unberechtigte Änderung und Löschung geschützt, auf berechtigte Rollen beschränkt und innerhalb der festgelegten Aufbewahrungsfrist auswertbar sein. | inkludiert | Go-Live Phase 1 | ||||||
| 3. Nutzergruppen, Rollen und Berechtigungen | R-06 | K | Die Lösung kann optional eine zentrale Anmeldung über Single Sign-on unterstützen, zum Beispiel über OIDC, SAML, Keycloak oder vergleichbare Authentifizierungsstandards. | Technische Architektur, Sicherheit und Datensouveränität | Go-Live Phase 4 | ||||||
| 3. Nutzergruppen, Rollen und Berechtigungen | R-07 | K | Die Lösung kann Delegations- und Vertretungsfunktionen für Abwesenheiten, Prüfketten und die stellvertretende Bearbeitung bereitstellen. Vertretungen müssen zeitlich befristet, vollständig protokolliert und für die Geschäftsstelle einsehbar sein. Sie dürfen das Vier-Augen-Prinzip nicht umgehen; identische Personen in Prüf- und Freigabeschritten müssen verhindert oder eindeutig ausgewiesen werden. | Funktionalität und Prozesspassung | Go-Live Phase 1 | ||||||
| 3. Nutzergruppen, Rollen und Berechtigungen | R-08 | M | Für definierbare Prozessschritte muss eine mehrstufige Freigabe einschließlich Vier-Augen-Prinzip konfigurierbar sein. Einreichende, prüfende und final freigebende Person müssen bei Bedarf organisatorisch getrennt werden können. | inkludiert | Go-Live Phase 1 | ||||||
| 4.1 Förderlinien, Teilprojekte und Standortstruktur | F-01 | M | Die Lösung muss mehrere Förderlinien beziehungsweise Vorhaben in einem System verwalten und dabei unterschiedliche Regeln zur Projekt- und Overheadpauschale sowie zur Mittelverfügbarkeit abbilden können. | inkludiert | Go-Live Phase 1 | ||||||
| 4.1 Förderlinien, Teilprojekte und Standortstruktur | F-02 | M | Die Lösung muss Teilprojekte mit mehreren beteiligten Standorten und standortbezogenen Finanzplänen abbilden können. | inkludiert | Go-Live Phase 1 | ||||||
| 4.1 Förderlinien, Teilprojekte und Standortstruktur | F-03 | M | Finanzpositionen müssen je Förderlinie, Teilprojekt, Standort und Haushaltsjahr geführt werden können. Die für den Abruf nach BNBest (Formular M03) erforderlichen Kontierungsmerkmale müssen zentral auf Ebene der NUM GmbH als Stammdaten geführt und in die jeweiligen Abrufvorgänge übernommen werden können. Eine Zuordnung der Kontierungsmerkmale zu einzelnen Standorten oder Teilprojekten ist für das M03 nicht erforderlich. Die endgültige Feldbelegung richtet sich nach dem mit den Vergabeunterlagen bereitgestellten Formular einschließlich des Kontierungsblatts. Zu den Kontierungsmerkmalen gehören insbesondere Bewirtschafternummer, Belegnummer des Bewirtschafters, Verarbeitungsschlüssel, Titelkonto und SB-Konto, Objektkonto, Kontrollnummer, Kostenstelle, Produkt, Kostenträger, Belegnummer der Festlegung und Fälligkeitsdatum. | inkludiert | Go-Live Phase 1 | ||||||
| 4.1 Förderlinien, Teilprojekte und Standortstruktur | F-04 | M | Die Lösung muss für Finanzmittel mindestens die Statuswerte bewilligt, gesperrt, entsperrt, zahlungsangefordert, abgerufen, als verwendet gemeldet, anerkannt, gekürzt, zurückgefordert und zurückgezahlt abbilden können. | inkludiert | jeweils zum zugehörigen Modul-Go-Live | ||||||
| 4.1 Förderlinien, Teilprojekte und Standortstruktur | F-05 | M | Die Lösung muss je Förderlinie unterschiedliche Regeln konfigurieren können, insbesondere zur Projekt- und Overheadpauschale, zur Sperr- und Entsperrlogik sowie zur Verfügbarkeit einzelner Finanzpositionen. | inkludiert | Go-Live Phase 1 | ||||||
| 4.1 Förderlinien, Teilprojekte und Standortstruktur | F-06 | M | Die Lösung muss Regeln für den Jahresübergang von Finanzmitteln konfigurieren können. Dies umfasst mindestens den Verfall und den Übertrag von Restmitteln je Haushaltsjahr einschließlich der Wirkung auf den Finanzierungsplan. Bei einem Übertrag bleibt der bisherige Sperrstatus unverändert: Gesperrte Mittel bleiben gesperrt, entsperrte Mittel bleiben entsperrt. Eine erneute Sperre allein aufgrund des Übertrags erfolgt nicht. | inkludiert | Go-Live Phase 3 | ||||||
| 4.1 Förderlinien, Teilprojekte und Standortstruktur | F-07 | K | Die Lösung kann regelbasierte Konsistenzprüfungen des Finanzdatenbestands durchführen, zum Beispiel Summen- und Vollständigkeitsprüfungen je Standort, Teilprojekt und Haushaltsjahr, und der Geschäftsstelle einen Abweichungsbericht bereitstellen. | Funktionalität und Prozesspassung | Go-Live Phase 1 | ||||||
| 4.1 Förderlinien, Teilprojekte und Standortstruktur | F-08 | K | Die Lösung kann eine grafische Übersicht der Finanzmittel je Förderlinie über die Haushaltsjahre auf Ebene der Teilprojekte und Standorte bereitstellen. Die Übersicht soll mindestens bewilligte, gesperrte, entsperrte und verbleibende Finanzmittel ausweisen. | Funktionalität und Prozesspassung | Go-Live Phase 4 | ||||||
| 4.2 Finanzplanungstool der Geschäftsstelle | FP-01 | M | Die Lösung muss die manuelle Planung noch nicht zugewiesener Finanzmittel nach Förderlinie, Haushaltsjahr und optionaler Zweckbindung ermöglichen. | inkludiert | Go-Live Phase 1 | ||||||
| 4.2 Finanzplanungstool der Geschäftsstelle | FP-02 | M | Die Lösung muss geplante Finanzmittel nachvollziehbar Teilprojekten, Standorten und Finanzpositionen zuweisen können. | inkludiert | Go-Live Phase 1 | ||||||
| 4.2 Finanzplanungstool der Geschäftsstelle | FP-03 | M | Die Lösung muss Auswertungen zum Gesamtbudget sowie zu verplanten, bewilligten, gesperrten, entsperrten, zahlungsangeforderten, abgerufenen und verfügbaren Finanzmitteln bereitstellen. | inkludiert | jeweils zum zugehörigen Modul-Go-Live | ||||||
| 4.2 Finanzplanungstool der Geschäftsstelle | FP-04 | K | Die Lösung kann eine Szenarioplanung beziehungsweise Planversionen für die Wirtschaftsplanung und für Forecasts bereitstellen. | Funktionalität und Prozesspassung | Go-Live Phase 4 | ||||||
| 4.3 Initiale Antragstellung | IA-01 | M | Die Lösung darf die Einreichung initialer Anträge durch berechtigte Standortnutzende je Standort und Teilprojekt erst nach einer erfolgreichen Vollständigkeits- und Plausibilitätsprüfung zulassen. Mindestens zu prüfen sind Pflichtfelder und Pflichtanlagen, die Summenkonsistenz der Finanzplanung, zulässige Finanzpositionen und Haushaltsjahre sowie hinterlegte Budgetgrenzen der jeweiligen Förderlinie beziehungsweise des Teilprojekts. | inkludiert | Go-Live Phase 1 | ||||||
| 4.3 Initiale Antragstellung | IA-02 | M | Die Lösung muss die direkte strukturierte Eingabe der erforderlichen Antragsdaten einschließlich der Gesamtbudgetplanung, der Finanzpositionen, der Haushaltsjahre und der Anlagen unterstützen. Zusätzlich muss sie die mit den Vergabeunterlagen bereitgestellten easy-Online-XML-Dateien der Formtypen AZA und AZK importieren und definierte Inhalte in die vorgesehenen Systemfelder übernehmen können. Der Import muss die unterschiedlichen XML-Strukturen der Formtypen AZA und AZK einschließlich optionaler beziehungsweise leerer Elemente sowie ein konfigurierbares Feldmapping unterstützen. Fehlerhafte oder nicht zuordenbare Inhalte sind nachvollziehbar auszuweisen; das produktive Mapping wird im Einführungsprojekt finalisiert. | inkludiert | Go-Live Phase 1 | ||||||
| 4.3 Initiale Antragstellung | IA-03 | M | Die Lösung muss die Einreichung, Versionierung, Überarbeitung und fachliche Prüfung einer Vorhabenbeschreibung (VHB) durch die jeweils zuständige Teilprojektleitung in einem eigenen Prüf- und Freigabestrang unterstützen. Anlagen und strukturierte Inhalte müssen dem Vorgang eindeutig zugeordnet werden können. | inkludiert | Go-Live Phase 1 | ||||||
| 4.3 Initiale Antragstellung | IA-04 | K | Die Lösung kann die GANTT- beziehungsweise Meilensteinplanung unmittelbar in der Software erstellen, bearbeiten und grafisch darstellen. Die Darstellung kann fällige Meilensteine je Monat, Teilprojekt und Standort sowie Abhängigkeiten zwischen einzelnen Meilensteinen umfassen. | Funktionalität und Prozesspassung | Go-Live Phase 1 | ||||||
| 4.3 Initiale Antragstellung | IA-05 | K | Die Lösung kann Meilensteine, Fristen und relevante Termine je Teilprojekt, Standort und Haushaltsjahr strukturiert erfassen, anzeigen und überwachen. | Funktionalität und Prozesspassung | Go-Live Phase 1 | ||||||
| 4.3 Initiale Antragstellung | IA-06 | M | Die Lösung muss den Upload von PDF-Anlagen und weiteren Dokumenten je Vorgang ermöglichen. | inkludiert | Go-Live Phase 1 | ||||||
| 4.3 Initiale Antragstellung | IA-08 | M | Die Lösung muss mindestens eine manuelle Zuweisung eingehender Anträge an Bearbeitende der Geschäftsstelle ermöglichen und offene Vorgänge transparent in einer Arbeitsliste darstellen. Eine zusätzliche regelbasierte oder automatische Zuordnung kann angeboten werden. | inkludiert | Go-Live Phase 1 | ||||||
| 4.3 Initiale Antragstellung | IA-09 | M | Die Lösung muss die administrative und fachliche Prüfung über konfigurierbare Checklisten unterstützen. Nach der fachlichen Erstprüfung müssen die weitere fachliche Prüfung sowie die administrative Antragsaufforderung und Prüfung parallel geführt werden können. Der Prozess umfasst Prüfpunkte, Korrekturen, Nachforderungen und Nachlieferungen mit Frist, einen Entscheidungsstatus und eine mehrstufige Freigabe einschließlich des Vier-Augen-Prinzips. | inkludiert | Go-Live Phase 1 | ||||||
| 4.3 Initiale Antragstellung | IA-10 | M | Die Lösung muss die Freigabe, Kürzung, Sperrung oder Ablehnung einzelner Finanzpositionen ermöglichen. | inkludiert | Go-Live Phase 1 | ||||||
| 4.3 Initiale Antragstellung | IA-11 | M | Die Lösung muss aus Checklisten, Entscheidungen, Kommentaren, Korrekturen, Nachforderungen und Nachlieferungen ein revisionssicheres Prüfprotokoll erstellen können. | inkludiert | Go-Live Phase 1 | ||||||
| 4.3 Initiale Antragstellung | IA-12 | K | Die Lösung kann die Erstellung der Vorhabenbeschreibung unmittelbar in der Software über strukturierte Eingabemasken einschließlich relevanter Anlagen und wiederverwendbarer Inhalte ermöglichen. | Funktionalität und Prozesspassung | Go-Live Phase 1 | ||||||
| 4.3 Initiale Antragstellung | IA-13 | M | Die Lösung muss den Vertrag oder die Vertragsanlage mit den bewilligten Finanzmitteln je Standort, Teilprojekt, Jahr und Finanzposition erzeugen beziehungsweise aktualisieren können. | inkludiert | Go-Live Phase 1 | ||||||
| 4.3 Initiale Antragstellung | IA-14 | K | Die Lösung kann den Bearbeitungsstatus für Standorte und die Geschäftsstelle nachvollziehbar darstellen. Mindestens vorzusehen sind die Status eingereicht, in Prüfung, Korrektur erforderlich, final geprüft, bewilligt und abgelehnt. | Funktionalität und Prozesspassung | Go-Live Phase 1 | ||||||
| 4.3 Initiale Antragstellung | IA-15 | M | Die Lösung muss den Upload einer GANTT- beziehungsweise Meilensteinplanung als Pflichtanlage im XLS-, XLSX- oder vergleichbaren Format und ihre eindeutige Zuordnung ermöglichen. Sie muss im fachlichen Prüf- und Freigabestrang versioniert, fachlich geprüft und bei Bedarf zur Überarbeitung zurückgegeben werden können. Ihr Vorliegen ist auf Vollständigkeit zu prüfen. | inkludiert | Go-Live Phase 1 | ||||||
| 4.4 Änderungsanträge | AA-01 | M | Die Lösung muss Standorten die Einreichung von Änderungsanträgen auf Grundlage der initial beantragten Finanzmittel ermöglichen. Dies umfasst Umwidmungen, Entsperrungen, Aufstockungen, Laufzeitanpassungen, Berufsgruppenwechsel und Zweckänderungen. Mindestens zu prüfen sind der vorhandene Ausgangsbestand, zulässige Finanzpositionen und Haushaltsjahre, Laufzeitgrenzen sowie die Verfügbarkeit der zu ändernden Mittel; bei Entsperrungen darf höchstens der aktuell gesperrt verfügbare Betrag beantragt werden. | inkludiert | Go-Live Phase 1 | ||||||
| 4.4 Änderungsanträge | AA-02 | M | Änderungsanträge müssen vorhandene Bestandsdaten referenzieren und geplante Änderungen strukturiert gegenüberstellen. Sowohl administrative (z.B. Finanzgerüst) als auch fachliche Bestandsdaten (z.B. GANTT und Meilensteinplanungen) müssen angepasst werden können. | inkludiert | Go-Live Phase 1 | ||||||
| 4.4 Änderungsanträge | AA-03 | M | Die Lösung muss die Prüfung über administrative und fachliche Checklisten unterstützen. Der Prozess muss Korrekturen des Standortes, Nachforderungen und Nachlieferungen mit Frist, Stellungnahmen der fachlichen Prüfung, die Finanzprüfung, einen Entscheidungsstatus und eine mehrstufige Freigabe einschließlich des Vier-Augen-Prinzips umfassen. | inkludiert | Go-Live Phase 1 | ||||||
| 4.4 Änderungsanträge | AA-04 | M | Die Lösung muss für jede Finanzposition beziehungsweise Änderungsposition folgende Entscheidungen ermöglichen: bewilligen, teilweise bewilligen, kürzen, sperren, ablehnen oder eine Korrektur anfordern. | inkludiert | Go-Live Phase 1 | ||||||
| 4.4 Änderungsanträge | AA-05 | K | Die Lösung kann die relevanten Finanzmittelstände nach der finalen Freigabe regelgestützt oder automatisch aktualisieren. | Funktionalität und Prozesspassung | Go-Live Phase 1 | ||||||
| 4.4 Änderungsanträge | AA-06 | M | Die Lösung muss aus Checklisten, Entscheidungen, Kommentaren, Korrekturen, Nachforderungen und Nachlieferungen ein revisionssicheres Prüfprotokoll erstellen können. | inkludiert | Go-Live Phase 1 | ||||||
| 4.4 Änderungsanträge | AA-08 | M | Die Lösung muss den Vertrag beziehungsweise die Vertragsanlage mit den bewilligten Finanzmitteln je Standort, Teilprojekt, Jahr und Finanzposition aktualisieren können. | inkludiert | Go-Live Phase 1 | ||||||
| 4.5 Zahlungsanforderungen und Bereitstellung von Abrufdaten | ZA-01 | M | Die Geschäftsstelle muss in der Lösung Zeitfenster für Zahlungsanforderungen freischalten können. Eine Freischaltung ist nur zulässig, wenn für den Standort und das Teilprojekt ein aktueller unterzeichneter Vertrag beziehungsweise eine aktuelle Vertragsanlage vorliegt und entsperrte beziehungsweise verfügbare Finanzmittel vorhanden sind. | inkludiert | Go-Live Phase 2 | ||||||
| 4.5 Zahlungsanforderungen und Bereitstellung von Abrufdaten | ZA-02 | M | Standorte können Zahlungsanforderungen je Standort, Teilprojekt, Jahr und Finanzposition einreichen. | inkludiert | Go-Live Phase 2 | ||||||
| 4.5 Zahlungsanforderungen und Bereitstellung von Abrufdaten | ZA-03 | M | Die Lösung muss Zahlungsanforderungen systemseitig auf die maximal entsperrten beziehungsweise verfügbaren Finanzmittel je Finanzposition begrenzen. | inkludiert | Go-Live Phase 2 | ||||||
| 4.5 Zahlungsanforderungen und Bereitstellung von Abrufdaten | ZA-04 | K | Die Lösung kann die Geschäftsstelle über eingereichte Zahlungsanforderungen benachrichtigen. | Funktionalität und Prozesspassung | Go-Live Phase 2 | ||||||
| 4.5 Zahlungsanforderungen und Bereitstellung von Abrufdaten | ZA-05 | M | Die Lösung muss die Prüfung und Freigabe jeder Zahlungsanforderung durch die Geschäftsstelle ermöglichen. Dabei muss mindestens das Vier-Augen-Prinzip konfigurierbar sein. | inkludiert | Go-Live Phase 2 | ||||||
| 4.5 Zahlungsanforderungen und Bereitstellung von Abrufdaten | ZA-06 | K | Die Lösung kann den Status zahlungsangeforderter beziehungsweise freigegebener Finanzmittel nach der Freigabe regelgestützt oder automatisch aktualisieren. | Funktionalität und Prozesspassung | Go-Live Phase 2 | ||||||
| 4.5 Zahlungsanforderungen und Bereitstellung von Abrufdaten | ZA-07 | M | Die Lösung muss die von der Geschäftsstelle freigegebenen Zahlungsanforderungsdaten als konsolidiertes Abrufdatenpaket je Teilprojekt exportieren. Die zugrunde liegenden standortbezogenen Einzelanforderungen müssen im Datenpaket nachvollziehbar enthalten bleiben. Die Übergabe muss systemunabhängig mindestens über CSV- oder XLSX-Dateien möglich sein. Da die Finanzsoftware des Auftraggebers erst nach dieser Vergabe ausgewählt wird, werden das konkrete Zielformat und die Feldbelegung im Einführungsprojekt abgestimmt; nach der Auswahl muss die Übergabe über ein dokumentiertes, mit der Finanzsoftware kompatibles Importformat umgesetzt werden können. Der Auftragnehmer erstellt und dokumentiert den Datenaustausch und weist die Funktionsfähigkeit anhand eines Testlaufs mit Beispieldaten nach. Die Einrichtung und der Betrieb auf Seiten der Finanzsoftware liegen in der Verantwortung des Auftraggebers. Das kompatible Importformat ist im Grundpreis enthalten. Eine direkte Herstelleranbindung wird gesondert angeboten. | inkludiert | Go-Live Phase 2 | ||||||
| 4.5 Zahlungsanforderungen und Bereitstellung von Abrufdaten | ZA-09 | K | Die Lösung kann den BNBest-Abruf M03 auf Grundlage der konsolidierten Gesamtsumme des jeweiligen Abrufvorgangs der NUM GmbH vorbefüllen oder generieren. Die erforderlichen Felder ergeben sich aus dem den Vergabeunterlagen beigefügten Formular einschließlich des Kontierungsblatts. | Funktionalität und Prozesspassung | Go-Live Phase 2 | ||||||
| 4.5 Zahlungsanforderungen und Bereitstellung von Abrufdaten | ZA-10 | M | Die Lösung muss die tatsächlich abgerufenen beziehungsweise ausgezahlten Beträge je Zahlungsanforderung und Finanzposition erfassen können, mindestens durch eine manuelle Eingabe oder durch einen Import aus der eingesetzten Finanzsoftware. | inkludiert | Go-Live Phase 2 | ||||||
| 4.6 Berichtswesen: Nachweise und fachliche Berichte | ZN-01 | M | Die Geschäftsstelle muss in der Lösung Zeitfenster für die Einreichung zahlenmäßiger Zwischen- und Verwendungsnachweise einschließlich der Beleglisten und Anlagen je Standort-Teilprojekt-Kombination und Berichtsperiode freischalten können. Die zugehörigen sachlichen Berichte werden derselben Berichtsperiode und demselben Teilprojekt zugeordnet. | inkludiert | Go-Live Phase 3 | ||||||
| 4.6 Berichtswesen: Nachweise und fachliche Berichte | ZN-02 | M | Die Lösung muss die als verwendet gemeldeten Finanzmittel je Finanzposition erfassen können. Die erfassten Verwendungen dürfen je Standort-Teilprojekt-Kombination die Summe der tatsächlich abgerufenen beziehungsweise ausgezahlten Finanzmittel des abgeschlossenen Jahres nicht überschreiten; eine Überschreitung muss systemseitig verhindert beziehungsweise als fehlerhafte Einreichung blockiert werden. | inkludiert | Go-Live Phase 3 | ||||||
| 4.6 Berichtswesen: Nachweise und fachliche Berichte | ZN-03 | M | Die vom Auftraggeber bereitgestellten AZA- und AZK-Beleglisten müssen mit ihren jeweiligen Tabellenblättern und Finanz- beziehungsweise Kostenpositionen importiert werden können. Einzelbelege sind dem richtigen Standort, Teilprojekt, Haushaltsjahr und der jeweiligen Finanz- oder Kostenposition zuzuordnen. Die Summen, Pflichtfelder und das Vorlagenformat sind bei der Übernahme zu validieren; fehlerhafte oder nicht zuordenbare Einträge sind in einem nachvollziehbaren Importbericht auszuweisen. Eine zusätzliche unmittelbare Erfassung im System kann angeboten werden. | inkludiert | Go-Live Phase 3 | ||||||
| 4.6 Berichtswesen: Nachweise und fachliche Berichte | ZN-04 | M | Die Lösung muss den Upload zahlenmäßiger Nachweise, sachlicher Berichte, Belege, Erläuterungen und weiterer Anlagen je Vorgang ermöglichen. | inkludiert | Go-Live Phase 3 | ||||||
| 4.6 Berichtswesen: Nachweise und fachliche Berichte | ZN-05 | M | Die Lösung muss die getrennte administrative Prüfung der zahlenmäßigen Nachweise und die fachliche Prüfung der sachlichen Berichte über konfigurierbare Checklisten unterstützen. Der Prozess muss Korrekturen, Nachforderungen und Nachlieferungen mit Frist, die Anerkennung oder Kürzung der Finanzmittel sowie eine mehrstufige Gesamtfreigabe einschließlich des Vier-Augen-Prinzips umfassen. | inkludiert | Go-Live Phase 3 | ||||||
| 4.6 Berichtswesen: Nachweise und fachliche Berichte | ZN-06 | M | Die Lösung muss für die administrativen und fachlichen Bestandteile revisionssichere Prüfprotokolle erstellen können. Diese müssen die finale Entscheidung, Korrekturen, Nachforderungen und Nachlieferungen umfassen. | inkludiert | Go-Live Phase 3 | ||||||
| 4.6 Berichtswesen: Nachweise und fachliche Berichte | ZN-07 | M | Die Lösung muss den Finanzierungsplan auf Grundlage der anerkannten Finanzmittel für abgeschlossene Jahre regelgestützt oder automatisch anpassen beziehungsweise kürzen können. | inkludiert | Go-Live Phase 3 | ||||||
| 4.6 Berichtswesen: Nachweise und fachliche Berichte | ZN-08 | M | Die Lösung muss ein Schluss-, Prüf-, Feststellungs- oder Anpassungsdokument erstellen und die vertraglichen Anlagen aktualisieren können. | inkludiert | Go-Live Phase 3 | ||||||
| 4.6 Berichtswesen: Nachweise und fachliche Berichte | ZN-09 | K | Die Lösung kann importierte Beleglisten automatisiert rechnerisch vorprüfen. Die Vorprüfung kann insbesondere einen Summenabgleich je Finanzposition sowie eine Dubletten- und Formatprüfung umfassen und soll Prüfhinweise für die Bearbeitung ausgeben. | Funktionalität und Prozesspassung | Go-Live Phase 3 | ||||||
| 4.6 Berichtswesen: Nachweise und fachliche Berichte | ZN-10 | M | Die Lösung muss Rückforderungen und Rückzahlungen im Nachweisprozess unterstützen und offene sowie ausgeglichene Rückforderungen je Standort und Teilprojekt ausweisen können. | inkludiert | Go-Live Phase 3 | ||||||
| 4.6 Berichtswesen: Nachweise und fachliche Berichte | ZN-11 | K | Die Lösung kann automatisierte Erinnerungen und eine Fristenüberwachung für offene Rückforderungen und ausstehende Rückzahlungen je Standort und Teilprojekt bereitstellen. | Funktionalität und Prozesspassung | Go-Live Phase 3 | ||||||
| 4.6 Berichtswesen: Nachweise und fachliche Berichte | BP-01 | M | Die Geschäftsstelle muss in der Lösung Zeitfenster für die Einreichung eigenständiger fachlicher Berichte freischalten können. Dies umfasst insbesondere Quartals- und Halbjahresberichte sowie weitere rein fachliche Berichte ohne zahlenmäßige Nachweismaske, die durch die jeweils zuständige Teilprojektleitung einschließlich des Dokumenten- und Datenuploads eingereicht werden. | inkludiert | Go-Live Phase 3 | ||||||
| 4.6 Berichtswesen: Nachweise und fachliche Berichte | BP-02 | M | Die Lösung muss die fachliche Prüfung eigenständiger Berichte über konfigurierbare Checklisten unterstützen. Der Prozess muss Korrekturen, Nachforderungen und eine konfigurierbare mehrstufige Freigabe umfassen. | inkludiert | Go-Live Phase 3 | ||||||
| 4.6 Berichtswesen: Nachweise und fachliche Berichte | BP-03 | K | Die Lösung kann für fällige fachliche Berichte je Teilprojekt und Berichtstyp Erinnerungen und eine Fristenüberwachung bereitstellen, mindestens per E-Mail-Benachrichtigung. | Funktionalität und Prozesspassung | Go-Live Phase 3 | ||||||
| 4.7 Übersichten, Cockpits und Arbeitslisten | Ü-01 | M | Die Lösung muss der Geschäftsstelle Arbeitslisten nach Vorgangstyp, Status, Frist, bearbeitender Person, Standort, Teilprojekt und Förderlinie bereitstellen. | inkludiert | Go-Live Phase 1 | ||||||
| 4.7 Übersichten, Cockpits und Arbeitslisten | Ü-02 | K | Die Lösung kann Standortnutzenden ein Dashboard mit bewilligten, gesperrten, entsperrten, zahlungsangeforderten, abgerufenen, als verwendet gemeldeten und anerkannten Finanzmitteln je Teilprojekt, Finanzposition und Jahr bereitstellen. | Funktionalität und Prozesspassung | jeweils zum zugehörigen Modul-Go-Live | ||||||
| 4.7 Übersichten, Cockpits und Arbeitslisten | Ü-03 | K | Die Lösung kann Teilprojektleitungen ein Dashboard mit allen beteiligten Standorten und den Finanzmittelständen des Teilprojekts bereitstellen. | Funktionalität und Prozesspassung | Go-Live Phase 2 | ||||||
| 4.7 Übersichten, Cockpits und Arbeitslisten | Ü-04 | K | Die Lösung kann der Geschäftsstelle ein Cockpit mit folgenden Antragsständen bereitstellen: eingereicht, in Prüfung, Korrektur erforderlich, final geprüft, bewilligt und abgelehnt. | Funktionalität und Prozesspassung | Go-Live Phase 1 | ||||||
| 4.7 Übersichten, Cockpits und Arbeitslisten | Ü-05 | K | Die Lösung kann Standortnutzenden und Teilprojektleitungen den Export der Finanzmittelübersichten in einem gängigen Format ermöglichen, mindestens als XLSX oder CSV. | Funktionalität und Prozesspassung | Go-Live Phase 2 | ||||||
| 4.7 Übersichten, Cockpits und Arbeitslisten | Ü-06 | K | Die Lösung kann einen Projekt- beziehungsweise Teilprojektsteckbrief mit aktuellen Kerninformationen bereitstellen. Dieser muss mindestens das Förderkennzeichen, das Akronym, die Kurzbeschreibung, die Laufzeit, die Projektleitung beziehungsweise wissenschaftliche Leitung, Ansprechpersonen der Projektkoordination, administrative und fachliche Hauptansprechpersonen der Geschäftsstelle, die beteiligten Standorte, die bewilligte Gesamtsumme sowie den aktuellen Finanzmittelstatus je Teilprojekt mit bewilligten, gesperrten, entsperrten, abgerufenen, als verwendet gemeldeten und anerkannten Beträgen enthalten. | Funktionalität und Prozesspassung | jeweils zum zugehörigen Modul-Go-Live | ||||||
| 4.7 Übersichten, Cockpits und Arbeitslisten | Ü-07 | M | Die Lösung muss eine Suchfunktion für Förderlinien, Teilprojekte und Standorte bereitstellen, mindestens nach Förderkennzeichen, Akronym, Standort und verantwortlicher Person. | inkludiert | Go-Live Phase 1 | ||||||
| 4.7 Übersichten, Cockpits und Arbeitslisten | Ü-09 | K | Die Lösung kann exportierbare Reports für Power BI oder vergleichbare Reportingtools bereitstellen. | Funktionalität und Prozesspassung | Go-Live Phase 4 | ||||||
| 5.1 Stammdaten- und Kontaktdatenverwaltung | ST-01 | M | Die Lösung muss zentrale Stammdaten für Förderlinien, Teilprojekte, Standorte, Finanzpositionen einschließlich der Kontierungsmerkmale nach F-03, Laufzeiten, Rollen und Vertragsstatus verwalten können. Der Vertragsstatus umfasst insbesondere unterzeichnete Verträge beziehungsweise Vertragsanlagen je Standort und Teilprojekt. Zusätzlich muss die Lösung die grundlegende Pflege der für den Förderprozess erforderlichen Ansprechpersonen mit mindestens folgenden Angaben ermöglichen: Name, Organisation beziehungsweise Standort, Rolle oder Funktion und E-Mail-Adresse. Standortstammdaten werden nach Prüfung und Freigabe durch die Geschäftsstelle übernommen. | inkludiert | Go-Live Phase 1 | ||||||
| 5.1 Stammdaten- und Kontaktdatenverwaltung | ST-02 | K | Die Lösung kann eine erweiterte projekt- und standortbezogene Kontaktverwaltung mit mehreren Kontaktpersonen je Rolle oder Funktion bereitstellen. Dies umfasst insbesondere die wissenschaftliche Leitung beziehungsweise den Principal Investigator, operative Hauptansprechpersonen, administrative Kontakte und Vertretungen. | Funktionalität und Prozesspassung | Go-Live Phase 1 | ||||||
| 5.1 Stammdaten- und Kontaktdatenverwaltung | ST-03 | K | Die Lösung kann eine erweiterte Kontaktdatenpflege mit einem Gültigkeits- beziehungsweise Aktualisierungsstatus und zusätzlichen organisatorischen Zuordnungen je Kontakt bereitstellen. | Funktionalität und Prozesspassung | Go-Live Phase 1 | ||||||
| 5.1 Stammdaten- und Kontaktdatenverwaltung | ST-04 | K | Die Lösung kann aktuelle Kontaktlisten beziehungsweise Verteiler nach Förderlinie, Teilprojekt, Standort und Rolle mindestens als XLSX oder CSV exportieren. | Funktionalität und Prozesspassung | Go-Live Phase 1 | ||||||
| 5.1 Stammdaten- und Kontaktdatenverwaltung | ST-05 | K | Die Lösung kann Änderungen an zentralen Kontaktpersonen historisieren, zum Beispiel einen Wechsel in der Koordination, bei der wissenschaftlichen Leitung beziehungsweise dem Principal Investigator oder in der administrativen Zuständigkeit. | Funktionalität und Prozesspassung | Go-Live Phase 1 | ||||||
| 5.1 Stammdaten- und Kontaktdatenverwaltung | ST-06 | M | Die Lösung muss für personenbezogene Kontaktdaten einen konfigurierbaren Lebenszyklus unterstützen. Die Daten sind auf die für den Förderprozess erforderlichen Angaben zu beschränken, müssen berichtigt und mit Gültigkeitszeiträumen versehen werden können und nach Wegfall des Zwecks sowie Ablauf der festgelegten Fristen löschbar oder anonymisierbar sein. Historisierte Kontakte müssen als nicht mehr aktuell erkennbar bleiben. | inkludiert | Go-Live Phase 1 | ||||||
| 5.2 Dokumentenablage und Versionierung | D-01 | M | Die Lösung muss Dokumente und Anlagen, insbesondere PDF-, XLS-, XLSX-, XML-, EML- und MSG-Dateien sowie gängige Office-Dateien und die zugehörigen Anlagen, vorgangsbezogen ablegen können. | inkludiert | Go-Live Phase 1 | ||||||
| 5.2 Dokumentenablage und Versionierung | D-02 | M | Dokumente müssen eindeutig einem Vorgang, einem Standort, einem Teilprojekt, einer Förderlinie, einem Dokumenttyp und einer Version zugeordnet werden können. Die Lösung muss eine konfigurierbare Aktenordnung beziehungsweise Ablagestruktur sowie einheitliche Benennungsregeln für Dokumente unterstützen. Die konkrete Aktenordnung und die Benennungsregeln werden in Phase 0 gemeinsam festgelegt und in der Lösung konfiguriert. | inkludiert | Go-Live Phase 1 | ||||||
| 5.2 Dokumentenablage und Versionierung | D-03 | M | Die Lösung muss hochgeladene und erzeugte Dokumente versionieren oder zumindest nachvollziehbar historisieren können. | inkludiert | Go-Live Phase 1 | ||||||
| 5.2 Dokumentenablage und Versionierung | D-04 | M | Erzeugte Verträge, Vertragsanlagen und Prüfprotokolle müssen unverändert wieder auffindbar sein. | inkludiert | Go-Live Phase 1 | ||||||
| 5.2 Dokumentenablage und Versionierung | D-05 | K | Die vorgesehene Ablage in einer Datenbank, in einem Dateisystem oder in einem externen DMS kann konzeptionell beschrieben werden. | Technische Architektur, Sicherheit und Datensouveränität | mit Angebotsabgabe | ||||||
| 5.2 Dokumentenablage und Versionierung | D-06 | K | Die Lösung kann eine Schnittstelle zu einem DMS bereitstellen, zum Beispiel zu Fabasoft, d.3, SharePoint oder einem vergleichbaren System. Die Übertragung muss verschlüsselt erfolgen. Rollen-, Mandanten-, Lösch- und Aufbewahrungsregeln müssen im Zielsystem fortgeführt werden. Wird das DMS vom Auftragnehmer oder einem Unterauftragnehmer betrieben, gelten die vertraglichen Datenschutz- und Sicherheitsanforderungen auch für diesen Betrieb. | Technische Architektur, Sicherheit und Datensouveränität | Go-Live Phase 4 | ||||||
| 5.2 Dokumentenablage und Versionierung | D-07 | M | Hochgeladene Dateien müssen vor Verarbeitung automatisiert auf Viren und Malware geprüft werden. Erkannte oder verdächtige Dateien sind zu blockieren oder in Quarantäne zu überführen; der Vorgang ist zu protokollieren. Die Prüfung kann durch die Lösung selbst oder durch eine vorgelagerte Komponente der Betriebsumgebung erfolgen. | inkludiert | Go-Live Phase 1 | ||||||
| 5.2 Dokumentenablage und Versionierung | D-08 | K | Die Lösung kann die Zuordnung ein- und ausgehender E-Mail-Korrespondenz durch eine besonders komfortable Funktion unterstützen, insbesondere per Drag-and-drop, über eine Mailbox-Anbindung oder über eine vergleichbare Funktion. Die Ablageentscheidung muss bewusst und rollenbasiert erfolgen; E-Mail-Dateien und Anlagen sind eindeutig einem Vorgang zuzuordnen und in das Lösch- und Aufbewahrungskonzept einzubeziehen. Die verpflichtende vorgangsbezogene Ablage richtet sich im Übrigen nach D-01 und D-02. | Funktionalität und Prozesspassung | Go-Live Phase 4 | ||||||
| 5.2 Dokumentenablage und Versionierung | D-09 | M | Die Lösung muss konfigurierbare Aufbewahrungs- und Löschfristen nach Daten- und Dokumentenkategorie unterstützen. Nach Ablauf der jeweils festgelegten Frist müssen Dokumente oder personenbezogene Angaben gezielt gelöscht, gesperrt, anonymisiert oder geschwärzt werden können, ohne die verbleibende revisionssichere Vorgangshistorie zu beeinträchtigen. Die konkreten Fristen werden durch den Auftraggeber bis zum Abschluss der Phase 0 und damit vor dem produktiven Go-Live der Phase 1 festgelegt; sie müssen durch berechtigte Administrierende änderbar sein. | inkludiert | Phase 0 | ||||||
| 5.3 Strukturierte Exporte und Datenportabilität | E-01 | M | Die Lösung muss relevante Daten mindestens als CSV oder XLSX und zusätzlich in einem strukturierten Format als XML oder JSON exportieren können. | inkludiert | jeweils zum zugehörigen Modul-Go-Live | ||||||
| 5.3 Strukturierte Exporte und Datenportabilität | E-02 | M | Der Export muss Vorgänge, Stammdaten, Finanzdaten, Statusinformationen, Dokumentmetadaten und relevante Prüfprotokolle umfassen. | inkludiert | jeweils zum zugehörigen Modul-Go-Live | ||||||
| 5.3 Strukturierte Exporte und Datenportabilität | E-03 | M | Bei Vertragsende muss ein vollständiger, maschinenlesbarer Datenexport einschließlich der Dokumente und Metadaten möglich sein, mindestens in gängigen Formaten wie CSV oder XLSX sowie zusätzlich strukturiert als XML oder JSON. | inkludiert | Go-Live Phase 1 / Vertragsende | ||||||
| 5.3 Strukturierte Exporte und Datenportabilität | E-04 | M | Audit-/Prozesshistorien müssen zumindest für prüfungsrelevante Vorgänge exportierbar oder nachvollziehbar archiviert werden können. | inkludiert | jeweils zum zugehörigen Modul-Go-Live | ||||||
| 5.3 Strukturierte Exporte und Datenportabilität | E-05 | K | Die Exporte müssen vor der Ausgabe nach definierten Kriterien filterbar sein, insbesondere nach Förderlinie, Teilprojekt, Standort, Haushaltsjahr, Vorgangstyp, Status, Finanzposition und Rolle beziehungsweise Funktion. | Funktionalität und Prozesspassung | jeweils zum zugehörigen Modul-Go-Live | ||||||
| 5.3 Strukturierte Exporte und Datenportabilität | E-06 | M | Die Lösung muss eine dokumentierte, versionierte REST-API oder eine gleichwertige offene Schnittstelle für den lesenden und schreibenden Zugriff auf definierte Datenobjekte sowie zum Auslösen freigegebener Prozessaktionen bereitstellen. Die Schnittstelle muss eine sichere Automatisierung wiederkehrender Datenübertragungen und Arbeitsabläufe ohne manuelle Doppelerfassung oder Copy-and-paste ermöglichen. Technische Identitäten müssen zweckgebunden und auf die erforderlichen Datenobjekte und Aktionen beschränkt sein. Zugangsdaten und Schlüssel sind sicher zu verwalten und regelmäßig zu wechseln; missbräuchliche Massenabfragen sind durch geeignete Begrenzungen und Überwachung zu verhindern. Unterstützt werden müssen mindestens Authentifizierung und Autorisierung, differenzierte Berechtigungen, Fehlerbehandlung, vollständige Protokollierung schreibender Zugriffe, Versionsmanagement, technische Dokumentation und eine Testmöglichkeit. Mindestens die Kernobjekte Antrag, Änderungsantrag, Zahlungsanforderung, Zwischen- beziehungsweise Verwendungsnachweis, fachlicher Bericht, Finanzposition mit Finanzmittelstand sowie Stammdaten müssen lesend und schreibend verfügbar sein; mindestens Statuswechsel und Vorgangsanlage müssen als Prozessaktionen auslösbar sein. Erweiterungen um zusätzliche Datenobjekte und Aktionen werden in Phase 0 festgelegt und über die Preisposition für optionale API-Module abgebildet. | inkludiert | Go-Live Phase 3 (Basis ab Phase 1) | ||||||
| 5.4 Datenmigration | MIG-01 | M | Der Auftragnehmer muss auf Basis anonymisierter Beispieldatensätze und Mengenangaben eine Migrationsanalyse durchführen. | inkludiert | Phase 0 | ||||||
| 5.4 Datenmigration | MIG-02 | M | Der Bieter muss ein Migrationskonzept einschließlich des Datenmappings, der Validierungsregeln, der Fehlerbehandlung und der Testmigration erstellen. | inkludiert | mit Angebotsabgabe | ||||||
| 5.4 Datenmigration | MIG-03 | M | Der Auftragnehmer muss vor der Produktivmigration eine Testmigration durchführen und einen Fehlerbericht sowie Bereinigungsempfehlungen bereitstellen. | inkludiert | Phase 0 | ||||||
| 5.4 Datenmigration | MIG-04 | M | Der Auftragnehmer muss alle zum Migrationsstichtag aktuellen fachlichen und finanziellen Werte einschließlich relevanter historischer Abrufwerte migrieren. Historische Änderungsversionen und sämtliche früheren Bearbeitungsstände der Daten sind nicht zu migrieren, sofern sie nicht für den aktuellen Datenbestand oder für gesetzliche Nachweispflichten erforderlich sind. | inkludiert | Go-Live Phase 1 | ||||||
| 5.4 Datenmigration | MIG-05 | M | Der Auftragnehmer muss den Migrationsprozess so planen, dass er mit dem laufenden Betrieb beziehungsweise einem Parallelbetrieb vereinbar ist. | inkludiert | mit Angebotsabgabe | ||||||
| 5.4 Datenmigration | MIG-06 | K | Die Lösung kann wiederkehrende Importfunktionen für Excel-, CSV- und XML-Dateien bereitstellen, sofern nach dem Go-Live regelmäßig externe Daten übernommen werden. | Vorgehensmodell, Migration und Service | Go-Live Phase 4 | ||||||
| 5.4 Datenmigration | MIG-07 | M | Migrationsdaten und Zwischenstände müssen während Übertragung und Speicherung verschlüsselt und auf den erforderlichen Personenkreis beschränkt werden. Für Analysen und Testmigrationen sind soweit möglich anonymisierte oder synthetische Daten zu verwenden. Sämtliche Migrationskopien und Zwischenstände sind nach Abschluss und Abnahme der Migration zu löschen; die Löschung ist dem Auftraggeber nachvollziehbar zu bestätigen. | inkludiert | Phase 0 bis Abnahme der Migration | ||||||
| 7.1 Datenschutz, Sicherheit und Revision | NF-01 | M | Die Lösung und die damit verbundenen Verarbeitungen müssen DSGVO-konform ausgestaltet sein. Dies umfasst insbesondere den mit den Vergabeunterlagen bereitgestellten Auftragsverarbeitungsvertrag, ein Lösch- und Aufbewahrungskonzept sowie ein Rollen- und Berechtigungskonzept. Der Bieter muss den Auftragsverarbeitungsvertrag mit Angebotsabgabe anerkennen und die vorgesehenen Angaben zu Unterauftragnehmern, Verarbeitungsorten und technischen und organisatorischen Maßnahmen vollständig ergänzen. | inkludiert | mit Angebotsabgabe | ||||||
| 7.1 Datenschutz, Sicherheit und Revision | NF-02 | M | Die Lösung muss relevante Aktionen und Entscheidungen revisionssicher protokollieren. Soweit die Protokolldaten personenbezogen sind, dürfen sie ausschließlich für Sicherheits-, Revisions- und Nachweiszwecke genutzt werden. Sie müssen gegen Veränderung und unberechtigte Löschung geschützt, nur für berechtigte Rollen zugänglich, auswertbar und nach einer konfigurierbaren Aufbewahrungsfrist löschbar sein. | inkludiert | Go-Live Phase 1 | ||||||
| 7.1 Datenschutz, Sicherheit und Revision | NF-03 | M | Die Lösung muss Berechtigungen nach dem Need-to-know-Prinzip umsetzen. Standortnutzende dürfen ausschließlich die Informationen ihrer eigenen Standorte und Projekte sehen. | inkludiert | Go-Live Phase 1 | ||||||
| 7.1 Datenschutz, Sicherheit und Revision | NF-04 | M | Die Lösung muss Daten während der Übertragung verschlüsseln und ruhende Daten nach dem aktuellen Stand der Technik schützen. | inkludiert | Go-Live Phase 1 | ||||||
| 7.1 Datenschutz, Sicherheit und Revision | NF-05 | M | Der Bieter muss mit dem Angebot eine strukturierte Beschreibung der technischen und organisatorischen Maßnahmen vorlegen. Sie muss mindestens Maßnahmen zu Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit, zur Wiederherstellung sowie zur regelmäßigen Überprüfung der Wirksamkeit abdecken. Wesentliche Änderungen während der Vertragslaufzeit sind dem Auftraggeber vorab anzuzeigen; die Beschreibung ist entsprechend aktuell zu halten. | inkludiert | mit Angebotsabgabe | ||||||
| 7.1 Datenschutz, Sicherheit und Revision | NF-07 | M | Der Auftragnehmer muss sich bereit erklären, während der Projektlaufzeit einmal einen vom Auftraggeber beauftragten unabhängigen Penetrationstest der angebotenen Lösung technisch zu ermöglichen und in einem vorab abgestimmten Umfang zu unterstützen. Zeitpunkt, Umfang, Testregeln und Mitwirkung werden vorab abgestimmt. Den externen Prüfdienstleister beauftragt und bezahlt der Auftraggeber. Etwaige gesonderte Leistungen des Auftragnehmers bedürfen einer vorherigen Beauftragung und werden auf Grundlage der vereinbarten Tagessätze vergütet. Festgestellte Schwachstellen im Verantwortungsbereich des Auftragnehmers sind nach NF-12 zu bewerten und zu behandeln. | inkludiert | im Projektverlauf nach Abstimmung | ||||||
| 7.1 Datenschutz, Sicherheit und Revision | NF-08 | M | Die Lösung muss eine Mehrfaktor-Authentifizierung unterstützen. Sie ist für privilegierte Rollen und administrative Zugriffe verpflichtend zu aktivieren. Für externe Nutzerkonten mit Schreib-, Einreichungs- oder Freigaberechten muss sie mindestens aktivierbar sein. | inkludiert | Go-Live Phase 1 | ||||||
| 7.1 Datenschutz, Sicherheit und Revision | NF-15 | K | Die Lösung kann für sämtliche Nutzergruppen eine erweiterte Mehrfaktor-Authentifizierung unterstützen, einschließlich mehrerer Faktoren beziehungsweise Passkeys und konfigurierbarer risikobasierter Authentifizierungsrichtlinien. | Technische Architektur, Sicherheit und Datensouveränität | Go-Live Phase 4 | ||||||
| 7.1 Datenschutz, Sicherheit und Revision | NF-09 | M | Die Lösung muss einen sicheren Einladungs-, Aktivierungs-, Sperr- und Deaktivierungsprozess für Nutzerkonten unterstützen. Dieser muss zeitlich begrenzte Einladungen, eine Verifikation und einen sofortigen Rechteentzug umfassen. | inkludiert | Go-Live Phase 1 | ||||||
| 7.1 Datenschutz, Sicherheit und Revision | NF-10 | M | Die Lösung muss für lokale Anmeldungen konfigurierbare Passwort- und Sitzungsregeln unterstützen. Diese müssen mindestens Vorgaben zur Passwortlänge, einen Schutz vor Brute-Force-Angriffen, Sperrregeln, eine Sitzungszeitüberschreitung und eine erneute Authentifizierung für sensible Aktionen umfassen. | inkludiert | Go-Live Phase 1 | ||||||
| 7.1 Datenschutz, Sicherheit und Revision | NF-11 | M | Der Auftragnehmer muss über einen dokumentierten Prozess für Sicherheitsvorfälle, erhebliche Sicherheitsvorfälle und Verletzungen des Schutzes personenbezogener Daten verfügen. Der Prozess muss Erkennung, Bewertung, Eindämmung, Beweissicherung, Meldung und Nachbereitung umfassen. Für Meldungen ist ein durchgehend erreichbarer Kontakt vorzuhalten. Kritische Vorfälle sind dem Auftraggeber unverzüglich, spätestens innerhalb von vier Stunden nach Bekanntwerden, zu melden. Die Erstmeldung muss mindestens Art, Zeitpunkt, betroffene Systeme und Daten, bekannte Auswirkungen, aktuelle Maßnahmen und eine Ansprechperson enthalten. Neue Erkenntnisse sind fortlaufend nachzumelden; nach Abschluss ist ein Bericht mit Ursachenanalyse und Abhilfemaßnahmen vorzulegen. Der Auftragnehmer unterstützt den Auftraggeber bei Beweissicherung, Bewertung und erforderlichen Benachrichtigungen. | inkludiert | Regelbetrieb | ||||||
| 7.1 Datenschutz, Sicherheit und Revision | NF-12 | M | Der Auftragnehmer muss über ein dokumentiertes Schwachstellen- und Patchmanagement verfügen. Neue Schwachstellen sind nach anerkannter Methodik risikobasiert zu bewerten; sicherheitsrelevante Schwachstellen mit Bezug zur angebotenen Lösung sind dem Auftraggeber mitzuteilen. Ein erreichbarer Meldeweg für externe Schwachstellenhinweise ist vorzuhalten. Dritt- und Open-Source-Komponenten sind in die Überwachung einzubeziehen. Sicherheitsupdates für kritische Risiken sind grundsätzlich innerhalb von 14 Kalendertagen und Sicherheitsupdates für hohe Risiken innerhalb von 30 Kalendertagen einzuspielen; begründete Abweichungen sind zu dokumentieren und abzustimmen. | inkludiert | Regelbetrieb | ||||||
| 7.1 Datenschutz, Sicherheit und Revision | NF-13 | M | Sicherheitsrelevante Ereignisse, fehlgeschlagene Anmeldungen, privilegierte Aktionen und Änderungen an Rollen oder Konfigurationen müssen protokolliert, überwacht und für Auswertungen bereitgestellt werden. Die Protokolle müssen gegen Manipulation und unberechtigte Löschung geschützt, nach einer abgestimmten Frist aufbewahrt und dem Auftraggeber in einem auswertbaren Format bereitgestellt werden können. | inkludiert | Go-Live Phase 1 | ||||||
| 7.1 Datenschutz, Sicherheit und Revision | NF-14 | M | Bei Vertragsende erfolgt die Löschung personenbezogener und auftragsbezogener Daten erst, nachdem der vollständige Daten- und Dokumentenexport nach E-03 bereitgestellt, durch den Auftraggeber geprüft und abgenommen wurde, soweit keine gesetzlichen Aufbewahrungspflichten entgegenstehen. Anschließend sind die Daten nach Ablauf vereinbarter Aufbewahrungsfristen vollständig zu löschen und die Löschung schriftlich zu bestätigen. Auf Weisung des Auftraggebers gelten die vereinbarten Lösch- und Aufbewahrungsregeln entsprechend. | inkludiert | Regelbetrieb / Vertragsende | ||||||
| 7.1 Datenschutz, Sicherheit und Revision | NF-16 | M | Der Bieter muss eine aktuelle und nachvollziehbare technische Dokumentation der angebotenen Lösung bereitstellen. Diese muss mindestens die System- und Softwarearchitektur, wesentliche Systemkomponenten und deren Abhängigkeiten, Datenflüsse, eingesetzte Technologien und Drittkomponenten, Integrations- und Schnittstellenarchitektur sowie die Trennung von Entwicklungs-, Test- und Produktivumgebungen beschreiben. Die Dokumentation ist während der Vertragslaufzeit bei wesentlichen Änderungen aktuell zu halten und dem Auftraggeber in einem gängigen elektronischen Format bereitzustellen. | inkludiert | mit Angebotsabgabe | ||||||
| 7.1 Datenschutz, Sicherheit und Revision | NF-17 | M | Der Bieter muss das eingesetzte Verschlüsselungskonzept vollständig und nachvollziehbar offenlegen. Dies umfasst mindestens die Verschlüsselung der Daten bei der Übertragung und im Ruhezustand, die eingesetzten kryptografischen Verfahren und Protokolle, den Schutz und die Verwaltung kryptografischer Schlüssel, Verfahren zur Schlüsselrotation beziehungsweise zum Schlüsselaustausch sowie die Verschlüsselung von Backups und Replikaten. Der Bieter hat darzustellen, welche Datenbestände und Übertragungswege jeweils verschlüsselt werden und ob kryptografische Schlüssel logisch oder technisch von den geschützten Daten getrennt verwaltet werden. Die eingesetzten Verfahren müssen dem zum Zeitpunkt der Leistungserbringung anerkannten Stand der Technik entsprechen. | inkludiert | mit Angebotsabgabe | ||||||
| 7.1 Datenschutz, Sicherheit und Revision | NF-18 | M | Der Bieter muss mit dem Angebot als Bestandteil des gemäß A.2 – Verzeichnis der einzureichenden Unterlagen vorzulegenden Betriebs- und Sicherheitskonzepts ein lösungs- und betriebsbezogenes Informationssicherheits- und Risikokonzept vorlegen. Dieses muss mindestens Schutzbedarf, wesentliche Informationswerte und Abhängigkeiten, Bedrohungen und Risiken, vorgesehene Maßnahmen, Verantwortlichkeiten, Restrisiken sowie Anlässe für eine Aktualisierung beschreiben. Das Konzept ist bei wesentlichen Änderungen und im Rahmen des regelmäßigen Risikomanagementprozesses fortzuschreiben. | inkludiert | mit Angebotsabgabe | ||||||
| 7.1 Datenschutz, Sicherheit und Revision | NF-19 | M | Der Auftragnehmer muss die Wirksamkeit der vereinbarten Sicherheitsmaßnahmen regelmäßig und anlassbezogen bewerten. Turnus und Anlässe sind risikobasiert festzulegen und im Informationssicherheits- und Risikokonzept zu beschreiben. Wesentliche Erkenntnisse aus Sicherheitsvorfällen, Schwachstellen sowie Wiederherstellungs- und Sicherheitstests sind zu berücksichtigen; erforderliche Maßnahmen sind nachzuverfolgen. Eine zusammenfassende Darstellung der Ergebnisse ist dem Auftraggeber auf Anforderung bereitzustellen. | inkludiert | Regelbetrieb | ||||||
| 7.1 Datenschutz, Sicherheit und Revision | NF-20 | M | Der Auftragnehmer darf für Entwicklung, Migration, Betrieb, Administration und Support nur entsprechend autorisiertes Personal einsetzen. Dieses Personal ist vor Tätigkeitsaufnahme auf Vertraulichkeit zu verpflichten und regelmäßig sowie anlassbezogen zu Datenschutz und Informationssicherheit zu schulen und zu sensibilisieren. Die Durchführung ist auf Anforderung nachzuweisen. | inkludiert | ab Phase 0 / fortlaufend | ||||||
| 7.1 Datenschutz, Sicherheit und Revision | NF-21 | M | Der Auftragnehmer muss einen dokumentierten sicheren Entwicklungs- und Änderungsprozess anwenden. Dieser muss Sicherheitsanforderungen, Code- und Änderungsprüfungen, die Prüfung eingesetzter Abhängigkeiten, Schwachstellentests, die Trennung von Entwicklungs-, Test- und Produktivumgebung, Freigaben vor Produktivsetzung, Rückfallmöglichkeiten und eine nachvollziehbare Dokumentation umfassen. Wesentliche sicherheitsrelevante Änderungen sind vor Produktivsetzung angemessen zu testen. | inkludiert | ab Phase 0 / fortlaufend | ||||||
| 7.2 Hosting und Betrieb | H-01 | M | Die Lösung muss webbasiert sein und über aktuelle Standardbrowser ohne lokale Spezialinstallation genutzt werden können. | inkludiert | Go-Live Phase 1 | ||||||
| 7.2 Hosting und Betrieb | H-02 | M | Produktive Daten, Backups, Replikate und sonstige dauerhafte Datenbestände werden ausschließlich in Deutschland oder im Europäischen Wirtschaftsraum gespeichert und gehostet; Datenstandorte, Verarbeitungslokationen und beteiligte Unterauftragnehmer sind vollständig offenzulegen. Eine dauerhafte Verlagerung der Datenhaltung in ein Drittland bedarf der vorherigen schriftlichen Zustimmung des Auftraggebers und ist nur zulässig, wenn die Voraussetzungen der Art. 44 ff. DSGVO erfüllt sind. Support-, Administrations- und Wartungszugriffe aus Drittstaaten werden ausschließlich nach H-11 geregelt. | inkludiert | Go-Live Phase 1 | ||||||
| 7.2 Hosting und Betrieb | H-03 | M | Der Auftragnehmer muss ein Backup-, Restore-, Notfall- und Krisenmanagementkonzept mit einem verbindlichen Recovery Time Objective von höchstens acht Stunden und einem Recovery Point Objective von höchstens 24 Stunden vorlegen. Backups sind gegen unberechtigte Veränderung und Löschung zu schützen und logisch oder technisch vom Produktivsystem zu trennen. Wiederherstellungs- und Notfallverfahren sind regelmäßig nach dem dokumentierten, risikobasierten Testplan des Auftragnehmers sowie nach wesentlichen Änderungen zu überprüfen. Ein aktueller, für die angebotene Betriebsumgebung aussagekräftiger Nachweis ist dem Auftraggeber auf Anforderung bereitzustellen. Das Krisenmanagement muss Rollen, Eskalationswege und Erreichbarkeiten benennen. | inkludiert | Go-Live Phase 1 | ||||||
| 7.2 Hosting und Betrieb | H-04 | M | Die Lösung muss eine mindestens logische Mandanten- und Berechtigungstrennung über Rollen und Objektberechtigungen gewährleisten. Dies umfasst insbesondere die wirksame Trennung der Daten der einzelnen Standorte untereinander sowie gegenüber nicht berechtigten Dritten. | inkludiert | Go-Live Phase 1 | ||||||
| 7.2 Hosting und Betrieb | H-05 | M | Hosting und technischer Betrieb der Lösung erfolgen vollständig durch den Auftragnehmer oder durch von ihm verantwortete Unterauftragnehmer. Ein Betrieb auf Infrastruktur des Auftraggebers ist nicht vorgesehen. | inkludiert | Go-Live Phase 1 | ||||||
| 7.2 Hosting und Betrieb | H-06 | K | Der Bieter kann eine zusätzliche Skalierbarkeit über die verbindliche Mindestleistung von bis zu 300 gleichzeitig aktiven Sitzungen hinaus nachweisen. Der Nachweis kann ein Konzept für Lastspitzen und wachsende Nutzer- beziehungsweise Vorgangsmengen umfassen. | Technische Architektur, Sicherheit und Datensouveränität | mit Angebotsabgabe | ||||||
| 7.2 Hosting und Betrieb | H-07 | M | Die Lösung muss rund um die Uhr eine monatliche Systemverfügbarkeit von mindestens 99,5 Prozent erreichen. Vereinbarte Wartungsfenster dürfen nur nach den festgelegten Bedingungen ausgenommen werden. | inkludiert | Regelbetrieb | ||||||
| 7.2 Hosting und Betrieb | H-08 | M | Planbare Wartungsfenster sind mindestens fünf Werktage im Voraus anzukündigen und grundsätzlich außerhalb der Geschäftszeiten 09:00-17:00 Uhr durchzuführen. Planbare Wartungsfenster dürfen insgesamt höchstens vier Stunden je Kalendermonat umfassen; darüber hinausgehende geplante Nichtverfügbarkeit wird bei der Berechnung nach H-07 als Ausfallzeit berücksichtigt. Notfallwartungen sind unverzüglich zu kommunizieren. | inkludiert | Regelbetrieb | ||||||
| 7.2 Hosting und Betrieb | H-09 | M | Der Auftragnehmer muss die Verfügbarkeit, Kapazität, Fehler und sicherheitsrelevanten Ereignisse kontinuierlich überwachen und dem Auftraggeber mindestens monatlich einen Betriebsbericht bereitstellen. Der Bericht muss zusätzlich den Schwachstellen- und Patchstand, relevante Sicherheitsvorfälle, Ergebnisse von Wiederherstellungs- und Sicherheitstests, offene Maßnahmen sowie wesentliche Änderungen bei Unterauftragnehmern und kritischen Drittkomponenten enthalten. | inkludiert | Regelbetrieb | ||||||
| 7.2 Hosting und Betrieb | H-10 | M | Der Bieter muss im Betriebskonzept verbindlich offenlegen: Staat der Unternehmenskontrolle, Staaten der Support-, Administrations- und Wartungszugriffe, sämtliche Unterauftragnehmer und deren Sitz beziehungsweise Verarbeitungsorte sowie mögliche Anwendbarkeit von Drittstaatenrecht oder Zugriffsrechten außereuropäischer Behörden. Änderungen sind vorab anzuzeigen. | inkludiert | mit Angebotsabgabe | ||||||
| 7.2 Hosting und Betrieb | H-11 | M | Support-, Administrations- und Wartungszugriffe aus Staaten außerhalb des EWR sind nur nach vorheriger schriftlicher Zustimmung des Auftraggebers zulässig. Sie sind auf den für den jeweiligen Zweck erforderlichen Zeitraum und Datenumfang zu beschränken, müssen personenbezogen beziehungsweise einer eindeutig identifizierbaren technischen Identität zugeordnet, zweckgebunden und revisionssicher protokolliert werden. Der Auftragnehmer muss vor dem Zugriff die einschlägige Transfergrundlage und die erforderlichen ergänzenden Schutzmaßnahmen dokumentieren und dem Auftraggeber auf Anforderung nachweisen. Eine dauerhafte Speicherung oder Kopie produktiver Daten in einem Drittstaat ist hierdurch nicht gestattet. | inkludiert | Regelbetrieb | ||||||
| 7.2 Hosting und Betrieb | H-12 | M | Entfällt die Grundlage für eine Übermittlung in ein Drittland oder wird sie ausgesetzt, insbesondere durch Wegfall oder Aussetzung eines Angemessenheitsbeschlusses, muss der Auftragnehmer die betroffene Verarbeitung innerhalb von drei Monaten nach Aufforderung auf eine ausschließlich im Europäischen Wirtschaftsraum erbrachte Leistung umstellen. Zusätzliche Kosten entstehen dem Auftraggeber dadurch nicht. | inkludiert | Regelbetrieb | ||||||
| 7.2 Hosting und Betrieb | H-13 | M | Der Auftragnehmer muss ein verbindliches Service Level Agreement (SLA) mit mindestens folgenden Regelungen bereitstellen: Verfügbarkeit gemäß H-07, definierte Reaktions- und Wiederherstellungszeiten für Störungen nach Prioritätsklassen, Supportzeiten und Erreichbarkeit, Eskalationsverfahren, geplante Wartungsfenster sowie Verfahren zur Messung und zum regelmäßigen Nachweis der vereinbarten Service Levels. Die Messmethodik, die Einstufung von Störungen und die Berechnung der Verfügbarkeit sind transparent zu dokumentieren. Abweichungen von den vereinbarten Service Levels sind dem Auftraggeber nachvollziehbar zu berichten. | inkludiert | mit Angebotsabgabe | ||||||
| 7.2 Hosting und Betrieb | H-14 | M | Der Auftragnehmer muss einen dokumentierten Auswahl-, Prüf- und Überwachungsprozess für Unterauftragnehmer sowie wesentliche Dritt- und Open-Source-Komponenten vorhalten. Unterauftragnehmer sind vertraglich auf ein gleichwertiges Datenschutz- und Sicherheitsniveau einschließlich Meldepflichten zu verpflichten. Der Auftraggeber ist vor wesentlichen Änderungen sowie unverzüglich über sicherheitsrelevante Vorfälle in der Lieferkette zu informieren. Ein aktuelles Verzeichnis der Unterauftragnehmer und wesentlichen Komponenten ist bereitzustellen. | inkludiert | mit Angebotsabgabe / fortlaufend | ||||||
| 7.3 Usability und Barrierearmut | UX-01 | M | Die Lösung muss für interne und externe Nutzergruppen eine durchgängig deutschsprachige Benutzeroberfläche bereitstellen. | inkludiert | Go-Live Phase 1 | ||||||
| 7.3 Usability und Barrierearmut | UX-02 | K | Die Lösung kann bei unvollständigen Einreichungen von Anträgen, Zahlungsanforderungen und Nachweisen klare Statusanzeigen, Validierungshinweise und Fehlermeldungen bereitstellen. | Funktionalität und Prozesspassung | jeweils zum zugehörigen Modul-Go-Live | ||||||
| 7.3 Usability und Barrierearmut | UX-03 | M | Die Lösung muss Such-, Filter- und Sortierfunktionen für Vorgänge, Standorte, Teilprojekte, Dokumente und Arbeitslisten bereitstellen. | inkludiert | jeweils zum zugehörigen Modul-Go-Live | ||||||
| 7.3 Usability und Barrierearmut | UX-04 | K | Die Lösung kann barrierearm und an den Anforderungen der BITV beziehungsweise WCAG orientiert gestaltet sein. | Funktionalität und Prozesspassung | Go-Live Phase 1 | ||||||
| 7.3 Usability und Barrierearmut | UX-05 | K | Die Lösung kann Hilfetexte, Tooltips und prozessbezogene Erläuterungen direkt in den Formularen bereitstellen. | Funktionalität und Prozesspassung | Go-Live Phase 1 | ||||||
| 7.3 Usability und Barrierearmut | UX-06 | K | Die Lösung kann die gleichzeitige Bearbeitung desselben Vorgangs durch mehrere berechtigte Personen ermöglichen, ohne dass sich deren Eingaben gegenseitig überschreiben. Hierfür kann eine Konflikterkennung beziehungsweise eine Sperr- und Hinweislogik eingesetzt werden. | Funktionalität und Prozesspassung | Go-Live Phase 1 | ||||||
| 8.1 Support und Wartung | SUP-01 | M | Der Auftragnehmer muss an Werktagen mindestens während der Geschäftszeiten von 09:00 bis 17:00 Uhr einen deutschsprachigen Support bereitstellen. | inkludiert | Regelbetrieb | ||||||
| 8.1 Support und Wartung | SUP-02 | M | Der Auftragnehmer muss ein Supportmodell mit Ansprechpersonen, Eskalationswegen und Reaktionszeiten bereitstellen. Für eine kritische Störung gilt eine Reaktionszeit von höchstens vier Stunden, für eine Störung mit hoher Priorität von höchstens einem Arbeitstag und für eine normale Anfrage von höchstens drei Arbeitstagen. Die Reaktionsfristen werden innerhalb der Supportzeiten nach SUP-01 berechnet; bei einem Eingang außerhalb der Supportzeiten beginnt die Frist mit dem nächsten Supportzeitfenster. Für sicherheitsrelevante Vorfälle gilt unabhängig davon die Meldefrist nach NF-11; hierfür muss ein durchgehend erreichbarer Melde- und Eskalationsweg bestehen. | inkludiert | Regelbetrieb | ||||||
| 8.1 Support und Wartung | SUP-03 | M | Der Auftragnehmer muss die regelmäßige Wartung, die Bereitstellung von Sicherheitsupdates und die Fehlerbehebung sicherstellen. | inkludiert | Regelbetrieb | ||||||
| 8.1 Support und Wartung | SUP-04 | M | Der Auftragnehmer muss dokumentierte Release- und Änderungsprozesse vorsehen und den Auftraggeber vor relevanten Änderungen informieren. | inkludiert | Regelbetrieb | ||||||
| 8.1 Support und Wartung | SUP-05 | M | Der Auftragnehmer muss eine von der Produktion getrennte, nichtproduktive Test- beziehungsweise Staging-Umgebung für neue Releases, Konfigurationsänderungen, Testmigrationen und Abnahmen bereitstellen. Produktive personenbezogene Daten dürfen in dieser Umgebung nicht verwendet werden; erforderliche Testdaten sind zu anonymisieren oder synthetisch bereitzustellen. | inkludiert | Phase 0 | ||||||
| 8.1 Support und Wartung | SUP-06 | K | Der Auftragnehmer kann eine zusätzliche Schulungsumgebung bereitstellen, die von der Test- und der Produktionsumgebung getrennt ist. Produktive personenbezogene Daten dürfen in dieser Umgebung nicht verwendet werden; Schulungsdaten sind zu anonymisieren oder synthetisch bereitzustellen. | Vorgehensmodell, Migration und Service | Phase 0 | ||||||
| 8.2 Schulung und Befähigung | SCH-01 | M | Der Auftragnehmer muss die Geschäftsstelle vor dem jeweiligen Modul-Go-Live in der Nutzung, Prüfung, Freigabe, Auswertung und Vertragserstellung schulen. | inkludiert | jeweils vor Modul-Go-Live | ||||||
| 8.2 Schulung und Befähigung | SCH-02 | M | Der Auftragnehmer muss administrative Nutzende in der Benutzerverwaltung, Rollenpflege und Stammdatenpflege schulen. | inkludiert | Go-Live Phase 1 | ||||||
| 8.2 Schulung und Befähigung | SCH-04 | M | Der Auftragnehmer muss für interne Nutzende eine Anwenderdokumentation und Kurzanleitungen bereitstellen. | inkludiert | jeweils vor Modul-Go-Live | ||||||
| 8.2 Schulung und Befähigung | SCH-05 | K | Der Auftragnehmer kann für die Geschäftsstelle, die Standorte und die Teilprojektleitungen Benutzermanuals oder Kurzanleitungen bereitstellen. | Vorgehensmodell, Migration und Service | jeweils vor Modul-Go-Live | ||||||
| 8.2 Schulung und Befähigung | SCH-06 | K | Der Auftragnehmer kann die Geschäftsstelle im erweiterten Customizing von Formularen, Workflows, Checklisten, Auswertungen und Dokumentvorlagen schulen. | Vorgehensmodell, Migration und Service | Go-Live Phase 4 | ||||||
| 8.3 Customizing und spätere Anpassbarkeit | C-01 | M | Der Bieter muss verbindlich darlegen, welche Anpassungen ohne Programmierung, welche per Konfiguration und welche ausschließlich durch Softwareentwicklung möglich sind. | inkludiert | mit Angebotsabgabe | ||||||
| 8.3 Customizing und spätere Anpassbarkeit | C-02 | M | Formulare, Checklisten, Statuswerte, Prüfworkflows, Dokumentvorlagen, Aufbewahrungs- und Löschfristen sowie Berechtigungsprofile müssen im Projektverlauf konfigurierbar und anpassbar sein. | inkludiert | jeweils zum zugehörigen Modul-Go-Live | ||||||
| 8.3 Customizing und spätere Anpassbarkeit | C-03 | M | Konfigurations- und Prozessänderungen müssen rollenbasiert vorgenommen, versioniert, dokumentiert, in einer nichtproduktiven Umgebung getestet und vor Produktivsetzung freigegeben werden. Eine Wiederherstellung des vorherigen Stands muss möglich sein. | inkludiert | Phase 0 | ||||||
| 8.3 Customizing und spätere Anpassbarkeit | C-04 | M | Der Auftraggeber muss nach Schulung grundlegende administrative Anpassungen selbst durchführen können. Dies umfasst mindestens Benutzer- und Rollenpflege, Stammdatenpflege, Aufbewahrungs- und Löschfristen, Berechtigungsprofile sowie die Pflege ausgewählter Parameter, Vorlagen, Hilfetexte und Wertelisten. Für diese Tätigkeiten darf keine regelmäßige Bieterunterstützung erforderlich sein. | inkludiert | Go-Live Phase 1 | ||||||
| 8.3 Customizing und spätere Anpassbarkeit | C-05 | K | Der Auftraggeber kann nach erweiterter Schulung weitergehende Anpassungen an Formularen, Checklisten, Auswertungen oder Workflows selbst durchführen. | Vorgehensmodell, Migration und Service | Go-Live Phase 4 | ||||||
| 8.3 Customizing und spätere Anpassbarkeit | C-06 | M | Für zusätzliche Konfigurationsleistungen wird in C.5 – Preisblatt eine Schätzmenge von 30 Personentagen angesetzt. Der Auftraggeber ruft diese Leistungen in den Phasen 0 bis 4 nach Bedarf und eigener Priorisierung ab, insbesondere für Formulare, Checklisten, Prüfworkflows, Statuswerte, Dokumentvorlagen, Auswertungen und Berechtigungsprofile. Abgerechnet werden ausschließlich die tatsächlich abgerufenen und erbrachten Personentage; aus der Schätzmenge folgt keine Abnahmeverpflichtung. | inkludiert | mit Angebotsabgabe | ||||||
| 8.3 Customizing und spätere Anpassbarkeit | C-07 | M | Für die zusätzlichen Konfigurationsleistungen nach C-06 sowie für Entwicklung, Beratung und Schulung sind in C.5 – Preisblatt verbindliche Tagessätze anzugeben. Sie gelten unverändert für die dreijährige Grundlaufzeit; ein Personentag umfasst acht Stunden. Anpassungen, die nach der gemäß A.2 einzureichenden Customizing-Matrix durch Konfiguration möglich sind, dürfen nicht als Entwicklungsleistung abgerechnet werden. | inkludiert | mit Angebotsabgabe | ||||||
| 9. Vorgehensmodell und gestaffelter Go-Live | P-01 | M | Der Bieter muss einen Projektplan mit Meilensteinen, Abhängigkeiten, Mitwirkungspflichten, Entscheidungszeitpunkten, Kosten je Phase und Jahr sowie dem erforderlichen personellen Mitwirkungsumfang des Auftraggebers bereitstellen. | inkludiert | mit Angebotsabgabe | ||||||
| 9. Vorgehensmodell und gestaffelter Go-Live | P-02 | M | Die gestaffelte Einführung nach den genannten Phasen muss möglich sein. Abweichungen sind im Angebot ausdrücklich zu benennen und zu begründen und bedürfen der Zustimmung des Auftraggebers. | inkludiert | mit Angebotsabgabe | ||||||
| 9. Vorgehensmodell und gestaffelter Go-Live | P-03 | M | Der Auftragnehmer muss die relevanten Nutzergruppen vor jedem produktiven Modulstart schulen. | inkludiert | jeweils vor Modul-Go-Live | ||||||
| 9. Vorgehensmodell und gestaffelter Go-Live | P-04 | M | Der Bieter muss Risiken der Migration und des Parallelbetriebs darstellen. | inkludiert | mit Angebotsabgabe | ||||||
| 9. Vorgehensmodell und gestaffelter Go-Live | P-05 | M | Die für die jeweilige Phase fälligen Muss-Kriterien und sonstigen ausdrücklich als verbindlich bezeichneten Mindestinhalte müssen vollständig erfüllt sein und dienen als Abnahmegrundlage vor dem jeweiligen Go-Live. Für Phasen mit produktivem Go-Live setzt die Abnahme zusätzlich voraus, dass die jeweils produktiv zu setzenden Kernprozesse in der vorgesehenen Rollen- und Berechtigungskonstellation vollständig von der Einreichung bis zum Abschluss durchgespielt, dokumentiert und durch den Auftraggeber freigegeben wurden. Kann-Leistungen sind nur dann Abnahmebestandteil, wenn sie verbindlich angeboten und beauftragt wurden. | inkludiert | jeweils zum Phasen-Go-Live |
Bewertungshinweise
| Unnamed: 0 | Unnamed: 1 | Unnamed: 2 | Unnamed: 3 |
|---|---|---|---|
| Bewertungshinweise | |||
| Bewertungshinweise | |||
| Stand vom 04.09.2026 | |||
| Zuschlagskriterien und Bewertung | |||
| Kriterium | Gewichtung | Hinweis | |
| Funktionalität und Prozesspassung | 0.25 | 31 zugeordnete Kann-Kriterien; jeweils 0 bis 5 Punkte; maximal 155 Rohpunkte | |
| Demo, Usability und Rollenansichten | 0.1 | Sechs gleich gewichtete Demo-Dimensionen; jeweils 0 bis 5 Punkte; maximal 30 Rohpunkte | |
| Technische Architektur, Sicherheit und Datensouveränität | 0.2 | 5 zugeordnete Kann-Kriterien (R-06, D-05, D-06, NF-15 und H-06); jeweils 0 bis 5 Punkte; maximal 25 Rohpunkte. Die übrigen technischen und sicherheitsbezogenen Muss-Kriterien werden nicht bepunktet | |
| Vorgehensmodell, Migration und Service | 0.15 | 5 zugeordnete Kann-Kriterien (MIG-06, SUP-06, SCH-05, SCH-06 und C-05); jeweils 0 bis 5 Punkte; maximal 25 Rohpunkte. Die erreichten Rohpunkte werden in maximal 5 Wertungspunkte umgerechnet. Zusätzlich werden vier gleich gewichtete Konzeptdimensionen mit jeweils 0 bis 5 Punkten bewertet; maximal 20 Rohpunkte. Diese werden in maximal 10 Wertungspunkte umgerechnet. Das Zuschlagskriterium „Vorgehensmodell, Migration und Service“ umfasst damit insgesamt maximal 15 Wertungspunkte. | |
| Preis und Gesamtbetriebskosten | 0.3 | Wertungspreis gemäß C.5 – Preisblatt; maximal 30 Wertungspunkte | |
| Teilbereich | Berechnung | Erläuterung | |
| Funktionalität und Prozesspassung | Summe der erreichten Rohpunkte ÷ 155 × 25 | 31 Kann-Kriterien × maximal 5 Punkte = maximal 155 Rohpunkte | |
| Technische Architektur, Sicherheit und Datensouveränität | Summe der erreichten Rohpunkte ÷ 25 × 20 | 5 Kann-Kriterien × maximal 5 Punkte = maximal 25 Rohpunkte | |
| Vorgehensmodell – Kann-Anteil | Summe der erreichten Rohpunkte ÷ 25 × 5 | 5 Kann-Kriterien × maximal 5 Punkte = maximal 25 Rohpunkte | |
| Vorgehensmodell – Konzeptanteil | Summe der vier Konzeptpunkte ÷ 20 × 10 | 4 Konzeptdimensionen × maximal 5 Punkte = maximal 20 Rohpunkte | |
| Demo | Summe der sechs Demo-Punkte ÷ 30 × 10 | 6 Demo-Dimensionen × maximal 5 Punkte = maximal 30 Rohpunkte; jede Dimension geht mit einem Sechstel in die Demo-Wertung ein | |
| Preis | 30 × niedrigster Wertungspreis ÷ Wertungspreis des jeweiligen Angebots | Das Angebot mit dem niedrigsten Wertungspreis erhält 30 Wertungspunkte | |
| Wertungspreis | Sämtliche einmaligen und laufenden Kosten der dreijährigen Grundlaufzeit ab produktivem Go-Live der Phase 1, die Kosten des einmaligen Optionsjahres, die Nettopreise aller bepunkteten optionalen Leistungen sowie die vorgegebenen Bewertungsmengen für Einheitspreise und Tagessätze | Maßgeblich sind die Preisangaben und Berechnungsvorgaben in C.5 – Preisblatt | |
| Tagessätze | 30 Personentage für zusätzliche Konfiguration sowie je zehn Personentage für Entwicklung, Beratung und Schulung | Die Bewertungsmengen dienen ausschließlich der Angebotswertung und begründen keine Abnahmepflicht | |
| Gesamtwertung | Summe der gewichteten Teilergebnisse | Maximal 100 Wertungspunkte | |
| Rundung | Kaufmännische Rundung auf zwei Nachkommastellen | Die Rundung erfolgt bei den gewichteten Teilergebnissen und bei der Gesamtpunktzahl, soweit nicht ausdrücklich anders geregelt | |
| Verbindliche Bewertungsskala für Kann-Kriterien | |||
| Punkte | Erfüllungsgrad | Bewertungslogik | |
| 0 | Nicht angeboten / nicht erfüllt | Das Kann-Kriterium wird nicht erfüllt, nicht verbindlich angeboten oder nur unverbindlich in Aussicht gestellt | |
| 1 | Verbindlich angeboten / Nachweis unklar | Die Leistung wird verbindlich angeboten, Umsetzungsweg oder Nachweis bleiben jedoch wesentlich unklar | |
| 2 | Bepreiste Entwicklung | Die Leistung wird bis zum ausgewiesenen Erfüllungszeitpunkt verbindlich als bepreiste Entwicklung angeboten | |
| 3 | Konfigurierbar | Die Leistung ist mit vorhandenen Konfigurationsmitteln umsetzbar | |
| 4 | Im Standard vorhanden | Die Leistung ist in der angebotenen Lösung vorhanden und wird nachvollziehbar nachgewiesen | |
| 5 | Im Standard qualitativ besonders überzeugend | In der angebotenen Lösung im Standard vorhanden, erfüllt die Anforderung vollständig und weist nachvollziehbare, unmittelbar auf das jeweilige Kriterium bezogene Zusatzqualität über die Mindestanforderung hinaus auf. Die Zusatzqualität ist durch die Produkt- oder Administrationsdokumentation, eine vergleichbare Referenz oder – soweit geeignet – durch die klickbare Demo zu belegen. Die Demo kann als Nachweismittel dienen; die Qualität der Demonstration wird ausschließlich im gesonderten Demo-Kriterium bepunktet | |
| Bewertungsskala für die Demo-Dimensionen | |||
| Punkte | Bewertung | Hinweis | |
| 0 | nicht gezeigt beziehungsweise nicht nutzbar | ||
| 1 | nur ansatzweise nachvollziehbar | ||
| 2 | teilweise überzeugend mit wesentlichen Einschränkungen | ||
| 3 | Anforderungen insgesamt nachvollziehbar erfüllt | ||
| 4 | gut und belastbar umgesetzt | ||
| 5 | besonders überzeugend, konsistent und ohne wesentliche Einschränkungen demonstriert |
Demo-Bewertungsmatrix
| Unnamed: 0 | Unnamed: 1 | Unnamed: 2 | Unnamed: 3 | Unnamed: 4 |
|---|---|---|---|---|
| Demo-Bewertungsmatrix | ||||
| Demo-Bewertungsmatrix | ||||
| Stand vom 04.09.2026 | ||||
| Verbindliche Demo-Bewertungsmatrix | ||||
| Die Demo wird nach Ablauf der Angebotsfrist mit allen Bietern durchgeführt, deren Angebote nach der formalen und der Eignungsprüfung weiter in der Wertung bleiben und die Muss-Kriterien verbindlich zugesagt haben. | ||||
| Bewertungsdimension | Anteil am Demo-Kriterium | Anteil an der Gesamtwertung | Verbindliche Beobachtungspunkte | |
| Prozesspassung | 1/6 | 0.016667 | Förderprozess wird vom Antrag bis zur Entscheidung plausibel und ohne sachfremde Umwege gezeigt; Statuswechsel, Prüfungen, Korrekturen und Finanzwirkungen greifen nachvollziehbar ineinander | |
| Bedienbarkeit | 1/6 | 0.016667 | Navigation, Aufgaben, Status, Validierungen und Fehlermeldungen sind für fachliche Nutzende verständlich; wesentliche Schritte sind ohne technische Spezialkenntnisse ausführbar | |
| Rollenlogik | 1/6 | 0.016667 | Rollen- und objektbezogene Sichten sind klar getrennt; Standort, Teilprojektleitung, Prüfung, Qualitätssicherung und Administration erhalten passende Zugriffe und Freigabemöglichkeiten | |
| Nachvollziehbarkeit | 1/6 | 0.016667 | Entscheidungen, Änderungen, Korrekturen, Dokumentversionen und verantwortliche Personen sind im Vorgang und Auditlog nachvollziehbar | |
| Anpassbarkeit | 1/6 | 0.016667 | Formulare, Checklisten oder Statuswerte werden in einer nichtproduktiven Umgebung geändert, getestet, versioniert, freigegeben und bei Bedarf zurückgesetzt; Konfiguration und Entwicklung werden klar abgegrenzt | |
| Integrationsfähigkeit | 1/6 | 0.016667 | Exporte, Importe, die systemunabhängige Bereitstellung der Abrufdaten, das Konzept für die spätere Übergabe an die Finanzsoftware und die API-Automatisierung werden konkret gezeigt oder technisch nachvollziehbar beschrieben | |
| Punkteskala | ||||
| Punkte | Bewertungsanker | Anwendung | Hinweis | |
| 0 | nicht gezeigt oder nicht nutzbar | Die Dimension ist nicht bewertbar oder die gezeigte Lösung erfüllt die Erwartung nicht | ||
| 1 | nur ansatzweise nachvollziehbar | Einzelne Ansätze sind erkennbar, wesentliche Bestandteile fehlen oder bleiben nur behauptet | ||
| 2 | teilweise überzeugend mit wesentlichen Einschränkungen | Die Erwartung wird nur teilweise gezeigt; erhebliche manuelle Umwege, Lücken oder Einschränkungen bleiben | ||
| 3 | insgesamt nachvollziehbar erfüllt | Die Erwartung wird im Wesentlichen erfüllt; einzelne Schwächen beeinträchtigen die Nutzbarkeit nicht wesentlich | ||
| 4 | gut und belastbar umgesetzt | Die Erwartung wird vollständig, klar und praxistauglich gezeigt; nur geringfügige Schwächen bleiben | ||
| 5 | besonders überzeugend | Die Erwartung wird vollständig und konsistent erfüllt und weist eine unmittelbar nutzbare Zusatzqualität ohne wesentliche Einschränkungen auf | ||
| Bewertungsregel | ||||
| Einzelwertung | Jede Dimension wird separat mit 0 bis 5 Punkten bewertet | |||
| Spätere Entwicklung | Ist eine verbindlich angebotene Kann-Leistung noch nicht produktiv demonstrierbar, sind Umsetzungskonzept, geplante Nutzerführung und technische Darstellung zu zeigen. Bewertet wird ausschließlich die Qualität und Nachvollziehbarkeit dieser Ersatzdarstellung; eine zusätzliche Abwertung allein wegen fehlender Produktreife erfolgt nicht | |||
| Nicht angebotene Kann-Leistung | Adressiert das Demo-Drehbuch ein Kann-Kriterium, das ein Bieter nicht anbietet, führt dessen Fehlen in der Demo nicht zu einer zusätzlichen Abwertung; die funktionale Erfüllung wird ausschließlich in der Kann-Wertung berücksichtigt | |||
| Rückfragen | Verständnisfragen werden dokumentiert. Ablauf und Kernfragen bleiben für alle Bieter gleich | |||
| Dokumentation der Bewertung | ||||
| Wertungsgremium | Jede Dimension wird von den Mitgliedern des Wertungsgremiums einzeln bewertet und kurz begründet. Bei mehreren Wertenden wird je Dimension der arithmetische Mittelwert der Einzelbewertungen gebildet und auf zwei Nachkommastellen gerundet |
Konzeptbewertungsmatrix
| Unnamed: 0 | Unnamed: 1 | Unnamed: 2 | Unnamed: 3 | Unnamed: 4 |
|---|---|---|---|---|
| Konzeptbewertungsmatrix | ||||
| Konzeptbewertungsmatrix | ||||
| Stand vom 04.09.2026 | ||||
| Verbindliche Konzeptbewertungsmatrix | ||||
| Bewertet werden ausschließlich das Migrationskonzept sowie der Umsetzungs-, Kosten- und Schulungsplan gemäß A.2. Sie bilden maximal zehn Wertungspunkte des Zuschlagskriteriums „Vorgehensmodell, Migration und Service“. Die Bewertung erfolgt nicht dokumentenbezogen, sondern dimensionsbezogen: Für jede der vier Bewertungsdimensionen werden sämtliche einschlägigen Angaben aus dem Migrationskonzept und dem Umsetzungs-, Kosten- und Schulungsplan gemeinsam betrachtet und mit 0 bis 5 Rohpunkten bewertet. Eine gesonderte Punktzahl je Unterlage wird nicht vergeben; die Summe der vier Dimensionsbewertungen wird nach der veröffentlichten Berechnungsformel in maximal zehn Wertungspunkte umgerechnet. Das Betriebs- und Sicherheitskonzept, das Schnittstellen- und Exportkonzept, die Customizing-Matrix und die Rollenmatrix dienen als verbindliche Nachweisunterlagen für die angebotene Leistung und werden weder als eigenständige Konzeptdimensionen noch gesondert bepunktet. Die Demo-Zuordnung dient der Vorbereitung und strukturierten Durchführung der gesonderten Demo-Wertung; sie erhält ebenfalls keine eigenständige Punktzahl. Die verbindlichen Mindestinhalte, Gliederungsvorgaben und Seitenlimits der einzureichenden Unterlagen ergeben sich aus A.2 – Verzeichnis der einzureichenden Unterlagen. | ||||
| Bewertungsdimension | Anteil an der Konzeptwertung | Anteil an der Gesamtwertung | Verbindliche Beobachtungspunkte | |
| Projektplan, Phasen und Umsetzbarkeit | 1/4 | 0.025 | Meilensteine, Abhängigkeiten, Entscheidungszeitpunkte, Ressourcen und Abnahmen sind realistisch, vollständig und auf Phase 0 sowie die vier Go-Live-Phasen abgestimmt | |
| Migration, Datenqualität und Parallelbetrieb | 1/4 | 0.025 | Datenmapping, Validierung, Testmigration, Fehlerbehandlung, Bereinigung, Cutover und Parallelbetrieb sind konkret und für die bereitgestellten Datenbestände nachvollziehbar beschrieben | |
| Schulung, Go-Live und Mitwirkung | 1/4 | 0.025 | Zielgruppen, Formate, Unterlagen, Zeitpunkte, Go-Live-Unterstützung und erforderliche Mitwirkung des Auftraggebers sind nachvollziehbar und realistisch geplant | |
| Risiko-, Qualitäts- und Projektsteuerung | 1/4 | 0.025 | Risiken, Qualitätssicherung, Eskalations- und Entscheidungswege, Änderungssteuerung und Berichterstattung sind konkret auf das Vorhaben zugeschnitten | |
| Punkteskala | ||||
| Punkte | Bewertungsanker | Anwendung | Hinweis | |
| 0 | nicht oder nicht verwertbar dargestellt | Die Dimension fehlt oder enthält keine belastbare Grundlage für die Umsetzung | ||
| 1 | nur ansatzweise nachvollziehbar | Einzelne Ansätze sind erkennbar; wesentliche Inhalte, Zuständigkeiten oder Abhängigkeiten bleiben offen | ||
| 2 | teilweise überzeugend mit wesentlichen Lücken | Die Dimension ist grundsätzlich beschrieben, weist aber erhebliche fachliche, zeitliche oder organisatorische Lücken auf | ||
| 3 | insgesamt nachvollziehbar erfüllt | Die Dimension ist schlüssig und umsetzbar dargestellt; einzelne Schwächen beeinträchtigen die Gesamtumsetzung nicht wesentlich | ||
| 4 | gut und belastbar ausgearbeitet | Die Dimension ist vollständig, konkret, realistisch und auf die Anforderungen des NUM zugeschnitten | ||
| 5 | besonders überzeugend | Die Dimension ist vollständig und konsistent ausgearbeitet und bietet eine unmittelbar nutzbare Zusatzqualität über die Anforderungen hinaus | ||
| Bewertungsregel | ||||
| Einzelwertung | Jede Dimension wird separat mit 0 bis 5 Punkten bewertet | |||
| Gesamtergebnis | Summe der vier Konzeptpunkte / 20 × 10 | |||
| Wertungsgremium | Jede Dimension wird von den Mitgliedern des Wertungsgremiums einzeln bewertet und kurz begründet. Bei mehreren Wertenden wird je Dimension der arithmetische Mittelwert der Einzelbewertungen gebildet und auf zwei Nachkommastellen gerundet | |||
| Anwendung der Bewertungsdimensionen | Erläuterung | |||
| Die zu jeder Bewertungsdimension aufgeführten Beobachtungspunkte erläutern, welche Inhalte das Wertungsgremium bei der Bewertung dieser Dimension berücksichtigt. Sie werden nicht als selbstständige Unterkriterien einzeln bepunktet oder gewichtet. Vielmehr wird für jede Bewertungsdimension anhand der veröffentlichten Bewertungsskala eine zusammenfassende Bewertung zwischen 0 und 5 Rohpunkten vergeben. Hierbei werden sämtliche für die jeweilige Bewertungsdimension relevanten Angaben aus dem Migrationskonzept und dem Umsetzungs-, Kosten- und Schulungsplan gemeinsam betrachtet. Maßgeblich ist, in welchem Umfang und in welcher Qualität die aufgeführten Beobachtungspunkte insgesamt nachvollziehbar behandelt werden. Fehlende, lediglich pauschale oder widersprüchliche Angaben fließen nach Maßgabe der veröffentlichten Bewertungsanker in die Gesamtbewertung der jeweiligen Dimension ein. Eine gesonderte Bewertung der einzelnen Beobachtungspunkte oder der beiden Unterlagen erfolgt nicht. |