Überblick Konditionsbaustein

Präsentation zum Thema: "Überblick Konditionsbaustein"—  Präsentation transkript:

1 Überblick Konditionsbaustein
Fachliche und technische Aspekte des Konditionsbausteins Horst Stein, AEW2PA / Matthias Maag, AEW1KB | JBFOne 2009

2 Ziel dieses Vortrags Sie gewinnen einen fachlichen Eindruck über den Konditionsbaustein am Beispiel „Kontokorrent“ Sie gewinnen einen technischen Überblick über die verwendeten Konzepte Sie bekommen eine Vorstellung davon, was auf Kernerneuerungsprojekte zukommt Sie wissen, welche Funktionen bereits allgemeingültig implementiert sind

3 Agenda Fachliche Ausgangssituation Ziel aus fachlicher Sicht
Technischer Überblick Erfahrungswerte Wieder verwendbare Konzepte

4 Agenda Fachliche Ausgangssituation Ziel aus fachlicher Sicht
Technischer Überblick Erfahrungswerte Wieder verwendbare Konzepte

5 Alle Konditionen direkt im Produkt
Schlagworte rund um den Konditionsbaustein agree® BAP: Vertrags-abrechnung vereinfachte Prozesse kein Medienbruch spartenneutral agree® BAP: Vertragsabrechnung Flexible Produktgestaltung mit dem Konditionsbaustein

6 agree® BAP: Vertragsabrechnung - „Konditionsbaustein“: Die Vertragsabrechnung wuchs in verschiedenen Systemen IST IKESA KONTO IST-Zustand PRODUKT Steuerungen und Datenhaltung sind in unterschiedlichen Umfeldern zu pflegen

7 agree® BAP: Vertragsabrechnung - „Konditionsbaustein“: Heute „tickt“ jede Sparte anders und ist anders gewachsen IST Laufzeit: Feste Laufzeiten Mindestlaufzeiten von - bis Konditionen: im Produkt im IKESA KOSL Echtzinssätze Umfeld: Getrennte Lösungen je Sparte / Kontoart Verwaltungsprogramme: Grundlagen Methoden Regeln Entgelte: im Produkt im IKESA in anderen Anwendungen (Dauerauftrag, ZV, Karte, etc.) Und weitere: Zahlungsvereinbarung Kündigung Bilanzierung etc.

8 Agenda Fachliche Ausgangssituation Ziel aus fachlicher Sicht
Technischer Überblick Erfahrungswerte Wieder verwendbare Konzepte

9 Zahlungsvereinbarung
agree® BAP: Vertragsabrechnung - „Konditionsbaustein“ Das Ziel ist eine spartenneutrale Querschnittszerlegung Konto-basierte Produkte haben eine einheitliche Grundstruktur, wenn man sie querschnittlich funktional betrachtet *: Konditions-baustein Konto korrent Spar- einlagen Termin einlagen Ge- schäfts- anteile Darlehen Emis- sionen Derivate Zins Preis Laufzeit Zahlungsvereinbarung Auszug Kündigung Bilanzierung heutige Sparten Querschnittliche Zerlegung * nicht alle Produkte haben alle Bausteine

10 agree® BAP: Vertragsabrechnung - „Konditionsbaustein“ Künftig soll zusammen sein, was zusammengehört
IKESA Kontokorrent-Produkt Bisher wurden Zinssätze im KOSL verschlüsselt und im IKESA zur Produktkondition zusammengefasst. Diese Produktkondition wurde als Referenz im Produkt hinterlegt Künftig werden die Zins- sätze direkt im Produkt eingepflegt. Damit befinden sich alle abrechnungs- relevanten Daten direkt im Produkt Produktkondition ALT Dokumentation Kondition Information KOSL Identifikation Stammdaten Disposition/ Zahlungsabwicklung Zinssatz Kontokorrent-Produkt Zins/Preis Abrechnung Konditions- übersicht Information NEU Identifikation Stammdaten Disposition/ Zahlungs- abwicklung Bilanz/ Controlling

11 agree® BAP: Vertragsabrechnung - „Konditionsbaustein“ Neu sind zusammengehörige Dinge an einem Ort – für jede Sparte ALT NEU Kondition BAP Kondition Zinsart Referenz BAP Zinsart IKESA Referenz Zins Zins IKESA Systembrüche und eine Vielzahl von Referenzen innerhalb des Produkts verlangen vom Nutzer ein aufwändiges Durchhangeln durch Bildschirme, um die effektiven Zinsen zu bearbeiten. In der neuen Welt findet der Nutzer zusammengehörige Daten an einem Ort – für jede Sparte gleich

12 agree® BAP: Vertragsabrechnung - „Konditionsbaustein“ Nutzen
Weniger Pflegeaufwand, da echte Zinssätze und Preise direkt in Produkt und Vertrag enthalten sind. Dadurch entfällt auch der Konditionsschlüssel Keine Medienbrüche, da sich alle Inhalte in agree BAP befinden; der Umweg über IKESA entfällt Ihr Nutzen Zeitersparnis, da die Prozesse einfacher und schlanker werden und die Erfassung redundanter Daten entfällt Hoher Individualisierungsgrad, da die Bank zahlreiche Möglichkeiten hat, ihre Konditionen selbst zu modellieren Einheitliches Look and Feel, da alle Eingabebildschirme und Arbeitsabläufe in allen Produkten gleich sind

13 Agenda Fachliche Ausgangssituation Ziel aus fachlicher Sicht
Technischer Überblick Erfahrungswerte Wieder verwendbare Konzepte

14 Überblick Abrechnung 0/66/138 (Überschrift) 242/79/18 (Akzente)
11/137/198 106/172/218 223/234/246 164/197/229 197/199/200 156/157/159 77/75/74 0/66/138 (Überschrift) 242/79/18 (Akzente) 131/174/211 (Hintergrund Schaubild/Foto) 213/227/248 (Hintergrund Text/Diagramm) Füllfarben Überblick Unload Produkt Unload IKESA Unload Limite BAP Produkt Produkt-Datenbank (IMS) 2. Produktdaten schreiben (Tx) Abrechnung Eingangs- liste Hinweis liste Produktkonditionen (DB2, bi-temp) Abrechnungs liste BAP JBF-Server Abrechnungs beleg 1. Konditionen schreiben Historien konto KK-Datenbank (IMS) Service Update GV bei bearbeiten/ändern Aktivität DWH BAP Kontokorrent 2. Kontodaten schreiben (Tx) Berechnung (SAP) Individualkonditionen (DB2, bi-temp) Buchung 1. Individualkondi-tionen schreiben (optional) Unload Vertrag Unload Kunde

15 Datenbank-Zugriff Verwendung einer Transaktionsklammer zur Konsistenz der Daten Wegen bitemporaler Datenhaltung fachlich korrekter Zugriff über Service-, Fach- oder Zugriffsprogramme (gemäß aSA) möglich Datenbereitstellung für Dialog und Batch in jeweils geeigneter Form Benötigte Schnittstellen wurden fachlich für Abnehmer optimiert

16 Agenda Fachliche Ausgangssituation Ziel aus fachlicher Sicht
Technischer Überblick Erfahrungswerte Wieder verwendbare Konzepte

17 Erfahrungswerte Die fachlichen Aufwände inklusive Test wurden unterschätzt Die Aufwände für die Koexistenzphase (Anpassung bestehender Programme) wurden extrem unterschätzt Eine Qualitätssicherung der Abrechnung und der damit erfolgten Migration war nur mit automatisierten Tests möglich Neue Technik ist sehr gut beherrschbar Das Datenbankdesign muss sowohl für JAVA als auch für COBOL tragfähig sein, da mit verschiedenen Techniken darauf zugegriffen wird (Framework vs. Native SQL) JAVA gibt Datenmodell vor, da COBOL-seitig nur Lesezugriffe erfolgen Bei Erweiterungen des entwickelten Datenmodells (Vertrag) muss auf Kontinuität (z. B. Bi-Temp) geachtet werden

18 Agenda Fachliche Ausgangssituation Ziel aus fachlicher Sicht
Technischer Überblick Erfahrungswerte Wieder verwendbare Konzepte

19 Wieder verwendbare Konzepte
Generator für DDLs aus RSA heraus Transaktionsklammer Bitemporale Datenhaltung Kundenindividuelle Mitteilung Eingangsliste Hinweisschreibung aCI-Batch (Massenänderung Konditionen) Zugriffsservice für eBanking

20 Zusammenfassung In „Produkt“ werden die Konditionen abgelegt und in „Konto“ bei Bedarf individualisiert Weitere Kontosparten (als nächste Darlehen) werden dieser Philosophie folgen Es wurde kein Projekt, sondern ein System implementiert Der Aufwand zum Verständnis der bitemporalen Datenhaltung/des Datenmodells ist nicht zu unterschätzen Die wieder verwendbaren Konzepte sind so implementiert, dass nachfolgende Projekte diese verwenden können

21 Fragen? – Diskussion? Matthias Maag Horst Stein Anwendungsentwicklung
0721/ Horst Stein 0721/

22 Ihr IT-Partner Vielen Dank