[Seite 1]
Anlage 0
Leistungsbeschreibung
„WIBank Reporting Plattform“
zum Rahmenvertrag vom TT.MM.JJJJ
zwischen
Landesbank Hessen-Thüringen Girozentrale
Neue Mainzer Straße 52 -58
60311 Frankfurt
– nachfolgend Helaba oder Auftraggeber genannt –
und
[Adresszeile 1: Vollständige Firmierung des Auftragnehmers]
[Adresszeile 2: Straße des Auftragnehmers]
[Adresszeile 3: PLZ und Stadt des Auftragnehmers]
– nachfolgend [Kürzel des Auftragnehmers] oder Auftragnehmer genannt
– zusammen auch „Vertragspartner“, „Vertragsparteien“
oder „Parteien“ genannt –
Version 1.0
[Seite 2]
Inhaltsverzeichnis
1 Einordnung ............................................................................................................ 3
2 Leistungsbeschreibung „Neue Reporting Plattform“ ......................................... 4 2.1 Hinweis zur Leistungserbringung ........................................................................ 4 2.2 Leistungsgegenstand – Übersicht ....................................................................... 4 2.3 Technische Zielarchitektur und technische Anforderungen.................................. 5
2.3.1 Zweck und Geltungsbereich .......................................................................................... 5
2.3.2 Plattform- und Zielarchitektur ......................................................................................... 5
2.3.3 Datenarchitektur, Historisierung und Versionierung ...................................................... 6
2.3.4 Datenintegration, Schnittstellen und Quellsystemanbindung ........................................ 7
2.3.5 ETL-/ELT-Verarbeitung und Orchestrierung .................................................................. 7
2.3.6 Reporting-, BI- und Zugriffsschicht ................................................................................ 8
2.3.7 Metadaten, Logging, Monitoring und Lineage ............................................................... 8
2.3.8 Entwicklung, Qualitätssicherung, CI/CD und Deployment ............................................ 9
2.3.9 Sicherheit, Berechtigungen und technische Schutzmaßnahmen .................................. 9
2.3.10 Performance, Skalierung und Betriebsfähigkeit ............................................................ 9
2.3.11 Betriebsdokumentation und Übergabefähigkeit ........................................................... 10 2.4 Enterprise Data Warehouse und Datenmodellierung ..........................................10
2.4.1 Zusammenfassung ...................................................................................................... 10
2.4.2 Mögliche Themen im Rahmen der Einzelbeauftragungen .......................................... 10 2.5 ETL-/ELT-Prozesse und Datenintegration ..........................................................11
2.5.1 Zusammenfassung ...................................................................................................... 11
2.5.2 Voraussichtliche wesentliche Aufgaben ...................................................................... 11 2.6 Berichtswesen, Power BI und Self-Service BI ....................................................12
2.6.1 Zusammenfassung ...................................................................................................... 12
2.6.2 Voraussichtliche wesentliche Aufgaben ...................................................................... 12 2.7 Schnittstellen und Quellsysteme ........................................................................12
2.7.1 Zusammenfassung ...................................................................................................... 12
2.7.2 SAP WIBank ................................................................................................................ 12
2.7.3 Kundenportal der WIBank ............................................................................................ 13
2.7.4 Enterprise Data Warehouse (EDW) der Helaba .......................................................... 13
2.7.5 Förderwerk ................................................................................................................... 13
2.7.6 Historische Infoportal-Daten ........................................................................................ 13 2.8 Support ..............................................................................................................13
2.8.1 Support-Modell ............................................................................................................. 13
2.8.2 Wesentliche Aufgaben ................................................................................................. 13
2.8.3 Qualitätssicherung ....................................................................................................... 13
Seite 2 von 14
[Seite 3]
1 Einordnung
Die vorliegende Leistungsbeschreibung definiert den Leistungsgegenstand für die Konzeption, Implementierung, Qualitätssicherung sowie die Unterstützung bei Inbe- triebnahme und Betrieb der neuen Reporting-Plattform der WIBank. Darüber hinaus umfasst sie die laufende Weiterentwicklung der im Rahmen des Projekts entstehen- den Plattform. Ziel des Vorhabens (Projekt + Weiterentwicklung) ist die Ablösung des bestehenden Infoportals durch eine moderne Business-Intelligence- und Reporting-Plattform. Diese soll eine zentrale, konsistente, qualitätsgesicherte und revisionssichere Da- tenbasis für Reporting, Analysen sowie Self-Service-BI-Funktionen bereitstellen. Die Plattform ist dabei so auszulegen, dass sie kontinuierlich an fachliche, regulatori- sche, technische und betriebliche Anforderungen angepasst werden kann. Das bestehende Infoportal bildet derzeit das zentrale Data-Warehouse- und Be- richtssystem der WIBank. Es konsolidiert Daten aus verschiedenen Quellsystemen und stellt darauf basierende Berichte sowie Meldungen für Förderprogramme der Europäischen Union, des Bundes und des Landes Hessen bereit. Gegenstand des Projekts ist die Bereitstellung einer neuen Reporting-Plattform für die Fachbereiche Finanz- und Rechnungswesen, Risikomanagement und Treasury. Hierzu zählen insbesondere die Anbindung von SAP WIBank als initialem operati- ven Quellsystem, der Aufbau des Data Marts „Meldewesen“, die Übernahme histori- scher Daten aus dem bestehenden Infoportal sowie die Umsetzung der definierten Zielberichte. Nach Abschluss des Projekts wird die entwickelte Plattform im Rahmen einer konti- nuierlichen Weiterentwicklung ausgebaut. Dies umfasst insbesondere die Anbin- dung weiterer Quellsysteme, den Aufbau zusätzlicher Data Marts sowie die Migra- tion weiterer Berichte aus dem bestehenden Infoportal. Langfristig soll das beste- hende Infoportal vollständig abgelöst und außer Betrieb genommen werden. Die Entwicklungsleistungen im Umfeld der WIBank Reporting-Plattform sollen künf- tig durch einen externen Entwicklungspartner erbracht werden. Der Leistungsum- fang umfasst dabei die Beratung, die fachlich-technische Konzeption, die Implemen- tierung, die Qualitätssicherung sowie die Unterstützung bei Inbetriebnahme und An- wendungsbetrieb. Die Reporting-Plattform ist in die IT-Landschaft der Helaba eingebettet. Die Anbin- dung weiterer Quellsysteme sowie der Aufbau zusätzlicher Data Marts sind nicht Bestandteil des initialen Projekts, müssen jedoch im Zielbild und in der technischen Architektur so berücksichtigt werden, dass eine spätere Erweiterung der Plattform effizient und nachhaltig möglich ist.
Seite 3 von 14
[Seite 4]
2 Leistungsbeschreibung „Neue Reporting Plattform“
2.1 Hinweis zur Leistungserbringung
Es wird ein Rahmenvertrag geschlossen, der die Grundlage für die Zusammenarbeit bildet. Die konkrete Umsetzung von Entwicklungs-, Konzeptions-, Umsetzungs-, Qualitätssicherungs- sowie Pflege- und Supportleistungen erfolgt ausschließlich über separate Einzelaufträge. Die Obergrenze für Abrufe aus dem Rahmenvertrag beträgt insgesamt EUR 6,5 Mio. (brutto). Das vorliegende Dokument dient der fachlichen Orientierung. Es beschreibt den ge- forderten Leistungsumfang, den aktuellen Funktionsumfang sowie mögliche Per- spektiven für zukünftige Entwicklungen. Keine der in diesem Dokument beschriebe- nen Anforderungen ist unmittelbar oder verbindlich durch den Bewerber umzuset- zen. Die Beauftragung erfolgt ausschließlich auf Basis von Einzelaufträgen im Rahmen des geschlossenen Vertrages. Jeder Einzelauftrag definiert: • den konkreten Leistungsumfang, • den zeitlichen Rahmen, • die zu erbringende Ergebnisse sowie • den Preis.
2.2 Leistungsgegenstand – Übersicht
Der Leistungsgegenstand sowohl für das Projekt neue Reporting Plattform als auch für die Weiterentwicklung der aus dem Projekt resultierenden Plattform gliedert sich in fünf zentrale, miteinander verzahnte Hauptbereiche. Die übergreifenden techni- schen Anforderungen an Architektur, Datenintegration, Historisierung, Datenqualität, Logging, Monitoring, Lineage, Sicherheit, Berechtigungen, CI/CD, Deployment und Betriebsfähigkeit sind in Kapitel 2.3 beschrieben und gelten für alle Leistungsberei- che.
- Enterprise Data Warehouse und Datenmodellierung Konzeption, Aufbau, Weiterentwicklung und Pflege der fachlichen Datenmo- delle, integrierten Datenstrukturen und Data-Mart-Strukturen der neuen Re- porting Plattform. Dies umfasst die fachliche Modellierung, die Umsetzung des Data Marts „Meldewesen“ sowie weitere im Rahmen der Weiterentwicklung, die Dokumentation der Datenmodelle sowie die Unterstützung fachlicher Ab- stimmungen und Abnahmen. (Details in Kapitel 2.4 „Enterprise Data Warehouse und Datenmodellierung“)
- ETL-/ELT-Prozesse und Datenintegration Konzeption, Entwicklung, Wartung und Optimierung der Lade-, Prüf- und Transformationsprozesse für die neue Reporting Plattform. Dies umfasst die fachliche und technische Spezifikation von Datenflüssen, Mapping-Regeln, Transformationslogiken, Datenqualitätsregeln, Fehlerbehandlung und Wieder- anlaufverfahren. (Details in Kapitel 2.5 „ETL-/ELT-Prozesse und Datenintegration“)
- Berichtswesen, Power BI und Self-Service BI Umsetzung von Berichten, semantischen Modellen und freigegebenen Self- Service-BI-Strukturen auf Basis der bereitgestellten Data-Mart-Strukturen. Im Seite 4 von 14
[Seite 5]
Projekt sind zwei definierte Zielberichte und der Data Mart „Meldewesen“ so- wie weitere im Rahmen der Weiterentwicklung umzusetzen. (Details in Kapitel 2.6 „Berichtswesen, Power BI und Self-Service BI“) 4. Schnittstellen und Quellsysteme Fachliche und technische Konzeption der Anbindung von SAP WIBank als ini- tialem operativem Quellsystem sowie Vorbereitung der Architektur für spätere Quellsysteme in der Projektphase. In der Weiterentwicklungsphase sollen An- bindungen an weiteren Quellsysteme (Kundenportal, Helaba EDW und För- derwerk) erfolgen. Die konkrete Ausgestaltung der Datenbereitstellung, Schnittstellenverträge und Lieferobjekte erfolgt je Einzelbeauftragung. (Details in Kapitel 2.7 „Schnittstellen und Quellsysteme“) 5. Anwendungsbetrieb und Support: Unterstützung im laufenden Betrieb: Ticket-Bearbeitung im 2nd Level Sup- port. Betriebsunterstützungsleistungen
2.3 Technische Zielarchitektur und technische Anforderungen
2.3.1 Zweck und Geltungsbereich Dieses Kapitel beschreibt die übergreifenden technischen Anforderungen an die neue Reporting Plattform der WIBank. Die nachfolgenden fachlichen Leistungsbe- reiche verweisen auf dieses Kapitel und konkretisieren jeweils nur die bereichsspe- zifischen Aufgaben, Liefergegenstände und Abnahmekriterien. Die technischen Anforderungen gelten für alle Entwicklungs-, Integrations-, Migrati- ons-, Reporting-, Betriebsunterstützungs- und Qualitätssicherungsleistungen im Rahmen der Einzelbeauftragungen. Ziel ist eine skalierbare, revisionssichere, wart- bare und erweiterbare Plattformarchitektur, die den aktuellen On-Premises-Betrieb unterstützt und spätere Erweiterungen um zusätzliche Quellsysteme und Data Marts ohne grundlegendes Re-Design ermöglicht. Die in dieser Leistungsbeschreibung genannten Produkte, Technologien und Werk- zeuge (z. B. Microsoft SQL Server, Informatica, Power BI, Automic, Active Direc- tory/Entra ID) ergeben sich aus der bestehenden bzw. vom Auftraggeber vorgege- benen Systemlandschaft und Zielarchitektur und sind zur Sicherstellung der In- teroperabilität, Wartbarkeit und Betriebsfähigkeit erforderlich. Sie sind insoweit nicht frei wählbar, sondern als technische Rahmenbedingung zu verstehen.
2.3.2 Plattform- und Zielarchitektur Die neue Reporting Plattform ist als Microsoft-SQL-Server-basierte Enterprise-Data- Warehouse-Architektur aufzubauen und weiterzuentwickeln. Die Architektur besteht aus logisch, berechtigungstechnisch und physisch getrennten Datenschichten bzw. Datenbanken. Die Zielarchitektur umfasst folgende Schichten:
• RDS - Raw Data Store / Rohdatenschicht
• IDS - Integrated Data Store / integrierte Datenschicht
• DM - Data-Mart-Schicht
• META - Metadaten-, Steuerungs-, Logging- und Monitoring-Schicht Die Datenbanken Athena_RDS, Athena_IDS, Athena_DM und Athena_META sind als getrennte technische Schichten vorzusehen. Die Plattform ist für den
Seite 5 von 14
[Seite 6]
Projektumfang rein On-Premises auszulegen; eine spätere Cloud-Nutzung ist nicht Gegenstand des Projekts.
Die Architektur muss spätere Erweiterungen um weitere Fachbereiche, zusätzliche Data Marts und weitere Quellsysteme ermöglichen.
- Im Abschnitt 2.3.4 sind die möglichen Lösungswege aufgeführt.
2.3.3 Datenarchitektur, Historisierung und Versionierung Die RDS-Schicht dient der unveränderten, nachvollziehbaren und revisionssicheren Ablage übernommener Rohdaten. Nach der fachlich-technischen Übergabe dürfen Daten nicht manuell verändert werden. Korrekturen, Nachlieferungen und erneute Bereitstellungen sind versioniert, protokolliert und fachlich nachvollziehbar zu verar- beiten. Die IDS-Schicht dient der fachlichen Integration, Harmonisierung und Historisierung der Daten. Hier sind fachliche Schlüssel, Codes, Statuswerte, Datums-, Betrags-, Mengen- und Währungsfelder konsistent zu behandeln. Für die Historisierung sind folgende Mechanismen vorzusehen:
• System-Versioned Temporal Tables in der IDS für SCD2-ähnliche Historisie- rung
• Snapshot-basierte Historisierung in den Data Marts
• Batch-, Lauf- bzw. LOAD_ID-basierte Versionierung über alle relevanten Ver- arbeitungsschichten
• Nachvollziehbare Behandlung von Full-, Delta-, Korrektur- und Nachlieferun- gen
Seite 6 von 14
[Seite 7]
• Protokollierung fachlicher und technischer Datenqualitätsprüfungen in der META-Schicht Die Data-Mart-Schicht stellt freigegebene, fachlich geprüfte und für Berichts- zwecke optimierte Datenstrukturen bereit.
2.3.4 Datenintegration, Schnittstellen und Quellsystemanbindung SAP WIBank ist im Projekt Neue Reporting Plattform das initiale operative Quellsys- tem. In der Weiterentwicklung werden weitere Quellsysteme (Helaba EDW, Kunden- portal und Förderwerk) angebunden. Die konkrete technische Form der Datenbereitstellung ist je Quellsystem, Datenob- jekt und Liefergegenstand im Rahmen der Konzeption und Einzelbeauftragung fach- lich und technisch zu bewerten, zu spezifizieren und mit den beteiligten Architektur-, Betriebs-, Sicherheits- und Fachbereichen abzustimmen. Für alle Quellsysteme kommen folgende Bereitstellungsvarianten in Frage, die zu bewerten und bei Eignung umzusetzen wären:
• Bei SAP- und Non-SAP-Systeme
• Flatfile-basierte Lieferung über eine definierte Datenrampe
• Extraktion über Informatica-Connectoren
• Bei SAP-Systeme:
• Extraktion über Informatica-Connectoren bzw. Table-Reader-Ansätze auf geeigneten SAP-CDS-Views
• Bereitstellung über TDE der Infofabrik
• weitere geeignete technische Verfahren, sofern diese die Anforderungen an Datenqualität, Nachvollziehbarkeit, Sicherheit, Betrieb und Revisionssicherheit erfüllen Für jede Bereitstellungsvariante sind geeignete Schnittstellen-, Liefer- bzw. Extrakti- onsverträge zu erstellen. Diese müssen Struktur, fachliche Bedeutung, technische Formate, Pflichtfelder, Datentypen, Schlüssel, Lieferart, Frequenz, Delta- bzw. Än- derungslogik, Kontrollinformationen, Fehlerbehandlung, Wiederanlauf und Nachvoll- ziehbarkeit beschreiben. Bei Flatfile-basierten Lieferstrecken sind zusätzlich Dateiformate, Kodierung, Na- menskonventionen, Kontrollinformationen, Hashwerte bzw. Prüfsummen, technische Eingangsprüfungen, Archivierung der Originallieferungen sowie Fehler- und Reject- Verzeichnisse zu definieren. Bei einer Extraktion über Informatica-Connectoren bzw. Table Reader aus SAP- CDS-Views sind die zugrunde liegenden CDS-Views, Selektions- und Delta-Krite- rien, Berechtigungen, Extraktionsfrequenzen, technische Laufzeitparameter, Fehler- behandlung, Monitoring und Lineage zu dokumentieren.
2.3.5 ETL-/ELT-Verarbeitung und Orchestrierung Die Lade-, Prüf- und Transformationsprozesse können sowohl datenbanknah auf Basis von Microsoft SQL Server und T-SQL als auch werkzeuggestützt mit Informa- tica CDI/PC umgesetzt werden. Der Auftragnehmer muss beide Ansätze beherr- schen, bewerten und abhängig von fachlichen, technischen, regulatorischen und be- trieblichen Anforderungen geeignet einsetzen können. Die Verarbeitung muss folgende Anforderungen erfüllen:
Seite 7 von 14
[Seite 8]
• transaktionale, nachvollziehbare, revisionssichere und wiederanlauffähige Verarbeitung
• Verarbeitung von Full- und Delta-Lieferungen
• LOAD_ID- bzw. laufbezogene Steuerung
• technische Eingangsprüfung auf Vollständigkeit, Struktur, Format, Namens- konventionen, Kontrollinformationen und technische Plausibilitäten
• regelbasierte fachliche Datenqualitätsprüfungen
• Fehler-, Reject- und Quarantäneprozesse
• End-to-End-Logging, Monitoring und Lineage
• dokumentierte Wiederanlaufverfahren
• nachvollziehbare Behandlung von Korrektur- und Nachlieferungen Automic ist als zentrale Orchestrierungsinstanz für Ablaufsteuerung, Scheduling und Monitoring vorzusehen, soweit dies für die jeweiligen Prozesse erforderlich ist.
2.3.6 Reporting-, BI- und Zugriffsschicht Power BI ist das primäre Reporting- und Analysewerkzeug der neuen Reporting Plattform. Berichte, Dashboards und semantische Modelle sind auf freigegebenen Data-Mart-Strukturen aufzubauen. Die Reporting- und BI-Schicht muss folgende Anforderungen erfüllen:
• Nutzung freigegebener Data-Mart-Objekte als fachlich geprüfte Datenbasis
• Aufbau semantischer Modelle und zentral definierter Kennzahlenlogik
• Performance-Optimierung für Standardberichte
• Dokumentation von Datenquellen, Filterlogik, Berechnungsvorschriften und fachlichen Freigaben
• technische Vorbereitung von SQL Server Reporting Services (SSRS) / SQL Server Report Builder
2.3.7 Metadaten, Logging, Monitoring und Lineage Die META-Schicht ist als zentrale technische Grundlage für Steuerung, Protokollie- rung, Monitoring, Datenqualität und Nachvollziehbarkeit vorzusehen. Sie umfasst:
• Prozessstatus und Laufsteuerung
• LOAD_ID-, Batch- und Ausführungsinformationen
• technische und fachliche Fehlerprotokolle
• Datenqualitätsprüfungen und DQ-Ergebnisse
• Lineage-Informationen
• Monitoring-Informationen
• Wiederanlauf- und Fehlerbehandlungsinformationen
• Nachvollziehbarkeit von Quelllieferungen, Transformationen und Zielbereitstel- lungen Die Protokollierung muss eine fachliche und technische Analyse von Verarbeitungs- läufen, Fehlern, Nachlieferungen und Korrekturen ermöglichen.
Seite 8 von 14
[Seite 9]
2.3.8 Entwicklung, Qualitätssicherung, CI/CD und Deployment Die Entwicklung der Datenbank- und Integrationsartefakte ist nachvollziehbar, versi- oniert und qualitätsgesichert durchzuführen. Hierfür gelten folgende technische Anforderungen:
• SQL-Projekte je DWH-Schicht
• Versionierung in Bitbucket
• Nutzung von Feature Branches und Pull Requests
• verpflichtende Code Reviews nach dem Vier-Augen-Prinzip
• reproduzierbare Builds aus Quellcode und Deployment-Artefakten
• DACPAC-basierte Datenbank-Deployments
• Bezug von Deployments auf Commit, Pull Request, Build-Lauf und Artefakt
• geeignete Deployment- und Konfigurationsartefakte für Informatica-Kompo- nenten
• technische Tests, Datenqualitätstests, Performance-Tests, Wiederanlauftests und Migrationstests Deployment-, Rollback- und Release-Verfahren sind zu dokumentieren und mit den Vorgaben des Auftraggebers abzustimmen.
2.3.9 Sicherheit, Berechtigungen und technische Schutzmaßnahmen Die Plattform ist unter Berücksichtigung der Vorgaben des Auftraggebers zu Daten- schutz, Informationssicherheit, Berechtigungskonzepten und bankfachlichen IT-An- forderungen umzusetzen. Zu berücksichtigen sind:
• rollenbasierte Berechtigungsmodelle
• Integration mit Active Directory / Entra ID
• SSO für Reporting- und Analysezugriffe
• technische Trennung der DWH-Schichten
• Schutz technischer Metadaten
• HTTPS/TLS für geeignete Kommunikationsstrecken
• SFTP/SSH für Flatfile-basierte Datenübertragungen
• nachvollziehbare Protokollierung technischer Zugriffe und Verarbeitungs- schritte
• Abstimmung mit Architektur, Betrieb, Informationssicherheit und Datenschutz
2.3.10 Performance, Skalierung und Betriebsfähigkeit Die Plattform ist auf das initiale Mengengerüst und auf künftiges Wachstum auszule- gen. Initial umfasst der Scope SAP WIBank als Quellsystem, drei Fachbereiche so- wie den Data Mart Meldewesen und spätere Weiterentwicklung. Die Lastannahme im Projekt umfasst ca. 25 Viewer, 5 Author und 2 Power User. Die Auslegung soll mindestens 150 % der zuvor genannten Ausgangslast (ca. 25 Viewer, 5 Author, 2 Power User) berücksichtigen. In der Weiterentwicklungphase wird sich diese Last- annahme erhöhen. Für Performance und Skalierung sind vorzusehen:
Seite 9 von 14
[Seite 10]
• geeignete Datenmodellierung und physische Datenbankgestaltung
• Partitionierungs- und Performancekonzepte
• Partition Switch / Sliding Window, soweit fachlich und technisch geeignet
• Performance-Optimierung für Ladeprozesse und Standardberichte
• Monitoring relevanter Laufzeiten, Datenmengen und Fehlerzustände
• Wiederanlauf- und Recovery-Fähigkeit
• Abstimmung von Backup-/Recovery-Anforderungen mit dem Betrieb
2.3.11 Betriebsdokumentation und Übergabefähigkeit Alle technischen Komponenten, Prozesse und Artefakte sind so zu dokumentieren, dass Betrieb, Weiterentwicklung, Fehleranalyse, Release-Management und Wissen- stransfer möglich sind. Mindestens zu dokumentieren sind:
• Datenmodelle und Schichtenmodell
• Schnittstellen-, Liefer- und Extraktionsverträge
• Mapping-Spezifikationen und Transformationsregeln
• Informatica-Mappings, Workflows und Konfigurationen
• SQL-Projekte, Stored Procedures, Views und technische Verarbeitungslogik
• Deployment-, Rollback- und Wiederanlaufverfahren
• Betriebsdokumentation, Runbooks und Monitoringkonzepte
• Berechtigungen, technische Rollen und relevante Sicherheitsanforderungen
2.4 Enterprise Data Warehouse und Datenmodellierung
2.4.1 Zusammenfassung Das Enterprise Data Warehouse ist das zentrale fachliche Datenhaltungssystem der neuen Reporting Plattform. Es stellt eine konsistente, historisierte und geprüfte Da- tenbasis für Reporting, Analyse und Self-Service BI bereit. Der Auftragnehmer unterstützt den Auftraggeber bei der fachlichen Modellierung, der Umsetzung integrierter Datenstrukturen, der Ableitung geeigneter Data-Mart- Strukturen sowie der Dokumentation und Qualitätssicherung der Datenmodelle.
2.4.2 Mögliche Themen im Rahmen der Einzelbeauftragungen Im Rahmen der Einzelbeauftragungen können folgende Leistungen beauftragt wer- den:
• fachliche und technische Konzeption von Datenmodellen für die relevanten Fachbereiche
• Entwicklung und Pflege eines fachlich integrierten Datenmodells
• Ableitung und Umsetzung fachbereichsspezifischer Data-Mart-Strukturen
• Aufbau und Weiterentwicklung der Datenmodell- und Datenstrukturen (Daten- haltungsschicht im DWH)
• Definition und Dokumentation zentraler Kennzahlenlogiken
Seite 10 von 14
[Seite 11]
• fachliche Abstimmung von Datenmodellen, Attributen, Schlüsseln, Kennzahlen und Berechnungslogiken mit den Fachbereichen
• Unterstützung bei der Validierung historisierter Datenstände
• Dokumentation von Datenmodellen, fachlichen Modellierungsentscheidungen, Metadaten und Abhängigkeiten
2.5 ETL-/ELT-Prozesse und Datenintegration
2.5.1 Zusammenfassung Die ETL-/ELT-Schicht bildet das Rückgrat der Datenversorgung der neuen Report- ing Plattform. Sie umfasst die fachliche und technische Konzeption, Entwicklung, Wartung und Qualitätssicherung der Datenflüsse von den Quellsystemen bis in die freigegebenen Zielstrukturen. Der Auftragnehmer unterstützt bei der Spezifikation von Datenflüssen, Mapping-Re- geln, Transformationslogiken, Datenqualitätsregeln, Fehlerbehandlungsprozessen, Wiederanlaufverfahren und Abstimmprozessen mit Fachbereichen, Betrieb und Ar- chitektur.
2.5.2 Voraussichtliche wesentliche Aufgaben Im Rahmen der Einzelbeauftragungen können folgende Leistungen beauftragt wer- den:
• Konzeption, Entwicklung, Wartung und Optimierung von Lade-, Prüf- und Transformationsprozessen
• fachliche und technische Spezifikation von Datenflüssen zwischen Quellsyste- men, DWH-Schichten und Data Marts
• Erstellung und Pflege von Mapping-Spezifikationen, Transformationsregeln und Datenqualitätsregeln
• Abstimmung von Lieferobjekten, Prüfregeln, Fehlerreaktionen und fachlichen Freigabeprozessen
• Unterstützung bei der Bewertung und Spezifikation geeigneter Datenbereit- stellungsvarianten
• Umsetzung und Pflege von fachlichen Plausibilitäts- und Datenqualitätsprüfun- gen
• Unterstützung bei Test, Fehleranalyse, Wiederanlauf, Nachlieferungen und Korrekturverarbeitungen
• Dokumentation der Datenflüsse, Mapping-Spezifikationen, Transformationsre- geln, Schnittstellenverträge und Wiederanlaufverfahren
Seite 11 von 14
[Seite 12]
2.6 Berichtswesen, Power BI und Self-Service BI
2.6.1 Zusammenfassung Das Berichtswesen bildet die zentrale fachliche Nutzerschicht der neuen Reporting Plattform. Im Projekt sind zwei definierte Zielberichte umzusetzen. In der Weiterent- wicklungsphase sollen weiterer Berichte aus dem bestehenden Infoportal migriert und neue Berichte entwickelt werden. Diese werden im Rahmen der jeweiligen Ein- zelbeauftragung fachlich benannt und spezifiziert. Die fachlichen Details, konkreten Kennzahlen, Dimensionen, Filterlogiken, Berechnungsvorschriften und Abnahmekri- terien sind im Rahmen der Einzelbeauftragungen mit den Fachbereichen zu schär- fen und verbindlich zu dokumentieren.
2.6.2 Voraussichtliche wesentliche Aufgaben Im Rahmen der Einzelbeauftragungen können folgende Leistungen beauftragt wer- den:
• Umsetzung definierter Berichte, Dashboards und Auswertungen auf Basis frei- gegebener Data-Mart-Strukturen
• Erstellung und Pflege semantischer Modelle
• Aufbau, Pflege und fachliche Weiterentwicklung der Berichts- und semanti- schen Modelle der Data Marts (Berichtsschicht)
• Definition und Dokumentation zentraler Kennzahlenlogiken und Berechnungs- vorschriften
• Abstimmung von Berichtsinhalten, Dimensionen, Filtern, Kennzahlen und Ab- nahmekriterien mit den Fachbereichen
• Qualitätssicherung der Berichte einschließlich fachlicher Abstimmung, Test- nachweisen und Abnahmeunterstützung
• Dokumentation aller Berichte einschließlich Datenquellen, Filterlogik, Berech- nungsvorschriften und fachlicher Freigaben
2.7 Schnittstellen und Quellsysteme
2.7.1 Zusammenfassung Im Projekt WIBank Neue Reporting Plattfom ist SAP WIBank als initiales operatives Quellsystem vorgesehen. Weitere Quellsysteme werden im Laufe der Weiterent- wicklung nach dem Projekt angebunden. Die weiteren Anbindungen müssen jedoch in der Zielarchitektur im Projekt vorbereitet werden. Der Auftragnehmer unterstützt den Auftraggeber bei der fachlichen und technischen Spezifikation der Quellsystemanbindung, der Lieferobjekte, der fachlichen Datenin- halte, der Abstimmprozesse sowie der Schnittstellen-, Liefer- bzw. Extraktionsver- träge. Die im Rahmen der Einzelbeauftragungen benötigten Datenobjekte, fachlichen In- halte, Verantwortlichkeiten, Abnahmekriterien und Lieferumfänge sind je Datenob- jekt zu spezifizieren und mit den beteiligten Fachbereichen, Architektur-, Betriebs- und Sicherheitsfunktionen abzustimmen.
2.7.2 SAP WIBank Das zentrale und operative, für die WIBank dedizierte SAP-System ist die Hauptda- tenquelle der neuen Reporting Plattform. Das SAP-System wird bereits in einem se- paraten Projekt von ECC auf S/4Hana angehoben und beinhaltet folgende Module: Seite 12 von 14
[Seite 13]
• ABAKUS - Förderbankensystem der Bankenkooperation / SAP Parzival
• FI - Finanzwesen
• CO - Controlling
• GP - Geschäftspartner
• CML/CMS - Kreditmanagement
2.7.3 Kundenportal der WIBank Das Kundenportal stellt Antragstrecken für Endkunden bereit. Eine Anbindung soll erst im Rahmen der Weiterentwicklung erfolgen.
2.7.4 Enterprise Data Warehouse (EDW) der Helaba Das EDW ist das zentrale DWH der Helaba und muss auch täglich mit Daten der WIBank beliefert werden. Eine Monatsverarbeitung soll auch bi-direktional mit Transfer von Daten über mehrere Bankarbeitstage umgesetzt werden. Eine Anbin- dung soll erst im Rahmen der Weiterentwicklung erfolgen.
2.7.5 Förderwerk Das Förderwerk ist ein SAP-System, was alle Landwirtschaftsförderungen für die WIBank abwickelt. Eine Anbindung soll erst im Rahmen der Weiterentwicklung erfol- gen.
2.7.6 Historische Infoportal-Daten Die Übernahme historischer Daten aus dem bestehenden Infoportal ist vorgesehen. Umfang, Migrationslogik, Datenqualität, fachliche Abnahmekriterien, Verantwortlich- keiten und Priorisierung sind im Rahmen der jeweiligen Beauftragung zu konkreti- sieren.
2.8 Support
2.8.1 Support-Modell Für den Support gilt folgende Aufgabenverteilung:
• Nur 2nd-Level-Support
• Kommunikation mit Endanwendern grundsätzlich über den Auftraggeber
2.8.2 Wesentliche Aufgaben • Bearbeitung von Tickets (überwiegend Change-Anforderungen)
• Wartungs- und Pflegemaßnahmen (z.B.: Bugfixes, Performance-Optimierungen) auf Basis von Service-Abrufen oder Wartungskontingenten
• Durchführung der Pflichtschulungen der Helaba für externe Dienstleister
• Dokumentation von Systemkonfigurationen
2.8.3 Qualitätssicherung Die Qualitätssicherung erstreckt sich als Querschnittsthema über alle Leistungsbereiche:
• Sicherstellung der Reproduzierbarkeit produktiver Softwareversionen aus dem Quell- code
Seite 13 von 14
[Seite 14]
• Erstellung und Pflege von Software-Stücklisten (SBOM)
• Etablierter Prozess für sichere Softwareentwicklung (SSDLC)
• Automatisierte Tests in CI/CD-Pipelines
• Code-Reviews nach dem Vier-Augen-Prinzip und statische Code-Analysen
Seite 14 von 14