C.2_NUM_FMM_Leistungsbeschreibung_V2_19.pdf

[Seite 1]

.

C.2 – Leistungsbeschreibung

Fördermittelmanagement-Software (FMM) für die Netzwerk

Universitätsmedizin NUM GmbH

Version 2.19 · Stand: 04.09.2026

[Seite 2]

Inhalt

1. Zielbild und Beschaffungsgegenstand ....................................................................... 1

2. Ausgangslage und Kontext ...................................................................................... 2

2.1 Mengen- und Nutzergerüst (Kalkulationsszenario).................................................. 5

3. Nutzergruppen, Rollen und Berechtigungen .............................................................. 5

4. Zielprozesse und funktionale Anforderungen ............................................................ 8

4.1 Förderlinien, Teilprojekte und Standortstruktur ..................................................... 8

4.2 Finanzplanungstool der Geschäftsstelle .............................................................. 10

4.3 Initiale Antragstellung ...................................................................................... 10

4.4 Änderungsanträge ........................................................................................... 12

4.5 Zahlungsanforderungen und Bereitstellung von Abrufdaten .................................. 14

4.6 Berichtswesen: Nachweise und fachliche Berichte................................................ 15

4.7 Übersichten, Cockpits und Arbeitslisten ......................................................... 17

5. Datenmodell, Stammdaten, Dokumente, Exporte und Migration ............................... 18

5.1 Stammdaten- und Kontaktdatenverwaltung ...................................................... 18

5.2 Dokumentenablage und Versionierung .............................................................. 19

5.3 Strukturierte Exporte und Datenportabilität ...................................................... 20

5.4 Datenmigration .............................................................................................. 21

6. Schnittstellen und Integration (Querverweise) ........................................................ 23

7. Nicht-funktionale und technische Anforderungen .................................................... 24

7.1 Datenschutz, Sicherheit und Revision ................................................................. 24

7.2 Hosting und Betrieb ......................................................................................... 28

7.3 Usability und Barrierearmut .............................................................................. 30

8. Betrieb, Support, Schulung und Customizing ........................................................... 31

8.1 Support und Wartung ...................................................................................... 31

8.2 Schulung und Befähigung ................................................................................. 31

8.3 Customizing und spätere Anpassbarkeit.............................................................. 32

9. Vorgehensmodell und gestaffelter Go-Live .............................................................. 33

10. Demo-Szenario und Angebotsvergleich ................................................................. 38

11. Eignung, Zuschlag, Vertragslaufzeit und Vergütung ................................................ 40

11.1 Eignungsanforderungen ................................................................................. 40

11.2 Zuschlagskriterien und Wertungsmethodik ...................................................... 40

[Seite 3]

11.3 Vertragslaufzeit und Vergütung ...................................................................... 41

12. Vom Auftraggeber bereitgestellte Unterlagen und Daten ........................................ 42

[Seite 4]

1. Zielbild und Beschaffungsgegenstand

Ziel ist die Einführung einer webbasierten, revisionssicheren und konfigurierbaren Softwarelösung für das Fördermittelmanagement des Netzwerks Universitätsmedizin (NUM). Die Lösung soll die Förderprozesse vom Antrag über Prüfung, Bewilligung, Vertragserstellung, Zahlungsanforderung sowie Zwischen- und Verwendungsnachweis digital abbilden.

Die Software muss sowohl die administrative Bearbeitung und Prüfung (derzeit Team Administration, Finanzen und Controlling) als auch die fachliche Bearbeitung und Prüfung (derzeit Team Wissenschaftsmanagement) unterstützen. Die jeweiligen Prüfungen erfolgen abhängig vom Prozess parallel, sequentiell oder aufeinander aufbauend. Eingabemasken, Checklisten, Prüfvermerke, Aufgabenlisten und Statuslogiken müssen daher beide Prüfperspektiven nachvollziehbar abbilden können.

Die Software führt weder die tatsächliche Zahlungsanweisung noch die Bankausführung oder den unmittelbaren Abruf bei der Bundeskasse aus. Sie muss jedoch die für die Weiterleitung der Mittel erforderlichen Daten strukturiert und systemunabhängig bereitstellen. Da die Finanzsoftware des Auftraggebers erst nach dieser Vergabe ausgewählt wird, muss die technische Übergabe mindestens über ein dokumentiertes, konfigurierbares Austauschformat möglich sein. Das konkrete Zielformat und die Feldbelegung werden nach Auswahl der Finanzsoftware im Einführungsprojekt abgestimmt. Der tatsächliche Abruf von Finanzmitteln bei der Bundeskasse und die Bankausführung erfolgen außerhalb der Software. Die Bereitstellung des Abrufdatenpakets und die technische Umsetzung des abgestimmten Datenaustauschs sind Bestandteil des Leistungsumfangs.

Gegenstand der Ausschreibung ist eine integrierte Fachanwendung für das Fördermittelmanagement, mit der die administrativen und fachlichen Prüf-, Bearbeitungs- und Entscheidungsprozesse vollständig digital abgebildet werden können. Das Dokumentenmanagement ist zentraler Bestandteil dieser Fachanwendung und muss die vorgangsbezogene Verknüpfung, strukturierte Ablage, Versionierung, Verwaltung und Wiederauffindbarkeit von Dokumenten sicherstellen. Gesucht wird damit weder eine reine Dokumentenablage noch ein isoliertes Formularsystem, sondern eine durchgängige Fördermittelmanagementlösung.

Soweit in dieser Leistungsbeschreibung Produkte, Verfahren oder Hersteller genannt werden, geschieht dies ausschließlich zur Beschreibung des geforderten Leistungsumfangs; gleichwertige Lösungen sind zugelassen. Bestehende beziehungsweise vor Veröffentlichung festgelegte Zielsysteme des Auftraggebers werden in den Vergabeunterlagen einschließlich des erforderlichen Integrationsumfangs eindeutig benannt.

Die nachfolgende Tabelle definiert zentrale Begriffe, damit Bieter die Anforderungen einheitlich verstehen und Angebote vergleichbar aufgebaut werden können.

Begriff Definition für diese Leistungsbeschreibung

Förderlinie / Eine Förderlinie beziehungsweise ein Vorhaben ist eine übergeordnete Vorhaben Finanzierungs- oder Programmlinie.

Ein Teilprojekt ist ein abgegrenztes Projekt innerhalb einer Förderlinie und Teilprojekt kann mehrere Standorte umfassen.

1

[Seite 5]

Begriff Definition für diese Leistungsbeschreibung

Ein Standort ist ein Universitätsklinikum, ein weiterer anerkannter Zuwendungsempfänger oder eine sonstige im NUM-Netzwerk beteiligte Standort Einrichtung, an die im Rahmen eines Teilprojekts Finanzmittel des NUM weitergeleitet werden.

Die Teilprojektleitung ist eine Person beziehungsweise Personengruppe mit Teilprojektleitung Verantwortung für ein Teilprojekt und kann standortübergreifend besetzt sein.

Die Geschäftsstelle umfasst die Bearbeitungseinheiten der NUM GmbH für Geschäftsstelle das Fördermittelmanagement, insbesondere die administrative sowie die fachliche Bearbeitung und Prüfung.

Ein Vorgang ist ein konkreter Antrag, ein Änderungsantrag, eine Zahlungsanforderung, ein Zwischen- oder Verwendungsnachweis, ein Vorgang eigenständiger fachlicher Bericht oder ein sonstiger fachlicher Prozess einschließlich der zugehörigen Daten, Dokumente, E-Mail-Korrespondenz und Prozesshistorie.

Die administrative Prüfung umfasst administrative, finanzielle, formale und Administrative zuwendungsbezogene Aspekte und erfolgt derzeit insbesondere durch das Prüfung Team Administration, Finanzen und Controlling.

Fachliche Die fachliche Bearbeitung und Prüfung umfasst inhaltliche, Bearbeitung und projektbezogene und sonstige fachliche Aspekte und erfolgt derzeit Prüfung insbesondere durch das Team Wissenschaftsmanagement.

Revisionssicherheit bedeutet die nachvollziehbare und unveränderlich Revisionssicherheit protokollierte Dokumentation wesentlicher Bearbeitungsschritte, Entscheidungen, Versionen, Zeitpunkte und verantwortlicher Personen.

Der BNBest-Abruf M03 ist ein Auszahlungsbeleg beziehungsweise eine Formulargrundlage für den Abruf von Finanzmitteln nach den BNBest. Die Software muss die hierfür erforderlichen Daten strukturiert und exportierbar BNBest-Abruf M03 bereitstellen. Eine unmittelbare Vorbefüllung beziehungsweise Generierung des Formulars ist optional und wird über ZA-09 bewertet; eine direkte Einreichung ist nicht Gegenstand der Leistung.

2. Ausgangslage und Kontext

Das NUM befindet sich in einer organisatorischen Übergangsphase. Bisherige Prozesse sind teilweise an bestehende Strukturen der Charité, externe Projektträgerprozesse, SharePoint- bzw. Dateiablagen, Excel-Tabellen, PDF-Dokumente sowie easy-Online-/XML-Daten angebunden. Künftig soll die Geschäftsstelle eigene Strukturen zur Bearbeitung, Prüfung und Dokumentation von Förderprozessen etablieren.

2

[Seite 6]

Die Lösung muss zwei Ausgangssituationen abbilden können:

1. Erstens Prozesse, die künftig direkt im System starten, insbesondere NUM-interne Weiterleitungs- und Antrags- und Projektbetreuungsprozesse; Standorte erhalten eine Overheadpauschale.
2. Zweitens Prozesse, bei denen strukturierte Antrags- oder Projektdaten aus externen Verfahren, insbesondere easy-Online bzw. Projektträgerverfahren, übernommen und im NUM- System weiterverarbeitet werden; Standorte erhalten Projektpauschale.

Alle universitären Standorte sind in beiden Förderlogiken beteiligt und müssen daher in beiden Ausgangssituationen parallel abgebildet werden können.

In beiden Fällen sollen die Daten so weit wie möglich in einem gemeinsamen Daten- und Prozessmodell geführt werden.

Die folgende Übersicht beschreibt die wesentlichen Rahmenbedingungen und ihre Konsequenzen für die zu beschaffende Softwarelösung.

Aspekt Beschreibung Konsequenz für die Software

Das Netzwerk umfasst ca. 37 Universitätskliniken sowie weitere Die Lösung muss standortbezogene Netzwerk- anerkannte Zuwendungsempfänger Rechte, Finanzmittelübersichten und struktur und sonstige beteiligte Vorgänge bei einer zentralen Steuerung Einrichtungen mit durch die Geschäftsstelle unterstützen. Finanzmittelbezug.

Es bestehen mehrere laufende und Die Lösung muss projekt- und zukünftige Teilprojekte mit standortbezogene Rechte, Laufzeiten, Teilprojekte unterschiedlichen Beteiligten und Finanzmittelübersichten und Vorgänge zeitlich begrenzten Laufzeiten. unterstützen.

Die Prozesse umfassen eine Die Lösung muss parallele oder administrative Bearbeitung und sequenzielle Prüfketten mit getrennten Prüfperspektiven Prüfung sowie eine fachliche Aufgaben, Checklisten, Prüfvermerken Bearbeitung und Prüfung. und Freigaben abbilden können.

Die Förderlinien können sich insbesondere bei der Projekt- und Overheadpauschale, den Sperr- und Die Lösung muss konfigurierbare Förderlinienlogik Entsperrregeln, Umwidmungen, Finanz-, Prüf- und Statusregeln Aufstockungen und bereitstellen. Laufzeitanpassungen unterscheiden.

Zu den relevanten Dokumenten Die Lösung muss eine gehören Anträge, Anlagen, vorgangsbezogene Dokumentenablage Dokumente Verträge, Weiterleitungsverträge, mit Versionierung und Export Beleglisten und Nachweise. unterstützen.

3

[Seite 7]

Aspekt Beschreibung Konsequenz für die Software

Die Daten stammen aus Excel-, XML-, Word- und PDF-Dateien, aus Der Bieter muss ein Migrations-, Datenquellen manuellen Eingaben und Import- und Exportkonzept vorlegen. gegebenenfalls aus einer SharePoint- oder DMS-Altstruktur.

4

[Seite 8]

2.1 Mengen- und Nutzergerüst (Kalkulationsszenario)

Für die Vergleichbarkeit von Lizenz-, Betriebs-, Hosting- und Performanceangeboten ist das folgende verbindliche Auslegungs- und Kalkulationsszenario zugrunde zu legen.

Kalkulationsgröße Ansatz Hinweis

Die Konten werden insbesondere von der Geschäftsstelle, der Interne Nutzerkonten Ca. 60 Administration, der Prüfung, dem Reporting und der Qualitätssicherung genutzt.

Die Konten werden insbesondere von den Externe Nutzerkonten bis zu 1.000 Standorten, den Teilprojektleitungen und weiteren Beteiligten genutzt.

Der Wert dient als Kalkulationsgrundlage für die Performance und Skalierung. Die Gleichzeitig aktive Sitzungen bis zu 300 gleichzeitige Bearbeitung eines Vorgangs durch mehrere Nutzende muss unterstützt werden.

Der Ansatz ist die verbindliche Aktive Projekte / Teilprojekte Ca. 60 Kalkulationsmenge.

Die angegebenen Mengen bilden die verbindliche Kalkulations- und Auslegungsbasis. Die Performanceanforderung für bis zu 300 gleichzeitig aktive Sitzungen ist im Angebotspreis enthalten. Für preisbildende Mengen, insbesondere Nutzerkonten und Teilprojekte, sind in C.5 – Preisblatt Einheitspreise auszuweisen. Überschreiten die tatsächlich genutzten preisbildenden Mengen einen Ansatz um mehr als 20 Prozent, wird nur die darüber hinausgehende Menge nach den Einheitspreisen in C.5 abgerechnet. Eine Unterschreitung führt nicht zu einer Erhöhung der Einzelpreise.

3. Nutzergruppen, Rollen und Berechtigungen

Die Software muss für menschliche Nutzende personenbezogene Nutzerkonten unterstützen. Funktionsaccounts für die menschliche Nutzung sollen vermieden werden, da alle relevanten Änderungen und Entscheidungen einer konkreten Person zuordenbar sein müssen. Für automatisierte Integrationen sind gesonderte technische Identitäten beziehungsweise Service Clients zulässig; sie müssen eindeutig identifizierbar, zweckgebunden, auf die erforderlichen Berechtigungen beschränkt, widerrufbar und vollständig protokollierbar sein. Das Rechtekonzept muss rollen- und objektbezogen arbeiten, insbesondere bezogen auf Standort, Teilprojekt, Förderlinie, Vorgang, Dokument, Bearbeitungsstatus und konkrete Eingabemöglichkeiten.

5

[Seite 9]

Die Anforderungen werden in zwei Kategorien geführt. Muss-Kriterien (M) sind zwingende Voraussetzungen und müssen spätestens zu dem in C.3 – Anforderungsmatrix ausgewiesenen Fälligkeits- beziehungsweise Erfüllungszeitpunkt vollständig erfüllt sowie im angebotenen Preis berücksichtigt sein. Kann-Kriterien (K) dienen der qualitativen Differenzierung geeigneter Angebote. Der Bieter muss in C.3 für jedes Kann-Kriterium angeben, ob die Leistung im Angebotspreis inkludiert, als optionale Leistung angeboten oder nicht angeboten wird. Bei optionalen Leistungen ist in C.3 auf die zugehörige Preisposition in C.5 – Preisblatt zu verweisen; der Nettopreis ist ausschließlich in C.5 anzugeben. Zugesagte und beauftragte Kann-Leistungen werden Vertragsbestandteil. Die Ausschluss-, Bewertungs- und Abnahmelogik richtet sich nach den Vergabe- und Vertragsbedingungen.

C.3 – Anforderungsmatrix weist für jedes Kriterium einen verbindlichen Fälligkeits- beziehungsweise spätesten Erfüllungszeitpunkt aus, zum Beispiel mit Angebotsabgabe, Phase 0, Go-Live der Phasen 1 bis 4 oder Regelbetrieb. Muss-Kriterien müssen zu diesem Zeitpunkt vollständig erfüllt sein; bei verbindlich angebotenen Kann-Kriterien gilt der jeweils ausgewiesene Zeitpunkt entsprechend.

Die folgende Tabelle beschreibt die Anforderungen an Nutzerverwaltung, Rollenmodell, Berechtigungen und Protokollierung.

Die IDs dienen als stabile Referenzkennzeichen über die Versionsstände. Nummernlücken aus konsolidierten oder entfallenen Anforderungen werden deshalb nicht neu vergeben; sie haben keine inhaltliche oder wertungsbezogene Bedeutung.

6

[Seite 10]

Die folgende Rollenübersicht beschreibt die mindestens vorzusehenden Rollen der Startkonfiguration. Die konkrete Rollenmatrix ist im Einführungsprojekt zu verfeinern. Die finale Freigabe der administrativen und fachlichen Qualitätssicherung ist Teil der mehrstufigen Freigabe nach R-08 (Vier- Augen-Prinzip) und ersetzt diese nicht; Nachbesserungen werden als Korrektur- beziehungsweise Nachforderungsschritt im jeweiligen Vorgang geführt.

Rolle Typische Rechte

Geschäftsstelle Die Rolle übernimmt die Benutzerverwaltung, Stammdatenpflege, Administration Fristensteuerung und Prozesskonfiguration im vereinbarten Umfang.

Administrative Die Rolle übernimmt die Annahme, die formale und finanzielle Bearbeitung und Prüfung Prüfung, Rückfragen sowie die Zuordnung und Bearbeitung von (derzeit Team Anträgen, Zahlungsanforderungen und Nachweisen. Sie kann Administration, Finanzen Zahlungsanforderungen freigeben, Finanzmittel sperren oder kürzen und Controlling) und Finanzmittelübersichten einsehen.

Administrative Die Rolle übernimmt die Qualitätsprüfung, fordert bei festgestellten Qualitätssicherung Mängeln Nachbesserungen an und erteilt die finale Freigabe.

7

[Seite 11]

Rolle Typische Rechte

Fachliche Bearbeitung und Prüfung (derzeit Team Die Rolle bewertet Vorhabenbeschreibungen, Meilensteine, GANTT- Wissenschaftsmanagemen Charts, KPIs, Anlagen, sachliche Berichte und Nachweise fachlich. t)

Die Rolle übernimmt die fachliche Qualitätsprüfung, fordert bei Fachliche festgestellten Mängeln Nachbesserungen an und erteilt die finale Qualitätssicherung Freigabe.

Standortnutzende reichen standortbezogene Vorgänge ein und bearbeiten diese. Sie können die Finanzmittelstände ihrer eigenen Standortnutzende Standort-Teilprojekt-Kombinationen einsehen und die standortbezogenen Finanzmittelübersichten exportieren.

Die Teilprojektleitung erhält eine Übersicht über die beteiligten Standorte, prüft beziehungsweise zeichnet definierte Vorgänge, kann Teilprojektleitung den Finanzmittel- und Meilensteinstatus des Teilprojekts einsehen und die Finanzmittelübersichten des Teilprojekts exportieren.

Die Rolle erhält einen Nur-Lese-Zugriff auf definierte Auswertungen, Lesende Rolle / Reporting Dashboards und Exporte.

4. Zielprozesse und funktionale Anforderungen

Die nachfolgenden Prozesse bilden das Zielbild des NUM. Die Bieterangaben zu Erfüllungsart, Umsetzungsweg, Leistungsstatus, Erläuterungen und Abweichungen erfolgen ausschließlich in C.3 – Anforderungsmatrix. Bei Kann-Kriterien werden Erfüllungsgrad, Reifegrad und Umsetzungsweg nach der dort veröffentlichten Bewertungsskala berücksichtigt. Die Punktevergabe für die Demo erfolgt ausschließlich im gesonderten Zuschlagskriterium „Demo, Usability und Rollenansichten“; die Demo kann zugleich als Nachweismittel für die Erfüllung eines Kann-Kriteriums dienen, ohne dass dessen funktionale Erfüllung dadurch ein zweites Mal bepunktet wird. Sämtliche Muss-Kriterien, einschließlich Projekt-, Betriebs-, Support-, Migrations- und Schulungsleistungen, sind verbindlich in den nach A.2 – Verzeichnis der einzureichenden Unterlagen geforderten Konzepten und in C.5 – Preisblatt einzuplanen.

4.1 Förderlinien, Teilprojekte und Standortstruktur

Im NUM sollen mehrere Fördervorhaben bzw. Förderlinien, ggf. von verschiedenen Förderern in einer gemeinsamen Software administriert werden. Die Grundprozesse sind weitgehend einheitlich, einzelne Förderlinien können sich jedoch insbesondere bei Projekt- beziehungsweise Overheadpauschalen, Verfügbarkeit von Finanzmitteln, Sperr- und Entsperrlogiken oder Laufzeiten unterscheiden. Die Anwendung muss solche Unterschiede konfigurierbar abbilden, ohne für jede Förderlinie getrennte Systeme oder parallele Datenbestände zu erfordern. Projekt- und Overheadpauschalen wirken als konfigurierbare Rechenregel je Förderlinie und Kostenkategorie (Faktor auf die maßgeblichen Beträge); Finanzmittel müssen mit und ohne Pauschale getrennt ausweisbar sein.

8

[Seite 12]

Jede Förderlinie gliedert sich in Teilprojekte mit individuellen Laufzeiten, an denen mehrere Standorte beteiligt sein können. Finanzdaten müssen deshalb mindestens entlang Förderlinie, Teilprojekt, Standort, Haushaltsjahr und Finanzposition strukturiert geführt werden. Rechte, Vorgänge, Dokumente und Auswertungen müssen auf diese Struktur Bezug nehmen, damit Geschäftsstelle, Standorte und Teilprojektleitungen jeweils die für sie relevanten Informationen sehen und bearbeiten können.

9

[Seite 13]

4.2 Finanzplanungstool der Geschäftsstelle

Das Finanzplanungstool dient der Geschäftsstelle zur internen Planung von Finanzmitteln, die noch keinem Teilprojekt oder Standort verbindlich zugeordnet sind. Solche Beträge müssen nach Förderlinie, Haushaltsjahr und gegebenenfalls Zweckbindung erfasst, in Planständen fortgeschrieben und später nachvollziehbar auf Teilprojekte, Standorte und Finanzpositionen verteilt werden können.

Die Planung ist von der buchhalterischen Finanzverwaltung und der tatsächlichen Zahlungsabwicklung abzugrenzen. Sie soll insbesondere Transparenz über Gesamtbudget, bereits verplante beziehungsweise zugewiesene Finanzmittel und noch verfügbare Reserven schaffen und damit eine belastbare Grundlage für spätere Bewilligungs- und Steuerungsentscheidungen bilden.

4.3 Initiale Antragstellung

Die initiale Antragstellung erfolgt in einem zweistufigen, aufeinander aufbauenden Verfahren. Zunächst reicht die jeweils zuständige Teilprojektleitung die fachliche Vorhabenbeschreibung einschließlich Meilensteinplanung ein. Nach der fachlichen Erstprüfung werden die beteiligten Standorte zur administrativen Antragstellung für das jeweilige Teilprojekt aufgefordert; die weitere fachliche Prüfung läuft parallel zur administrativen Antragsaufforderung und Prüfung weiter.

Fachliche Antragstellung:

Die jeweils zuständigen Teilprojektleitungen reichen die Vorhabenbeschreibung und eine GANTT- beziehungsweise Meilensteinplanung ein. Einreichung, Versionierung, Überarbeitung und fachliche Prüfung beider Unterlagen müssen in einem eigenen fachlichen Prüf- und Freigabestrang unterstützt werden. Ob die Vorhabenbeschreibung unmittelbar in der Software über strukturierte Eingabemasken erstellt werden kann, wird über IA-12 qualitativ bewertet. Die GANTT- beziehungsweise Meilensteinplanung muss mindestens als Datei hochgeladen und eindeutig dem Vorgang zugeordnet werden können; die verpflichtende Einreichung und fachliche Prüfung werden über IA-15 geregelt. Die unmittelbare Erstellung, Bearbeitung und grafische Darstellung in der Software wird über IA-04 qualitativ bewertet. Nach erfolgreicher fachlicher Erstprüfung fordert die administrative Bearbeitung die beteiligten Standorte zur administrativen Antragstellung auf.

Administrative Antragstellung:

10

[Seite 14]

Nach Aufforderung reichen die Standorte initiale Anträge der Formtypen AZA oder AZK bezogen auf ein Teilprojekt einer Förderlinie ein. Der Antrag umfasst strukturierte Antrags- und Finanzdaten sowie die jeweils erforderlichen Anlagen.

Da sich die Antrags- und Finanzdaten abhängig von Förderlinie und Fördergeber unterscheiden können, muss neben der direkten Eingabe der Import der mit den Vergabeunterlagen bereitgestellten easy-Online-XML-Dateien der Formtypen AZA und AZK möglich sein. Der Import wird über IA-02 als Muss-Anforderung vorgegeben und darf nicht lediglich als Dateiablage wirken, sondern muss die definierten Inhalte in die vorgesehenen Systemfelder übernehmen. Nicht zuordenbare beziehungsweise fehlerhafte Inhalte sind nachvollziehbar auszuweisen.

Nach der Einreichung muss der Vorgang einer bearbeitenden Person oder Organisationseinheit der Geschäftsstelle zugeordnet und in einer Arbeitsliste sichtbar werden. Administrative und die weitere fachliche Bearbeitung und Prüfung erfolgen nach der fachlichen Erstprüfung parallel anhand konfigurierbarer Checklisten und umfassen Nachforderungen, Nachlieferungen, Korrekturen, Entscheidungen je Finanzposition sowie eine mehrstufige Freigabe. Aus dem geprüften Datenbestand müssen ein revisionssicheres Prüfprotokoll und die vertragliche Grundlage mit den bewilligten Finanzmitteln erzeugt oder aktualisiert werden können.

11

[Seite 15]

4.4 Änderungsanträge

Änderungsanträge beziehen sich auf bereits bewilligte und im System vorhandene Bestandsdaten auf Grundlage initialer Antragsdaten je Standort und Teilprojekt. Sie können insbesondere

12

[Seite 16]

Umwidmungen, Entsperrungen, Aufstockungen, Laufzeitanpassungen, Berufsgruppenwechsel oder Zweckänderungen betreffen. Das System muss den Ausgangsstand und die beantragte Änderung strukturiert gegenüberstellen, damit Auswirkungen auf Finanzpositionen, Haushaltsjahre, Laufzeiten und Vertragsdaten nachvollziehbar geprüft werden können.

Änderungsanträge werden in einem einstufigen Verfahren eingereicht. Die fachlichen und administrativen Unterlagen werden gleichzeitig durch den Standort eingereicht und anschließend administrativ und fachlich geprüft. Der weitere Bearbeitungsprozess umfasst Rückfragen, Korrekturen, Entscheidungen je Änderungsposition, eine Vier-Augen-Freigabe und ein revisionssicheres Prüfprotokoll. Nach der finalen Entscheidung müssen die aktualisierten Finanzmittelstände sowie die Verträge beziehungsweise Vertragsanlagen konsistent angepasst werden; frühere Stände müssen nachvollziehbar bleiben.

13

[Seite 17]

4.5 Zahlungsanforderungen und Bereitstellung von Abrufdaten

Zahlungsanforderungen werden in von der Geschäftsstelle festgelegten Zyklen für einzelne oder alle Standorte freigeschaltet. Standorte geben die benötigten Beträge je Teilprojekt, Haushaltsjahr und Finanzposition an; die Anforderung darf die jeweils entsperrten und verfügbaren Finanzmittel nicht überschreiten. Eingereichte Anforderungen müssen für die Geschäftsstelle unmittelbar sichtbar sein und im Vier-Augen-Prinzip geprüft und freigegeben werden.

Die Software bündelt die von der Geschäftsstelle freigegebenen standortbezogenen Zahlungsanforderungen zu einem nachvollziehbaren Abrufdatenpaket je Teilprojekt. Die freigegebenen Daten müssen systemunabhängig mindestens als CSV- oder XLSX-Datei bereitgestellt und nach Auswahl der Finanzsoftware über ein dokumentiertes, mit ihr kompatibles Importformat übergeben werden können. Das konkrete Zielformat und die Feldbelegung werden im Einführungsprojekt abgestimmt. Die tatsächlich abgerufenen beziehungsweise ausgezahlten Beträge müssen anschließend mindestens durch manuelle Eingabe oder durch Import aus der Finanzsoftware zurückgeführt werden können, damit die Finanzmittelstände aktuell bleiben. Eine direkte Zahlung, Bankbuchung oder Einreichung bei der Bundeskasse ist nicht Gegenstand der Leistung.

14

[Seite 18]

4.6 Berichtswesen: Nachweise und fachliche Berichte

Das Berichtswesen umfasst Zwischen- und Verwendungsnachweise sowie weitere eigenständige fachliche Berichte. Ein Zwischen- oder Verwendungsnachweis setzt sich aus den zahlenmäßigen Nachweisen der beteiligten Standorte einschließlich Beleglisten und Anlagen sowie einem sachlichen Bericht der zuständigen Teilprojektleitung zusammen. Die Bestandteile werden derselben Berichtsperiode und demselben Teilprojekt zugeordnet, können getrennt eingereicht und geprüft werden und werden für den Abschluss des Nachweises zusammengeführt. Weitere eigenständige fachliche Berichte, insbesondere Quartals- und Halbjahresberichte, werden gesondert geführt. Zwischen- und Schlussberichte sind dagegen sachliche Bestandteile des jeweiligen Zwischen- beziehungsweise Verwendungsnachweises und werden nicht als eigenständige Berichtspflichten angelegt. Eigenständige fachliche Berichte enthalten ausschließlich fachliche Inhalte in Form von Fließtext und keine zahlenmäßige Nachweismaske.

Die zahlenmäßigen Nachweise werden administrativ, der sachliche Bericht wird fachlich geprüft. Beide Bestandteile erhalten einen eigenen Bearbeitungsstatus; der gesamte Zwischen- oder Verwendungsnachweis gilt erst als abgeschlossen, wenn die erforderlichen Bestandteile vorliegen und nach der festgelegten mehrstufigen Freigabelogik freigegeben wurden. Korrekturen, Nachforderungen und Nachlieferungen müssen im jeweiligen Vorgang dokumentiert und in das Prüfprotokoll übernommen werden. Nach Abschluss werden die anerkannten Finanzmittel festgestellt, der Finanzierungsplan angepasst und das vorgesehene Prüf- beziehungsweise Anpassungsdokument

15

[Seite 19]

einschließlich aktualisierter Vertragsanlage erzeugt. Eigenständige fachliche Berichte werden durch die zuständige Teilprojektleitung eingereicht und fachlich geprüft.

16

[Seite 20]

4.7 Übersichten, Cockpits und Arbeitslisten

Die Software muss den beteiligten Nutzergruppen transparente Übersichten und Arbeitslisten bereitstellen. Ziel ist, dass Vorgangsstände, offene Aufgaben, Finanzmittelstände, Fristen und zentrale Projektinformationen ohne manuelle Parallelpflege nachvollziehbar sind.

17

[Seite 21]

5. Datenmodell, Stammdaten, Dokumente, Exporte und Migration

5.1 Stammdaten- und Kontaktdatenverwaltung

Dieser Abschnitt beschreibt Anforderungen an Stammdaten und Kontaktdaten der Standorte. Ziel ist, dass aktuelle Ansprechpersonen, E-Mail-Adressen, Rollen und projektbezogene Verteiler nicht außerhalb der Software in separaten Listen gepflegt werden müssen.

18

[Seite 22]

5.2 Dokumentenablage und Versionierung

Dieser Abschnitt beschreibt die Anforderungen an die Ablage und Wiederauffindbarkeit von Dokumenten. Die Dokumentenablage muss immer vorgangsbezogen und mit den jeweiligen Datenobjekten verknüpft sein, damit Anträge, Anlagen, Nachweise, Verträge und Vertragsunterlagen prüfbar bleiben.

19

[Seite 23]

5.3 Strukturierte Exporte und Datenportabilität

Dieser Abschnitt definiert Anforderungen an strukturierte Exporte, Datenportabilität, offene Schnittstellen und Exit-Fähigkeit. Der Auftraggeber muss die eigenen Daten bei Systemwechsel oder Vertragsende vollständig und maschinenlesbar erhalten können. Darüber hinaus muss eine dokumentierte, lesende und schreibende Programmierschnittstelle die Automatisierung wiederkehrender Datenübertragungen und Prozessschritte ermöglichen. Dadurch werden manuelle Doppelerfassung, Copy-and-paste-Prozesse und eine technische Abhängigkeit von der Fachanwendung vermieden. Die API muss sicher, versioniert und so dokumentiert sein, dass autorisierte Drittsysteme und Automatisierungsdienste definierte Datenobjekte verarbeiten und freigegebene Prozessaktionen auslösen können.

20

[Seite 24]

5.4 Datenmigration

Die Migration bestehender Daten ist als eigenständiges Arbeitspaket zu behandeln. Bieter müssen Annahmen, Grenzen und notwendige Mitwirkungspflichten transparent darstellen. Eine belastbare Aufwandsschätzung setzt voraus, dass anonymisierte Beispieldaten, Mengenangaben und typische Datenrelationen bereitgestellt werden.

21

[Seite 25]

Die nachfolgende Tabelle beschreibt die vom Auftraggeber für die Migrationsbewertung bereitzustellenden Informationen. Sie dient dazu, Bieterangebote vergleichbarer zu machen und Nachträge aufgrund unklarer Datenlage zu reduzieren.

4 Standorte, 8 Ein anonymisierter Teilprojekte, 8 Auszug wird Finanz- und Abrufdaten je Finanzpositionen, 144 Bestandteil der Standort, Teilprojekt, Datenzeilen; XLSX Vergabeunterlagen; der Haushaltsjahr und Finanzposition Vollbestand ca. 37 Vollbestand wird zum (heute als Kreuztabelle geführt) Standorte und ca. 60 Migrationsstichtag Teilprojekte bereitgestellt.

Haushaltsjahresscheiben je Die Daten sind Finanzposition (bewilligt, Bestandteil des Jahre 2025 bis 2030 XLSX gesperrt, entsperrt) einschließlich anonymisierten Restmitteln Auszugs.

Die Daten sind Q3/2025 bis Abrufe je Quartal sowie Bestandteil des Q2/2026; XLSX Rückzahlungen je Nachweisjahr anonymisierten Rückzahlungen 2025 Auszugs.

22

[Seite 26]

Kalkulationsannahme: Die Dokumente bis zu 15.000 Dokumente je Vorgang (Anträge, PDF, XLSX, werden zum Dokumente, Verträge, Nachweise, Beleglisten) Office Migrationsstichtag Gesamtvolumen bis bereitgestellt. 30 GB

Nur für Spalten, interne Kürzel oder Wird nur beigefügt, Kurze Erläuterung zum Statuswerte, deren falls solche Felder im anonymisierten Migrationsauszug XLSX Bedeutung aus dem finalen Auszug (nur falls erforderlich) finalen Auszug nicht verbleiben eindeutig hervorgeht

Nicht befüllte Quellfelder werden nicht als fachliche Ist- Fachliche Zuordnungsfelder Werte migriert. Ihre Im übergebenen Forschungslinie/Basisinfrastruktur XLSX Zuordnung zum Auszug nicht befüllt und AZK Zielmodell wird im Datenmapping der Migrationsanalyse festgelegt.

Der anonymisierte Beispieldatensatz ist vor Veröffentlichung fachlich zu bereinigen; bekannte Doppelzuordnungen dürfen nicht Bestandteil der Kalkulationsgrundlage sein. Für die Dokumentmigration gilt die Mengenannahme von bis zu 15.000 Dokumenten und 30 GB mit einer Toleranz von 20 Prozent. Darüber hinausgehende Mehrmengen werden ausschließlich nach den in C.5 – Preisblatt vorgegebenen Migrations-Einheitspreisen abgerechnet.

6. Schnittstellen und Integration (Querverweise)

Schnittstellen sind technische Datenübergaben an oder aus Drittsystemen. Um Doppelanforderungen und Doppelwertungen zu vermeiden, werden die Integrationsanforderungen ausschließlich in den jeweils fachlich maßgeblichen Kapiteln bewertet. Die folgende Tabelle enthält die entsprechenden Querverweise. Nutzerportale für Standorte und Teilprojektleitungen sind Bestandteil des Rollen- und Rechtekonzepts. Die systemunabhängige Bereitstellung des Abrufdatenpakets und der nach Auswahl der Finanzsoftware abgestimmte Datenaustausch sind Bestandteil des Leistungsumfangs. Ebenso verbindlich ist eine dokumentierte, lesende und schreibende API zur Automatisierung und zur Vermeidung manueller Copy-and-paste-Prozesse. Lediglich eine direkte Schnittstelle zur Bundeskasse sowie die tatsächliche Zahlungs- und Bankausführung bleiben außerhalb des Leistungsumfangs.

23

[Seite 27]

7. Nicht-funktionale und technische Anforderungen

7.1 Datenschutz, Sicherheit und Revision

Dieser Abschnitt enthält Anforderungen an Datenschutz, IT-Sicherheit und revisionssichere Nachvollziehbarkeit. Sie sind für den Betrieb eines Fördermittelmanagementsystems mit internen und externen Nutzergruppen wesentlich.

24

[Seite 28]

25

[Seite 29]

26

[Seite 30]

27

[Seite 31]

7.2 Hosting und Betrieb

Die folgende Tabelle beschreibt Muss-Kriterien an den technischen Betrieb. Bieter müssen transparent darlegen, wo Daten verarbeitet werden, welche Unterauftragnehmer beteiligt sind und wie Betrieb, Backup und Wiederherstellung abgesichert werden.

28

[Seite 32]

29

[Seite 33]

7.3 Usability und Barrierearmut

Die Software wird von unterschiedlichen Nutzergruppen mit verschiedenen Rollen genutzt. Sie muss daher verständlich, deutschsprachig und für externe Standorte ohne intensive technische Vorkenntnisse bedienbar sein. Gemeinsames Arbeiten an Vorgängen muss möglich sein.

30

[Seite 34]

8. Betrieb, Support, Schulung und Customizing

8.1 Support und Wartung

Der Bieter muss ein nachvollziehbares Support- und Wartungsmodell anbieten. Die folgenden Anforderungen definieren Mindestumfang, Sprache und Reaktionszeiten für einen realistischen Regelbetrieb.

8.2 Schulung und Befähigung

Für eine erfolgreiche Einführung sind Schulungen vor den jeweiligen Modulstarts erforderlich. Der Bieter muss Schulungskonzepte, Unterlagen, Durchführungsformen und Rollen der Teilnehmenden darstellen.

31

[Seite 35]

8.3 Customizing und spätere Anpassbarkeit

Die Software muss Anpassungen ermöglichen, ohne dass jede Änderung eine Individualentwicklung auslöst. Die Geschäftsstelle muss grundlegende und regelmäßig erforderliche Konfigurationen selbstständig vornehmen können. Der Bieter muss transparent abgrenzen, welche Änderungen ohne Programmierung, durch Konfiguration oder ausschließlich durch Entwicklung möglich sind. Änderungen müssen rollenbasiert, versioniert, in einer nichtproduktiven Umgebung testbar, revisionssicher dokumentiert und bei Bedarf auf einen vorherigen Stand zurücksetzbar sein. Anzubieten ist eine einsatzfähige Standardsoftware und kein Entwicklungskonzept; die angebotene Lösung muss dem in dieser Leistungsbeschreibung beschriebenen Funktionsumfang entsprechen. Sämtliche Konfigurations- und Anpassungsleistungen, die zur Erfüllung der Muss-Kriterien und der Mindestinhalte aller Phasen erforderlich sind, sind vollständig im Angebotspreis enthalten; ein gesonderter Vergütungsanspruch entsteht insoweit nicht.

32

[Seite 36]

9. Vorgehensmodell und gestaffelter Go-Live

Aufgrund der organisatorischen Übergangsphase erfolgen Abnahme und Go-Live gestaffelt je Phase. Der Bieter muss einen Umsetzungs-, Kosten- und Schulungsplan nach den Vorgaben von A.2 – Verzeichnis der einzureichenden Unterlagen mit Meilensteinen, dem erforderlichen personellen Mitwirkungsumfang des Auftraggebers je Phase, Abhängigkeiten zwischen den Phasen, Risiken und Abweichungen vom Phasenplan vorlegen. Das Schulungskonzept ist je Modul mit Durchführungsform, Zielgruppen und Unterlagen zu beschreiben. Prozesse, deren zugehöriges Modul noch nicht produktiv gesetzt ist, können bis zum jeweiligen Go-Live bei Bedarf als Übergangsprozess außerhalb des Systems fortgeführt werden. Die Einführung ist so zu planen, dass alle ab dem jeweiligen Go-Live relevanten Prozesse gemäß Phasenplan produktiv unterstützt werden.

Die nachfolgende Phasenplanung beschreibt die verbindliche Einführungslogik mit den spätesten Go- Live-Terminen.

33

[Seite 37]

Phase Zieltermin Ziel Mindestinhalt

Der Mindestinhalt umfasst den Kick-off, Prozessworkshops, das Datenmodell, das Rollenmodell, die Migrationsanalyse und den Ziel ist ein gemeinsames Projektplan. Sofern die Phase 0: Projektstart / nach Zielbild mit einem Zuschlagserteilung die Feinspezifikation Zuschlag abgestimmten Leistungserbringung und Umsetzungsplan. Abnahme noch im Jahr 2026 zulässt, erfolgt bis zum 18.12.2026 eine Teilabnahme des Zielbilds, des Daten- und Rollenmodells sowie der Feinspezifikation für Phase 1.

34

[Seite 38]

Phase Zieltermin Ziel Mindestinhalt

Der Mindestinhalt umfasst die Standort- und Teilprojektstruktur, die Einreichung der fachlichen Antragsunterlagen einschließlich der Vorhabenbeschreibung und der GANTT- beziehungsweise Meilensteinplanung, den Import der AZA- und AZK- XML-Dateien, die Erstellung und Einreichung initialer Phase 1: Kernsystem Anträge und initiale und Ziel ist der erste Änderungsanträge, die nach 01.04.2027 Änderungsanträge / produktive Kernprozess. der fachlichen Erstprüfung Prüfung / Vertrag parallel geführte weitere fachliche und administrative Prüfung durch die Geschäftsstelle auf Grundlage von Checklisten, die Überführung der Prüfentscheidung in einen Vertrag beziehungsweise eine Vertragsanlage, die Dokumentenablage, eine Basis-API für Kernobjekte und Automatisierung sowie die Schulung vor dem Go-Live.

35

[Seite 39]

Phase Zieltermin Ziel Mindestinhalt

Der Mindestinhalt umfasst die Freischaltung der Zahlungsanforderungen durch die Geschäftsstelle auf Grundlage individueller Voraussetzungen, die Prüfung Ziel sind strukturierte eingereichter Unterlagen, die Phase 2: Zahlungsanforderungen systemunabhängige Zahlungsanforderungen 01.06.2027 und die Bereitstellung Bereitstellung des / Abrufdaten von Abrufdaten. Abrufdatenpakets, die nach Auswahl der Finanzsoftware abzustimmende Datenübergabe, die Aktualisierung der Finanzmittelstände und die Schulung vor dem Go-Live.

Der Mindestinhalt umfasst zahlenmäßige Nachweise, AZA- und AZK-Beleglisten, sachliche Berichte als Bestandteil der Zwischen- und Verwendungsnachweise, Ziel sind die eigenständige fachliche Unterstützung der Quartals- und Phase 3: Berichtswesen Nachweise und Halbjahresberichte, die / Zwischen- und 01.08.2027 fachlichen Berichte getrennte administrative und Verwendungsnachweise sowie die Abbildung der fachliche Prüfung, die Jahresabschlusslogik. Gesamtfreigabe, die Anpassung des Finanzierungsplans, ein Prüf- beziehungsweise Anpassungsdokument und die Schulung vor dem Go- Live.

36

[Seite 40]

Phase Zieltermin Ziel Mindestinhalt

Der Mindestinhalt umfasst die bis Phase 4 fälligen Muss- Kriterien. Darüber hinaus werden optionale Ziel sind die Erweiterungen nur Optimierung der umgesetzt, soweit sie Phase 4: Erweiterungen Grundlösung und die 01.10.2027 verbindlich angeboten und / Optimierung Umsetzung beauftragter beauftragt wurden, optionaler insbesondere Reporting, Erweiterungen. DMS, Customizing- Schulungen, API- Erweiterungen und zusätzliche Schnittstellen.

Die Vergütung der Einführungsleistungen erfolgt phasenbezogen. Je Phase werden Lieferung, Prüfung durch den Auftraggeber, Abnahme auf Grundlage der Mindestinhalte und die Zahlung des auf die Phase entfallenden Anteils vereinbart; die Zahlungsanteile je Phase sind in C.5 – Preisblatt auszuweisen. Bei Phasen mit produktivem Go-Live erfolgt die Abnahme erst nach einem erfolgreichen und dokumentierten Ende-zu-Ende-Test der jeweils produktiv zu setzenden Kernprozesse in der vorgesehenen Rollen- und Berechtigungskonstellation sowie nach deren Freigabe durch den Auftraggeber. Sofern die Zuschlagserteilung die Leistungserbringung und Abnahme noch im Jahr 2026 zulässt, weist der Bieter im Umsetzungs-, Kosten- und Schulungsplan den auf die bis zum 18.12.2026 geplanten, selbständig prüf- und abnahmefähigen Liefergegenstände entfallenden Zahlungsanteil aus. Für die bis zu diesem Zeitpunkt tatsächlich erbrachten und abgenommenen Leistungen wird ein Anteil von rund 25 Prozent der Implementierungskosten angestrebt; ein geringerer Anteil ist zulässig. Voraussetzung der Abrechnung ist die tatsächliche Abnahme dieser Liefergegenstände; Vorabzahlungen für noch nicht erbrachte Leistungen sind ausgeschlossen.

Die Zieltermine stehen unter dem Vorbehalt einer rechtzeitigen Zuschlagserteilung und der erforderlichen internen Freigaben. Die Vergabe erfolgt im offenen Verfahren. Die Angebotsfrist beträgt 30 Kalendertage. Die verbindlichen Fristen und der Zuschlagstermin ergeben sich aus den übrigen Vergabeunterlagen.

Die folgende Anforderungstabelle konkretisiert die Projektsteuerungs- und Einführungsanforderungen.

37

[Seite 41]

10. Demo-Szenario und Angebotsvergleich

Nach Ablauf der Angebotsfrist wird das vorgegebene Demo-Szenario 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. Die Demo erfolgt in einer klickbaren Standard- oder Beispielkonfiguration. Ablauf, Zeitrahmen, Demo-Zuordnung, Kernfragen und Bewertungsmaßstab sind für alle Bieter gleich. Die sechs Bewertungsdimensionen, Beobachtungspunkte, Gewichtung und Punkteskala sind in C.3 – Anforderungsmatrix veröffentlicht. Die Demo bildet das eigenständige Zuschlagskriterium „Demo, Usability und Rollenansichten“ und kann zugleich als Nachweismittel für diejenigen Kann-Kriterien dienen, die in der angebotenen Ausprägung bereits demonstrierbar sind. Die funktionale Erfüllung eines Kann-Kriteriums wird ausschließlich in der Kann-Wertung bepunktet; innerhalb der Demo werden nur die Qualität und Nachvollziehbarkeit der Demonstration anhand der sechs Demo-Dimensionen bewertet. Wird ein im Demo-Szenario adressiertes Kann-Kriterium nicht angeboten, führt dessen Fehlen in der Demo nicht zu einer zusätzlichen Abwertung. Muss-Kriterien bleiben unabhängig von der Demo verbindlich und werden zusätzlich über die einzureichenden Konzepte, Leistungszusagen und Projektpläne geprüft. Reine Folienpräsentationen oder ausschließlich vorproduzierte Videos sind nicht ausreichend.

Kann-Kriterien, die verbindlich als bepreiste Entwicklung bis zum ausgewiesenen Erfüllungszeitpunkt angeboten werden, müssen zum Angebotszeitpunkt noch nicht funktionsfähig in der klickbaren Demo vorliegen. Im betreffenden Demo-Schritt sind mindestens das verbindliche Umsetzungskonzept, die geplante Nutzerführung und eine belastbare technische Darstellung, zum Beispiel als Mock-up, Prototyp oder vergleichbare Darstellung, vorzustellen. Die Einstufung als bepreiste Entwicklung wird ausschließlich im Kann-Kriterium über die Reifegradskala berücksichtigt. In der Demo wird nur die Qualität und Nachvollziehbarkeit der gezeigten Ersatzdarstellung bewertet; eine zusätzliche Abwertung allein wegen fehlender Produktreife erfolgt nicht.

38

[Seite 42]

Das folgende Demo-Drehbuch dient der einheitlichen Bewertung der Prozesspassung und Bedienbarkeit.

• Standortnutzende melden sich an und sehen ausschließlich eigene Standort- /Teilprojektkombinationen. • Ein Standort legt einen Antrag oder Änderungsantrag in einem Teilprojekt mit Finanzpositionen, Haushaltsjahren und Anlagen an. • Die bereitgestellten AZA- und AZK-XML-Beispieldaten werden importiert, definierte Inhalte in die vorgesehenen Systemfelder übernommen und nicht zuordenbare Inhalte nachvollziehbar ausgewiesen. • Die verpflichtende GANTT-/Meilensteinplanung wird hochgeladen, versioniert, fachlich geprüft und zur Überarbeitung zurückgegeben. Soweit angeboten, werden für IA-04 Anlegen, Aktualisieren und grafische Darstellung gezeigt; für IA-05 Erfassung, Anzeige und Überwachung von Meilensteinen, Fristen und Terminen. • Der Antrag wird eingereicht und erscheint in der Arbeitsliste der Geschäftsstelle. • Administrative und fachliche Prüfende bearbeiten ihre jeweiligen Checklisten und erstellen Prüfvermerke. Der Bearbeitungsstatus aktualisiert sich in der Arbeitsliste. • Standortnutzende erhalten eine Information zum aktualisierten Status des Antrags. • Die Geschäftsstelle fordert bei Bedarf Korrekturen an; eingereichte Korrekturen werden im Vorgang dokumentiert. • Eine Finanzposition wird teilweise gekürzt oder gesperrt; der Finanzmittelstand aktualisiert sich nachvollziehbar. • Die Vier-Augen-Freigabe erfolgt. • Der Vertrag beziehungsweise die Vertragsanlage wird aus Systemdaten erzeugt, den Standortnutzenden zur Verfügung gestellt und im Vorgang abgelegt. • Soweit Ü-02 beziehungsweise Ü-03 verbindlich angeboten werden, zeigen Standortdashboard und Teilprojektleitungsdashboard die aktualisierten Finanzmittelstände. • Soweit Ü-06 verbindlich angeboten wird, wird der Projekt- beziehungsweise Teilprojektsteckbrief aufgerufen. • Ein berechtigter Administrator der Geschäftsstelle ändert in einer nichtproduktiven Umgebung ein Formularfeld, einen Prüfpunkt oder einen Statuswert, testet die Änderung, veröffentlicht sie versioniert und stellt bei Bedarf den vorherigen Stand wieder her. • Der Bieter zeigt nachvollziehbar, welche Anpassungen die Geschäftsstelle selbst konfigurieren kann und welche Änderungen Bieterunterstützung oder Entwicklungsleistungen erfordern. • Soweit ST-04 verbindlich angeboten wird, wird eine aktuelle Kontaktliste beziehungsweise ein Verteiler aus dem System exportiert. • Auditlog, Dokumenthistorie und ein filterbarer Report werden der Geschäftsstelle angezeigt. • Die systemunabhängige Bereitstellung freigegebener Zahlungsanforderungsdaten wird anhand einer Beispieldatei nachvollziehbar dargestellt. Das Konzept für die nach Auswahl der Finanzsoftware abzustimmende technische Übergabe wird anhand einer Schnittstellenbeschreibung oder eines kompatiblen Importformats erläutert. Soweit ZA-09 angeboten wird, wird zusätzlich der BNBest-Abruf M03 auf Grundlage der konsolidierten Gesamtsumme des Abrufvorgangs vorbefüllt oder erzeugt.

39

[Seite 43]

• Der Bieter zeigt anhand eines definierten Datenobjekts, wie Daten über die dokumentierte API automatisiert gelesen und geschrieben sowie ein freigegebener Prozessschritt oder Status ohne manuelle Übertragung ausgelöst beziehungsweise aktualisiert wird; die resultierende Änderung wird anschließend im Audit- beziehungsweise Prozessprotokoll nachvollzogen.

11. Eignung, Zuschlag, Vertragslaufzeit und Vergütung

Die verfahrensbezogenen Eignungs- und Zuschlagsregelungen werden in den hierfür vorgesehenen Vergabeunterlagen geführt. Diese Leistungsbeschreibung enthält die für Leistungsumfang, Einführung, Abnahme, Vertragslaufzeit und Vergütung maßgeblichen Festlegungen.

11.1 Eignungsanforderungen

Die verbindlichen Eignungsanforderungen und die hierzu vorzulegenden Erklärungen und Angaben ergeben sich abschließend aus B.1 – Eigenerklärung zur Eignung sowie aus der Auftragsbekanntmachung.

11.2 Zuschlagskriterien und Wertungsmethodik

Die Zuschlagskriterien und deren Gewichtung ergeben sich aus A.1 – Verfahrens- und Angebotsbedingungen. Insgesamt können maximal 100 Wertungspunkte erreicht werden. Davon entfallen maximal 70 Wertungspunkte auf die Qualitätswertung und maximal 30 Wertungspunkte auf die Preiswertung.

Die Qualitätswertung setzt sich aus der Bewertung der Kann-Kriterien, der Demo und der Konzeptwertung zusammen. Muss-Kriterien sind verbindliche Mindestanforderungen und werden nicht bepunktet. Ihre Nichterfüllung führt nach Maßgabe der Vergabeunterlagen zum Ausschluss des Angebots. Die Anforderungsmatrix C.3 enthält insgesamt 41 Kann-Kriterien. Jedes Kann-Kriterium wird anhand der dort veröffentlichten Bewertungsskala mit 0 bis 5 Punkten bewertet. Die verbindliche Zuordnung der Kann-Kriterien zu den Zuschlagskriterien ergibt sich aus Spalte K der Anforderungsmatrix. Innerhalb des jeweiligen Zuschlagskriteriums werden die zugeordneten Kann- Kriterien gleich gewichtet. Die Kann-Kriterien verteilen sich wie folgt:

• 31 Kann-Kriterien sind dem Zuschlagskriterium „Funktionalität und Prozesspassung“ zugeordnet. Es können maximal 155 Rohpunkte erreicht werden. Die Umrechnung in maximal 25 Wertungspunkte erfolgt nach der Formel: erreichte Rohpunkte ÷ 155 × 25. • 5 Kann-Kriterien sind dem Zuschlagskriterium „Technische Architektur, Sicherheit und Datensouveränität“ zugeordnet. Es können maximal 25 Rohpunkte erreicht werden. Die Umrechnung in maximal 20 Wertungspunkte erfolgt nach der Formel: erreichte Rohpunkte ÷ 25 × 20. • 5 Kann-Kriterien sind dem Zuschlagskriterium „Vorgehensmodell, Migration und Service“ zugeordnet. Es können maximal 25 Rohpunkte erreicht werden. Die Umrechnung in maximal 5 Wertungspunkte erfolgt nach der Formel: erreichte Rohpunkte ÷ 25 × 5.

Für das Zuschlagskriterium „Demo, Usability und Rollenansichten“ können maximal 10 Wertungspunkte erreicht werden. Die Demo wird anhand von sechs gleich gewichteten Bewertungsdimensionen mit jeweils 0 bis 5 Punkten bewertet. Bei maximal 30 erreichbaren Rohpunkten erfolgt die Umrechnung nach der Formel: Summe der sechs Demo-Punkte ÷ 30 × 10. Das

40

[Seite 44]

verbindliche Demo-Szenario ergibt sich aus Abschnitt 10 dieser Leistungsbeschreibung. Die Bewertungsdimensionen, Beobachtungspunkte, Bewertungsanker und weiteren Bewertungsregeln ergeben sich aus der Demo-Bewertungsmatrix in C.3.

Das Zuschlagskriterium „Vorgehensmodell, Migration und Service“ umfasst neben den maximal 5 Wertungspunkten aus den zugeordneten Kann-Kriterien weitere maximal 10 Wertungspunkte aus der Konzeptwertung. Bewertet werden ausschließlich das Migrationskonzept sowie der Umsetzungs-, Kosten- und Schulungsplan gemäß A.2 – Verzeichnis der einzureichenden Unterlagen. Die Bewertung erfolgt anhand von vier gleich gewichteten Konzeptdimensionen mit jeweils 0 bis 5 Punkten. Bei maximal 20 erreichbaren Rohpunkten erfolgt die Umrechnung nach der Formel: Summe der vier Konzeptpunkte ÷ 20 × 10. Die weiteren nach A.2 einzureichenden Konzepte und Darstellungen dienen dem Nachweis der angebotenen Leistung und werden nicht als eigenständige Konzeptdimensionen bepunktet. Die verbindlichen Bewertungsdimensionen, Beobachtungspunkte und Bewertungsanker ergeben sich aus der Konzeptbewertungsmatrix in C.3.

Für das Zuschlagskriterium „Preis und Gesamtbetriebskosten“ können maximal 30 Wertungspunkte erreicht werden. Sämtliche Preisangaben und die Berechnung des Wertungspreises richten sich ausschließlich nach C.5 – Preisblatt. Die Preiswertung erfolgt nach der Formel: 30 × niedrigster Wertungspreis ÷ Wertungspreis des jeweiligen Angebots.

Die Gesamtpunktzahl ergibt sich aus der Summe der gewichteten Teilergebnisse. Die Teilergebnisse und die Gesamtpunktzahl werden, soweit in den Vergabeunterlagen nicht ausdrücklich anders geregelt, kaufmännisch auf zwei Nachkommastellen gerundet.

11.3 Vertragslaufzeit und Vergütung

Sofern Zuschlagserteilung und erforderliche interne Freigaben eine Leistungserbringung und Abnahme bis zum 18.12.2026 zulassen, wird für tatsächlich bis zu diesem Zeitpunkt erbrachte und abgenommene Leistungen der Phase 0 ein Anteil von rund 25 Prozent der Implementierungskosten angestrebt; ein geringerer Anteil ist zulässig. Aus dem Zielwert folgt weder eine Abnahme- noch eine Zahlungspflicht für nicht erbrachte Leistungen.

Die Grundlaufzeit beträgt drei Jahre und beginnt mit dem produktiven Go-Live der Phase 1. Der Auftraggeber kann den Vertrag durch einseitige Erklärung einmal um zwölf Monate verlängern. Die Verlängerung umfasst ausschließlich die weitere Bereitstellung und Nutzung des bereits beauftragten Leistungsumfangs einschließlich Lizenzen, Hosting, Betrieb, Wartung und Support; zusätzliche Implementierungs- oder Customizing-Leistungen sind nicht Bestandteil der Verlängerungsoption. Ohne Ausübung der Option endet der Vertrag mit Ablauf der Grundlaufzeit automatisch, bei Ausübung mit Ablauf des Optionsjahres. Einer ordentlichen Kündigung bedarf es nicht; das Recht zur außerordentlichen Kündigung aus wichtigem Grund bleibt unberührt.

Für die Grundlösung beginnen laufende Lizenz-, Hosting-, Betriebs- und Supportentgelte mit dem produktiven Go-Live der Phase 1. Laufende Entgelte für später beauftragte optionale Leistungen beginnen erst mit deren jeweiligem produktiven Go-Live. Sämtliche Preispositionen, Bewertungsmengen und die Berechnung des Wertungspreises ergeben sich ausschließlich aus C.5 – Preisblatt sowie aus A.1 – Verfahrens- und Angebotsbedingungen.

41

[Seite 45]

12. Vom Auftraggeber bereitgestellte Unterlagen und Daten

Der Auftraggeber stellt mit den Vergabeunterlagen beziehungsweise im Einführungsprojekt die nachfolgend genannten Unterlagen und Daten bereit. Die jeweiligen Bereitstellungszeitpunkte ergeben sich aus dieser Leistungsbeschreibung, C.4 – Termin- und Abrufplan sowie den Vergabe- und Vertragsunterlagen.

• C.6 – Auftragsverarbeitungsvertrag nach Art. 28 DSGVO • die Ablaufdarstellung der Zielprozesse • das Formular BNBest-Abruf M03 einschließlich des Kontierungsblatts • technisch bereinigte AZA- und AZK-Beleglisten einschließlich dokumentierter Summenlogik • je einen plausibel befüllten AZA- und AZK-XML-Beispieldatensatz einschließlich Feldbeschreibung und Soll-Mapping für IA-02 • den fachlich bereinigten und anonymisierten Migrationsauszug; soweit einzelne Spalten, interne Kürzel oder Statuswerte nicht eindeutig sind, ergänzt der Auftraggeber eine kurze Erläuterung • das konkrete Zielformat und die Feldbeschreibung für die Übergabe an die spätere Finanzsoftware, sobald diese ausgewählt ist; die technische Ausgestaltung wird im Einführungsprojekt gemeinsam abgestimmt

42