SAS Banking Intelligence Architecture Detail Data Store (SAS BIS DDS)

Präsentation zum Thema: "SAS Banking Intelligence Architecture Detail Data Store (SAS BIS DDS)"—  Präsentation transkript:

1 SAS Banking Intelligence Architecture Detail Data Store (SAS BIS DDS)
Einführung für VW FS –

2 Ziele und Erwartungen – kurze Einführung
Agenda Ziele und Erwartungen – kurze Einführung Datenhaltungskonzepte und Banking DDS Physische Designprinzipien Datenmodellierungsaspekte und Erweiterbarkeit Logische Designprinzipien Allgemein und anhand eines konkreten Themas: Meldewesen Banking DDS Betrieb Installation und Beladung Diskussion und Verbleib

3 Kurze einführung SAS BIS DDS

4 Muss Kriterien für DWH Strategie
Einführung Muss Kriterien für DWH Strategie Zusätzlich steigen durch Regulierung und Wettbewerbsfähigkeit die Anforderungen an Datenhaushalte: Höhere Frequenzen in der Steuerung (z.B.: täglich, untertätig in der Liquiditätssteuerung) Höhere Datenvolumen (Steuerung auf Cashflow Ebene) Häufigkeit von Modelländerungen durch Finanzproduktentwicklung Steigende Anforderungen an Datenqualität und Data Governance (BCBS 239)

5 Nutzungsflexibilität Standardisierungsbreite
DWH Wesentliche Herausforderungen Analysetiefe Grad der fachlichen Abdeckung und Potential für zukünftige Analysen Single-version-of-the-truth als Basis für einheitliches Reporting und Analytics Integrationstiefe Grad der Integration zwischen fachlichen Applikationen / Nutzern des Modells Erreichung durch viele Iterationen bzgl. Gesamtdesign des Modelles Nutzungsflexibilität Qualität der Integration zwischen fachlichen Applikationen Ausreichende Flexibilität in der Nutzung durch richtige Abstraktionen Modellstabilität Grad der Auswirkung einer Änderung auf gekoppelten Bereiche / Module Hohe Modellstabilität ist zentrales Ziel zur Erreichung von Kostensenkungen Standardisierungsbreite Niedrige Standardisierungsbreite deutet auf zu generische Modellierung hin Hohe Standardisierungsbreite ist nicht konkret genug um Mehrwert zu bringen

6 Drei Schlüsselkriterien zur Auswahl eines Industriedatenmodells
SAS BIS DDS Praxistauglichkeit Nur nachhaltige Kundenprojekte beweisen Praxistauglichkeit. Funktionsabdeckung Datenmodell–basierende, fertige Lösungen beweisen Vollständigkeit und Richtigkeit. Vollständige Integration Nur Implementierungen aus einem Guss beweisen die Integration über alle relevanten Aspekte. 300 Referenzen weltweit Modularität Durchgängige Metadaten Einheitliche Technologie Integrierte Data Integration Tools Integrierte Data Quality Tools Durchgängige Dokumentation Durchgängige Standardisierung Erprobte Implementierungs- methodologie Banksteuerung Risikosteuerung Kundensteuerung Personal Rechnungswesen Meldewesen SAS erfüllt alle drei Kriterien!!

7 SAS BIS DDS „Das Avokado Prinzip“ SAS BIS DDS
Maximale Integrationstiefe bei sinnvoller Standardisierungsbreite Hohe Integrationstiefe bedeutet gute Modellstabilität Kostenintensive „moving source“ Szenarien werden vermieden Sicherung der Wirtschaftlichkeit der Investition durch hohe Standardisierungsbreite Beibehaltung der Nutzungsflexibilität durch einfache Erweiterbarkeit SAS BIS DDS Mangelhafte Integrationstiefe Einsatz eines nicht-integrierten Datenmodelles ist nicht sinnvoll Hohe Folgekosten durch Designiterationen und Doppelentwicklungen Mangelhafte Analysetiefe (fachliche Abdeckung) Keine Mehrwert aufgrund fehlender „Intellectual Property“ Hohe Folgekosten durch hohe Eigenentwicklung

8 Datenhaltungskonzepte und Banking DDS
Was ist das SAS BIS DDS?

9 Datenhaltungs-konzepte und Banking DDS
Zu unterstützende Prozesse – Warum Halten wir Daten? Management Prozess Umsetzung von Informationen zur Steuerung des täglichen Betriebes Business Intelligence Prozess Analytische Verarbeitung, Informationsgewinnung, Entscheidungshilfe Business Operations Prozess Verarbeitung von Informationen des normalen, täglichen Betriebes

10 Datenhaltungs-konzepte
Differenzierung Big Table Z.B.: Google Big Table Große Datenmengen – Big Data, Flache aber multidimensionale Tabelle NoSql (Not only Sql) Große Cluster Systeme als Hardware Multidimensionale Systeme Z.B.: ‚OLAP Cubes‘, Hierarchien Datenobjekte sind durch hierarchische Dimensionen organisiert – ‚Star Schema‘ Designet für analytische Anwendungen – Drilldownfähigkeiten Immer konkrete, begrenzte Anwendungen In sogenannten „Star Schemes“ umgesetzt Relationale Systeme Basieren auf der Mengentheorie Entititäten sind über Attribute verbunden durch Relationen Enstprechen der sogenannten Normalform, werden durch SQL betrieben Industrie Standard für Datenbanken seit den 1980er Jahren Technologie unabhängiges Konzept Z.B.: Teradata, Oracle, DB2, SQL Server, ...

11 Datenhaltungs-konzepte
Relational Systeme – ‚Entity/Relationship‘ ModelLe

12 Datenhaltungs-konzepte
Multi-Dimensionale Systeme – ‚Star Schema‘

13 Datenhaltungs-konzepte und Banking DDS
Zu unterstützende Prozesse – Warum Halten wir Daten? Management Prozess Umsetzung von Informationen zur Steuerung des täglichen Betriebes Business Intelligence Prozess Analytische Verarbeitung, Informationsgewinnung, Entscheidungshilfe Business Operations Prozess Verarbeitung von Informationen des normalen, täglichen Betriebes Decision Support Systeme DSS Operationale Systeme OLTP – Online Transaction Processing

14 Vergleich der Schwerpunkte
OLPT VS DDS Vergleich der Schwerpunkte Operationale Systeme - OLTP Decision Support Systeme - DSS Optimiert für: Hohe Anzahl an Transaktion mit begrenztem Datenvolumen Genau definierte, hohe Performance- anforderungen Hochverfügbarkeit – ‚system is mission critical‘ Skalierbar, wenn sich die Muster der Transaktion nicht stark ändern Konstanter Grad an Hardwareausnutzung Optimiert für: Kleine Anzahl an Einzeltransaktionen mit relativ hohen Datenvolumen Entspannte Anforderungen an Response Zeiten Integration von Daten unterschiedlicher Quellen Historische Daten werden gespeichert Hardwarenutzung erlebt immer wieder Peaks

15 Vergleich der Daten-manipulationen
Vergleich der Schwerpunkte Operationale Systeme - OLTP Decision Support Systeme - DSS Datenvolumen/Transaktion + Inserts Updates Leseprozesse Löschprozesse Datenvolumen/Transaktion +++ Inserts Updates n.a. Leseprozesse Löschprozesse n.a. Widersprüchliche Nutzungsmuster!

16 OLPT VS DsS Schlussfolgerung Widersprüchliche Nutzungsanforderungen zwischen OLTP- und DSS-Systemen Trennung der Systeme, hinsichtlich Hardware-, Software- und Datenarchitektur Unterschiedliche Designs erforderlich

17 DsS - Systeme Varianten Data Warehouse (DWH) Data Mart Operational Data Store (ODS)

18 DSS - Systeme DWH ‘... collection of subject-oriented, integrated, time-variant, nonvolatile data that is designed to support strategic decision-making for the enterprise.’ [Inmon, 2002] Eine zweite Instanz der Unternehmensdaten, die den operationalen Daten gegenüber gestellt werden Hält große Mengen an historischen Daten Integriert Daten verschiedenster Quellsysteme Zugriff von analytischen und Abfrageprozessen entweder direkt auf das DWH oder abgeleiteten Marts

19 DSS - Systeme Data mart Ein Datenstruktur, die ein spezifisches „Subset“ der Unternehmensdaten zu Analyse- und Reportingzwecken hält Maßgeschneidert für die Nutzung einzelner Abteilungen oder Geschäftsprozesse Die Daten können in eine nicht generisches Format transformiert werden, um eine eng begrenzten Anforderung Genüge zu tun

20 DSS - Systeme ODS Themenorientierte und integrierte Sammlung von Daten die für DSS genutzt werden Dient zur raschen, unmittelbaren Integration von operationalen Daten unterschiedlicher Vorsysteme Im Gegensatz zu einem DWH sind die Daten aktuell (nicht historisch) und volatil Dient oft als Quelle für ein DWH

21 Was ist das Banking DDS? SAS BIS DDS - DeFinition Das SAS BIS DDS dient als ‚single version of the truth‘ für SAS Banking Intelligence Solutions und als Basis für Anwendungen im Bereich Banksteuerung. Es enthält die Detaildaten und historische Informationen, die benötigt werden, um die fachlichen Anwendungs-Data Marts zu befüllen. Es liefert eine umfassende und integrierte Datenarchitektur. Es ist ein logisches und physische Datenmodell, das einen sehr weiten Bereich der Daten einer Bank abdeckt. Es ist ein Datenmodell, das für analytische- und Reportinganforderungen genutzt werden kann. Es ist nicht als ein operational Data Store gedacht.

22 Fokus auf Standardisierung
SAS BIS DDS Fokus Hoher Reifegrad Relationales Industrie Datenmodell in der 8. Design Iteration Ständige Weiterentwicklung durch Fachexperten bei SAS Drastische Reduzierung der Modellierungsaufwände im Unternehmen Vermeidung teurer Designiterationen Fokus auf Integration Löst Komplexität zwischen Quellsystemen und Zielanwendungsbereichen auf Erzielung von Synergieeffekten bei Datenakquisition gegenüber Insellösungen Basis für alle Gesamtbanksteuerungslösungen von SAS Fokus auf Standardisierung Etablierung einer einheitlichen „Sprache“ über Daten Hoher Abdeckungsgrad Flexibles Deployment Unterstützt Think Big – Start Focused Ansatz Deployment für ein oder mehrere SAS for Banking Solutions Deployment auf SAS Datenhaltung oder allen gängigen RDBMS

23 SAS BIS DDS Big Picture!

24 ERWin Modelle als Bestandteil der Dokumentation - Optional PowerDesigner
SAS BIS DDS

25 SAS BIS DDS Integration in Verbindung mit SAS DI Studio

26 SAS BIS DDS Integration mit SAS Data Quality Komponenten

27 Physische Designprinzipien
Datenmodellierungsaspekte und Erweiterbarkeit

28 Attributkategorisierung
SAS BIS DDS Modellierung und Standardisierung Allgemeines Relationales Datenmodell in 3. Normalform Gängige Datenbankplattformen werden unterstützt Schlüsselmanagement Generierter Surrogatschlüssel und separate Speicherung der Quellsystem ID Primärschlüssel aus Surrogatschlüssel und Gültigkeitsperioden Entitätsklassen Kategorisierung von Entitäten aufgrund gemeinsamer Charakteristika Berücksichtigung in Namenskonvention zur Reduzierung der Komplexität Attributkategorisierung Kategorisierung der Attribute aufgrund Datentype und Verwendung Berücksichtigung in Namenskonvention zur Reduzierung der Komplexität Historisierung Historisierung unter Verwendung von SCD Type 2 Konzept Optimierung auf rasches Einfügen, Löschen und Gesamtbestandsabfrage

29 Physische Designprinzipien
Surrogatschlüssel Ein Surrogatschlüssel wird generell als Primärschlüssel einer DDS-Tabelle genutzt (_RK für „Retained Key“) Ein Surrogatschlüssel ist immer numerisch und matscht 1:1 zum natürlichen Schlüssel Der Primärschlüssel ist ein kombinierter Schlüssel und enthält zusätzlich ein Gültigkeitsdatum oder noch andere Attribute Für einige Tabellentypen ist der Primärschlüssel der natürliche Schlüssel und nicht der Surrogatschlüssel, z.B. _CD in Referenztabellen

30 Physische Designprinzipien
Typische DDS Tabelle Schlüsselmanagement Surrogatschlüssel für diese Entität Primärschlüssel für diese Entität Zeitfelder für Versionierung Fachlicher, natür-licher Schlüssel für diese Tabelle

31 Physische Designprinzipien
Typische DDS Tabelle – Zusatzattribute Optional “Business Effective” Fremdschlüssel (surrogate) Attribute Columns …_CD Schlüssel einer ... Referenztabelle

32 Physische Designprinzipien
Historisierung Konzepte Hinzufügen neuer Datensätze mittels SCD Type 2 Umsetzung durch Gültigkeitsperiode (Von - Bis) Durchgängige, lückenlose Zeitscheiben erforderlich Auch zusätzliche Gültigkeitsperiode für die Historisierung von Korrekturen vorhanden Beispiel Bestehender Datensatz INTERNAL_ORG_RK VALID_FROM_DTTM VALID_TO_DTTM ORGANIZATION_NM 100 01-JAN :00:00 01-JAN :00:00 Marketing Hinzufügen neuer Information und Anpassen des bestehenden Datensatzes INTERNAL_ORG_RK VALID_FROM_DTTM VALID_TO_DTTM ORGANIZATION_NM 100 01-JAN :00:00 31-DEC :59:59 Marketing 01-JAN :00:00 01-JAN :00:00 World Wide Marketing

33 Physische Designprinzipien
Zwei Dimensionale Historisierung Beispiel Unterscheidung zwischen technischer Gültigkeit und fachlicher Gültigkeit Erfordert Adaptierung der CDC Logik Steuerung für nachfolgende Applikationen über Views Bestehender Datensatz INTERNAL_ORG_RK VALID_FROM_DTTM VALID_TO_DTTM Effective_From Effective_To ORGANIZATION_NM 100 01-JAN :00:00 01-JAN :00:00 Marketing Hinzufügen neuer Information und Anpassen des bestehenden Datensatzes INTERNAL_ORG_RK VALID_FROM_DTTM VALID_TO_DTTM Effective_From Effective_To ORGANIZATION_NM 100 01-JAN :00:00 31-DEC :59:59 Marketing 01-JAN :00:00 01-JAN :00:00 World Wide Marketing

34 Physische Designprinzipien
Zwei Dimensionale Historisierung Domäne Namens-konvention Kommentar / Beispiel Identifier _ID z.B. ID in Quellsystemen (CUSTOMER_ID) Small Code _CD z.B. ADRESS_TYPE_CD Medium Code z.B. EXCHANGE_SYMBOL_CD Large Code z.B. POSTAL_CD Count Code _CNT z.B. AUTHORIZED_USER_CNT Name _NM z.B. FIRST_NM Short Length Text _TXT Beliebige Verwendung Medium Length Text _TXT, _DESC Beliebige Verwendung, z.B. code table desc. Indicator Field _FLG Binärindicator, z.B. DEFAULT_FLG Surrogate Key _RK, _SK Generierte Surrogatschlüssel Currency Amount _AMT Standard Währungsbetrag, z.B. LIMIT_AMT Rates _PCT, _RT z.B. exchange rates Date / Time _DT, _DTTM Datum und Uhrzeit, z.B. DEFAULT_DATE

35 Physische Designprinzipien
RelationsnotatioN Das DDS Datenmodel nutzt die Entity Relationship Notation, wie sie im Erwin Data Modeler benutzt wird. Beispiel einer 1:1 Relation:

36 Physische Designprinzipien
RelationsnotatioN Beispiele von 1:N Relationen: Optionale Relation zwischen Department und Employee (beide Richtungen) Verpflichtende Relation zwischen Department und Employee (beide Richtungen) Employee muss ein Department haben, das Department muss keinen Employee haben

37 Physische Designprinzipien
RelationsnotatioN Beispiel einer identifizierenden Relation: Die Beziehung zeigt an, dass ein EMPLOYEE nicht außerhalb des Kontext eines Departments existieren kann Identifizierende Relation zwischen Tabellen

38 Physische Designprinzipien
RelationsnotatioN Beispiel von M:N Relation: Ein Konto kann mehreren Kunden gehören und ein Kunde kann mehrere Konten besitzen Diese M:N Relation kann durch das Einführen einer Zwischentabelle im physischen Datenmodell aufgelöst werden

39 Physische Designprinzipien
Modellierung Supertyp/Subtyp Relationen Immer wenn mehrere Tabellen Informationen gemeinsam haben, werden sie in einer Tabelle gespeichert: Gemeinsame Informationen in einer Tabelle Verschiedene Informationen in getrennten Tabellen Ein Attribut in der Supertyptabelle dient als Diskriminator um die richtige Subtyptabelle zu finden Beispiel: Gemeinsame Tabelle Account Loan Account Tabelle Mortgage Account Tabelle andere Account Tabellen

40 Physische Designprinzipien
Supertype/Subtype tables Gleiche Surrogatschlüssel Diskriminator Attribut

41 Physische Designprinzipien
Modellierung: „Frequently Changing Data“ Immer wenn eine Tabelle sowohl schnell als auch langsam ändernde Attribute aufweist: Die schnell ändernden Attribute werden in eine getrennte Tabelle ausgelagert Beispiel: Account Tabelle Open Date Close Date Andere statische Attr. Account Change Tabelle Balance Outstanding Days Andere rasch ändernde Attr.

42 Physische Designprinzipien
Transaktionstabelle Transaktionstabellen dienen zum Speichern von Events, die zu einem bestimmten Zeitpunkt passieren. Eine typische Spalte ist das TRANSACTION_DT, meist kein VALID_FROM – VALID_TO:DT Zum Beispiel Zahlungen auf einem bestimmten Konto Beispieltabellen: LOAN_TRANSACTION FX_QUOTE CUSTOMER_ACCOUNT_SCORE

43 Physische Designprinzipien
Referenztabellen Referenztabellen enthalten Code Definitionen und deren Übersetzung. Referenztabellen haben immer ein _CD Attribut für den Code ein _DESC Attribut für die Beschreibung der Codebedeutung Referenztabellen enthalten Attribute zur Historisierung im Falle einer Änderung einer Codebedeutung Referenztabellen enthalten ein LANGUAGE_CD Attribut, um Bedeutungen von Codes in unterschiedliche Sprachen Übersetzen zu können Beispiele: ACCOUNT_STATUS ASSET_TYPE

44 Physische Designprinzipien
Mastertabellen Mastertabellen sind Tabellen von zentraler Bedeutung, sie haben meist mehr als 100 Zeilen und sie werden häufig beladen (abgeändert) Mastertabellen enthalten typischerweise fünf folgende Attribute: * _RK für den Surrogatschlüssel VALID_FROM_DTTM und VALID_TO_DTTM für die Historisierung *_ID für den natürlichen, fachlichen Schlüssel SOURCE_SYSTEM_CD zu Speicherung des Quellsystems aus dem das *_ID Feld stammt Beispiele: FINANCIAL_PRODUCT FINANCIAL_ACCOUNT CUSTOMER COUNTERPARTY

45 Physische Designprinzipien
Intersection Tabellen Intersection Tabellen werden benötigt, um M:N Beziehungen aufzulösen. Z.B: Ein Mitarbeiter kann mehr als einer internen Organisationseinheit angehören und eine interne Organisationseinheit hat meist mehr als einen Mitarbeiter Sind an *_X_* im Namen zu erkennen Beispiele: EMPLOYEE_X_INTERNAL_ORG CUSTOMER_X_FINANCIAL_ACCOUNT

46 Physische Designprinzipien
Assoziationstabellen Assoziationstabellen werden verwendet um Beziehungen zwischen zwei Zeilen einer Tabelle herzustellen Assoziationstabellen haben ein _ASSOC Suffix. Alle Assoziationstabellen haben ein ASSOC_TYPE_CD Attribute, um die Art der Beziehung zwischen den beiden Zeilen zu definieren Assoziationstabellen können zum Speichern von Hierarchien verwendet werden Beispiele: INTERNAL_ORG_ASSOC PRODUCT_CATEGORY_ASSOC

47 Physische Designprinzipien
Assoziationstabellen Assoziationstabellen werden verwendet um Beziehungen zwischen zwei Zeilen einer Tabelle herzustellen Assoziationstabellen haben ein _ASSOC Suffix. Alle Assoziationstabellen haben ein ASSOC_TYPE_CD Attribute, um die Art der Beziehung zwischen den beiden Zeilen zu definieren Assoziationstabellen können zum Speichern von Hierarchien verwendet werden Beispiele: INTERNAL_ORG_ASSOC PRODUCT_CATEGORY_ASSOC

48 Physische Designprinzipien
Hierarchien mit Assoziationstabellen Internal_Org Tabelle Beispiel: Interne Organisationsstruktur INTERNAL_ORG_RK ORG_NM INTERNAL_ORG_REFERENCE_NO 3001 ORG1 IT1 3002 ORG2 IT2 4001 ORG3 T2 4002 ORG4 T3 5001 ORG5 AT3 ORG 5 ORG 3 ORG4 ORG 1 ORG 2 GEO – Geographische Hierarchie REP – Reportinghierarchie

49 Physische Designprinzipien
Assoziationstabellen Designvorteile: Bietet Modellierungsmöglichkeiten für: Multiple Hierarchien Hierarchien variabler Tiefe Vermeidet die Notwendigkeit Hierarchie/Levels hart zu codieren Sehr flexibel verwendbar und reduziert daher die Notwendigkeit individuelle Datenmodellanpassungen vorzunehmen

50 Physische Designprinzipien
Erweiterbarkeit des SAS BIS DDS (Customizing)

51 Physische Designprinzipien
Customization Adding Tables You can add tables to support a new business area or to enhance the functionality of an existing business area that is not in the current banking DDS. New tables should be added with a prefix (for example, X_) to distinguish them from tables that are provided in the current banking DDS. Adding Columns You can add columns to existing tables in the banking DDS to support a new business area or to enhance the functionality of an existing business area that is not in the current banking DDS. New columns should be added with a prefix (for example, X_) to distinguish them from columns that are provided in the current banking DDS.

52 Physische Designprinzipien
Customization Expanding Column Length You can expand the column length to accommodate the data from upstream applications. You should perform an impact analysis before expanding the length of a column to avoid truncation in tables in downstream applications. Changing Formats and Informats You can change the formats and informats to address the local language requirements. Storing Descriptions in Different Languages Reference tables allow descriptions to be stored in multiple languages. Use the LANGUAGE_CD column in the reference table to specify the language for the description. Remember the downstream processing impact if you store a description in more than one language.

53 Physische Designprinzipien
Modifications to Avoid Avoid changing column names. They have significant impact on already implemented downstream processing. Avoid changing data types for columns. This can also have significant impact on already implemented downstream processing. Deletion of columns is not recommended. Columns that are not required by the client can hold missing values. Avoid changing the intended content of columns. Add a new column instead.

54 Physische Designprinzipien
Process for Model Modifications Goal is: Create new/modified physical data structures Update the SAS metadata structures End product: Updated DDL saved to source management Updated documentation (ERWin file, data dictionary, pdfs)

55 Physische Designprinzipien
Process for Model Modifications 1. Make addition in ERWin file or update DDL scripts directly 2. Create Physical tables by running DDL 3. Update Metadata definitions For tables - “Register Tables” For columns - “Update Metadata” 4. Store updated collateral/code in source management DDL, ERWin file, Data Dictionary

56 Logische Designprinzipien
Allgemein und anhand eines konkreten Themas: Meldewesen

57 Logische Designprinzipien
Modell Design Grobe Einteilung Das SAS BIS DDS kann auf einer groben Ebene in sogenannte „Subject Areas“ eingeteilt werden „Subject Areas“ „Subject Areas“ kann man als oberste Ebene von Geschäftsobjekten verstehen. Geschäftsobjekte Diese Geschäftsobjekte stehen in einer logischen Verbindung zueinander

58 Logische Designprinzipien
„Subject Areas“

59 Logische Designprinzipien
Überblick fachliche Inhalte und „Subject Areas“

60 Logische Designprinzipien
Vier wesentliche „Subject Areas“ im Detail Parties Financial Accounts (Financial Instruments, Financial Postions) Credit Facility Credit Risk Mitigant

61 Logische Designprinzipien
„Subject Area“: „Parties“

62 Logische Designprinzipien
„Subject Area“: „Parties“ Kernkonzept Eine COUNTERPARTY kann ein CUSTOMER sein oder auch nicht Eine COUNTERPARTY wird genauer spezifiziert durch: CUSTOMER, oder EXTERNAL_ORGANISATIONON, oder EXTERNAL_INDIVIDUAL, oder INTERNAL_ORGANISATION, oder EMPLOYEE … Ein Kunde ist entweder ein INDIVIDUAL_CUSTOMER oder ein CORPORATE CUSTOMER

63 Logische Designprinzipien
Counterparty Counterparty Customer External Org Internal Org External Individual Employee

64 Logische Designprinzipien
Customer Customer Individual Customer Corporate Customer Employee External Organization Owners

65 Logische Designprinzipien
„Subject Area“: „Financial Accounts”

66 Logische Designprinzipien
„Subject Area“: „Financial Accounts”

67 Logische Designprinzipien
„Subject Area“: „Financial Account” Account Typen des SAS BIS DDS: Savings Checking / Current Loan Mortgage Credit Card Investment Core Banking Account Lease Account Life Insurance Motor Insurance Travel Insurance Property Insurance Protection Insurance Retirement / Pension

68 Logische Designprinzipien
„Subject Area“: „Financial Accounts” Counterparties Credit Facilitie Credit Risk Mitigants Customers Transactions Financial Accounts Account Types Specific Provisions Credit Assessments

69 Logische Designprinzipien
„Subject Area“: „Financial Instruments“

70 Logische Designprinzipien
„Subject Area“: „Financial Instruments“ Kernkonzept Alle gehandelten Wertpapiere werden in diesen Entitäten gespeichert. Es gibt eine Beziehung zu den RISK_FACTOR TABELLEN. FINANCIAL_POSITION nimmt Daten zu einzelnen Positionen und Transaktionen auf. Es gibt eine Verbindung zu COUNTERPARTY. Es gibt eine Verbindung zu CREDIT_RISK_MITIGANT Daten. Es gibt eine Verbindung zu Ratings. Es gibt eine Verbindung zu Ausfällen und Verzügen.

71 Logische Designprinzipien
„Subject Area“: „Financial Position“

72 Logische Designprinzipien
Folgende Wertpapiertypen werden unterstützt Cash Instruments Funds Equities Bonds Commodities Currency Swaps Credit Derivatives Warrants Convertible Bonds Swaps Options Swaptions Forward Rate Agreements (FRA’s) Receivables Repurchase Agreements (Repos) Securitization Exotic Options Cash flow Options and Forwards

73 Logische Designprinzipien
Instrument Quotes Financial Instrument Association Financial Instrument Financial Instrument Calc. Spec. Financial Instrument CHNG Financial Position Derivative Equity Quote Tables Option Bond …

74 Logische Designprinzipien
„Subject Area“: „Credit Facility“ ToDo: Andreas

75 Logische Designprinzipien
„Subject Area“: „Credit Facility“ Kernkonzept Eine Credit Facility speichert jede Art von Off Balance Exposure Eine Credit Facility kann zu einem oder mehreren Fianncial Accounts gehören Es können auch verschachtelte Beziehungen zwischen Credit Facilities gespeichert werden

76 Logische Designprinzipien
„Subject Area“: „Credit Facility“ Financial Accounts Counterparties Transactions Credit Risk Mitigants Credit Facilities Groups Specific Provisions Credit Assessments

77 Logische Designprinzipien
„Subject Area“: „Credit Risk Mitigant“

78 Logische Designprinzipien
„Subject Area“: „ Credit Risk Mitigant“ Kernkonzept CRADIT_RISK_MITIGANT ist die zentrale Tabelle für alle Sicherheiten Details werden in Subtabellen abgebildet: PHYSICAL_COLLATERALLS, FINANCIAL_COLLATERALS, GUARANTEES, RECEIVEABLES Es gibt Verbindungen zu: COUNTERPARTY, FINANCIAL_ACCOUNT, FINANCIAL_POSITION und CREDIT_FACILITY, CREDIT_DERIVATIVES

79 Logische Designprinzipien
„Subject Area“: „ Credit Risk Mitigant“ Counterparty Credit Risk Mitigant Financial Position Financial Account Receivables Physical Collateral Credit Facility Guarantees Financial Collateral Credit Cerivatives Mitigant

80 Logische Designprinzipien
Vertiefung im Hinblick auf VW FS Meldewesen

81 Meldewesen Quellsysteme der VW FS
Vertiefung Meldewesen Quellsysteme der VW FS BCA - Bankingdaten, Girokonten und Direct Banking KREDIS - Kredite und Finanzierungen LEASIS – Leasingverträge CML - Darlehen an die Händler und Tochtergesellschaften CFM - Treasury ZGP - zentraler Geschäftspartner HF - Händlerfinanzierungen, als Unterstruktur zu BCA zu verstehen. FI - Debitoren und Kreditorenbuchhaltung, nur Teile des Hauptbuches FS-CD - Debitorenbuchhaltung auf Leasingforderungen LAM - Finanzierungsanfragen für KREDIS. Anträgen, nur bestätigte Anträge sind für MW relevant CIC – Claim Management EWB - Einzelwertberichtigungen LX - Large Exposures -> für Meldewesen Barsicherheiten ABS - Asset backed Securities Risk - Ausfälle, Scorings, Verzüge VOKUS - Konzernkonsolidierung, Konsolidierungskreise etc.

82 Meldewesen Quellsysteme VW FS
Mapping zu relevanten SAS BIS DDS Entitäten BCA - Bankingdaten, Girokonten und Direct Banking KREDIS - Kredite und Finanzierungen LEASIS – Leasingverträge CML - Darlehen an die Händler und Tochtergesellschaften HF - Händlerfinanzierungen, als Unterstruktur zu BCA zu verstehen. CIC – Claim Management FINANCIAL_ACCOUNT CREDIT_FACILITY LOAN ACCOUNT LEASE_ACCOUNT CORE_BANKING_ACCOUNT FINANCIAL_ACCOUNT_CHNG COUNTERPARTY CUSTOMER INDIVIDUAL_CUSTOMER CORPORATE_CUSTOMER CREDIT_RISK_MITIGANT

83 Meldewesen Quellsysteme VW FS
Mapping zu relevanten SAS BIS DDS Entitäten CFM - Treasury FINANCIAL_INSTRUMENTS FINANCIAL_POSITION BOND_INSTRUMENT EQUITY_INSTRUMENT OPTION_INSTRUMENT FINANCIAL_INSTRUMENT_ASSOC CREDIT_RISK_MITIGANT

84 Meldewesen Quellsysteme VW FS
Mapping zu relevanten SAS BIS DDS Entitäten ZGP - zentraler Geschäftspartner COUNTERPARTY CUSTOMER INDIVIDUAL_CUSTOMER CORPORATE_CUSTOMER EXTERNAL_ORGANISATION

85 Meldewesen Quellsysteme VW FS
Mapping zu relevanten SAS BIS DDS Entitäten FI - Debitoren und Kreditorenbuchhaltung, nur Teile des Hauptbuches FS-CD - Debitorenbuchhaltung auf Leasingforderungen LAM - Finanzierungsanfragen für KREDIS. Anträgen, nur bestätigte Anträge sind für MW relevant EWB – Einzelwertberichtigungen GENERAL_LEDGER FINACIAL_ACCOUN_APPLICATION SPECIFIC_PROVISION

86 Meldewesen Quellsysteme VW FS
Mapping zu relevanten SAS BIS DDS Entitäten ABS - Asset backed Securities Risk - Ausfälle, Scorings, Verzüge FINANCIAL_INSTRUMENT SECURITISATION_INSTRUMENT DEFAULT_EVENT RATING_GRADE ACCOUNT_X_RATING_GRADE INSTRUMENT_RATING_GRADE CUSTOMER_XRATING_GRADE

87 Meldewesen Quellsysteme VW FS
Mapping zu relevanten SAS BIS DDS Entitäten VOKUS - Konzernkonsolidierung, Konsolidierungskreise etc. INTERNAL_ORG INTERNAL_ORG_ASSOC EXTERNAL_ORG EXTERNAL_ORG_ASSOC

88 LogischeLogische Designprinzipien
ausgewählte Produktabbildungen im SAS BIS DDS

89 Ausgewählte Produkt-abbildungen
Optional: Darstellung Konkreter Beispiele Siehe Beispiele in Excel Darstellung

90 Banking DDS Betrieb Installation und Beladung des SAS BIS DDS

91 Installationserfordernisse
Sas Bis DDs Installationserfordernisse SAS Foundation 9.4 SAS Data Integration Studio SAS Metadata Server und ein Metadaten Repository Banking DDS: DDL Scripts Metadaten Package (SPK files) Dokumentation Erwin Data Model * Bereits für SAS Credit Scoring for Banking bei VW FS im Einsatz

92 Sas Bis DDs Installationsprocess

93 Sas Bis DDs Beladung Schritt 1: Definition der zu beladenden Daten
Das Banking DDS ist designt um mehrere Lösungen zu unterstützen, obwohl nicht alle Solution gleichzeitig implementiert werden müssen. Das BANKING DDS muss also nicht komplett befüllt werden. Eine genaue Liste der zu befüllenden Entitäten sollte erstellt werden Schritt 2: Daten aus den Quellsystemen extrahieren Schritt 3: Daten Konsolidierung und Data-Cleansing Dabei sollten die Daten bereits in die DDS Struktur gebracht werden Schritt 4: Beladung der Reference Tables Schritt 5: Beladung und Validierung der restlichen Tabellen Die korrekte Beladungssequenz muss eingehalten werden. Zum Beispiel kann einen ACCOUNT_TRANSACTION erst beladen werden, wenn der zugehörige ACCOUNT bereits existiert. Die Loading-Stage hat bereist die gleiche Struktur wie das DDS, mit der Ausnahme, dass noch keine *_RK- Felder und keine Gültigkeitsdatums existieren müssen Die Beladung erfolgt mittels des SDD II Loader-Plug-In des SAS DI Studio

94 Mehrwerte von SAS BIS DDS
Industrie Standard Datenmodell vs. Eigentwicklung

95 Argumenten für ein Industrie Standard Datenmodell
Zusammenfassung Argumenten für ein Industrie Standard Datenmodell Analystenaussagen u.a. Für Industrie Standard DM spricht: Kosteneffektiv (nicht kurzfristig, aber langfristig) Deckt aktuelle Marktanforderungen ab und ist zukunftsorientiert (wird fachlich kontinuierlich erweitert) Weitreichende Automatisierung und Standardisierung Best Practices aus einer Vielzahl von Implementierungen Stabile Basis für schnellen Projektstart Hohe Agilität und Flexibilität Fördert zentrale „Information Governance“ und den Kulturwandel im Sinne eines unternehmensweiten „single point of truth“ (inkl. Rückfluss von Ergebnisinformationen aus unterschiedl. FBen) Fördert die Kommunikation und das Verständnis für IT und Buiness Sicht > Zusammenarbeit von IT und FB durch Konzentration auf die fachlichen Inhalte und definierte Prozesse und vorgegebener Modellsicht Ist dafür ausgelegt, schnell die richtigen Informationen bereitzustellen (auswertungsorientiert)

96 Zwei wesentliche Vorteile von Buy-Variante
Make vs. Buy Zwei wesentliche Vorteile von Buy-Variante Einsparung der Modellierungsphase Reduzierung des Diskussions- und Abstimmungsaufwandes Sofortiger „Zielorientierter“ Start Komplexitätsreduktion durch 80/20 Ansatz (Kerndatenmodell) ► Bessere „Time to Intelligence“ bei höherem Lernaufwand und ca. gleichen Einführungskosten Höhere Modellstabilität in den Kernentitäten führt zu deutlich reduzierten Change-Aufwänden am Daten-Modell Einsatz in der Praxis erzeugt Investitionssicherheit Zeit Kosten Ergebnisse Deutliche schnellere Ergebnisse Geringere Folgekosten

97 Zentraler Hebel für Kostensenkung und Qualitätsverbesserung in der Steuerung
SAS BIS DDS

98 SAS BIS DDS Mehrwerte für VW FS Kürzere Implementierungszeiten durch Industriedatenmodell und vorgefertigte Komponenten Wirtschaftlichkeit im Betrieb Klare Strukturen durch Vorgaben und Reduzierung der Komplexität (Keine Work-Arounds, Historisierung, fachliche Definitionen, Erweiterbarkeit etc.) Bewerte Integration in bestehende IT Landschaft Fachliche Vorzüge (Analytics, vorkonfigurierte Lösungen etc.) Verfügbarkeit (Daten, IT-Performance, Time to Market) Bestehendes Know How und Praxis Erfahrungen bei VW FS Erfüllung von BCBS 239 Anforderungen (Integrierte Datenhaushalt, Data Governance, Transparenz, etc.)

99 Vielen Dank für Ihre Aufmerksamkeit

100 BAckUp

101 Implementation SAS BIS DDS

102 Vorgehens- weise Umsetzung auf Basis SAS Intelligence Solutions Implementation Methodology

103 Check with Target System
Vorgehens- weise Agile Methodologie mit kurzen iterationen nach phasen, subject area‘s und finanzprodukten Zeitleiste 1 Infrastruktur Mapping Codierung Qualitäts-sicherung 2 Counter parties Financial Products Risk Mitigants Models & Scores … 3 Entity Mapping Field Mapping Transformation Rules Check with Target System …

104 Vorgehens- weise Standardisierte mapping templates zur effizienten dokumentation der anforderungen

105 Vorgehens- weise Vorgefertigte business szenarien als unterstützung im mapping prozess

106 Vorgefertigte business szenarien als unterstützung im mapping prozess
Vorgehens- weise Vorgefertigte business szenarien als unterstützung im mapping prozess Data Delivery Access & Security Views ABT Creation Mart Transform. De-Normalization … Data Management Archivierung Korrekturen Entity Types Recovery Key Management Nameskonvention Data Acquisition Load Strategies CDC Historisierung Job Templates Dev. Guidelines Staging Design