2 SAP Bank Analyzer im Überblick · 2014-02-17 · SAP Bank Analyzer im Überblick 73 ziehbar sein, d.h., die Eingangswerte, der finanzmathematische Ablauf ei-ner Methode, der Zeitpu

71SAP Bank Analyzer im Überblick

2 SAP Bank Analyzer im Überblick

Für die internationale Bankenwelt ist eine Zeit rapiden Wan-dels angebrochen. Zunehmender Wettbewerbsdruck, neue Technologien und geringere Gewinnspannen stellen für die Banken eine immer größer werdende Herausforderung dar. Der SAP Bank Analyzer und die darauf aufbauenden Anwendungen zur Gesamtbanksteuerung bieten eine umfassende Unterstüt-zung zur Bewältigung dieser Herausforderungen.

Strategische Entscheidungzur Gesamtbank-steuerung

Bei vielen Banken werden zum Zwecke der Gesamtbanksteuerung dieSteuerungsdaten von den operativen Systemen importiert und mit einemReportingtool oder Data Warehouse zusammengeführt. Die daraus erstell-ten Managementberichte sind oftmals inkonsistent, d.h., die Zahlen sindnicht überleitbar. In größeren Banken beschäftigen sich zunehmend mehrMitarbeiter damit, diese Differenzen zu erklären. Aus Revisionssicht erge-ben sich aufgrund der vielfach eingesetzten Excel- und Access-basiertenIndividuallösungen erhebliche Bedenken zur Revisionssicherheit, denn einNachweis, welche Daten zu welchem Zeitpunkt die Basis für die Bericht-erstattung gebildet haben, ist nur schwer zu erbringen. Die zugrunde lie-genden finanzmathematischen Berechnungen lassen sich dezentral nursehr schwer konsistent halten.

Abbildung 2.1 Strategische Entscheidung zur Gesamtbanksteuerung

Operative System 1

Operative System ...

Valuation- andCalculation-methods 1

Valuation- andCalculation-methods 2

Overall bank controlling Centralized overall bank controlling

CentralValuation-

und Calculation-methods

ReportingMicrosoft

Excel-Arbeitsblatt

Operative System 1


Correctionand glazing

of differences

Data Warehouse Data Warehouse


Deshalb bleibt für jede Bank die strategische Entscheidung, sich Steue-rungsergebnisse dezentral von den operativen Systemen zu besorgen odereine zentrale Infrastruktur zu schaffen, in der die Ergebnisse auf der Grund-lage einer homogenen Datenbasis aller Bankgeschäfte über finanzmathe-matisch konsistente Methoden erzeugt werden. Einheitliche Daten undMethoden ergeben sich jedoch auch als Konsequenz aus einer Reihe an-derer Anforderungen.

Einheitliche Daten Die betriebswirtschaftliche Sicht auf die Prozesse einer Bank macht deut-lich, dass wesentliche Steuerungsaspekte, die bisher separat betrachtetwurden, immer stärker zusammenwachsen und Einfluss aufeinander aus-üben. So rücken auf der Basis der Segmentberichterstattung das interneund das externe Rechnungswesen, aber auch die Risiko- und die Control-lingkennzahlen stark zusammen. Beispielsweise werden im Meldeweseneinzelne Risikoaktiva zur Ermittlung von Deckungsbeitragsstufen benötigt.Dieses Zusammenwachsen erfordert eine einheitliche und integrierte Sichtauf die Einzelgeschäfte, Bestände der Bank, die ausschließlich auf der Basiseiner gemeinsamen Dateninfrastruktur realisiert werden können. Alle Da-ten müssen in konsistenter Form vorhanden sein, um eine Abstimmbarkeitund einheitliche Sicht der einzelnen Prozessdimensionen zu gewährleis-ten.

Abbildung 2.2 Einheitliche Daten zur Gesamtbanksteuerung

Eine spätere Analyse und das Reporting können nur durch diese Verein-heitlichung und Homogenisierung der Daten eine optimale Steuerung derBank, seiner Geschäftsbereiche und Abteilungen sicherstellen.

EinheitlicheMethoden

Ein weiterer wichtiger Aspekt folgt aus den sich immer mehr verstärkendenAusrichtungen auf den Konzern. Dabei liegt der Fokus auf der konsistentenKalkulation und Bewertung von Daten über alle Konzernunternehmenhinweg. Alle errechneten Ergebnisse müssen von der Revision nachvoll-

Uniform, consistentData

Operative System 1

Operative System 2


Further Processing

Further Processing

FurtherProcessing


ziehbar sein, d.h., die Eingangswerte, der finanzmathematische Ablauf ei-ner Methode, der Zeitpunkt der Methodenausführung und die erzeugtenErgebnisse werden dokumentiert und sind nachvollziehbar. Eine zentraleMethodeninfrastruktur muss für die Errechnung jeglicher interner und ex-terner Kennzahlen herangezogen werden. Nur eine derart zentralisierteKontrolle über die finanzmathematischen Methoden kann die Ergebnis-konsistenz (also die Garantie, dass mehrere einzelne Ergebniswerte mitderselben betriebswirtschaftlichen Bedeutung einheitlich erzeugt wurden)über alle Geschäftsbereiche und Abteilungen einer Bank garantieren.

Abbildung 2.3 Einheitliche Methoden zur Gesamtbanksteuerung

Als Beispiel mag das Durchschnittsvolumen dienen, das sich aus Bestands-und Bewegungswerten errechnet. Eine Methoden- und damit Ergebnis-konsistenz liegt vor, wenn die Berechnung der Basis der Bestands- und Be-wegungswerte für alle Geschäfte einheitlich abläuft.

Integration von internem und externem Reporting

Aufbauend auf dieser Daten- und Methodenkonsistenz kann eine Integra-tion von internem und externem Reporting vollzogen werden. Dies istangesichts regulatorischer Anforderungen wie IAS und Basel II eine Not-wendigkeit, da zunehmend auch interne Kennzahlen in die externe Be-richterstattung einfließen. Das interne und externe Reporting einer Bankverschmelzen dadurch immer mehr.

Wie die Anforderungen des Marktes unterliegen auch die gesetzlichenRechnungslegungsvorschriften einem kontinuierlichen Wandel, der sichdurch die diversen Bilanzierungsskandale der letzten Jahre noch verstärkthat. Immer detailliertere Anhänge zur Bilanz müssen über die Geschäfteund Risiken einer Bank Auskunft geben.

Uniform, consistentMethods


Operative System 1

Operative System 2


Further Processing

Further Processing

FurtherProcessing


Abbildung 2.4 Integration von internem und externem Reporting

Berücksichtigungmehrerer Rech-nungslegungs-

standards

Speziell in den europäischen Ländern befinden sich zudem die Banken, wiez.B. HGB in Deutschland, im Wandel ihrer bilanziellen Bewertung der Fi-nanzgeschäfte hin zu internationalen Bewertungsvorschriften wie US-GAAP oder IAS. Bis sich international einheitliche Standards etabliert ha-ben, sind die Banken gefordert, parallel Bilanzen nach unterschiedlichenRechnungslegungsvorschriften zu erstellen.

Abbildung 2.5 Berücksichtigung mehrerer Rechnungslegungsstandards



Data Warehouse

Reporting

Operative System 1

Operative System 2


Further Processing

Further Processing

FurtherProcessing



Data Warehouse

Reporting

Operative System 1

Operative System 2


Further Processing

Further Processing

FurtherProcessing

Accounting Standard, e.g. US-GAAP

Accounting Standard, e.g. IAS


Dazu ist es notwendig, die einzelnen Vorgänge in unterschiedlichen, pa-rallelen Rechnungslegungsvorschriften zu bilanzieren. Gemäß IAS und US-GAAP sind darüber hinaus erweiterte Unternehmenskennzahlen wie Risi-kokennzahlen, Economic Capital und Rentabilitätskennzahlen zu berich-ten.

Risk-Return-Messungen und -Steuerungen

Ebenso können aufbauend auf der Daten- und Methodenkonsistenz mo-derne Analyseansätze für Banken wie Risk Return umgesetzt werden, nachdenen Erfolgs- und Risikoergebnisgrößen zusammengeführt werden. Eineeinheitliche Erfolgs- und Risikomessung der Geschäfte ist dabei die Vor-aussetzung, um konsistente Risk-Return-Kennzahlen zu erzeugen. Auchbestehen bezüglich der Ermittlung der verschiedenen Risiken Abhängig-keiten. So benötigen zum Beispiel Barwert- und Exposuresimulationen so-wohl das Marktrisiko als auch die Kontrahenten-Exposuremessung, wel-che wiederum zusätzlich als Zwischenrechnung für Adressrisiko- oderCredit-Value-at-Risk-Messungen verwendet werden kann. Dies bedingtneben einer konsistenten Ermittlung auch die entsprechende Verwaltungder Risikoergebnisgrößen in einer einheitlichen Risikoergebnisdatenbank,die die Grundlage für entsprechende Auswertungen und das Managementdes allokierten Risikokapitals darstellt.

Abbildung 2.6 Risk-Return-Messungen und -Steuerungen

Eine Weiterführung des Konzepts einer zentralen Infrastruktur bedeutet,die entsprechenden Steuerungskennzahlen und -verfahren nicht nur fürexterne oder interne Berichtszwecke zu ermitteln, sondern diese aus dem



Data Warehouse

Reporting

Operative System 1

Operative System 2


Further Processing

Further Processing

FurtherProcessing


Back Office heraus den Business-Management-Systemen und damit ope-rativen Bankabteilungen wie Trading, Kredit- oder Kundenmanagementzur Verfügung zu stellen. Dadurch wird im Sinne einer bankweiten Opti-mierung der Risikokapitalallokation eine direkte und konsistente Steue-rung ermöglicht. Hierzu werden die Risikoanwendungen um ein einheit-liches Limitmanagementsystem ergänzt, in dem die verschiedenenRisikokennzahlen gleichermaßen ermittelt und limitiert werden. Im Rah-men dessen wird insbesondere das aktive Management der allokierten Li-mite und damit Risikokapitalien sowohl über einzelne Geschäftsbereichehinweg als auch innerhalb dieser unterstützt.

2.1 Problemhintergrund

Zentralisierte und homogenisierte Daten sowie gemeinsam genutzte be-triebswirtschaftliche Methoden über alle Geschäftsbereiche einer Bankhinweg sind der Schlüssel zur konsistenten Analyse und Steuerung auf Un-ternehmens-, Abteilungs- und Projektebene. Benötigt wird eine »Gesamt-bankinfrastruktur«, die diese Dienste zur Verfügung stellt.

KernthemaGesamtbank-infrastruktur

Die Vernetzung und Zusammenarbeit auf der Grundlage homogenisierterDaten und gemeinsamer betriebswirtschaftlicher Methoden zum Zweckder optimalen Informationsverarbeitung bringt eine Fülle neuer Möglich-keiten mit sich, jedoch mindestens ebenso viele Herausforderungen, dieunter dem Stichwort Gesamtbankinfrastruktur zusammengefasst werdenkönnen. An eine derartige Gesamtbankinfrastruktur (und die auf ihr ab-laufende Informationsverarbeitung) stellen Banken hohe Anforderungen:

1. Sie muss applikations- und unternehmensübergreifend einheitliche,offene Standards bieten und von wenigen tausend bis zu vielen Millio-nen Geschäftsvorfällen pro Tag stabil und skalierbar sein.

2. Sie muss auf heutige und zukünftige Anforderungen des Unternehmensund seiner Partner, des Marktes sowie der Gesetzgebung flexibelanpassbar sein. Für den Anwender muss sie Informationen aus unter-schiedlichsten Quellen integriert anbieten können.

3. Sie muss die unterschiedlichen Rechnungslegungsvorschriften in eineminternationalen Konzern unterstützen und auch die parallele Bilanzie-rung nach unterschiedlichen Rechnungslegungsvorschriften abbilden,beispielsweise HGB und IAS.

4. Sie muss über flexible und transparente Mechanismen zur Kosten- undErlösrechnung verfügen, die den stark unterschiedlichen Anforderun-

77Problemhintergrund

gen der Anwender aus den einzelnen Projekten, Abteilungen und Berei-chen gerecht wird.

5. Sie muss interne Ratingmodelle eines Finanzdienstleisters zur Bewer-tung seiner Geschäftspartner einbinden können. Aktuelle gesetzlicheAnforderungen, wie beispielsweise die Umsetzung der BASEL II-Richt-linien, müssen möglich sein.

6. Sie muss interne Limitvorgaben verwalten und automatisch kontrollie-ren, sodass sich die Risiken aus den Geschäften einer Bank exakt steuernlassen. Die Limitvorgaben müssen dabei auf unterschiedlichen Granu-laritätsebenen wie Land, Geschäftsbereich und Produkt angelegt wer-den können, um die Geschäftstätigkeit nicht unnötig zu behindern.

7. Sie muss What-if-Analysen auf Ergebnisdaten unterstützen, mit derenHilfe die Auswirkungen verschiedener Marktdatenszenarien undAbschreibungsvorgänge auf die Bilanz und die Gewinn- und Verlust-rechnung durchgeführt werden können. Es muss das Ziel sein, dasUnternehmen proaktiv über Kennzahlen steuern zu können.

Hohe Anforde-rungen an die Infrastruktur

Vergleicht man diese Anforderungen nun mit Ihren IT-Projekten, die Sieaktuell oder in nächster Zeit in Ihrem Unternehmen und vielleicht sogar zu-sammen mit anderen Gesellschaften durchführen wollen, so stellt mansehr schnell fest, dass man kaum im Rahmen des Projekts neben der oh-nehin immer komplexeren und umfassenderen Geschäftslogik auch nochfür alle oben genannten Punkte in ausreichendem Maße selbst Eigenent-wicklungen leisten kann. Sowohl der Zeitplan als auch die Kosten würdensich vervielfachen und das Projektziel gefährden. Es stellt sich allerdings dieFrage: Wenn Sie es nicht können und wollen, wer tut es dann?

Die Antwort lautet SAP – und zwar aus folgendem Grund: Mögen sich dieAnforderungen an Ihre Geschäftsprozesse noch so sehr von anderen Ge-schäftsprozessen unterscheiden, die Anforderungen an die Gesamtbank-infrastruktur weisen große Gemeinsamkeiten auf.

SAP Bank Analyzer-Definition

Der SAP Bank Analyzer ist eine Infrastruktur für die Lösung von wesent-lichen, grundlegenden Problemen der Gesamtbanksteuerung. Als flexibelkonfigurierbare Plattform adressiert SAP Bank Analyzer exakt die oben ge-nannten Punkte und bietet Funktionalität, um die Gesamtbanksteuerungauf der Grundlage einheitlicher Daten und Methoden zu ermöglichen. Da-bei versteht er sich nicht als Ersatz operativer Banksysteme, sondern als Er-gänzung, der die Daten aus den operativen Systemen in homogener Formspiegelt und zentralisiert. Dies entlastet die operativen Systeme von dennachgelagerten Prozessen der Gesamtbanksteuerung und zentralisiert


gleichzeitig die damit einhergehenden Prozesse, damit die oben genann-ten betriebswirtschaftlichen Ziele erreicht werden.

Punkt 1:SAP NetWeaver

Eine Infrastruktur für die Gesamtbanksteuerung muss technisch auf einerstabilen und zukunftsträchtigen Entwicklungs- und Laufzeitumgebungaufbauen, die neben etablierten Verfahren modernste Kommunikations-standards wie HTTP, HTML, XML und SOAP zur Anbindung von Vorsyste-men unterstützt sowie betriebssystem- und datenbankunabhängig einge-setzt werden kann. Eine abgesicherte Ausführung jeder einzelnenApplikation muss ebenso selbstverständlich sein wie umfangreiche Fea-tures für die Vermeidung von Fehlern und Engpässen, eine automatischeSpeicherbereinigung, leichter Zugriff auf Datenbanken, Sperrmechanis-men zur Verwaltung des Mehrbenutzerbetriebs, Benutzerverwaltung undKontrolle von Benutzerrechten, Datenpufferung zum schnellen Zugriff,Loadbalancing über viele Applikationsserver hinweg und eine hochverfüg-bare und performante Nutzbarkeit selbst bei sehr vielen gleichzeitigen An-wendern und Millionen von Transaktionen pro Tag.

Der SAP Bank Analyzer basiert auf der zukunftssicheren und bewährtenEntwicklungs- und Laufzeitplattform SAP NetWeaver, die auch die tech-nische Grundlage für alle anderen SAP-Applikationen bildet.

Punkt 2:ÜbergreifendeKomponenten

Eine Infrastruktur für die Gesamtbanksteuerung muss auf einheitlichenDaten und betriebswirtschaftlichen Methoden aufbauen, um die Konsis-tenz der Ergebnisse sicherstellen zu können. Ein generisches Datenmodellzur Übernahme und zentralisierten Ablage aller heutigen und zukünftigen,für die Rechnungslegung und das Risikomanagement relevanten Daten ei-ner Bank gehört ebenso zu den Notwendigkeiten wie die Verwaltung undBeschränkung des Zugriffs auf diese Daten, die Möglichkeit zur manuellenKorrektur von maschinell angelieferten Vorsystemdaten, die übergrei-fende Verwaltung von Kennzahlen und deren Kategorisierung, die Bereit-stellung zentraler und zukünftig erweiterbarer Berechnungsmethoden so-wie ein leistungsfähiges Analyse- und Simulationswerkzeug.

Der SAP Bank Analyzer beinhaltet die Financial Database zur Zentralisie-rung und Verwaltung von Finanzdaten aus operativen Vorsystemen jegli-cher Art, einheitliche übergreifende Methoden zur Aufrechnung von Er-gebnissen und die konsistente Risikobewertung über die verschiedenenAnwendungen hinweg sowie das SAP Business Information Warehouse zurperformanten Analyse und Simulation aller Unternehmensdaten.

Punkt 3:Balance Analyzer

Eine Infrastruktur für die Gesamtbanksteuerung muss buchhalterisch inder Lage sein, Buchungsbelege oder erfasste Geschäftsvorfälle aus den ver-

79Problemhintergrund

schiedensten Vorsystemen und Tochtergesellschaften aufzunehmen unddaraus eine abgestimmte Bilanz nach lokalen und internationalen Rech-nungslegungsvorschriften wie beispielsweise HGB und IAS zu erstellen.Unterschiedliche Berichtsperioden sind dabei genauso zu berücksichtigenwie Mehr- und Fremdwährungsgeschäfte, Absicherungen (Hedges) vonGeschäften, die Verarbeitung komplex strukturierter und ineinander ver-schachtelter Verträge sowie die länderspezifisch korrekte Marktdatener-mittlung, Amortisierung und steuerliche Bewertung aller Transaktionen.

Der SAP Bank Analyzer beinhaltet den Balance Analyzer, der neben mo-dernsten buchhalterischen Methoden speziell auf die Finanzbestandsfüh-rung zugeschnittene Fähigkeiten besitzt und damit alle oben genanntenAnforderungen einer Bank erfüllen kann.

Punkt 4:Profit Analyzer

Eine Infrastruktur für die Gesamtbanksteuerung muss in der Lage sein, ne-ben der Bilanzierung auch die Kosten- und Erlösrechnung auf der Grund-lage von Buchungsbelegen oder erfassten Geschäftsvorfällen aus verschie-denen Vorsystemen und Tochtergesellschaften durchzuführen und darausflexibel und multidimensional auswertbare Berichte, wie z.B. Deckungs-beitragsrechnungen auf Organisations-, Produkt- oder Kundenebene, zuerstellen. Hierbei kommt es vor allem auf die Flexibilität der Lösung an, umden höchst unterschiedlichen und teils sehr komplexen Anforderungengerecht werden zu können.

Der SAP Bank Analyzer beinhaltet den Profit Analyzer, der über ein äußerstflexibles Framework zur Kalkulation, Verrechnung und Informationsablei-tung verfügt und damit die oben genannten Anforderungen erfüllen kann.

Punkt 5:Credit Risk Analyzer

Eine Infrastruktur für die Gesamtbanksteuerung muss das Risiko bei derVergabe und Annahme von Krediten einheitlich messen und so für alle Ab-teilungen, Bereiche und lokale wie internationale Tochtergesellschafteneiner Bank die Durchsetzung gleichmäßig hoher Qualitätsstandards bezüg-lich einer Bewertung möglich machen. Die Einbeziehung von geografi-schen Risiken auf Landes- und regionaler Ebene gehört ebenso zu den An-forderungen wie die Auswertung branchenspezifischer Risiken und dieBerücksichtigung wichtiger Unternehmens- bzw. Organisationskennzah-len.

Der SAP Bank Analyzer beinhaltet den Credit Risk Analyzer, um das Risi-kopotenzial von zukünftigen und bereits ausgegebenen bzw. in Anspruchgenommenen Geldvergaben kontinuierlich nach allen oben genanntenGesichtspunkten zu bewerten.


Punkt 6:Limit Manager

Eine Infrastruktur für die Gesamtbanksteuerung muss neben dem Messenvon Risiken (siehe Credit Risk Analyzer) auch Limitvorgaben hinterlegenkönnen, mit denen sich die Risiken aus den Geschäften einer Bank auf Län-der-, Branchen- oder Produktebene bis hinunter zum einzelnen Geschäfts-partner vom Management exakt vorgeben und steuern lassen. Gerade vordem Hintergrund aufsichtsrechtlicher Regelungen, die eine exakte Steue-rung aller Bankrisiken sowie die damit verbundene Allokation und Hinter-legung von entsprechendem Eigenkapital verlangen, ist die Limitierungvon Risiken für einen optimalen Einsatz der liquiden Mittel unerlässlich.

Der SAP Bank Analyzer beinhaltet den Limit Manager, der den Prozess derLimitvorgabe sowohl für alle Arten von Produkten aus dem Handelsge-schäft wie auch für klassische Kreditgeschäfte unterstützt.

Punkt 7:Strategy Analyzer

Eine Infrastruktur für die Gesamtbanksteuerung muss die Aktiv-/Passiv-steuerung unterstützen. Durch die Hochrechnung und die Simulation vonGeschäften sowie die Analyse von Zins- und Wechselkursszenarien wer-den die damit verbundenen Auswirkungen auf die Bilanzstruktur transpa-rent. Ferner müssen mögliche Markt- und Abschreibungsrisiken auf Posi-tionen von Wertpapieren und Derivaten frühzeitig bei der Planung derBilanzstruktur sowie der Gewinn- und Verlustrechnung Berücksichtigungfinden.

Der SAP Bank Analyzer beinhaltet den Strategy Analyzer, der Zinsände-rungs-, Währungs- und Liquiditätsrisiken über die Zeit nach Bestand, Ab-lauf und Cashflow darstellt. Simulationen unterstützen die strategischeKontrolle von Bilanzstrukturen und die Entwicklung der Gewinn- und Ver-lustrechnung.

Mit dem SAP Bank Analyzer tritt SAP den Beweis an, eine zukunftsorien-tierte, den Anforderungen für die Gesamtbanksteuerung gerecht wer-dende Infrastruktur und darauf aufbauende Lösungen anzubieten. DieseAnwendungen und Lösungen werden ab Abschnitt 2.3 bzw. Abschnitt 2.4erläutert. Wir wollen uns zunächst weiter in die Konzeption und Architek-tur der Gesamtbankinfrastruktur vertiefen.

2.2 Konzeption und Architektur

Selten wurde bei der SAP ein branchenspezifisches Produkt mit einem der-art großen Umfang entwickelt wie der SAP Bank Analyzer. Bis zu 150 Pro-jektmitglieder gleichzeitig arbeiten mittlerweile seit vier Jahren an dieserSoftware (Stand Dezember 2003, Bank Analyzer-Release 3.0). Übertroffenwird dieses Engagement allenfalls durch das SAP Account Management –

81Konzeption und Architektur

ein ebenfalls bankenspezifisches Softwareprodukt zur Abwicklung derKontoführung in Großbanken.

Grundlagen Schritt für Schritt

Die Vollversion des aktuellen SAP Bank Analyzer 3.0 umfasst mehr als 70CDs, vollgepackt mit Daten, Anwendungen und Online-Handbüchern. In-stalliert belegen sie über 30 GByte Festplattenkapazität und beinhaltensieben große Komponenten für die Unterstützung der verschiedensten Be-reiche einer Gesamtbanksteuerung. Diese Vollversion beinhaltet diegrundlegende technische und betriebswirtschaftliche Infrastruktur, die Bi-lanzerstellung, die Kosten- und Erlösrechung, die Risikobewertung vonmonetären Geschäften und die Limitverwaltung, weiterhin die Strategie-analyse und schließlich ein übergreifendes Reporting. Hier handelt es sichzwischen einigen tausend und vielen Millionen unterstützte Transaktionenpro Tag und um hundertprozentige Anpassungen an die Bedürfnisse desKunden durch Customizing sowie vorgesehene Einstiegspunkte für Pro-grammerweiterungen und -modifikationen. Darauf aufbauend hat die SAPmit ihren Softwarepartnern mehrere vorgefertigte Anwendungen und Lö-sungen geschaffen, die sich auf die hochaktuellen Themen Hedge Manage-ment, IAS-Bilanzierung und Risikomanagement gemäß BASEL II beziehen.

SAP Bank Analyzer 1.0

Derartige Anwendungen und Lösungen brauchen Infrastruktur – und dieliefert der SAP Bank Analyzer. Er wurde Ende des Jahres 2001 im Zusam-menhang mit der Profitability-Management-Anwendung am Markt einge-führt und enthielt zu diesem Zeitpunkt noch nicht alle Komponenten.

Abbildung 2.7 Architektur des SAP Bank Analyzer 1.0 im Überblick

Business Information Warehouse


Financial Database

Data Warehouse

Reporting

Operative System 1

Operative System 2


Profit Analyzer


Einzige Bestandteile waren die Komponenten Financial Database zur Spie-gelung der operativen Unternehmensdaten, der Profit Analyzer für dieKosten- und Erlösrechnung und das SAP Business Information Warehousefür die Analyse und Berichterstellung der Ergebnisse. Wesentliche grund-legende Architekturkonzepte des SAP Bank Analyzer wie die Zentralisie-rung von Finanzdaten, die Weiterverarbeitung durch fachspezifische Kom-ponenten (Analyzer oder Manager) sowie die Nutzung des SAP BusinessInformation Warehouse als einheitliches Reportingwerkzeug für die erar-beiteten Ergebnisse waren hier jedoch bereits festgelegt und gelten un-eingeschränkt bis heute.

SAP Bank Analyzer2.0

Ende des Jahres 2002 wurde das stark erweiterte Release 2.0 des SAP BankAnalyzer auf den Markt gebracht. Es enthielt bereits die meisten unter Re-lease 3.0 vorhandenen Komponenten, d.h. neben den bereits in Release1.0 verfügbaren Komponenten Financial Database, SAP Business Informa-tion Warehouse und Profit Analyzer auch die Übergreifenden Methodenzur Buchführung und Bilanzierung den Credit Risk Analyzer zur Risikobe-wertung von Krediten und Handelsgeschäften, den Limit Manager zur Vor-gabe von maximalen Risiken im Handels- und Kreditgeschäft und den Stra-tegy Analyzer zur Simulation und Hochrechnung der Auswirkungen vonKredit- und Marktzinsänderungen auf das Unternehmensergebnis.




Financial Database

Data Warehouse

Reporting

Operative System 1

Operative System 2


Profit Analyzer

Balance Analyzer

Credit RiskAnalyzer

LimitManager

StrategyAnalyzer


Das grundlegende Architekturkonzept des SAP Bank Analyzer ist seit Re-lease 2.0 vollständig umgesetzt.

SAP Bank Analyzer 3.0

Ende des Jahres 2003 wurde schließlich das abermals stark erweiterte Re-lease 3.0 des SAP Bank Analyzer auf den Markt gebracht. Diesmal lag derSchwerpunkt in der Funktionserweiterung vorhandener Komponenten,die durch die neuen Anforderungen einer parallelen Bilanzierung von IASneben einem lokalen Rechnungslegungsstandard sowie durch die Unter-stützung flexibler bankinterner Ratingverfahren zur Risikobewertung vonFinanzgeschäften gemäß Basel II geprägt wurden.


Zur Umsetzung der IAS-Lösung wurden neben Erweiterungen des BalanceAnalyzers die IAS-Servicefunktionen und – als kundenspezfische Erweite-rung – das Hedge Management entwickelt. Im Bereich Basel II wurde derCredit Risk Analyzer erweitert und die Komponenten Historiendatenbank(HDB), Offenlegung und Reporting sowie die Meldewesen-Schnittstellehinzugefügt.

Abbildung 2.10 stellt die unterschiedlichen Entwicklungsschwerpunkteder einzelnen Releases grafisch dar.



Financial Database

Data Warehouse

Reporting

Operative System 1

Operative System 2


Profit Analyzer

Balance Analyzer

Credit RiskAnalyzer

LimitManager

StrategyAnalyzer

e.g.IAS

e.g. Basel II

HedgeManagement


Abbildung 2.10 Entwicklungsschwerpunkte der einzelnen SAP Bank Analyzer-Releases

Berücksichtigt man als Realisierungszeitraum für jedes neue Release einenZeitraum von einem Jahr, so wird deutlich, dass SAP stets gleichzeitig anzwei Releases gearbeitet hat. Während die Anforderungen an ein Releasevon der Entwicklung innerhalb eines Jahres technisch umgesetzt wurden,arbeitete man gleichzeitig an den betriebswirtschaftlichen Spezifikationendes nächstfolgenden Release.

Abgrenzung desSAP Bank Analyzerzu den operativen

Systemen

Nachdem nun die Komponenten des SAP Bank Analyzer und ihre Fähig-keiten im Überblick bekannt sind, können wir eine funktionale Abgren-zung zu den operativen Banksystemen ziehen. Diese Abgrenzung definiert,was der SAP Bank Analyzer nicht kann und nicht können soll.

In den operativen Systemen einer Bank werden die Finanzgeschäfte ge-genüber dem Kunden juristisch geführt. Der SAP Bank Analyzer ist einBack-Office-System und somit kein operatives System. Alle für die Ge-samtbanksteuerung wesentlichen Daten müssen ihm deshalb aus den ope-rativen Systemen zur Verfügung gestellt werden. Insbesondere benötigt erdie juristisch relevanten Bestände und Finanzgeschäfte, um daraus juris-tisch relevante Berechnungen auszuführen und letztlich Berichte zu erstel-len. Anders ausgedrückt: Im SAP Bank Analyzer wird ein juristisches Spie-gelbild der Daten aus den operativen Systemen aufgebaut. Daraufbasierend können unternehmenssteuernde Methoden und Prozesse eineflexible Sicht auf die Daten ermöglichen, z.B. Local-GAAP-Bestand, IAS-

2001 2002 2003

Profit AnalyzerProfit Analyzer

Credit RiskAnalyzerCredit RiskAnalyzer

LimitManagerLimitManager

StrategyAnalyzerStrategyAnalyzer

Balance AnalyzerBalance Analyzer

Release 1 Release 2

IASIAS

Release 3

Financial DatabaseFinancial Database

Reporting-BWReporting-BW

Business MethodsBusiness Methods

Profit AnalyzerProfit Analyzer

Financial DatabaseFinancial Database

Reporting-BWReporting-BWBasel IIBasel II


Bestand, Risikobewertung von Finanzgeschäften nach internem oder ex-ternem Rating, Meldewesendaten, Local-GAAP Bilanz, IAS-Bilanz etc. Eskönnen beliebige und daher auch parallele Darstellungen der Vorgängeaufgebaut werden, ohne die operativen Systeme zu belasten.

Abbildung 2.11 Abgrenzung des SAP Bank Analyzer von den operativen Systemen

Da diese Darstellungen alle in der integrierten Infrastruktur des SAP BankAnalyzer ablaufen, können durch die Anwendung geeigneter Einstellun-gen und Methoden konsistente Ergebnisdaten erzeugt werden. Der SAPBank Analyzer arbeitet auf dem niedrigsten angelieferten Detaillierungs-grad, damit sämtliche Auswertungen der Fachabteilungen auf diesen Ba-sisdaten aufsetzen können. Andere Systeme wie z.B. das mySAP CRM Ban-king oder Drittanwendungen können sich ebenfalls der Detaildaten desSAP Bank Analyzer bedienen. Der SAP Bank Analyzer hat jedoch in jedemFall die Kontrolle über die Anwendung von Methoden und die analyti-schen Ergebnisdaten, womit eine Ergebniskonsistenz erreicht werdenkann.

Grundlegende Architektur-konzepte

Der SAP Bank Analyzer ist ein hochgradig generisches Produkt und musssich den vielfältigen Datenmodellen und Verarbeitungsschritten der un-terschiedlichen Banken anpassen können, soweit die betriebswirtschaftli-chen Prozesse dies erfordern. Ein von SAP fest vorgegebenes Daten- undVerarbeitungsmodell kann diese Anforderungen nicht erfüllen. Stattdes-sen muss eine Reihe grundlegender Architekturkonzepte für eine rei-bungslose Erweiterbarkeit sorgen, die durchgehend in allen Komponentenverwendet werden.

Analyticalrelevant Information

Derived Keyfiguresand Characteristics

PeriodicControlling, Reportingand Disclosure

Master Data Transaction Data Position Data

Averages Counters

ProfitabilityAnalysis

Operational BankingAnalytical Banking

Share&Derivative Administration

Loan Administration

Company AccountAdministraiton

Customer AccountAdministration

Real EstateAdministration

Customer AccountAdministration

HedgeAdministration

RegionsClassesSummations

IASFin. Statement

Basel IIRisk Statement

RegulatoryReporting Data


Zu den verwendeten Architekturkonzepten des SAP Bank Analyzer zählen:

� Tool-BWSAP Bank Analyzer als Add-On auf dem SAP Business Information Ware-house

� Merkmal- und KennzahlrepositoryGlobales Verzeichnis für semantische Felder, die im SAP Bank Analyzerverwendet werden

� SegmentierungsserviceVerwaltung von generischen Stammdaten

� AbleitungstoolAnreicherung von Bewegungsdaten

� ParallelisierungstoolSkalierbarkeit für lang laufende Geschäftsprozesse

� Business Add-Ins (BAdIs)Erweiterbarkeit der Software ohne Modifikationen an SAP-Quelltexten

� Business Application Programming Interfaces (BAPIs)Integration in vorhandene Systemlandschaften

� MandantenkonzeptErhaltung der Mandanteninformation auch im Reporting-BW

� Application LogNachrichten- und Fehleranalyse von gelaufenen Prozessen

Die wichtigsten Architekturkonzepte wollen wir in diesem Abschnitt vor-stellen. Dazu gehören das Tool-BW, das Merkmal- und Kennzahlreposi-tory, der Segmentierungsservice, das Ableitungstool, das Parallelisierungs-tool, die programmatische Erweiterung und Integration durch BAdIs bzw.BAPIs sowie die Mandantentrennung und Nachrichten-/Fehlerauswer-tung.

Roadmap Ende des Jahres 2004 wird voraussichtlich das Release 4.0 des SAP BankAnalyzer auf den Markt kommen. Er soll vor allem funktionale Erweite-rungen im Bereich der Basel II-Lösung enthalten, da einige der diesbezüg-lichen Richtlinien erst im ersten Halbjahr 2004 verabschiedet werden. EineUmsetzung ist folglich erst nach diesen Terminen sinnvoll.


Abbildung 2.12 Geplante Erweiterungen des SAP Bank Analyzer 4.0

Andere Erweiterungen betreffen die Bereiche Hedge Management und dieAbrundung der IAS-Lösung für eine parallele Rechnungslegung. Darüberhinaus strebt SAP langfristig die Migration von SEM-Banking-Kunden aufdie SAP Bank Analyzer-Plattform an.

Abbildung 2.13 Roadmap SAP Bank Analyzer

FazitDer SAP Bank Analyzer ist eine technische und betriebswirtschaftliche In-frastruktur zur Gesamtbanksteuerung, die Bestände und Finanzgeschäfteaus den operativen Systemen spiegelt, mittels umfangreicher Prozesse und


Financial Database

Data Warehouse

Reporting

Operative System 1

Operative System 2


Profit Analyzer

Balance Analyzer

Credit RiskAnalyzer

LimitManager

StrategyManager

IASenhanced

Basel IIenhanced

HedgeMngmt


IntegratedAccounting

• Highest priority: Stability of presently running IAS and Basel II developments

• Earliest development start for Profitability Management

• After Basel II: Credit Risk Enhancements

• Further solutions on the basis of Bank AnalyzerMigration option from SEM Banking to Bank Analyzer

• Anticipated transfer of SEM Banking into customer specific maintenance

2003

2004

2005

…

2009


Methoden weiterverarbeitet und für beliebige Berichte flexibel aufberei-tet. Auf diese Weise erfüllt der SAP Bank Analyzer unterschiedlichste An-forderungen an das interne und externe Reporting. Der SAP Bank Analyzerwird in Zusammenarbeit mit mehreren Banken und Beratungsunterneh-men ständig weiterentwickelt.

2.2.1 Tool-BW – Business Information Warehouse als integraler Bestandteil

Das SAP Business Information Warehouse ist eines der erfolgreichstenSoftwareprodukte der SAP für den Aufbau einer zentralen Data-Ware-house- und Berichtsplattform. Im SAP Bank Analyzer wird es darüber hi-naus als Werkzeug zur Verwaltung von Merkmal- und Kennzahlinforma-tionen sowie Indizes und Sichten auf Datenbanktabellen verwendet.

GrundlagenSchritt für Schritt

Das SAP Business Information Warehouse wird im Rahmen der mySAPBusiness-Intelligence-Lösung als Softwarelösung zum Aufbau und Betriebvon zentralen Data-Warehouse- und Berichtsplattformen verwendet. ImRahmen des Softwareprodukts SAP Bank Analyzer kommt das SAP Busi-ness Information Warehouse gleich zweimal zum Einsatz. Zum einen wirdes als so genanntes Tool-BW zusammen mit den anderen SAP Bank Ana-lyzer-Komponenten auf einem Core-System installiert. Zum anderen wirdes auf einem separaten System als Reporting-BW eingesetzt, welches dieEndergebnisse aus den einzelnen Komponenten des SAP Bank Analyzeraufnimmt und dort die Analyse und Aufbereitung zu Berichten ermöglicht.

Während sich Abschnitt 3.2.17 mit der Rolle als Reporting-BW beschäftigt,geht es in diesem Abschnitt um die Verwendung als Tool-BW. Das Tool-BWwird speziell zur Verwaltung von Merkmalen und Kennzahlen sowie vonIndexinformationen und Datenbankviews auf Tabellen verwendet:

� Verwaltung aller MerkmalinformationenDas manuelle Anlegen von zusätzlichen kundendefinierten Merkmalenund das Erfassen von Stammdaten einschließlich der Hierarchien fürdiese Merkmale erfolgt im Tool-BW. Diese Merkmale werden anschlie-ßend über eine Funktion Abgleichen in das Merkmalrepository repli-ziert. Umgekehrt werden Merkmale, die Feldern im Bank Analyzer-Coreentsprechen, in das Tool-BW repliziert. Abschnitt 2.2.2 enthält detail-lierte Informationen über das Merkmal- und Kennzahlrepository undAbschnitt 6.1.1 grundlegende Informationen über Merkmale.


� Verwaltung eines Großteils der KennzahlinformationenDas manuelle Anlegen von Kennzahlen erfolgt im Kennzahlrepository.Beim Speichern werden die Kennzahlinformationen automatisch in dasTool-BW repliziert. Die Replizierung erfolgt also bei Kennzahlen immerin der Richtung vom Core zum Tool-BW. Abschnitt 2.2.2 enthält detail-lierte Informationen über das Merkmal- und Kennzahlrepository undAbschnitt 6.1.1 grundlegende Informationen über Kennzahlen.

� Indexfunktion in der Financial DatabaseDie Financial Database schreibt für alle Finanzdaten wie Finanzge-schäfte, Bestände etc. ausgewählte Informationsbestandteile in Daten-banktabellen (so genannte ODS-Objekte) des Tool-BW fort, beispiels-weise die ISIN-Nummer zu Aktien, die Vertragsnummer von Finanz-geschäften oder die Identifikationsnummern der beteiligtenGeschäftspartner. Abschnitt 3.2.4 enthält detaillierte Informationenüber die Indexfunktion in der Financial Database.

� Datenbankviews über FinanzdatenAufbauend auf der Indexfunktion wickelt die Financial Database sämt-liche Datenselektionen über die im Tool-BW fortgeschriebenen Daten-banktabellen ab. Konkret können über Datenbankviews (so genannteInfoSets) im Tool-BW die benötigten Informationen aus einer oder meh-reren Datenbanktabellen ausgelesen werden, um beispielsweise Dateneines Finanzgeschäfts zusammen mit Informationen über denGeschäftspartner zu erhalten. Abschnitt 3.2.4 enthält detaillierte Infor-mationen über die Verwendung von InfoSets in der Financial Database.

Weitere Informationen zur Systemlandschaft und zum Zusammenspiel desBank Analyzer-Core mit dem Tool-BW enthält Abschnitt 1.4.

2.2.2 Merkmal- und Kennzahlrepository – Zentrale Verwaltung von Feldern

Das Merkmal- und Kennzahlrepository gehört zu den grundlegendenDiensten des SAP Bank Analyzer und stellt allen Komponenten auf Anfragedie semantischen und technischen Eigenschaften von Merkmalen undKennzahlen zur Verfügung, die zur korrekten Verarbeitung sowie Ein- undAusgabe entsprechender Werte benötigt werden.


Das Konzept der Merkmale und Kennzahlen wurde zusammen mit demSAP Business Information Warehouse im Jahr 1998 eingeführt. Unter demBegriff Kennzahlen werden hauptsächlich die Beträge und Mengen mit ih-ren Einheiten wie beispielsweise EURO oder Stück zusammengefasst, aberauch einheitenlose Kennzahlen wie z.B. Faktoren oder prozentuale Werte


fallen unter diesen Begriff. Das gemeinsame Kriterium von Kennzahlen ist,dass man mit ihnen rechnen kann. Unter den Begriff Merkmale fallen alleübrigen Daten, wie zum Beispiel Länderinformationen, Geschäftspartner-informationen, Zeitangaben oder Rechnungsnummern. Sowohl Merkmaleals auch Kennzahlen können zu einem Zeitpunkt immer nur einen Wertaufnehmen, und dieser ist bei Merkmalen oftmals wegen zusätzlicher se-mantischer Anforderungen auf einige wenige Inhalte eingeschränkt. Bei-spielsweise gibt es in manchen Komponenten das Merkmal Legale Einheit(siehe Abschnitt 4.2.4), welches Geschäftsvorfälle und Bestände als zu ei-ner bestimmten Tochtergesellschaft eines Konzerns zugehörig kennzeich-net. Es muss natürlich verhindert werden, hier die Kennung einer nichtexistierenden Tochtergesellschaft einzutragen. Im Detail erfüllt das Merk-mal- und Kennzahlrepository die folgenden Anforderungen:

� Einheitliche Verwaltung von Merkmalen und KennzahlenDie Semantik der hier verwalteten Merkmale und Kennzahlen ist im SAPBank Analyzer übergreifend bekannt und einheitlich. Wenn mehrereKomponenten das gleiche Merkmal bzw. die gleiche Kennzahl verwen-den, ist sichergestellt, dass die gleiche Semantik gemeint ist.

� Grundlegende Datenmodellierung Im Merkmal- und Kennzahlrepository ist auf grundlegender Ebenebereits eine Datenmodellierung möglich. Dies gilt insbesondere fürMerkmale, da diese über Klammerung, Attributierung und Referenzie-rung zueinander in Beziehung stehen können.

� Erweiterbarkeit um Kundenmerkmale und -kennzahlenDas Repository ist erweiterbar und erlaubt es damit dem Kunden, seineeigenen Begriffe in das Datenmodell des SAP Bank Analyzer einzufüh-ren.

� Nahtlose Integration von SAP- und KundenfeldernDas Merkmal- und Kennzahlrepository stellt eine Reihe von einheit-lichen Services für die enthaltenen Felder zur Verfügung. Die Anwen-dungen werden hierdurch insbesondere von der unterschiedlichen Her-kunft und den speziellen Eigenschaften der einzelnen Merkmale bzw.Kennzahlen abgeschirmt (z.B. im SAP-Datenmodell enthalten oder vomKunden angelegt, mögliche Werte als Wertetabelle oder Festwerteusw.). Dies ermöglicht eine generische Programmierung, bei der dieKomponente die tatsächlich vorhandenen Felder nicht statisch zu ken-nen braucht. Insbesondere unterstützt das Repository die Komponen-ten bei der Generierung von zusammengesetzten Objekten (Struktu-ren/Tabellen) aus den verwalteten Feldern und bei der Verwendung die-


ser generierten Objekte. Beispielsweise baut der in Abschnitt 2.2.4beschriebene Segmentierungsservice auf den Funktionalitäten desMerkmal- und Kennzahlrepository auf.

Detaillierte Informationen über das Konzept der Merkmale und Kennzah-len erhalten Sie in Abschnitt 6.1.1.

Die Architektur des Merkmal- und Kennzahlrepo-sitory

Um eine einheitliche Verwendung von Merkmalen und Kennzahlen in al-len Komponenten des SAP Bank Analyzer zu ermöglichen, wurde dasMerkmal- und Kennzahlrepository realisiert. Es versorgt alle Komponen-ten auf Anfrage mit den technischen und semantischen Eigenschaften vonMerkmalen und Kennzahlen und ermöglicht somit die Nutzung der glei-chen Datenformate, Überschriften, Beschreibungen etc. in allen Ein- undAusgaben.

Abbildung 2.14 Die Architektur des Merkmal- und Kennzahlrepository im Überblick

Die Datennutzung zwischen den einzelnen Komponenten inklusive des alsTool-BW benutzten SAP Business Information Warehouse wird so verein-heitlicht, dass alle »vom Gleichen« reden. Für die Pflege von Merkmalenund Kennzahlen stellt es diverse Customizingoberflächen zur Verfügung.

Definieren von Merkmalen und Kennzahlen

Zusätzliche kundeneigene Merkmale, die keinem im Bank Analyzer-Corevorhandenen Feld entsprechen, werden im Tool-BW definiert und in einendem Merkmalrepository bekannten Katalog aufgenommen. Über eineFunktion Abgleichen im Customizing des Merkmalrepository werden allein diesem Katalog definierten Merkmale anschließend aus dem Tool-BW

Tool-BW Field Repository SAP Bank Analyzer Core Field Repository

RuntimeAPI

Layer

Keyfigures:

Meta Data(Description, Help,tec. Attributes, etc.)

RuntimeAPI

Layer

Keyfigures:


Dialogs forKeyfigure

Administration

Replication >

< Replication

Dialogs forCharacteristicsAdministration

Characteristics:

Meta Data(Description,Help,tec. Attributes, etc.)

Master Data(Possible Values,

etc.)

Characteristics:

Meta Data(Description,Help,tec. Attributes, etc.)

Master Data(Possible Values,

etc.)

Application


ausgelesen und in das Merkmalrepository repliziert. Umgekehrt werdenMerkmale, die bereits als Felder im Bank Analyzer-Core vorhanden sind,dort im Merkmalrepository registriert und ins Tool-BW repliziert. Die Re-gistrierung eines Feldes als Merkmal kann bereits durch die SAP-Entwick-lung erfolgen (Feste Merkmale) oder kundenindividuell vorgenommenwerden (Optionale lokale Merkmale).

Abbildung 2.15 Definieren von Merkmalen und Kennzahlen

Kennzahlen werden immer im Bank Analyzer-Core angelegt, da im BankAnalyzer einige Eigenschaften, namentlich die so genannte Kennzahlklasseund der Währungstyp, als Information benötigt werden, für die es im Tool-BW keine Ablagemöglichkeit gibt. Aus diesem Grund definiert man dietechnischen und semantischen Eigenschaften einer Kennzahl direkt imCustomizing des Kennzahlrepository, und beim Abspeichern werden dannalle Informationen bis auf die Kennzahlklasse und den Währungstyp in dasTool-BW repliziert.

Regeln zurDefinition von

Merkmalen undKennzahlen

Merkmale und Kennzahlen können wie beschrieben vom Anwender an-gelegt werden (Erweiterbarkeit), sie können aber auch schon von der SAP-Entwicklung definiert und ausgeliefert werden. Natürlich kann der Kundeauch eigene Erweiterungen der Software entwickeln und in diesem Zu-sammenhang Merkmale und Kennzahlen definieren. In jedem Fall solltenbei der Definition einige Regeln erfüllt sein, damit alle Merkmale undKennzahlen generisch verwendbar sind und für den Anwender das Daten-modell des Systems transparent machen.

1. Define customer characteristic in Tool-BW

2. Assign customer characteristic to catalog

3. Replicate catalog with Characteristic Repository

1. Define key figure in Key Figure Repository

2. Replicate key figure with catalog in Tool-BW

Characteristics

Key figures

Characteristic/Key Figure Repository Tool-BW

1. Define fix/local characteristic in Tool-BW

2. Replicate with Tool-BW Catalog


� Generelle Regeln

� Eindeutige betriebswirtschaftliche SemantikDie betriebswirtschaftliche Semantik des Feldes ist global für den SAPBank Analyzer bekannt, d.h. in allen Komponenten gleich.

� Eigenständige SemantikDie betriebswirtschaftliche Semantik sollte eigenständig sein, unddas Feld sollte keine anderen Felder brauchen, damit die Bedeutungklar ist.

� Spezielle RegelnInsbesondere sollten folgende Arten von Feldern genau daraufhinuntersucht werden, ob sie tatsächlich betriebswirtschaftlich relevanteInformationen transportieren:

� Lokale FelderFelder, die nur in einer Komponente bekannt sind, sollten nicht alsMerkmal bzw. Kennzahl registriert werden (oder aber die Sichtbar-keit sollte eingeschränkt werden).

� Erläuternde FelderFelder, deren Inhalt die Bedeutung anderer Felder näher beschrei-ben, sollten nicht als Merkmal oder Kennzahl, sondern als Attributdefiniert werden.

� Technische Felder ohne betriebswirtschaftliche SemantikFelder, die keine betriebswirtschaftliche Semantik tragen und des-halb nicht sinnvoll in generischen Funktionen und zum Transport vonInformationen über eine Komponente hinaus verwendet werdenkönnen, sollten nicht registriert werden (oder aber ihre Sichtbarkeitsollte eingeschränkt werden).

Es hat sich gezeigt, dass es aus Effizienzgründen sinnvoll sein kann, gegendie oben genannten Regeln zu verstoßen. Daher wurde das Konzept derSichtbarkeit von Merkmalen und Kennzahlen eingeführt. So kann man Fel-der anlegen, die im Repository vorhanden sind und für die entsprechendeServices genutzt werden können, die aber für andere Komponenten undAnwender nicht überall sichtbar sind. Die Einstellung der Sichtbarkeit kannausschließlich von der SAP-Entwicklung genutzt werden.

Beim Anlegen von Merkmalen im Kundensystem sollte in folgender Rei-henfolge vorgegangen werden:


1. Prüfen, ob es ein von SAP ausgeliefertes Festes Merkmal mit dergewünschten Semantik gibt. Wenn dies der Fall ist, sollte das FesteMerkmal verwendet werden.

2. Prüfen, ob es im Bank Analyzer-Core ein Feld (Datenelement) mit dergewünschten Semantik gibt. Wenn dies der Fall ist, sollte ein LokalesMerkmal unter Verwendung des Datenelements angelegt werden. SAPliefert zur Unterstützung dieser Prüfung eine Vorschlagsliste mit Daten-elementen aus, die als Merkmale in Frage kommen.

3. Anlegen eines Frei definierbaren Merkmals im Tool-BW mit Hilfe einesInfoObjects.

Unterschiede zumData Dictionary

Sowohl Merkmale als auch Kennzahlen sind also letztlich Felder mit einerdefinierten Semantik und bestimmten technischen Eigenschaften. Diesentspricht soweit der Rolle von Datenelementen im Data Dictionary, wiees jedem ABAP-Objects-Programmierer geläufig ist. Die Notwendigkeit ei-nes eigenen Repository, das sich vom Data Dictionary unterscheidet, er-gibt sich aber aus folgenden Punkten:

� Verwaltung zusätzlicher Informationen Das Repository kann zusätzliche Eigenschaften verwalten, die es imData Dictionary nicht gibt, die aber für die Anwendungen notwendigoder nützlich sind. Beispiele hierfür sind ein festgelegter Feldname, derin allen Anwendungen für dieses Feld verwendet werden soll, die Klam-merung von Merkmalen oder die Hierarchisierung von Merkmalen.

� Katalogfunktion für FelderDas Merkmal- und Kennzahlrepository grenzt die in bestimmter Weiseverwendbaren Felder vom (viel größeren) Rest des Data Dictionary ab.Dies vereinfacht für den Anwender die Bedienung der entsprechendenFunktionen und ermöglicht eine sinnvolle Auswahlhilfe (Hilfe F4).

� High-Level ServicesDie Verwendung der Felder wird gegenüber dem Dictionary durchgekapselte, einheitliche Services vereinfacht. Diesbezüglich werdensowohl komfortable programmatische Funktionalitäten zum Auslesenvon technischen und semantischen Eigenschaften zur Verfügunggestellt, als auch komfortable und für den Endanwender taugliche Ver-waltungsoberflächen.

� Mandantenabhängigkeit von Merkmalen und KennzahlenDas Merkmal- und Kennzahlrepository ist im Gegensatz zum Data Dic-tionary mandantenabhängig, d.h., pro Mandant kann bei Bedarf eineigener Katalog an Merkmalen und Kennzahlen verwendet werden. Die


Mandantenabhängigkeit ist durch die Verwendung des Tool-BW je nachVerwendung der Quellsystem-ID eingeschränkt (siehe Abschnitt 2.2.9).

Gemeinsamkeiten zum Data Dictionary

Da Merkmale und Kennzahlen im SAP Bank Analyzer u.a. den Zweck ha-ben, als Felder Grundlage für die Generierung von zusammengesetztenData-Dictionary-Objekten (Strukturen, Tabellen) zu sein, besteht ein en-ger Zusammenhang zwischen Merkmalen und Kennzahlen auf der einenSeite sowie Datentypen im Data Dictionary auf der anderen Seite. Zu denEigenschaften jedes Feldes im Repository gehört u.a. ein zugeordnetes Da-tenelement. Allerdings sieht das Konzept im SAP Bank Analyzer vor, dassnicht alle Eigenschaften der Merkmale und Kennzahlen in die Datenele-mente repliziert werden. Zu den Gemeinsamkeiten zwischen Merkmal-und Kennzahlrepository und Data Dictionary gehört:

� Verwendung des Data Dictionary bei MerkmalenZu den Merkmalen, die aus dem BW übernommen werden, wird einDatenelement generiert, jedoch keine Domäne, sodass bestimmteEigenschaften hier nicht hinterlegt werden können, sondern direkt ausdem Tool-BW nachgefragt werden, z.B. Stammdaten für die Auswahl-hilfe (Hilfe F4).

� Verwendung des Data Dictionary bei KennzahlenZu jeder Kennzahl wird ein eigenes Datenelement generiert, jedochkeine Domäne, sondern es wird eine Standarddomäne jeweils fürBeträge, Mengen, Fixpunkt bzw. Fließkommazahlen verwendet.

Generell werden Eigenschaften von Merkmalen und Kennzahlen nicht ausden Data-Dictionary-Eigenschaften der generierten Strukturen und Tabel-len ermittelt. Stattdessen gehen die Komponenten im Bank Analyzer im-mer den Weg über das Merkmal- und Kennzahlrepository. Dies gilt z.B. fürfolgende Feldeigenschaften und Funktionen:

� Beschriftung und Beschreibung (sprachabhängig!) Kurze, mittlere und lange Titel sowie Kurzbeschreibungen werdensprachabhängig aus dem M/K-Repository ausgelesen.

� Auswahlhilfe (F4-Hilfe)Stammdaten mit Titeln werden sprachabhängig vom M/K-Repositoryzur Verfügung gestellt.

� Wertprüfung Auf Eingabeoberflächen werden automatisch Wertprüfungen durchge-führt, z.B. gegen den gültigen Wertebereich, hinterlegte Stammdatenetc.


� KonvertierungsexitsKonvertierungsexits, die sprachabhängig die Eingaben des Anwendersin interne Formate konvertieren (beispielsweise für Datum und Zeit)werden vom M/K-Repository zur Verfügung gestellt.

Beispielsweise darf bei einer internen Tabelle, die auf einer generiertenStruktur basiert und die mit dem SAP List Viewer angezeigt werden soll,nicht nur die generierte Struktur dem List Viewer bekannt gemacht wer-den. Stattdessen wird der Feldkatalog des List Viewers explizit mit den vomRepository zur Verfügung gestellten Eigenschaften versorgt. Die meistenim Bank Analyzer verwendeten Tools bieten entsprechende Möglichkeitenan (teilweise existieren entsprechende Verschalungen, z.B. für die FreienSelektionsdialoge).

Berechtigungenauf Merkmals-

ebene

Grundsätzlich besteht die Möglichkeit, Berechtigungen für einzelne Aus-prägungen beliebiger Felder der Datenbanktabellen zu vergeben. Bei-spielsweise soll ein Mitarbeiter im Credit Risk Analyzer nur die Risikobe-wertungen zu Finanzgeschäften aus der Legalen Einheit Konzernanschauen dürfen, ein anderer Mitarbeiter im Balance Analyzer nur ma-nuelle Buchungen zu Aktien erfassen dürfen, die zum Handeln angeschafftwurden etc. Welche Felder hierfür verwendet werden, kann kundenspe-zifisch festgelegt werden.

Abbildung 2.16 Berechtigungen auf Merkmalsebene

Routine from Authority check

Application

Authority check

Analysis of customizing

Assembly of theauthority check

Interpretationof selection criterias

Generation of authority check call

Call ofauthority check

GenerateABAP-Coding

Temporary/Permanent

generation of subroutinepools

SAPRepository

SAPMemory

SAP Authori-ty check

SAP Authori-ty check

Charactericisticsand master data

Customizing data

Authority check types

Authority check charactericistic

profiles

Applicationfields Contexts


Zentrales Steuerungselement ist der Berechtigungstyp. Für jeden Berech-tigungstyp wird ein eigenes Berechtigungsobjekt angelegt. Die Zuordnungder Merkmale zu den Feldern des Berechtigungsobjektes geschieht überein Berechtigungsmerkmalprofil. Zusätzlich können für jedes Berechti-gungsobjekt eigene Anwendungsfelder fest ausgeprägt werden. Um nichtfür jedes benötigte Berechtigungsmerkmalprofil ein eigenes Berechti-gungsobjekt kreieren zu müssen und damit letztlich den Aufwand bei derVergabe der Berechtigungen zu erhöhen, sieht das Berechtigungskonzeptein dreistufiges Verfahren zur Interpretation der Berechtigungsfelder vor.

Der Ablauf der Analyse des Customizings hängt davon ab, welche Ein-gangsparameter von der Anwendung übergeben wurden bzw. wie dasCustomizing selbst aussieht. Durch die Angabe eines Kontextes oder einesBerechtigungsmerkmalprofils kann die Interpretation der zu prüfendenDaten gesteuert werden.

� Es wurde kein Berechtigungsmerkmalprofil übergeben, im System-Customizing ist kein Kontext hinterlegt.Anhand des Berechtigungstyps ermittelt das Programm aus dem Cus-tomizing das Berechtigungsobjekt, die auszuprägenden Anwendungs-felder, das zugeordnete Berechtigungsmerkmalprofil und den Aufbaudieses Berechtigungsmerkmalprofils.

� Es wurde kein Berechtigungsmerkmalprofil übergeben, im System-Customizing ist ein Kontext hinterlegt.Die Ermittlung des Berechtigungsobjektes und der auszuprägendenAnwendungsfelder erfolgt analog zum vorhergehenden Szenario. Mitder Ausprägung des Kontextfeldes wird versucht, das kontextbezogeneBerechtigungsmerkmalprofil zu ermitteln. Ist zum Kontext kein Berech-tigungsmerkmalprofil hinterlegt, wird das am Berechtigungstyp hinter-legte Profil verwendet.

� Es wurde ein Berechtigungsmerkmalprofil übergebenBerechtigungsobjekt und auszuprägende Anwendungsfelder werdenanalog zum ersten Szenario ermittelt. Das von der Anwendung über-gebene Berechtigungsmerkmalprofil wird zum Aufbau der Berechti-gungsprüfung verwendet, auch wenn ein davon abweichendes im Cus-tomizing hinterlegt ist.

Verzichtet die Anwendung auf die Angabe eines Kontextes, wird das zumBerechtigungstyp hinterlegte Berechtigungsmerkmalprofil verwendet. DieBerechtigungsobjekte haben folgenden Aufbau:


� Freie Verwendung von Applikationsfeldern und MerkmalenDie Anzahl der Applikationsfelder ist unabhängig von der Anzahl derMerkmalfelder, auf deren Grundlage die Berechtigungsprüfung abläuft.

� Maximale Anzahl von Feldern = 10Die Anzahl von Applikationsfeldern plus Merkmalfeldern ist auf insge-samt zehn begrenzt.

� Minimale Anzahl von Feldern = 2Es muss mindestens ein Applikationsfeld und ein Merkmalfeld vorhan-den sein.

Abbildung 2.17 Aufbau des generischen Berechtigungsobjekts

Die Zahl n ergibt sich aus der maximalen Anzahl Berechtigungsfelder (z. Z.10) abzüglich mindestens eines Merkmalfeldes. Die Zahl m ergibt sich ausder maximalen Anzahl Berechtigungsfelder (z. Z. 10) abzüglich der Anzahlder Anwendungsfelder. Die Felder Anwendungsfeld 1 bis Anwendungsfeldn werden von der Anwendung abhängig vom Berechtigungstyp mit spe-zifischen Feldern des Berechtigungstyps versorgt, die für die Berechti-gungsprüfung relevant sind, z.B. Objekttyp, Objektname/-nummer, Sta-tus, Kalkulationsgebiet. Die Bedeutung der Anwendungsfelder wird ineiner Systemtabelle hinterlegt und von SAP ausgeliefert (z.B. hat im Pro-zess Risikolauf Anwendungsfeld 1 die Bedeutung Lauftyp und Anwen-dungsfeld 2 die Bedeutung Status). Diese Bedeutung muss entsprechenddokumentiert werden, damit der Anwender die Berechtigungen richtigvergeben kann. Durch das System-Customizing kann eines der Anwen-dungsfelder als kontextidentifizierendes Feld ausgezeichnet werden. Dar-über hinaus wird festgelegt, ob ein Anwendungsfeld als Muss- oder Kann-feld angesehen werden soll.

Der Kontext stellt eine Art Berechtigungsobjekttyp dar, der eine abwei-chende oder differenziertere Sicht auf einen Berechtigungstyp zulässt. Erbeschreibt das Umfeld, in dem die Berechtigungsprüfung stattfindet, z.B.Vertrag oder Risikolauf. Kontexte werden von SAP definiert und in einer

Merkmal m

...

Merkmal 1

Anwendungsfeld n

...

Anwendungsfeld 1


Systemtabelle ausgeliefert. Eine typische Ausprägung des Anwendungs-feldes ist die Aktivität. In letzterem Fall bezieht sich das Feld auf die TabelleTACT (Anlegen/Ändern/Anzeigen/Löschen/Freigeben/...). Die Verwen-dung der Anwendungsfelder ist für die Anwendung optional, ebenso dieFestlegung eines Kontextes. Zur Laufzeit werden die Felder Merkmal 1 –Merkmal n entsprechend dem Customizing mit den Werten der zugeord-neten Merkmale versorgt und ein Authority Check ausgeführt. Wenn nichtallen Berechtigungsfeldern ein Merkmal zugeordnet ist, wird für die nichtzugeordneten Felder keine Berechtigungsprüfung durchgeführt.

VerwendungDas Merkmal- und Kennzahlrepository wird in allen Komponenten unddort von den meisten Prozessen benötigt. Sei es für die Anzeige von Daten,in deren Zusammenhang sprachabhängig kurze, mittlere und lange Be-schreibungen zu den Feldern nachgelesen werden müssen; sei es zur Er-mittlung, ob ein Kundenfeld der Kategorie der Merkmale oder der Kenn-zahlen zuzuordnen ist; sei es zur Prüfung von Eingaben auf Eingabe- oderSelektionsbildschirmen gegen hinterlegte Stammdaten.

Folgende Verwendungen des Merkmal- und Kennzahlrepository bietensich:

� Verwendung in fast allen Komponenten

� Klassifikation von Feldern Prüfung, ob ein kundendefiniertes Feld in einer Struktur oder Tabelleein Merkmal oder eine Kennzahl ist (Betrag, Menge, Faktor)

� Lesen von kurzen, mittleren und langen TextfeldernJeder Anzeige-Dialog benötigt Textfelder, um Beschriftungen undTooltipps der Felder anzuzeigen.

� EingabeprüfungEingegebene Werte für Merkmale oder Kennzahlen können gegendie entsprechenden Regeln bzw. vorhandene Stammdaten geprüftwerden.

� Verwendung in vielen grundlegenden Diensten/Tools

� Kundenspezifische StammdatenIm Segmentierungsservice werden die technischen Eigenschaftenvon Merkmalen benötigt, um die Strukturen und Tabellen zur Ver-waltung von Stammdaten zu erzeugen.

� Kundenspezifische BewegungsdatenIn der Result Database werden die technischen Eigenschaften vonMerkmalen und Kennzahlen benötigt, um die Tabellen zur Verwal-tung von Bewegungsdaten zu erzeugen.


Darüber hinaus spielt das Merkmal in allen Services zur Unterstützung derkundenspezifischen Anpassung von Strukturen und Tabellen eine ent-scheidende Rolle. Liefert es doch die notwendigen technischen Eigen-schaften zu jedem Merkmal und jeder Kennzahl wie Datentyp, Länge etc.

2.2.3 Struktur-Customizing/Prozess-Customizing – Trennung von Daten- und Prozessanforderungen

Der SAP Bank Analyzer ist ein hochgradig generisches Produkt. Die meis-ten Datenstrukturen können um eigene Merkmale und Kennzahlen erwei-tert oder gar komplett benutzerdefiniert angelegt werden, bevor die aufdiesen Datenstrukturen ablaufenden Prozesse gemäß den Kundenanfor-derungen angepasst werden.


Der Kunde kann das SAP Bank Analyzer-Datenmodell an vielen Stellendurch Hinzunahme von Merkmalen und Kennzahlen zu den von SAP festvorgegebenen Feldern anpassen oder auch völlig eigene Strukturen undTabellen definieren. Beispielsweise könnte er das Produkt Optionsanleihemit einem Datum für den Abschluss eines dazu gehörenden Vorvertrags(Letter of Intent) ausstatten oder die Granularität der Buchführung im Fallevon Aktien auf die Unterscheidung einzelner Händler verfeinern. DieseEinstellungen werden als Struktur-Customizing oder auch Konfigurationbezeichnet und erweitern bzw. definieren Datenstrukturen und Daten-banktabellen. Folgende Aufgaben umfasst das Customizing im SAP BankAnalyzer:

� Struktur-Customizing zur Anpassung/Definition des DatenmodellsAnpassung, Erweiterung bzw. Definition des Datenmodells von Struk-turen und Datenbanktabellen, die später zur Kommunikation zwischenden Komponenten sowie zur Ablage von Daten benutzt werden sollen

� Generierung von Strukturen und Datenbanktabellen Erzeugt aus dem kundenspezifischen Datenmodell die Strukturen undDatenbanktabellen, d.h. Umsetzung des Datenmodells im System

� Prozess-Customizing zur Anpassung/Definition der betriebswirt-schaftlichen Funktionalität Anpassung, Erweiterung bzw. Definition des betriebswirtschaftlichenProzess-Customizings, das die Weiterverarbeitung von Finanzdaten,beispielsweise die Anreicherungen, Kalkulationen und Bewertungensteuert

Auf das Struktur-Customizing folgt in einem zweiten Schritt die so ge-nannte Generierung, in der die notwendigen Strukturen, Datenbanktabel-


len etc. tatsächlich im SAP Bank Analyzer-System erzeugt werden. Die Ge-nerierung findet sowohl in der gemeinsamen Datengrundlage, derFinancial Database, als auch an den notwendigen Stellen innerhalb der üb-rigen Komponenten des SAP Bank Analyzer statt. Sie umfasst somit allestrukturbildenden Einstellungen des SAP Bank Analyzer und grenzt sichdadurch vom restlichen Customizing, dem so genannten Prozess-Customi-zing ab. Letztere Customizingeinstellungen beeinflussen nur die Prozess-verarbeitung im SAP Bank Analyzer und setzen auf den strukturbestim-menden Einstellungen des Struktur-Customizings auf.

Vorgehensweise im Customizing

Zum Struktur-Customizing müssen sowohl betriebswirtschaftliche als auchtechnische Faktoren mit berücksichtigt werden. Die Konsistenz der Kon-figuration in den verschiedenen Teilen des SAP Bank Analyzer muss derKunde weitgehend selbst sicherstellen. Unterstützt wird er dabei von Kon-figurationsleitfäden für die einzelnen Komponenten. In Teilbereichen sindauch Abhängigkeiten zwischen verschiedenen Konfigurationseinstellun-gen dem System bekannt und werden entsprechend automatisch zu ab-hängigen Objekten weitergereicht (beispielsweise innerhalb der Generie-rung des Balance Analyzer).

Abbildung 2.18 Vorgehensweise beim Customizing des SAP Bank Analyzer

Ergebnis des Struktur-Customizings sind in der Regel eine Vielzahl von ge-nerierten Datenstrukturen. Dabei handelt es sich um transiente Struktu-ren, die z.B. zu Kommunikationszwecken an Schnittstellen verwendetwerden, und um persistente Strukturen (Datenbanktabellen) zur Ablage

Definition of Characteristics and Keyfigures

Definition and Extension of

Structures / Tables

Run Structure / Table

Generation

Define Derivation Steps

Process Customizing

Structure Customizing

tDefine CalculationSteps

DefineCommunication

Steps

...


der Anwendungsdaten nach dem vom Kunden angepassten Datenmodell.Das Thema Customizing wird innerhalb der Detailabschnitte zu den Über-greifenden Komponenten, der IAS-Lösung und der Basel II-Lösung nochmehrfach aufgegriffen.

Verwendung In den Übergreifenden Komponenten ist ein Großteil der Einstellungs-möglichkeiten dem Begriff Struktur-Customizing zuzuordnen. Dort be-steht die zentrale Datenablage für die Spiegelung operativer Daten (Finan-cial Database) aufgrund ihrer großen Flexibilität beinahe ausschließlich ausStruktur-Customizing, während die zentralen Methoden zur Bereitstellungder im ganzen Bank Analyzer genutzten Übergreifenden Methoden vor-wiegend aus Prozess-Customizing bestehen.

Folgendermaßen werden das Struktur-Customizing, die Generierung unddas Prozess-Customizing verwendet:

� Verwendung in den Übergreifenden Methoden

� Die Speicherung von Finanzdaten besteht hauptsächlich aus Struk-tur-Customizing, weil das Datenmodell flexibel ist (Financial Data-base).

� Das Mapping der Finanzdaten auf fixe Berechnungsstrukturen erfor-dert teilweise Struktur-Customizing (Übergreifende Methoden).

� Verwendung in der IAS-LösungDas Customzing ist genau definiert in die Segmente »Vor Generierung«(Struktur-Customizing), »Generierung« and »Nach Generierung« (Pro-zess-Customizing).

� Verwendung in der Basel II-LösungJeder Funktionsblock unterteilt das Customzing in die Auswahl vonMerkmalen und Kennzahlen (Struktur-Customizing), die Definition derProzessschritte (Prozess-Customizing) und die Aktivierung (Generie-rung).

Die IAS-Lösung baut auf einer Reihe von SAP festgelegter betriebswirt-schaftlicher Entitäten (Stammdaten) auf, die vom Kunden weitgehend anseine konkreten Anforderungen angepasst werden können (Buchhaltungs-objekt, Saldenobjekt etc.). Diese Entitäten beeinflussen den Aufbau bei-nahe jeder Kommunikationsstruktur und jeder Datenbanktabelle, sodassdort das Struktur-Customizing unter dem Begriff Vor Generierung zusam-mengefasst wurde, worauf die Generierung folgt und sich daran das Pro-zess-Customizing unter dem Begriff Nach Generierung anschließt. Die BaselII-Lösung kommt ohne von SAP festgelegte betriebswirtschaftliche Enti-täten (Stammdaten) aus und ist in ihrer Ausprägung für den Kunden völlig


frei konfigurierbar. Hier unterteilt sich jeder Prozessschritt in die Auswahlvon Quellmerkmalen und Kennzahlen (Struktur-Customizing), die Bestim-mung der Prozessschritte (Prozess-Customizing) sowie die Aktivierung desProzessschritts (Generierung).

2.2.4 Segmentierungsservice – Generierung von Datenstrukturen

Der Segmentierungsservice gehört zu den grundlegenden Diensten desSAP Bank Analyzer zur Verwaltung von Stammdaten. Er ermöglicht die Ge-nerierung und Speicherung von Data-Dictionary-Strukturen und Daten-banktabellen, die sich ganz oder teilweise aus kundendefinierten Merk-malen zusammensetzen.


Um das Architekturkonzept des Struktur- und Prozess-Customizings fürStammdaten technisch zu unterstützen, wurde der Segmentierungsservicerealisiert. Diesem teilt ein Konfigurator manuell bzw. eine Komponenteautomatisch die Namen der gewünschten Merkmale aus dem Merkmal-repository mit, und er generiert mit diesen Informationen eine entspre-chende Struktur bzw. Datenbanktabelle. Die Informationen über die re-levanten Merkmale werden in Merkmalstrukturen (SGS-Strukturen)gespeichert.

Folgendes sind die Aufgaben des Segmentierungsservice:

� Definition kundenspezifischer Strukturen und DatenbanktabellenDer Segmentierungsservice kennt nur Merkmale und wird deshalb aus-schließlich für die Verwaltung generischer Stammdaten verwendet.

� Verwaltung von kundendefinierten Strukturen und DatenbanktabellenDer Segmentierungsservice stellt High-Level-Funktionen und Customi-zing-Transaktionen für die Verwaltung der kundendefinierten Merk-malsstrukturen sowie für die generierten DDIC-Strukturen/-Tabellen zurVerfügung.

� Möglichkeit zur modifkationsfreien Erweiterung applikationsspezifi-scher TabellenDie kundeneigenen Daten werden in lokal generierten Tabellen gespei-chert. Die SAP-Tabellen und -Strukturen beinhalten lediglich eine ein-deutige Referenz (GUID) auf einen vom SGS verwalteten Datensatz.Dadurch wirkt der SGS wie eine modifikations- und programmierfreieErweiterungsmethode zu kundeneigenen Daten.


Diese kundendefinierten SGS-Strukturen und Datenbanktabellen werdenvon den Komponenten des SAP Bank Analyzer an den geplanten Stellenmit einbezogen und erweitern somit die fixen Strukturen und Datenbank-tabellen.

Architektur desSegmentierungs-

services

Die Architektur des Segmentierungsservices lässt sich in zwei Bereiche auf-teilen. Einerseits ermöglicht ein Satz von Customizingtransaktionen dieDefinition von SGS-Strukturen und die Generierung der zugehörigen Da-tenbanktabellen. Andererseits bietet eine Run-Time-API einer Anwendungflexible Möglichkeiten, entweder Daten in die generierten Tabellen zuschreiben oder performant zu lesen.

Abbildung 2.19 Die Architektur des Segmentierungsservices im Überblick

Im Segmentierungsservice werden nur merkmalartige bzw. attributartigeFelder (CHAR, NUMC, DATS, TIMS, CUKY) zugelassen und verarbeitet. Alstechnische Felder sind Felder vom Typ RAW zugelassen. Kennzahlen wer-den vom Segmentierungsservice nicht unterstützt, da es sich hierbei nichtum Stamm- sondern um Bewegungsdaten handelt, die meistens erst imLaufe der Verarbeitung entstehen. Neben spezialisierten Tools wie demBusiness Accounting zum Verwalten von Buchungsbelegen (siehe Ab-schnitt 4.2 steht für derartige Zwecke die Result Database zur Verfügung(siehe Abschnitt 2.2.6).

Verwaltung vonStrukturen und

Tabellen

Der Segmentierungsservice vergibt für jede Zeile einer generierten Tabelleeinen eindeutigen Schlüssel (GUID, Global Unique Identifier), der in den

SAP Bank Analyzer CoreSegmentation Service

CustomizingDialogs

Runtime&

Config.API

Layer

SAP Bank Analyzer Core Field Repository

RuntimeAPI

Layer

Keyfigures:


Dialogs forKeyfigure

Administration

Characteristics:


Master Data(PossibleValues,

etc.)

Application

Generated Structures &

Tables:

Data(Structureand Table Values,

etc.)

SGS Structures:

Meta Data(Index DefinitionsCharacteristics,

tec. Attributes, etc.)


ausgelieferten Datenbanktabellen des SAP Bank Analyzer als eindeutigeReferenz vermerkt wird.

Abbildung 2.20 Referenz von SGS-Datensätzen in ausgelieferten Tabellen

So ist eine Erweiterung von ausgelieferten Datenbanktabellen um kunden-spezifische Felder möglich, ohne dass die von SAP vorgegebenen Daten-banktabellen in ihrer Struktur verändert werden müssen. Ein Lese- oderSchreibzugriff auf die Daten wird von der Applikation so durchgeführt,dass neben dem Inhalt der eigenen Tabelle auch der Inhalt der vom Seg-mentierungsservice verwalteten generischen Tabelle berücksichtigt wird.Der Zugriff auf die Daten in den kundeneigenen generierten Tabellen wirdausschließlich über den Segmentierungsservice abgewickelt. Das Daten-modell des SAP Bank Analyzer lässt sich auf diese Weise weitgehend an dieBedürfnisse des Kunden anpassen.

PerformancePerformance ist im gesamten Bank Analyzer ein kritischer Aspekt, dem derSegmentierungsservice besonders Rechnung trägt:

� Generierter ABAP-CodeDer Segmentierungsservice verwendet für sämtliche Zugriffe auf diegenerierten Datenbanktabellen (DB-Schicht im Schichtenmodell) gene-rierte Funktionsbausteine mit jeweils integriertem ABAP Puffer. Ver-gleichbar ist dies mit vorkompilierten SQL-Statements, die auf internePuffer mit den zuletzt gelesenen Datensätzen zurückgreifen können,um die Geschwindigkeit des Zugriffs zu optimieren.

My Future

Bad Bond

Good Share

Header Text

AB1413.4.20046383MyrexIAS

AB1313.4.20042534KordobaIAS

AB1213.4.20040234OlympicIAS

SegmentationService ID

BookingDateBusiness Transaction ID

SourceSystemAccountingSystem

No

No

Yes

Pending Transaction

Subsidiary1

Subsidiary1

Corporate

Legal Entity

BuyFutureAB14

Sell BondAB13

BuyShareAB12

TransactionType

SegmentationService ID

Customer specific extension via SGS

SAP defined table


� Unterscheidung von Einzel- und MassenzugriffDer Segmentierungsservice bietet Anwendungen verschiedene Metho-den, um auf die Daten zuzugreifen. Dadurch können die Zugriffe demProzess angepasst und damit performanceoptimiert durchgeführt wer-den.

� Optionale DatenvalidierungIm Segmentierungsservice lassen sich die Prüfungen zur Datenvalidie-rung wahlweise ein- oder ausschalten, um so die Geschwindigkeit beider Verwaltung bereits geprüfter Daten weiter zu beschleunigen. DerKunde kann somit die Prioritäten zwischen Performance und Datenva-lidierung selbst setzen.

Der Segmentierungsservice stellt Steuerungsparameter zur Verfügung,über die die Datenvalidierung sowie Feldregeln (z.B. Muss- oder Kann-Feld) gesteuert werden können. Dies kann flexibel je nach Prozess undKontext gesteuert werden.

Verwendung Der Segmentierungsservice wird intensiv in der zentralen Datenablage füroperative Daten genutzt (Financial Database). Dort übernimmt er die Ver-waltung von z.B. kundeneigenen Merkmalen an Finanzgeschäften und -in-strumenten, die zusätzlich zu den von SAP vorgegebenen Feldern geführtwerden sollen.

Folgendermaßen werden die Segmentierungsservices verwendet:

� Verwendung in den Übergreifenden Komponenten

� Verwaltung von kundendefinierten Merkmalen für Primärobjektewie Finanzgeschäfte, Finanzinstrumente, Konten usw.

� Verwaltung von Stammdaten in der Rahmenlinienverteilung

� Verwendung in der IAS-LösungVerwaltung von wesentlichen betriebswirtschaftlichen Entitäten (z.B.Buchhaltungsobjekt, Finanzbestandsobjekt, Saldenobjekt)

� Verwendung in der Basel II-LösungVerwaltung von Stammdaten in der Kreditrisikoermittlung

In der IAS-Lösung kommt der Segmentierungsservice für die Verwaltungder von SAP festgelegten betriebswirtschaftlichen Entitäten zum Einsatz.Diese betriebswirtschaftlichen Entitäten (z.B. Buchhaltungsobjekt, Sal-denobjekt) können in ihren Ausprägungen vom Kunden weitgehend selbstbestimmt werden. Zur Erfüllung bestimmter Anforderungen (z.B. Buch-haltungsobjekt oder Bestand) wurde eine weitere wichtige zusätzlicheFunktionalität im Segmentierungsservice realisiert, die sicherstellt, dass


Datenzeilen in einer vom Kunden zusammengesetzten Merkmalstruktur inihrer Ausprägung genau einmal vorkommen dürfen. Die zugehörigenMerkmalstrukturen müssen dazu das Attribut UNIQUE gesetzt haben. Inder Basel II-Lösung wird der Segmentierungsservice zur Verwaltung vonStammdaten im Rahmen des Credit Risk Analyzer verwendet.

2.2.5 Ableitungstool – Anreicherung von Datenstrukturen

Das Ableitungstool gehört zu den grundlegenden Diensten des SAP BankAnalyzer und erlaubt das Füllen von SAP- und kundendefinierten Data-Dictionary-Strukturfeldern durch Mapping, Ableitung und per Funktions-bausteinaufruf. Es stellt damit eine Grundvoraussetzung dar, um Struktu-ren und Tabellen, deren Aufbau erst während der Konfiguration der Soft-ware festgelegt wird, überhaupt in die Verarbeitung integrieren zu können.


Die weitgehende Anpassung des Datenmodells an die Bedürfnisse desKunden bringt es mit sich, dass der SAP Bank Analyzer mit Merkmalen,Kennzahlen und darin enthaltenen Werten umgehen können muss, diezum Auslieferungszeitpunkt der Software noch gar nicht bekannt sind,sondern erst zu Beginn des Struktur-Customizings definiert werden. Umüberhaupt »arbeiten« zu können, benötigt der SAP Bank Analyzer daher anvielen Stellen im Customizing einen Mechanismus, der den Inhalt von kun-dendefinierten und auch festen Feldern auf diejenigen Felder mapped, diein den einzelnen Komponenten zur Verarbeitung herangezogen werden.Beispielsweise benötigt die IAS-Lösung eine so genannte Objektwährungzur Führung von Finanzbeständen, die in der Regel aus der Transaktions-währung eines Geschäftsvorfalls übernommen wird. Ebenso kann es vor-kommen, dass benötigte Felder in den Vorsystemen des Kunden nicht be-kannt sind und demzufolge deren Wert erschlossen werden muss.Beispielsweise gibt es in der IAS-Lösung den zentralen Begriff der Halte-kategorie für Finanzgeschäfte, den es in den meisten Local-GAAP Vor-schriften (z.B. HGB) nicht gibt und der demzufolge z.B. aus der Depot-nummer, der Art des Instruments oder einer ganzen Kombination vonKriterien abgeleitet werden muss (Wenn-dann-Beziehung).

ZuweisungsregelI = 5; A = B; etc.

AbleitungsregelIF I < 1000, THEN K = 'Small'; IF I < 10000, THEN K = 'Medium';IF I >= 10000, THEN K = 'Big'.Etc.


BerechnungsregelCALL FUNCTION 'DO_SOMETHING'.Implementation of function with ABAP:FUNCTION 'DO_SOMETHING'. J = I + 5.ENDFUNCTION.

Der komplexeste Fall tritt ein, wenn der Inhalt eines vom SAP Bank Ana-lyzer benötigten Feldes nur über einen Algorithmus bestimmt werdenkann. Der Algorithmus muss dann in Form von ABAP-Programmcodes(Funktionsbaustein) entwickelt und eingebunden werden, um den Wertdes benötigten Feldes zu bestimmen. Beispielsweise benötigt der Preis-rechner zur Fair-Value-Ermittlung einen betriebswirtschaftlichen undtechnischen Zeitpunkt, wobei Letzterer über einen Algorithmus von an-derer Stelle nachgelesen und als Wert in das betreffende Feld geschriebenwird. Falls erforderlich kann auch der Kunde weitere Algorithmen entwi-ckeln und in die Verarbeitung einbinden.

Architektur desAbleitungstools

Alle drei Anforderungen werden durch das Ableitungstool abgedeckt, wel-ches sogar – in einer beliebigen Kombination von Schritten zusammenge-fasst – in einer so genannten Ableitungsstrategie sowohl Zuweisungen, Ab-leitungen und Programmcodes nacheinander ausführen kann und seineDienste den einzelnen Komponenten des SAP Bank Analyzer zur Verfü-gung stellt. Diese machen an mehr als 100 Stellen Gebrauch von dieserTechnik. Intern gliedert sich das Ableitungstool in zwei Bereiche, und zwardie Pflegetransaktion und den Ableitungsprozessor. Die Pflegetransaktiondient zum Einstellen der durchzuführenden Ableitungsschritte und wirdim Rahmen des Prozess-Customizings eingestellt.

Der Ableitungsprozessor wird zur Laufzeit aus der gestarteten Applikationheraus über den Funktionsbaustein ABADR_DERIVE_CHARACTERISTICSaufgerufen, wobei besonders komplexe Prozesse durchaus auch den Ab-leitungsprozessor mehrmals an verschiedenen Stellen aufrufen können. Sowird beispielsweise im Prozess Externe Geschäftsvorfälle buchen der IAS-Lösung der Ableitungsprozessor nacheinander an verschiedenen Stellenzur Ableitung des Buchungsdatums, der Buchungskennzahlart sowie derBuchungskennzahl aufgerufen. Das Ableitungstool hält zur Nachverfol-gung aller Ableitungsentscheidungen zur Laufzeit einen Trace-Mechanis-mus bereit, der allerdings nur per Tracing (Debugging) aktiviert werdenkann. Man setzt dann einen Breakpoint auf den oben genannten Funk-tionsbaustein und setzt wie im Quellcodekommentar beschrieben die in-terne Tracing-Variable auf »X«.


Abbildung 2.21 Die Architektur des Ableitungstools im Überblick

Anschließend wird jeder ausgeführte Ableitungsschritt am Bildschirm aus-gegeben. Für den SAP Bank Analyzer mit seiner mannigfaltigen Nutzungdes Ableitungstools ist Tracing ein effizientes Hilfsmittel, um komplexe Ab-leitungsfolgen nachzuvollziehen.

VerwendungIn den Übergreifenden Komponenten kommt das Ableitungstool an meh-reren Stellen zum Einsatz. Einerseits wird es für das Mapping von Struk-turen für die Kommunikation zwischen zentraler operationaler Datena-blage und Tool-BW verwendet (Mapping zur Befüllung von ODS-Objekten). Andererseits kommt es für das Mapping von Merkmalen undKennzahlen auf die Felder der zentralen Methoden zum Einsatz, auf denengerechnet wird.

Das Ableitungstool wird folgendermaßen verwendet:


� Mapping von Informationen in Strukturen für die Kommunikationzwischen Datenspeicherung in der FDB und Tool-BW

� Mapping zwischen Merkmalen und Kennzahlen und festen Kalkula-tionsfeldern in den Übergreifenden Methoden

� Verwendung in der IAS-LösungAbleitung von kundenspezifischen Kennzahlen, auf die in der Buchhal-tung gebucht werden soll

Derivation Tool

Customizing transactions per „Strategy“:

Runtime Framework

Call „Strategy“ out of specific application

Derivation rules Function rulesAssignment rules

Derivation rules Function rulesAssignment rules

ABAP Code Generation


� Verwendung in der Basel II-LösungAbleitung von Parametern, die die Kalkulation des Kreditrisikos im Cre-dit Risk Analyzer steuern

In der IAS-Lösung kommt das Ableitungstool an sehr vielen Stellen zumEinsatz, z.B. wird es zur Bestimmung der kundendefinierbaren Kennzahleneingesetzt, auf die gebucht werden soll. In der Basel II-Lösung kann dasAbleitungstool optional zu jedem Prozess mit einbezogen werden, wennz.B. Steuerungsmerkmale für den Prozess aus anderen Merkmalen abge-leitet werden müssen.

2.2.6 Result Database – Verwaltung von Ergebnisdaten-sätzen

Die Result Database gehört zu den grundlegenden Diensten des SAP BankAnalyzer zur Verwaltung von Ergebnisdaten. Sie ermöglicht die Generie-rung und Speicherung von Datensätzen in Datenbanktabellen, die ganzoder teilweise aus kundendefinierten Merkmalen und Kennzahlen beste-hen.


Um das Architekturkonzept eines massenverarbeitenden Back-Office-Sys-tems wie dem SAP Bank Analyzer zu unterstützen, d.h. um Massendateneines Analyzers aufzunehmen, die dieser in lauforientierten Prozessen er-zeugt, wurde die Result Database (RDB) realisiert. Dabei ist die RDB ko-operativ zu parallelisierenden Analyzerschreibprozessen (siehe Abschnitt2.2.8). Eine Komponente teilt der Result Database während der Generie-rung die Namen der in Form von Datensätzen zu verwaltenden Merkmaleund Kennzahlen mit, und sie generiert mit diesen Informationen eine ent-sprechende Datenbanktabelle.

Die Result Database hat die folgenden Aufgaben:

� Flexibler Datenspeicher für ErgebnisdatenDefinition kundenspezifischer Datenbanktabellen zur Speicherung vonBewegungsdaten

� Bereitstellung umfangreicher VerwaltungsfunktionenVerwaltung von (Zwischen-)Ergebnissen in Form von Datensätzen überkomfortable Lese-, Schreib- und Änderungsfunktionen. Darüber hinauswerden administrative Funktionen wie Archivierung, Versiegelung etc.zur Verfügung gestellt.

� Extraktion der Ergebnisdaten in das Reporting-BWUnterstützung der Extraktion von Ergebnisdatensätzen zur Übernahmein das Reporting-BW oder in Dateien


Die generierten Datenbanktabellen werden von den Komponenten desSAP Bank Analyzer an den geplanten Stellen mit einbezogen und mit den(Zwischen-)Ergebnissen aus Prozessschritten gefüllt. Außerdem stellt dieResult Database Funktionalitäten zur Erzeugung einer Data Source bereit,die für die Extraktion von Daten aus den Datenbanktabellen in Dateien,das SAP Business Information Warehouse oder andere Komponenten desSAP Bank Analyzer notwendig ist.

Architektur der Result Database

Die Architektur der Result Database lässt sich in zwei Bereiche aufteilen.Einerseits ermöglicht ein Satz von Laufzeitfunktionen die Generierung vonDatenbanktabellen sowie Data Sources zur Extraktion. Andererseits er-möglicht ein Satz von Laufzeitfunktionen das Lesen, Schreiben und Lö-schen von Datensätzen.

Abbildung 2.22 Die Architektur der Result Database im Überblick

Separate Customizingtransaktionen zur Verwaltung der Result Databasegibt es nicht, da sie stets »dunkel«, d.h. von anderen Komponenten wäh-rend der Generierung mit den notwendigen Konfigurationsinformationenversorgt wird. Neben spezialisierten Tools wie dem Business Accountingzum Verwalten von Buchungsbelegen (siehe Abschnitt 4.2) ist die ResultDatabase das einzige generische Werkzeug zur Verwaltung von Ergebnis-daten im SAP Bank Analyzer. Im Gegensatz dazu handelt es sich beim Seg-mentierungsservice um ein Werkzeug zur Stammdatenverwaltung (sieheAbschnitt 2.2.4).

SAP Bank Analyzer CoreResult Database

RuntimeAPI

Layerfor Meta

Data

Tables:

Meta Data(Indices, Descr.,

tec. Attributes, etc.)Data

(StructureValues, etc.)

Structures:

Meta Data(Indices, Descr.,

tec. Attributes, etc.)Data

(StructureValues, etc.)

RuntimeAPI

Layerfor Data

Application

Create, Destroy,Open, Close

Read, Write,Delete, Update


Verwendung Die Result Database wird von den weiterverarbeitenden Komponentendes SAP Bank Analyzer genutzt. Die IAS-Lösung beispielsweise verwendetdie Result Database zur Speicherung von Ergebnisdaten und Ergebnispo-sitionen, die letztlich im Reporting-BW zu entsprechenden Abschlussbe-richten aufbereitet werden.

Folgendermaßen kann die Result Database verwendet werden:

� Verwendung in den Übergreifenden KomponentenArchivieren der Ergebnisse der Prozesse der Kontoaufrechnung, Rah-menlinienverteilung und Sicherheitenverteilung

� Verwendung in der IAS-LösungErgebnispositionen einer Periode werden in der Result Databasegespeichert und können von dort aus in das Reporting-BW zur Aufbe-reitung in Bilanzen und zur Analyse transportiert werden.

� Verwendung in der Basel II-Lösung

� Ermittelte Risikobewertungen zu Finanzinstrumenten werden in derResult Database gespeichert und können von dort weiter in dasReporting-BW geleitet werden.

� Die Historiendatenbank arbeitet intern mit der Result Database, uminterne Bewertungsmodelle und Prozessparameter zu speichern undgegebenenfalls in das Reporting-BW weiterzuleiten.

Die Basel II-Lösung verwendet die Result Database zur Speicherung der Er-gebnisse aus Risikobewertungen von Finanzgeschäften oder zur Histori-sierung von Bewertungsmodellen.

2.2.7 Freigabetool – Vier- bis Acht-Augen-Prinzip für Änderungen

Das Freigabetool gehört zu den grundlegenden Diensten des SAP BankAnalyzer und erlaubt die Gegenprüfung von Änderungen an Daten durchweitere Endanwender, bevor die geänderten Daten Gültigkeit erlangen. Esstellt damit eine Grundvoraussetzung für das Handling mit unternehmens-kritischen Informationen zur Verfügung.


Der Gesetzgeber sowie unternehmensinterne Security Policies von Finanz-dienstleistern sehen für die Änderung sensitiver Daten gesonderte Freiga-beregelungen vor, d.h., neben einem Erfasser von Daten müssen ein odermehrere Mitarbeiter bestimmt werden, um die Richtigkeit der Erfassung zu


kontrollieren. Daneben werden Kompetenzen für die Mitarbeiter festge-legt, deren ordnungsgemäße Handhabung ebenfalls durch Freigaberege-lungen unterstützt werden können.

Folgende Aufgaben hat das Freigabetool:

� DatenschutzSchutz von sensitiven Daten vor unautorisierten oder versehentlichenÄnderungen

� Überwachung von KompetenzrichtlinienÄnderungen von sensiblen Daten dürfen häufig nur nach dem Vier-,Sechs- oder Acht-Augen Prinzip durchgeführt werden.

� ÄnderungsnachverfolgungZu jeder Änderung von sensiblen Daten wird mitprotokolliert, wer waswann und mit wessen Autorisierung geändert hat.

� Bereitstellung eines komfortablen WorkflowsÜber einen Workflow soll die Handhabung der Freigabe von Änderun-gen an sensiblen Daten möglichst komfortabel und übersichtlich gestal-tet sein.

Im Übrigen kann die Revisions- und/oder die Kontrollabteilung zeitver-setzt feststellen, welcher Mitarbeiter eine Freigabe von Datenerfassungendurchgeführt hat und somit für den Sachverhalt (mit-)verantwortlich ist.Um den Freigabeprozess sensitiver Daten zu unterstützen, ist eine Umset-zung als Workflow erstrebenswert, da so der Fluss der Daten von der Inboxdes einen Mitarbeiters zum nächsten automatisiert wird.

Architektur des Freigabetools

Alle genannten Anforderungen werden durch das Freigabetool abgedeckt.Intern und für den Administrator weitgehend transparent setzt das Frei-gabetool auf der mächtigen Softwarekomponente SAP Business Workflowauf, die mit dem SAP Web Application Server ausgeliefert wird und sich so-mit nahtlos in die übrige SAP-Systemlandschaft einfügt. Für Mitarbeiter,die nur selten an Workflows teilnehmen, existiert eine Benachrichtigungüber neue Workflows per E-Mail sowie eine Weboberfläche, die über je-den Browser benutzt werden kann.


Abbildung 2.23 Die Architektur des Freigabetools im Überblick

Letztlich besteht das Freigabetool aus einem Workflow-Template, das fürdas geforderte Vier- bis Acht-Augen-Prinzip vorbereitet ist, sowie aus ei-nem Framework, welches das Workflow-Template bei Bedarf für einen An-wender instanziiert und ausführt. Registriert eine Anwendung zur Verar-beitung sensitiver Daten nun ihrerseits bestimmte Funktionen zurEingabe, Prüfung, Freigabe und Rücknahme der konkreten Daten, so wer-den diese Funktionen automatisch gemäß dem Verlauf des Workflows auf-gerufen.

Verwendung Das Freigabetool wird intensiv in der zentralen Datenablage genutzt. Dortübernimmt es für beliebig definierbare Bereiche von Geschäftsdaten dieFreigabesteuerung bei manuellen Änderungen. Für maschinell aus denVorsystemen angelieferte Datenänderungen steht hingegen ein so ge-nannter Korrekturserver zur Aufzeichnung jeglicher Änderungen zur Ver-fügung, der jedoch im Rahmen dieses Kapitels nicht weiter berücksichtigtwird. Beispielsweise können mit dem Freigabetool Änderungen an Finanz-instrumenten, an Konten oder Hedgebeziehungen, reglementiert undkontrolliert werden.

Das Freigabetool wird folgendermaßen verwendet:


� Kontrolliert bei Bedarf Änderungen an sensitiven Stammdaten, z.B.an Finanzinstrumenten, Konten oder Hedgebeziehungen

Release Tool

Customizing / Development / Enduser Transactions

Workflow Template

Runtime Workflow Engine

Application

ForwardCallback

RejectCallback

DisplayCallback

...

Workflow Instance 3Workflow Instance 2

Workflow Instance 1


� Kontrolliert bei Bedarf Änderungen an sensitiven Bewegungsdaten,z.B. an Geschäftsvorfällen oder Beständen

� Verwendung in der IAS-LösungDie Saldenverarbeitung nutzt das Freigabetool indirekt über den Kor-rekturserver, sofern die Anbindung im Customizing eingestellt wurde.

� Verwendung in der Basel II-LösungKontrolliert bei Bedarf Änderungen an sensitiven Bewertungsgrundla-gen, beispielsweise den internen Bewertungsmodellen in der Histori-endatenbank

Neben den genannten Stammdaten kann das Freigabetool auch für sämt-liche Bewegungsdaten eingerichtet werden, beispielsweise für Geschäfts-vorfälle, Bestände und alle Arten von Marktdaten wie Zinskurven, Wäh-rungskurse etc. Innerhalb der IAS-Lösung kommt nicht das Freigabetoolzum Einsatz, sondern die üblichen buchhalterischen Mittel Buchung undStornierung.

2.2.8 Parallelisierungstool – Parallelisierung von Prozess-schritten

Das Parallelisierungstool gehört zu den grundlegenden Diensten des SAPBank Analyzer und erlaubt die parallele Verarbeitung von Prozessschrittenauf einem logischen SAP-System, das aus mehreren Servern besteht. Esstellt damit eine Grundvoraussetzung dar, um die Skalierbarkeit innerhalbeines Prozesses sicherzustellen.


Mit der aktuellen Technologie- und Integrationsplattform SAP NetWeaver(siehe Abschnitt 1.3) ist es möglich, Hundertausende von Endanwenderngleichzeitig und performant mit Anwendungen zu versorgen. Die mit gro-ßem technologischen Aufwand betriebene automatische Verteilung vonAnwender- und Hintergrundprozessen auf die zur Verfügung stehendeHardware sorgt stets für eine optimale Auslastung des Systems. Doch fürden SAP Bank Analyzer als typisches Back-Office-System ist dies nicht ge-nug. Hier geht es häufig nicht um die Verteilung von Prozessen auf ver-schiedene Rechner, sondern um die Verteilung der Rechenkapazität inner-halb eines Prozesses, d.h. der darin ablaufenden einzelnen Prozessschritte,das so genannte Multithreading über mehrere Rechner. Zu diesem Zweckunterstützt der SAP Bank Analyzer ein spezielles Parallelisierungskonzept,das die Last der Verarbeitung auf der Ebene einzelner Prozessschritte op-timal unter den vorhandenen Servern aufteilt und gleichzeitig die am Sys-tem arbeitenden Anwender nicht behindert.


Das Parallelisierungstool hat folgende Aufgaben:

� Komfortables FrameworkBietet dem Entwickler ein komfortables Framework, um Prozessschrittezu parallelisieren

� Standarisiertes CustomizingBietet dem Kunden ein standisiertes Customizing, unabhängig von demzu kontrollierenden parallelen Prozess

� SkalierbarkeitKomplexe Prozesse können mit Hilfe des Parallelisierungstools nahezulinear skaliert werden und bewältigen auf diese Weise sehr viele Daten-sätze in einer vorgegebenen Zeit.

Realisiert wird die parallele Ausführung von Prozessschritten über das Pa-rallelisierungstool, welches ursprünglich für die Komponente SAP AccountManagement entwickelt wurde und sich dort zur Bewältigung von Tages-abschlussarbeiten auf mitunter mehreren 100 Millionen Konten bewährthat.

Architektur desParallelisierungs-

tools

Die Architektur des Parallelisierungstools lässt sich in mehrere Bereicheaufteilen. Einerseits ermöglicht ein Satz von Customizingtransaktionen dasFeintuning der Parallelisierung von Prozessschritten durch den Administ-rator. Andererseits unterstützt ein Framework zur Laufzeit die Phase zurVorbereitung, die Phase der eigentlichen parallelen Ausführung der Pro-zessschritte und die Phase zur Nachbereitung.

Abbildung 2.24 Die Architektur des Parallelisierungstools im Überblick

Release Tool Runtime Framework

Release Tool Customizing Transactions

RuntimePreparation

(in one sequential

process step)

Runtime Parallel

Execution (in many parallel process

steps)

Runtime Postprocessing

(in one sequential

process step)


Innerhalb dieser drei Laufzeitphasen steht jeweils eine Reihe von Ereignis-sen zur Verfügung, an die sich der Prozessschritt bei Bedarf aufrufen lassenkann, beispielsweise zum Schnüren der in einem parallelisierten Prozess-schritt zu verarbeitenden Arbeitspakete, zur Nachselektion von Anwen-dungsdaten, zum Einsammeln der Erfolgs- und Fehlermeldungen, zumWiederaufsetzen bei temporär gesperrten Objekten etc. Die Arbeitspaketewerden dabei üblicherweise auf der Ebene betriebswirtschaftlich sinnvol-ler Unterteilungen vorgenommen. Beispielsweise verarbeitet der ProzessStichtagsbewertung in der IAS-Lösung üblicherweise mehrere Millionen Fi-nanzbestände, die sich mit Hilfe des Parallelisierungstools in »Häppchen«von z.B. je 1000 Stück auf zehn Server verteilen lassen, sodass die Bewer-tung von jeweils zehn Finanzbeständen parallel und damit sehr performantausgeführt werden kann.

Verwendung Das Parallelisierungstool wird von den weiterverarbeitenden Komponen-ten des SAP Bank Analyzer genutzt. Das Hedge Management beispiels-weise verwendet das Parallelisierungstool zu Beschleunigung der Cash-flow-Hedge-Analyse, bei der über eine in der Regel sehr große Anzahl vonFinanzbeständen passende Kombinationen herausgesucht werden, derenWertschwankungen sich gegenseitig aufheben.

Das Parallelisierungstool kann auf folgende Arten verwendet werden:

� Verwendung im Hedge ManagementDie Ermittlung von möglichen Geschäftskombinationen für die Bildungvon Cashflow Hedges wird im Hedge Management mit Hilfe des Paral-lelisierungstools vorgenommen.

� Verwendung in der IAS-LösungDie Stichtagsbewertung bewertet u.U. Millionen von Finanzbeständenin der IAS-Lösung über parallele Teilprozesse, die mit Hilfe des Paralle-lisierungstools gesteuert werden.

� Verwendung in der Basel II-LösungDie Ermittlung von Emittenten- oder Geschäftspartnerrisiken von u.U.Millionen von Finanzgeschäften geschieht in der Basel II-Lösung paral-lelisiert mit Hilfe des Parallelisierungstools.

In der IAS-Lösung kommt die Parallelisierung von Prozessschritten in je-dem der Hauptprozesse Geschäftsvorfälle buchen, Stichtagsbewertung undBilanzpositionsaufbereitung zum Einsatz. Die Basel II-Lösung verwendetdas Parallelisierungstool zur Beschleunigung der Emmitenten- und Kon-trahentenrisikoermittlung.


2.2.9 Quellsystem-ID – Mandantentrennung für Core- und Reportingsystem

Die Quellsystem-ID gehört zu den grundlegenden Konzepten des SAPBank Analyzer und erlaubt die informationstechnische Unterscheidungvon Ergebnisdatensätzen aus unterschiedlichen SAP Bank Analyzer-Core-Systemen in einem Reporting-BW sowie von Daten im Tool-BW, die zuverschiedenen Bank Analyzer-Mandanten gehören. Es stellt damit eineGrundvoraussetzung dar, um vorhandene SAP-Business-Information-Warehouse-Systemlandschaften weiterverwenden zu können und dabeidie Anforderung der Mehrmandantenfähigkeit der Anwendung zu erfül-len.


Während die Anwendungsdaten im SAP Bank Analyzer-Core-System übereine Mandantentrennung verfügen, d.h. in Abhängigkeit vom Login nurmit den Anwendungsdaten des entsprechenden Mandanten gearbeitetwerden kann, ist dies im Tool-BW wie auch im Reporting-BW zunächstnicht der Fall. Die dorthin replizierten bzw. extrahierten Daten werden inDatenbanktabellen gespeichert, die über keine Mandantentrennung mehrverfügen. Demzufolge ist eine Auswertung über alle Daten möglich, egalin welchem Mandanten man eingeloggt ist. Durch die Verwendung derQuellsystem-ID zur Trennung von Daten, die zu verschiedenen Bank Ana-lyzer-Mandanten gehören, ist die Anforderung der Mehrmandantenfähig-keit (d.h. die Möglichkeit zur Trennung aller Anwendungsdaten) auch beiVerwendung der BW-Funktionen erfüllt.

Die Aufgaben der Quellsystem-ID umfassen:

� Standard-BW-FunktionalitätDas Merkmal 0SOURCESYSTEM ist ein Standard-BW-Feld, dass beijeder Kennzahl und jedem Merkmal angeklammert werden kann. Eskann jeder Struktur und Datenbanktabelle als Feld beigefügt werden.

� Bewahren der Mandanteninformation im BW Bewahren der Mandanteninformation, die der SAP Bank Analyzer imCore-System mit den Daten extrahiert.

� Drill-down zum Core-SystemDie Quellsystem-ID ist eine Voraussetzung für die Drill-down-Funktio-nalität vom Reporting-BW zurück zum SAP Bank Analyzer-Core-Sys-tem.

Um die Mandanteninformation aus dem SAP Bank Analyzer-Core-Systemim Tool-BW und Reporting-BW ebenso wie die Drill-down-Funktionalitä-ten aus dem Reporting-BW zurück auf die zugrunde liegenden Daten im


SAP Bank Analyzer-Core-System nicht zu verlieren, sollten alle zugehöri-gen Daten und Metadaten das Contentmerkmal Quellsystem-ID (techni-scher Name 0SOURSYSTEM) enthalten bzw. sie müssen im Falle von In-foObjects an die Quellsystem-ID geklammert sein. Überall dort, woMetadaten aus dem BA-Core heraus angelegt werden (z.B. InfoObjectsund ODS-Tabellen), wird automatisch das Merkmal für die Quellsystem-IDmit aufgenommen/geklammert.

Manuelle Berück-sichtigung der Quellsystem-ID

Wenn kundeneigene Merkmale (InfoObjects) im Tool-BW angelegt wer-den, sollte entschieden werden, ob die Stammdaten des Merkmals man-dantenabhängig oder mandantenübergreifend gültig sein sollen. Bei man-dantenabhängiger Gültigkeit (dies ist der Normalfall für Stammdaten)muss eine Klammerung angelegt werden, indem beim Anlegen/Änderndes InfoObjects im Reiter Klammerung das Kennzeichen Stammdaten lokalzum Quellsystem gesetzt wird. Für andere Objekte geschieht die Aufnahmedes Merkmals Quellsystem-ID genauso wie die Aufnahme jedes anderenInfoObjects.

Objekte wie ODS-Objekte, die ein an die Quellsystem-ID geklammertesInfoObject enthalten, können nur aktiviert werden, wenn sie das Merkmalfür die Quellsystem-ID (0SOURSYSTEM) enthalten. In ODS-Objekten, diezur Indexfortschreibung verwendet werden (siehe Viewcluster /BA1/VC_TF3_CMP), ist für dieses Szenario vorgeschrieben, dass das InfoObject0SOURSYSTEM als erstes oder zweites InfoObject im Schlüssel vorhandenist.

Verwendung der Quellsystem-ID

Für die meisten Komponenten des SAP Bank Analyzer ist die Verwendungder Quellsystem-ID völlig transparent und nur in einigen wenigen Funk-tionalitäten der zentralen Datenablage muss die Verwendung explizit imCustomizing berücksichtigt werden. Diese Funktionalitäten befassen sichmit der Schnittstelle zum Tool-BW und unterstützen die Datentrennungauf mehrere Arten.

� MerkmaleBeim Anlegen/Ändern des InfoObjects im Tool-BW sollte im Kartei-reiter Klammerung das Flag »Master data local to source system«gesetzt sein, wenn die Stammdaten des Merkmals mandantenab-hängig gültig sein sollen.

� Andere Objekte (z.B. ODS-Objekte)Einbetten des Feldes 0SOURCESYSTEM in jede Struktur/Datenbank-tabelle


Die Quellsystem-ID kann folgendermaßen verwendet werden:

� Verwendung in den Übergreifenden KomponentenDer Index von Primärobjekten im Tool-BW beinhaltet die Quellsystem-ID, um die Daten der Primärobjekte unterschiedlicher Mandantenunterscheiden zu können.

� Verwendung in der IAS-LösungDer Extraktor für die Ergebnisdaten füllt die Quellsystem-ID, um dieInformationen für das Reporting-BW zu bewahren, welcher Mandantdie Daten extrahiert hat.

� Verwendung in der Basel II-LösungDer Extraktor für die Kalkulationsergebnisse aus der Result Databasefüllt die Quellsystem-ID, um die Mandanteninformation jedes Daten-satzes im Reporting-BW zu bewahren.

Eine automatische Klammerung von generierten InfoObjects an0SOURSYSTEM erfolgt bei der Initialkonfiguration des Tool-BWs. Die Be-füllung des Merkmals 0SOURSYSTEM bei der Übertragung von Datensät-zen einer Datenbanktabelle erfolgt beispielsweise für die zentrale Daten-ablage im Rahmen der Indexfunktion, die über Tabellen im Tool-BWabgebildet ist. Die IAS- und die Basel II-Solution füllen jeweils das Merkmalbei der Extraktion von Ergebnisdatensätzen in das Reporting-BW. Das Le-sen von Daten kann somit sowohl im SAP Bank Analyzer-Core-System alsauch im Tool-BW und Reporting-BW per Selektionsbedingung so einge-schränkt werden, dass nur Daten zu einem bestimmten Mandanten – alsozu einer bestimmten Quellsystem-ID – berücksichtigt werden. Zudemkann auch der Zugang zu den Daten durch eine entsprechende Berechti-gungsvergabe auf bestimmte Quellsystem-IDs eingeschränkt werden. DieZuordnung eines Bank Analyzer-Mandanten zu einer bestimmten Quell-system-ID muss sowohl im Bank Analyzer-Core (in der Definition der Sys-temlandschaft) als auch im BW (beim Anlegen des Quellsystems) vorge-nommen werden. Es muss darauf geachtet werden, dass diese beidenEinstellungen konsistent zueinander sind. Es ist im BW möglich, mehrerenphysischen Quellsystemen die gleiche Quellsystem-ID zuzuweisen. Dieskann ausgenutzt werden, wenn Daten aus verschiedenen externen Quel-len für den gleichen Bank Analyzer-Mandanten gültig sein sollen, z.B. ope-rative Systeme zur Verwaltung von Organisations- und Produktinforma-tionen, die im Bank Analyzer jeweils als Merkmalstammdaten abgebildetwerden.


2.2.10 Application Log – Meldungenaufnahme, -speicherung und -anzeige

Das Application Log gehört zu den grundlegenden Diensten aus dem SAPWeb Application Server, die in besonderem Maße im SAP Bank Analyzerverwendet werden und erlaubt die Aufzeichnung von Meldungen. Es stelltdamit eine Grundvoraussetzung dar, um die zumeist komplexen und langelaufenden Prozesse im Nachhinein zu analysieren.


Das Application Log gehört zu den Basisdiensten des SAP Web ApplicationServer, die der SAP Bank Analyzer aufgrund seiner Auslegung als Back-Of-fice-System, d.h. mit lange laufenden, komplexen Prozessen und ver-gleichsweise wenigen Dialoganwendungen, extensiv verwendet. Es dientzur einheitlichen Aufnahme, Persistierung und Anzeige von Meldungspro-tokollen. Klassifiziert werden die Meldungen in so genannte Nachrichten-typen, deren mögliche Ausprägungen die Meldung als Status, Information,Warnung, Fehler oder Abbruch kategorisieren.

Zu den Aufgaben des Application Log gehört:

� Speichern von NachrichtenprotokollenSpeichern von Nachrichtenprotokollen, deren Meldungen aus Informa-tionen, Warnungen, Fehlern, Statusmeldungen und Texten bestehen

� KategorisierungKategorisieren der Meldungen, die eine unterschiedliche Wichtigkeitbesitzen können, z.B. »sehr wichtig, »wichtig«, »mittel« und »Zusatz-information«

� KlassifizierungKlassifizieren der Meldungen, die entweder technisch oder betriebs-wirtschaftliche Relevanz besitzen können (nur IAS-Lösung)

� SchnittstellenAnbieten von Schnittstellen, um nach Nachrichtenprotokollen suchenzu können, Nachrichtenprotokolle zusammenzuführen etc.

Weiterhin wird jede Meldung mit einer Einordnung ihrer Wichtigkeit ver-sehen, die die vier Stufen »Sehr wichtig«, »Wichtig«, »Mittel« und »Zu-satzinformation« enthält. Speziell die IAS-Lösung kategorisiert ihre Mel-dungen darüber hinaus durch die Eigenschaft »Technisch« oder»Betriebswirtschaftlich«. Eine kurze Beschreibung enthält den Text derMeldung in derjenigen Sprache, in deren Kontext der Prozess gestartetwurde. Selbstverständlich können die Meldungen beim Anzeigen des Ap-plication Logs auch in einer anderen Sprache angezeigt werden.


Architektur desApplication Logs

Die Architektur des Application Logs lässt sich in mehrere Bereiche auf-teilen. Einerseits unterstützt ein Framework zur Laufzeit die Applikationenbeim Einsammeln der Meldungen in Protokolle sowie beim Speichern, La-den, Löschen, Abmischen und bei sonstigen Aufgaben zur Protokollver-waltung. Andererseits existiert eine Endanwenderapplikation für die Suchevon Protokollen sowie die Analyse der darin vorhandenen Meldungen.

Abbildung 2.25 Die Architektur des Application Logs im Überblick

Innerhalb des Frameworks stehen eine ganze Reihe von Funktionen zurVerfügung, die ein Prozess bei Bedarf aufrufen kann, beispielsweise zumHinzufügen einer Meldung zu einem Protokoll, zum Speichern eines Pro-tokolls in der Datenbank gegen Ende eines Prozesses, zum Abmischen ei-nes Protokolls aus den Protokollen mehrerer parallel ausgeführter Prozess-schritte etc.

Verwendung Das Application Log wird von allen Prozessen des SAP Bank Analyzer um-fassend genutzt. Die übergreifenden Komponenten verwenden das Appli-cation Log beispielsweise zur Protokollierung von fehlerhaft eingegebenenoder maschinell angelieferten Daten, wobei der Anwender im ersten Falldirekt eine Liste mit den gefundenen Fehlern angezeigt bekommt.

Auf folgende Arten kann das Application Log verwendet werden:

� Verwendung in den Übergreifenden KomponentenVerwendung in allen Prozessen, z.B. Protokollierung von fehlerhaftmaschinell angelieferten Primärdaten, die nicht als Primärobjekt gespei-chert werden konnten.

Enduser Transactions for Analyzing

Protocol administration

Messageadministration

Protocol / MessageRecording

Application

Application Log Runtime Framework


� Verwendung in der IAS-LösungVerwendung in allen Prozessen, z.B. zur Protokollierung des Fehlers inder Stichtagsbewertung, weil keine Marktdaten gefunden werdenkonnten.

� Verwendung in der Basel II-Lösung Verwendung in allen Prozessen, z.B. die Protokollierung von nicht risi-kobewertbaren Finanzgeschäften aufgrund eines fehlenden internenBewertungsmodells.

In der IAS-Lösung kommt das Application Log ebenfalls bei allen Prozessenzum Einsatz und protokolliert beispielsweise die wegen fehlender Markt-daten nicht zu ihrem Barwert bewertbaren Finanzbestände. Die Basel II-Lösung verwendet das Application Log ebenfalls umfassend in allen Pro-zessen und erfasst mit seiner Hilfe beispielsweise die aufgrund von feh-lenden Modellparametern nicht risikobewertbaren Finanzgeschäfte.

Grundsätzlich wird im SAP Bank Analyzer die Standard-Benutzeroberflä-che des Application Logs (Transaktion SLG1) zur Analyse der Protokolleverwendet. Die IAS-Lösung stellt darüber hinaus eine eigene Benutzer-oberfläche zur Verfügung (Transaktion /BA1/B0_LOG_DISPLAY), die dieSortierung und Filterung von Meldungen nach betriebswirtschaftlich re-levanten Entitäten – also Merkmalen – ermöglicht, beispielsweise die An-zeige aller Meldungen zu einem bestimmten Depot, einer Haltekategorieoder einer ISIN. Die zu Sortierungs- und Filterzwecken zur Verfügung ste-henden Merkmale werden im Customizing aus den verfügbaren Merkma-len zusammengestellt.

2.2.11 BAdIs – Funktionale Erweiterungen von Algorithmen

BAdIs gehören zu den grundlegenden Programmierschnittstellen des SAPBank Analyzer und erlauben die Erweiterung von SAP-eigenen Prozessendurch einen kundenspezifischen Programmcode, der in ABAP Objects ver-fasst ist und im gleichen System abgelegt wird wie der SAP Bank Analyzer-eigene Programmcode. Diese Erweiterung gilt aus SAP-Sicht nicht als Mo-difikation des Systems und beinflusst somit nicht die Wartungszusagen derSAP.


Business Add-Ins, kurz BAdIs, stellen die SAP-Standardtechnologie fürfunktionale Erweiterungen an vordefinierten Stellen dar. Für die Erstellungvon BAdIs sind Kenntnisse in der objektorientierten ProgrammierspracheABAP Objects erforderlich. Der BAdI-Bereitsteller (bei SAP-Komponentendie SAP selbst) definiert dazu eine Schnittstelle, die von den BAdI-Ver-


wendern (SAP, Entwicklungspartner und Kunden) durch Methoden einerglobalen Klasse implementiert werden können. BAdIs werden im BankAnalyzer breit genutzt, um unterschiedliche Zielsetzungen zu verfolgen.

BAdIs definieren Stellen im Programmcode, an denen der Kunde die Mög-lichkeit zur Einbringung eigener Erweiterungen hat, ohne den vorhande-nen ABAP-Code modifizieren zu müssen. Hier ist das BAdI der Ersatz fürden klassischen User-Exit. SAP-intern werden BAdIs häufig zur Entkoppe-lung verschiedener Module untereinander verwendet; typisch ist der Fall,dass ein Prozess einen Dienst in spezieller Weise verwenden möchte undzu diesem Zweck einen Teil der dort vorhandenen Funktionalität per BAdIersetzt. Der Dienst kann auf diese Weise die speziellen Anforderungenerfüllen, ohne den Code in seine Standardverarbeitung zu übernehmen.Außerdem kann SAP über BAdI-Schnittstellen den Code an den vorgese-henen Stellen schnell und flexibel erweitern, sei es wegen neuer Anforde-rungen der Kunden, wegen weiterentwickelter Standards oder sich än-dernder gesetzlicher Vorschriften.

Architektur desBAdI-Konzepts

Im SAP Bank Analyzer werden einerseits die BAdI-Interfaces definiert. An-dererseits werden auch schon BAdI-Implementierungen als Teil der Funk-tionalität ausgeliefert. Die verschiedenen Zielsetzungen schließen sich ge-genseitig nicht aus. Ein und dasselbe BAdI kann sowohl zu Zwecken derKundenerweiterung als auch intern aus Flexibilitätsgründen verwendetwerden. Die integrierte ABAP-Entwicklungsumgebung Object Navigatorunterstützt den Kunden bei der Implementierung von BAdIs durch spezi-elle Wizards.

Aufgaben von BAdIs

� ErweiterbarkeitKunden können Prozesse an definierten Stellen um eigenen ABAP-Programmcode erweitern, ohne existierenden ABAP-Programmcodeder SAP ändern zu müssen.

� EntkopplungDie Entkopplung von Diensten ist sichergestellt, selbst wenn ein Pro-zess den Dienst um spezifische Funktionalitäten erweitern möchte,die nicht als Standard-Funktionalität in den Dienst übernommenwerden soll.

� FlexibilitätSAP wie auch der Kunde selbst kann schnell auf neue betriebswirt-schaftliche Anforderungen, sich entwickelnde Standards oder gesetz-liche Vorgaben reagieren.


Abbildung 2.26 Die Architektur des BAdI-Konzepts im Überblick

Das BAdI-Interface besteht aus einer globalen, objektorientierten Klasseund enthält alle Methoden und deren Übergabeparameter, die später vonden BAdI-Implementierungen realisiert werden müssen. In den Methodendes BAdI-Interface ist jeweils der Code für den Aufruf der entsprechendenMethode aus der BAdI-Implementierung. Vorgegeben ist ferner eine BAdI-Kategorie, die bestimmt, ob immer nur eine BAdI-Implementierung zu ei-nem Zeitpunkt aktiv sein darf und aufgerufen wird (1 Aufruf), ob mehrereBAdI-Implementierungen gleichzeitig aktiv sein dürfen und nacheinanderaufgerufen werden (n Aufrufe) oder ob zwar mehrere BAdI-Implementie-rungen gleichzeitig aktiv sein dürfen, sich aber anhand eines anzugeben-den Filterwertes unterscheiden müssen, sodass zur Laufzeit anhand desFilterwertes mit einem vom Prozess übergebenen Wert entschieden wird,ob und welche BAdI-Implementierungen aufgerufen werden.

Verwendung als Erweiterungs-schnittstelle für Kunden

BAdIs können durch den Kunden implementiert werden, d.h., der Kundekann an vordefinierten Stellen im SAP-Standard nicht vorhandene, abervon ihm benötigte Funktionalitäten ergänzen. Dabei ist zu beachten, dassdie Komplexität der BAdI-Schnittstellen gewisse Anforderungen an einesolche Kundenimplementierung stellt. Die Kundenimplementierungenkönnen dabei von SAP zur Verfügung gestellte Implementierungen erset-zen oder zusätzlich zu diesen verwendet werden. Beispiele für möglicheKundenerweiterungen sind in der IAS-Lösung die Bereitstellung eigenerBerechnungsschrittmethoden in der Buchhaltung oder die Ergänzung ei-gener Konsistenzprüfungen bei der manuellen Buchung.

e.g. XY=2

BADI-Definition(OO-Framework)

Single-BAdI Implementation 1



Multi-BAdI Implementation 1



Filter-BAdI Implementation XY=1



Single Multi Filter




Folgendermaßen können BAdIs als Schnittstelle für Kundenerweiterungenverwendet werden:


� Erweiterung der BAPI-Schnittstelle, über die kundenspezifische Spei-cheraufrufe zu Primärobjekten in der Financial Database implemen-tieren zu können.

� Implementierung eigener Bewertungsmodelle, die vom Preisrechnerzur Ermittlung von Fair Values und anderen Kennzahlen verwendetwird.

� Verwendung in der IAS-Lösung

� Implementierung kundenspezifischer Kalkulationsschrittmethoden,die währed der Aktualisierung interner Geschäftsvorfälle oder derStichtagsbewertung aufgerufen werden können.

� Erweiterung der Konsistenzprüfungen, die während der manuellenBuchung auf Finanzinstrumenten durchgeführt werden sollen.

� Verwendung in der Basel II-LösungErweiterung um kundenspezifische Methoden zur Kalkulation von Kre-ditrisiken in der Risikokalkulation.

Einen Sonderfall stellt die Verwendung von BAdIs im Rahmen der Nutzungvon BAPIs dar: Der Kunde kann kundeneigene Erweiterungen (Extensions)an BAPI-Schnittstellen importieren oder exportieren. Die Verarbeitungdieser kundeneigenen Erweiterungen erfolgt dann innerhalb von BAdIs,die der Kunde zu implementieren hat, da nur er wissen kann, was mit sei-nen kundeneigenen Daten geschehen soll. Ein Beispiel wäre die Verwen-dung von kundeneigenen Servicebausteinen an FDB-Primärobjekten. DieDaten zu diesen Servicebausteinen müssen auch beim Anlegen und Aus-lesen der Primärobjektdaten über BAPIs mitbeachtet werden. Dazumüsste der Kunden in BAdI-Implementierungen die kundeneigenen Ser-vicebausteindaten entgegennehmen und persistieren (Anlegen) bzw. per-sistierte Daten auslesen und an der BAPI-Schnittstelle zur Verfügung stel-len.

Verwendung zurEntkoppelung

BAdIs werden zu Entkoppelungszwecken zwischen verschiedenen Prozes-sen und Komponenten des SAP Bank Analyzer verwendet. Dabei kann essich um die Entkoppelung zwischen betriebswirtschaftlichen Komponen-ten (z.B. zwischen Analyzern) oder auch zwischen einem Anwendungstoolund seinen Verwendern handeln.


Folgendermaßen können BAdIs zur Entkoppelung verwendet werden:

� Verwendung innerhalb der Übergreifenden KomponentenJeder Prozess, der die Sekundäre Datenquelle bzw. Moduleditor ver-wenden möchte, muss bestimmte, vom Tool definierte BAdIs imple-mentieren, um sich dem Tool bekannt zu machen.

� Verwendung innerhalb der IAS-LösungDie Entkopplung, z.B. zwischen Risikoträgerstruktur des Preisrechnersund den Finanzbeständen, wird durch ein BAdI geleistet. SAP definiertmit einer Standard-Implementation das Mapping zwischen FDB-Pro-dukten, Preisrechner und Finanzbestandsführung, die vom Kundendurch ein eigenes BAdI abgeändert werden kann.

� Verwendung innerhalb der Basel II-LösungDie Basel II-Lösung entkoppelt beispielsweise die Implementierung vonBerechnungsmethoden innerhalb der Historiendatenbank per BAdI.

Das folgende Beispiel zeigt die Entkoppelung zwischen betriebswirtschaft-lichen Komponenten. Die Servicefunktion zur Ermittlung von Fair Valuesund Amortized Costs aus der Risikobasis benötigt Eingangsdaten, die nichtalle direkt beim Aufruf der Servicefunktion mitgegeben werden könnenbzw. sollen. Die Servicefunktion soll unabhängig davon arbeiten können,wer der Lieferant dieser Eingangsdaten in einem bestimmten Einsatzsze-nario der Servicefunktion ist. Dazu definiert die Servicefunktion ein BAdImit einer oder mehreren Methoden, um die benötigten Inputdaten zu er-fragen. Bei Verwendung der Servicefunktion aus dem Balance Analyzerheraus wird dieses BAdI-Interface durch eine Klasse aus dem Balance Ana-lyzer implementiert, der die benötigten Daten aus dem Balance Analyzerermittelt. In einem anderen Einsatzszenario der gleichen Servicefunktionwäre es denkbar, die benötigten Inputdaten aus einem anderen Analyzeroder aus FDB-Daten bereitzustellen. Hierzu wäre eine andere BAdI-Im-plementierung notwendig. Hier ein Beispiel für die Entkoppelung zwischeneinem Anwendungstool und seinen Verwendern: Verwender des Modul-editors müssen bestimmte vom Tool definierte BAdIs implementieren, umsich dem Tool bekannt zu machen, z.B. für einen Verwendungsnachweiszu einem Modul. Die Wiederverwendung von Komponenten innerhalboder auch außerhalb des SAP Bank Analyzer wird dadurch erleichtert, dassdie Abhängigkeit auf eine Richtung beschränkt wird: Der BAdI-Implemen-tierer kennt den BAdI-Bereitsteller (Definition), aber nicht umgekehrt.

Verwendung zur Flexibilisierung

Außer zu Entkoppelungszwecken können BAdIs auch verwendet werden,um eine höhere Flexibilität in der Bereitstellung von SAP-eigener Funkti-onalität zu erreichen. Durch das Hinzufügen weiterer BAdI-Implementie-


rungen durch SAP selbst können zusätzliche Funktionen bereitgestelltwerden, ohne dass am BAdI-Verwender dazu eine Änderung notwendigist. Durch die Filterfunktion kann ausgesteuert werden, wann welcheBAdI-Implementierung zum Zuge kommt. Die Filtergrößen können z.B.Einstellungen aus dem Customizing sein, sodass der Kunde im Customi-zing letztendlich beeinflussen kann, wann welche BAdI-Implementierungausgeführt wird. Im SAP Bank Analyzer finden sich dazu eine ganze Reihevon Beispielen.

Zur Flexibilisierung können BAdIs in den folgenden Varianten verwendetwerden:

� Flexibilisierung des PreisrechnersHinzufügen eines neuen Bewertungsmodells innerhalb des Preisrech-ners der Übergreifenden Methoden per BAdI, z.B. für die Bewertungvon Darlehen mit Bermuda-styled Options.

� Flexibilisierung der BuchungslogikHinzufügen einer neuen Berechnungsmethode für Kennzahlen inner-halb der Buchhaltung der IAS-Lösung per BAdI.

Der Preisrechner aus den Übergreifenden Methoden enthält eine BAdI-Implementierung für jedes bereitgestellte Bewertungsmodell. Bermuda-styled Options werden bislang vom Preisrechner jedoch nicht unterstützt.Soll ein neues Bewertungsmodell zur Bewertung von Bermuda-styled Op-tions zur Verfügung gestellt werden, so kann ein weiteres BAdI implemen-tiert und aktiviert werden. In der IAS-Lösung kann auf analoge Weise eineneue Berechnungsmethode für Kennzahlen eingeführt werden, die wäh-rend der Buchung von Geschäftsvorfällen zur Erzeugung der Buchhal-tungsbelegzeilen einbezogen werden.

Eine vollständige Übersicht über die BAdI-Klassen im SAP Bank Analyzerfinden Sie in Abschnitt 6.2.

2.2.12 BAPIs – Plattformunabhängige Programmierschnitt-stellen

BAPIs gehören zu den grundlegenden Programmierschnittstellen des SAPBank Analyzer und ermöglichen den Aufruf betriebswirtschaftlicher Funk-tionalitäten auch aus Nicht-SAP-Systemen heraus. Eine Integration vonFremdsoftware und dem SAP Bank Analyzer ist über diese Schnittstellenrealisierbar.



BAPI-Funktionen (Business Application Programming Interface) bilden dieBausteine für die Kommunikation auf hohem und damit anwendungs-freundlichem Niveau. Technisch gesehen handelt es sich um den lokalenoder entfernten Aufruf von in ABAP Objects programmierten Funktions-bausteinen über das SAP-eigene RFC-Protokoll (Remote Function Call).Die Intention der BAPI-Funktionen ist jedoch die Verarbeitung eines be-triebswirtschaftlichen Geschäftsvorganges, der unter Umständen hun-derte interner Aufrufe nach sich zieht. Derartige Funktionsbausteine müs-sen deshalb spezielle Anforderungen bezüglich der Dokumentation,Schnittstellenbeschreibung und Gültigkeit über mehrere Releases einerSoftware erfüllen und werden gesondert im Business Object Repository(BOR) registriert und verwaltet. Es gibt inzwischen tausende von BAPI-Funktionen für die verschiedensten R/3- und mySAP-Produkte, und sie be-sitzen in der Praxis für die Kommunikation mit SAP-Systemen eine enormeWichtigkeit. BAPIs werden organisatorisch in so genannten Business Ob-jects strukturiert und über die Transaktion SWO1 gepflegt.

BAPIs haben die folgenden Aufgaben:

� High-Level-ProgrammierschnittstelleBAPIs stellen eine betriebswirtschaftliche orientierte High-Level Pro-grammierschnittstelle zu allen SAP Komponenten zur Verfügung.

� Integration von externen SoftwareproduktenBAPIs lieferen ein stabile und dokumentierte Schnittstelle für andereSoftwareprodukte und können von fremden Betriebssystemen und Pro-grammierumgebungen aus aufgerufen werden.

� Grundlage der SAP Enterprise Service ArchitectureBAPIs liefern den Beweis, dass SAP ein Lieferant offener Business Ser-vices für seine Kunden ist.

Wie der Name bereits suggeriert, werden Business Objects ähnlich den ob-jektorientierten Klassen verwaltet, d.h., es gibt Objekte wie Geschäfts-partner, Auftrag oder Mitarbeiter, zu denen es jeweils eine oder mehrereMethoden (die BAPIs) gibt – wie z.B. »Geschäftspartner anlegen«, »Ge-schäftspartner löschen« etc. Ab SAP NetWeaver-Release 6.20 wurde dieMöglichkeit hinzugefügt, dass ein BAPI auch eine echte ABAP-Objects-Methode einer globalen Klasse sein kann. Beim Aufruf wird dann automa-tisch ein Objekt der Klasse instanziiert und erst dann die eigentliche Me-thode ausgeführt. Der Aufrufer merkt von den zusätzlichen Aktionennichts.


Architektur desBAPI-Konzepts

Die Architektur des BAPI-Konzepts lässt sich in mehrere Bereiche auftei-len. Auf der Serverseite ist der Remote Function Call Layer relevant, der dasgleichnamige Protokoll zur Verfügung stellt und im Kernel des SAP WebApplication Server implementiert ist. Die Kommunikation zu den Clientserfolgt beim RFC-Protokoll aufbauend auf dem TCP/IP-Protokoll. Für dieKommunikation über das standardisierte WebServices-Protokoll wird derKern der SAP Exchange Infrastructure – die Integration Engine – verwen-det, die ebenfalls mit jedem SAP Web Application Server ausgeliefert wird.Sie nimmt die über den SAP-eigenen Webserver Internet CommunicationManager eintreffenden Daten im WebService-Format in Empfang, wan-delt sie in lokale Aufrufe der BAPI-Funktion um und führt sie aus. Funkti-onsergebnisse werden auf dem entgegengesetzten Weg zurücktranspor-tiert. Die Kommunikation mit den Clients geschieht für gewöhnlich überdas HTTP-Protokoll, jedoch können theoretisch auch alle anderen vomWebserver unterstützten Protokolle verwendet werden.

Abbildung 2.27 Architektur des BAPI-Konzepts im Überblick

Auf der Clientseite stehen entweder ein anderes SAP-System, die von SAPfür diverse Betriebssystem- und Programmierplattformen entwickeltenFunktionsbibliotheken (Connectors), integriert in eine selbstentwickelteAnwendung, oder aber ein standardisierter WebServices-Client zur Kom-munikation mit dem Server zur Verfügung, die den Weitertransport vonund zur eigentlichen Anwendung erleichtern.

Verwendung Der SAP Bank Analyzer verfügt über eine ganze Reihe von BAPIs, die meistin der Financial Database angesiedelt sind, um unterschiedliche Finanzda-

BOR

Bor: Business Object Repository BAPIs are used for:

mySAP Components Comm.

Internet/Intranet

Business Workflow

External Programs

Development by Customer or Partner

BOR

BAPI

BAPIBO

BAPI

BAPIBO

BAPI

BAPIBO

BAPI

BO

contains

BO: Business Object

e.g. Customer order

BO

has method

BAPI: Business Application

e.g. Create_Order

BAPI

131Customizing und Administration

ten aus den Vorsystemen anliefern zu können. Sie lassen sich fachlich ineinzelne Businessobjekte untergliedern, die jeweils über eine Reihe vonBAPIs verfügen.

Andere BAPIs betreffen das Adressrisiko und die Historiendatenbank in derBasel II-Lösung sowie den Profit Analyzer. Eine vollständige Übersicht überdie BAPI-Methoden im SAP Bank Analyzer finden Sie in Abschnitt 6.2.

2.3 Customizing und Administration

Die Einstellung von SAP-Software gehört zu den Grundvoraussetzungen zuderen Nutzung und geschieht im Rahmen der Anpassung an die konkretentechnischen und betriebswirtschaftlichen Anforderungen des Kunden. DieVerwaltung (also Administration) von SAP-Software findet zumeist im lau-

Verwendung in den Übergreifenden KomponentenObjekttyp Beschreibung/BA1/B100 Finanzgeschäft Bank Analyzer/BA1/B101 Finanzinstrument Bank Analyzer/BA1/B102 Bestandsdaten BankAnalyzer/BA1/B104 Konto Bank Analyzer/BA1/B106 Merkmalsservices/BA1/B107 SAP GP-FS im Rahmen des BankAnalyzers/BA1/B108 Steuerung des Korrekturservers/BA1/B112 Geschäftsvorfall Bank Analyzer/BA1/B113 Land Bank Analyzer/BA1/B114 Hedge-Beziehung Bank Analyzer /BA1/B118 Physischer Vermögenswert/BA1/B121 Marktdaten: Wertpapierkurse/BA1/B122 Marktdaten: Währungskurse/BA1/B123 Marktdaten: Zinsen/BA1/B124 Marktdaten: Volatilitäten/BA1/B126 Internes Modell/BA1/B127 HDB Layer/BA1/B128 GenericMarketData/BA1/FK CorrectionWorkbench Bank Analyzer

Verwendung in der Basel II-LösungObjekttyp Beschreibung/BA1/B126 Internes Modell/BA1/B127 HDB Layer


fenden Betrieb statt und soll die reibungslose Funktion über den komplet-ten Betriebszeitraum sicherstellen.

Grundlagen zurEinstellung undzur Verwaltung

von SAP-Systemen

SAP unterscheidet traditionell zwischen Customizing und Administration.Unter Customizing wird dabei die – meistens einmalig bei der Software-einführung oder -erweiterung durchgeführte – Einstellung der Software-produkte und der darauf ablaufenden Lösungen auf die konkreten tech-nischen und betriebswirtschaftlichen Anforderungen des Kundenverstanden. Gerade bei neueren Lösungen erfolgt erst hier die Generie-rung eines Großteils des Datenmodells, das somit komplett auf die Be-dürfnisse des Kunden zugeschnitten wird. Das Customizing wird daher be-grifflich weiter unterteilt in die Begriffe Struktur-Customizing auf der einenSeite und Prozess-Customizing auf der anderen Seite (siehe Abschnitt2.2.3). Das Customizing wird in der Regel mit Hilfe eines der zahlreichenlokalen oder globalen SAP-Partner durchgeführt, da Kunden aus Kosten-gründen das Customizing-Know-how für einen optimalen Zuschnitt derSoftware auf ihre Geschäftsprozesse nur selten permanent vorhalten.

Abbildung 2.28 Unterteilung von Customizing und Administration

Die Administration bezieht sich auf die im laufenden Betrieb bei Bedarfbzw. regelmäßig durchzuführenden Verwaltungsaufgaben wie Wartungs-und Pflegemaßnahmen und werden in der Regel vom Kunden selbst oderaber einem der zahlreichen Service- oder Outsourcingpartner der SAPübernommen. Typische Aufgaben sind hier die Pflege von Benutzern undRollen, die Überwachung der Systemleistung und die Optimierung derAuslastung sowie die regelmäßige Systemsicherung durch Backups und Ar-

Customizing Administration

Structure Customizing(Configuration)

Process Customizing

Component 1 Component n...

Component 1 ... Component n

Component 1 Component n...

133Customizing und Administration

chivierung. Beiden Tätigkeiten vorgeschaltet ist die Installation, die auf un-terschiedlichen Betriebssystem- und Hardwareplattformen durchgeführtwerden kann und bei größeren Einführungen bzw. Erweiterungen mit Hilfedes Werkzeugs SAP Solution Manager geplant und begleitet wird, dernicht im Rahmen dieses Kapitels erläutert wird.

CustomizingDie Customizingoberfläche ist – bei entsprechender Berechtigung – überdie Transaktion SPRO erreichbar.

Dort kann man eines der Customizingprojekte auswählen, die bei umfang-reicheren Einführungsprojekten zur Verteilung der Aufgaben angelegtwerden können.

Abbildung 2.29 Customizing Execute Project

Alternativ wählt man den Button SAP Reference IMG, worauf alle Einstel-lungsmöglichkeiten komplett angezeigt werden. Je nachdem, welche Lö-sungen zusätzlich zum SAP Web Application Server installiert sind, enthältdas erscheinende Menü einen unterschiedlichen Aufbau, über den die ein-zelnen Customizingpunkte ausgewählt, die Dokumentation studiert undnatürlich Einstellungen angezeigt bzw. geändert werden können.


Abbildung 2.30 Customizingmenü des SAP Bank Analyzer

Die SAP-Software ist bekannt für ihre Anpassungsfähigkeit, und entspre-chend umfangreich sind die gebotenen Einstellungsmöglichkeiten. GanzeBücher beschäftigen sich mit der optimalen Anpassung einer Installationan die konkreten Kundenbedürfnisse – pro SAP-Lösung versteht sich.Nicht weniger Materialien stehen für Administratoren zur Verfügung.

Administration Zur Administration werden zahlreiche Dienste und Werkzeuge benötigt,die im gleichnamigen Menübereich des Endanwendermenüs SAP Easy Ac-cess zu finden sind. Dort kann man eines der zahlreichen Administrations-werkzeuge auswählen und die entsprechenden Überwachungs-, Verwal-tungs- und Wartungsarbeiten durchführen.

Der Aufbau des Menübereichs Administration ist im Gegensatz zum Cus-tomizingmenübaum unabhängig von den installierten Softwarekompo-nenten und stets gleich. Normalerweise ist die Ausführung der Administ-rationsanwendungen mittels entsprechender Rechtevergabe stark einge-schränkt auf die Administratoren selbst oder aber für Endanwender aus derFachabteilung ganz aus dem Anwendungsmenü herausgenommen.

135Lösungen auf der Grundlage des SAP Bank Analyzer

Abbildung 2.31 Administrationsmenübereich des SAP Bank Analyzer

Ziel der Custo-mizing- und Administrations-abschnitte in diesem Buch

Die Customizing- und Administrationsabschnitte in diesem Buch stellenkeine Alternative zur SAP-Dokumentation dar. Stattdessen enthalten sieeine Beschreibung ausgewählter Customizing- und Administrationsberei-che, die für das Verständnis des SAP Bank Analyzer und der darauf auf-bauenden Anwendungen und Lösungen wichtig sind.

2.4 Lösungen auf der Grundlage des SAP Bank Analyzer

Aufbauend auf der Gesamtbankinfrastruktur des SAP Bank Analyzer hatSAP eine Reihe von Lösungen realisiert, die aktuelle Anforderungen desMarktes und der Gesetzgebung abdecken und breiter aufgestellt sind alseinzelne Anwendungen.

Die vom SAP Bank Analyzer zur Verfügung gestellte Gesamtbankinfra-struktur lässt sich durch Customizing flexibel auf die Erfüllung vielfältigergesetzlicher Anforderungen hin anpassen. SAP selbst und seine Entwick-lungspartner treten den Beweis dazu an, indem sie zwei umfangreiche Lö-sungen zu hochaktuellen Themen anbieten, die sich aus mehreren Anwen-dungen zusammensetzen.


2.4.1 IAS-Lösung

Die International Accounting Standards (IAS) wurden vom gleichnamigenCommitee IASC zur weltweiten Vereinheitlichung und Vergleichbarkeitvon Bilanzen entwickelt und veröffentlicht. Vertreter aus vielen Nationensetzen sich für die Einführung dieses Standards in ihrem Heimatland ein.Seit dem Jahr 2001 gilt in der EU ein Gesetz, nach dem alle börsennotiertenUnternehmen dort ab dem Jahr 2005 ihren Konzernabschluss auf derGrundlage der International Accounting Standards (IAS) erstellen müssen.


Das International Accounting Standard Commitee (IASC, http://www.iasc.org.uk) setzt sich aus Vertretern vieler Nationen zusammen, dar-unter Australien, Kanada, Frankreich, Deutschland, Großbritannien, Ja-pan, USA, Neuseeland und die nordischen Länder. Ihr gemeinsames Ziel istdie Vereinheitlichung der Bilanzierungsregeln für Unternehmen unter demTitel International Accounting Standards (IAS). Seit März 1999 ist der Stan-dard verabschiedet und wird seitdem regelmäßig durch Anwendungshilfenund Ergänzungen (z.B. 2003/Q3 »Amendments to IAS 39 Financial Instru-ments: Recognition and Measurement«) erweitert.

IAS-Bilanzierungin absehbarer Zeit

Pflicht

Während in den meisten Ländern die Bilanzierung nach IAS vom Gesetz-geber (noch) nicht vorgeschrieben ist, hat die Europäische Kommissioneine Verordnung verabschiedet, nach der alle börsennotierten Unterneh-men in der EU ab dem Jahr 2005 ihren Konzernabschluss auf der Grund-lage des International Accounting Standards (IAS) erstellen müssen. Trotzgeltender Übergangs- und Fristverlängerungsregelungen, bei deren Aus-schöpfung die EU-Unternehmen bis einschließlich 2006 nur einge-schränkte IAS-Jahresabschlüsse vorlegen müssen, wollen viele Finanz-dienstleister – auch außerhalb der Reichweite der EU-Kommission aufanderen Kontinenten – aus Gründen der zu erwartenden positivenMarktresonanz bereits für das Jahr 2005 einen ersten vollständigen IAS-Jahresabschluss vorlegen.

Rechnungsle-gungsvorschriftenfür Finanzdienst-

leister

Die Rechnungslegung der Finanzdienstleister ist gegenüber anderen Bran-chen wesentlich stärker reguliert. Das erklärt sich aus ihrer besonderenvolkswirtschaftlichen Bedeutung. Dies wiederum erhöht den Druck imVergleich zu anderen Branchen bei der Umsetzung von IAS. Das Hauptzielder IAS ist die Vereinheitlichung von Konzernabschlüssen. Dazu werdendie notwendigen Berichtskomponenten und Bewertungsregeln harmoni-siert. Durch die Anwendung von standardisierten Vorschriften könnenAbschlüsse unterschiedlicher Unternehmen zwischen verschiedenen Län-dern miteinander verglichen werden. Grenzübergreifender Wertpapier-handel, Zusammenschlüsse und grenzüberschreitende Akquisitionen so-


wie Finanzierungsmaßnahmen sollen dadurch erleichtert werden. IASbesteht aus verschiedenen Standards. Für die Finanzdienstleister sindhauptsächlich die Standards IAS 32 und IAS 39 von besonderer Bedeutung.Diese beiden Standards beziehen sich auf die Bewertung von Finanzin-strumenten.

Abbildung 2.32 IAS-Historie und wichtige Meilensteine für Finanzdienstleister

IAS 39 behandelt die Bilanzierung und Bewertung von Finanzinstrumen-ten, die für die meisten Finanzdienstleister eine völlig neue Vorgehens-weise bei der Ermittlung ihres Finanzergebnisses bedeuten. IAS 32 ver-langt Darstellungs- und Offenlegungsvorschriften mit umfänglichenAnhangsangaben. Dazu müssen die Mitarbeiter das notwendige Wissenaufbauen, und auch auf die IT-Systeme kommen neue Anforderungen zu.Dies alles geschieht vor dem Hintergrund, dass die Finanzdienstleister ineinem zunehmend wettbewerbsintensiven Umfeld zu rigorosen Kosten-einsparungen gezwungen sind.

Betriebswirt-schaftlicher Hintergrund

Anders als die meisten neuen Standards erfordert die Umsetzung von IAS39 den Einsatz beträchtlicher interner und externer Ressourcen. Expertenaus den Bereichen Bilanzierung, Treasury, IT und Steuern müssen zusam-menarbeiten, um eine wirksame Umsetzung zu gewährleisten.

Starting phase 1973-1989IAS 1 – Disclosureof AccountingPoliciesIAS 2 – Presentationof Financial StatementsIAS 3 – ConsolidatedFinancial Statements...

Starting phase 1973-1989IAS 1 – Disclosure of AccountingPoliciesIAS 2 – Presentation of Financial StatementsIAS 3 – Consolidated Financial Statements...

Establishment phase 1989-1995IAS 30 – Disclosurein the finalcialStatements of banksIAS 31 – Financial Reporting of Interestsin Joint Ventures...

Establishment phase 1989-1995IAS 30 – Disclosure in the financialStatements of banksIAS 31 – Financial Reporting of Interestsin Joint Ventures...

Completion phase since 1995IAS 32 – Financial Instruments: Disclosureand PresentationIAS 39 – Financial Instruments: Recognitionand Measurement...

Completion phase since 1995IAS 32 – Financial Instruments: Disclosure and PresentationIAS 39 – Financial Instruments: Recognition and Measurement...

t


Insbesondere die folgenden Vorschriften bzw. Fragestellungen kommenauf die Unternehmen zu:

1. Das Hedge Accounting, also die Bilanzierung von Sicherungsgeschäften(d.h. die Abgrenzung von Gewinnen und Verlusten aus Sicherungsge-schäften), wird strengen Regelungen unterworfen. Insbesondere wer-den an die bilanzielle Behandlung von Absicherungen auf Makroebeneund den Einsatz konzerninterner Sicherungsgeschäfte besondereAnsprüche gestellt. Ähnliches gilt für die Absicherung auf Portfolio-ebene.

2. Es können Änderungen in den internen Risikomanagementstrategien,-systemen und -verfahren erforderlich sein, um die mit den Sicherungs-geschäften verfolgten Zielsetzungen des Managements in den Ab-schlüssen entsprechend abbilden zu können.

3. Die Klassifizierung der finanziellen Vermögenswerte in verschiedeneKategorien muss sorgfältig überlegt werden. Investments in Eigen- undFremdkapitaltitel werden grundsätzlich zum beizulegenden Zeitwert(Fair Value) bewertet, sofern sie nicht voraussichtlich bis zur Endfällig-keit gehalten werden. Ausnahmen bilden dabei vom Finanzinstitut aus-gereichte Kredite und bis zur Endfälligkeit zu haltende Eigen- undFremdkapitaltitel, welche zu fortgeführten Anschaffungskosten (Amor-tized Cost) bewertet werden. Der vorzeitige Verkauf von bis zur End-fälligkeit zu haltenden finanziellen Vermögenswerten kann schwerwie-gende Folgen für die Bilanzierung nach sich ziehen, da IAS 39 für solcheFälle Sanktionen vorsieht.

4. Die Unternehmen müssen sämtliche finanziellen Vermögenswerte undfinanziellen Schulden dahingehend überprüfen, ob sie eingebettetederivative Komponenten enthalten. Diese Derivate müssen unterbestimmten Voraussetzungen für Bilanzierungszwecke vom Basisinstru-ment abgespalten und zum Marktwert bewertet werden.

5. Der Standard verlangt umfangreiche zusätzliche Angaben. Die Bereit-stellung dieser Informationen kann zu Anpassungsbedarf bei den EDV-Systemen führen.

6. IAS 39 ist nicht retrospektiv anzuwenden, die Bilanzierung derGeschäftsvorfälle in früheren Perioden ist daher nicht anzupassen. Aller-dings werden in den Übergangsvorschriften des Standards einige Fra-gestellungen behandelt, die in der Vorbereitungsphase auf den Über-gang geklärt werden müssen.


Zu berücksichti-gender Zeitrahmen

Wer vollständig in IAS bilanzieren will, auf den kommen zeitlich eng be-grenzte Anforderungen zu, denn der erste Jahresabschluss muss in der Re-gel nach IAS bereits ein Jahr zuvor erstellt werden, da IAS zwingend Ver-gleichszahlen aus dem Vorjahr verlangt. Die Einführung dergrundlegenden Voraussetzungen (z.B. konforme Datensammlung) müsstedeshalb bereits zwei Jahre zuvor erfolgreich abgeschlossen worden sein(z.B. 2005 IAS-Jahresabschluss, 2004 IAS-Vergleichsabschluss, ab Ende2003/Anfang 2004 IAS-konforme Datensammlung). Erleichterungen be-züglich der Vergleichszahlen für Finanzinstrumente aus dem Jahr 2004 fürden Erstabschluss im Jahr 2005 sind in der Diskussion.

Abbildung 2.33 Zeitlich zu berücksichtigender Rahmen einer IAS-Bilanzierung

Für die zuständigen Abteilungen ist es in jedem Fall eine große Herausfor-derung, die Richtlinien umzusetzen und in ein effizientes Controllingsys-tem einzubinden. Für den IAS-konformen Konzernabschluss müssen alleTochtergesellschaften global operierender Finanzdienstleister einen voll-ständigen IAS-Einzelabschluss erarbeiten, der in einem zweiten Schrittzum Konzernabschluss konsolidiert wird.

Die IAS-Lösung von SAP

Die Anforderungen bezüglich IAS werden große Veränderungen in denverschiedenen Bereichen der Finanzdienstleister implizieren. Die gesam-ten Prozesse des Rechnungswesens müssen neu organisiert werden. Zu-dem sind die Auswirkungen auf die IT-Systeme zu berücksichtigen, von de-nen nur die wenigsten in der Lage sein werden, ohne größere AnpassungenIAS-konforme Werte zu liefern. Als Anbieter von Core-Banking- und En-terprise-Management-Lösungen ist SAP ein bewährter Partner, um die

2002 2003 2004 2005Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4

2006

Quantitative Impact Study

3rd Consul-tation paperBasel Committee

Final Basel Accord

National regulation

Phase of parallel reportingn Old accordn New accord

Reporting according to new accord

IAS system loads

IAS balance 2004 (for comparison)

IAS balance 2005


Banken bei diesen Herausforderungen zu unterstützen. SAP hat bereits diebestehenden Bankenlösungen in Zusammenarbeit mit renommierten Part-nern und Pilotkunden diesbezüglich erweitert. Grundsätzliche Anforde-rungen der IAS-Verordnung sind deshalb bereits vorhanden. Die SAP-IAS-Lösung orientiert sich an den Anforderungen, die an eine zukunftsorien-tierte integrierte Controllinglösung gestellt werden. Sie passt sich nahtlosin eine effiziente Gesamtbanksteuerung ein. Die SAP-Architektur basiertauf einer zentralen Datenbasis, auf die standardisierte Methoden ange-wendet werden, um die ermittelten Ergebnisse in einem integrierten Re-porting auszuweisen.

Abbildung 2.34 Die Architektur der IAS-Lösung im Überblick

Bilanzierungs-prozess in der

Bank als Einzelge-sellschaft

Der Ansatzpunkt für die SAP-Grundkonzeption ist die Erstellung eines pa-rallelen Rechnungslegungsabschlusses auf der Basis einer bestehenden lo-kalen Rechnungslegung. Ausgehend von einem lokalen Abschluss (z.B.HGB) werden für die IAS-relevanten Geschäftsvorfälle IAS-konformeWerte im Finanzbestandsnebenbuch ermittelt und daraufhin die ur-sprünglichen Ergebnisse der lokalen Rechnungslegung ersetzt. Dadurchwird eine parallele und redundante Verarbeitung im Finanzbestandsne-benbuch vermieden. Es werden lediglich die Werte ersetzt, bei denen dasErgebnis der lokalen Rechnungslegung von dem der IAS-Rechnungslegungabweicht. In einem abschließenden Schritt werden die bereits im Ursprung

Operative Systems

External data transfer

Financial Database

Analyzer

Result Database

ReportingData extraction

Consolidation


IAS-konformen Daten mit den neu ermittelten IAS-Ergebnissen zusam-mengeführt und in einer Ergebnisdatenbank abgelegt. Die Ergebnisdaten-bank wird damit der Anforderung eines Hauptbuches gerecht, die Positi-onen für einen IAS-Abschluss einer legalen Einheit vollumfänglichvorzuhalten.

BerichtswesenDurch die Ausgestaltung des Bilanzierungsprozess ist es möglich, nicht nurBilanz- und GuV-Informationen bereitzustellen. Auf der Grundlage der in-tegrierten Datenbasis, der Ergebnisdatenbank, können durch zusätzlicheMethoden auch anhangrelevante Informationen bereitgestellt werden.Außerdem besteht die Möglichkeit, Daten zu exportieren, um sie in an-deren Anwendungen weiter zu verarbeiten. Beispielsweise können dieseDaten zu einer Konzernkonsolidierung genutzt werden.

KonsolidierungDie neue EU-Verordnung schreibt explizit nur vor, dass der Konzernab-schluss der betroffenen Unternehmen auf der Grundlage der IAS erstelltwerden muss. Regelungen, die den Einzelabschluss betreffen, sind derzeitnoch als Wahlrecht ausgestaltet und müssen noch von den einzelnen Mit-gliedsstaaten präzisiert werden. Die SAP-IAS-Lösung baut auf dem Einzel-abschluss auf. Basierend auf dem lokalen (Einzel-)Abschluss wird das IAS-Ergebnis ermittelt. Über Extraktoren können diese Ergebnisse dann zurweiteren Bearbeitung bereitgestellt werden. Im Sinne eines integriertenKonzernrechnungswesens bietet SAP über die IAS-Lösung hinaus aucheine Konsolidierungslösung an. Das SAP Business Consolidation System(BCS) ist eine bewährte Lösung, die die notwendigen Funktionalitäten wiez.B. Schuldenkonsolidierung und Zwischenergebniseliminierung besitzt,um die Konzernkonsolidierung durchzuführen. Wichtig ist hierbei auch dieMöglichkeit, die Konsolidierung nach verschiedenen Sichten durchzufüh-ren. Eine zentrale Berichtsanforderung der IAS ist die Segmentberichter-stattung, bei der die finanzwirtschaftlichen Informationen nach verschie-denen Segmenten (Geschäftsfelder, geografische Gliederung etc.)ausgewiesen werden müssen.

Technische und methodische Kompetenz

Die SAP-IAS-Lösung wird zusammen mit renommierten Beratungspart-nern umgesetzt. Die Beratungspartner sind für die IAS-Methoden verant-wortlich und damit für den betriebswirtschaftlichen Inhalt. Außerdembringt eine Gruppe von ausgewählten Pilotbanken ihre Praxisanforderun-gen in das Projekt ein. Durch dieses Modell der Zusammenarbeit ergibtsich für weitere interessierte Banken der Vorteil, dass sie von den bereitsvorhandenen Synergien profitieren können. Dies bedeutet nicht nur einequalitative Absicherung der Methoden, sondern auch eine Reduktion desEntwicklungsrisikos. Dadurch ergibt sich ein sehr kosteneffizientes Vorge-


hen für die einzelnen Banken, denn nicht jede Bank muss selbst die ge-samte technische und methodische Entwicklung leisten. Zudem ergibt sicheine Entlastung des Bankpersonals, da viele theoretische Konzepte undVorarbeiten bereits berücksichtigt und umgesetzt worden sind.

Synergien undKostenreduktion

Ein besonderer Vorteil der SAP-IAS-Lösung ist die zukunftsorientierte Ar-chitektur. Die Basis dafür stellt ein zentraler Datenpool dar. Dieser Daten-pool ist jedoch nicht ausschließlich für das Datenmanagement von IAS-re-levanten Informationen vorgesehen, sondern offen für andereAuswertungen. Die Basel II-Lösung von SAP verwendet diese Architekturebenso und basiert daher auf demselben Datenpool, in dem u.a. die Fi-nanzprodukte der Bank abgebildet werden. Dadurch lassen sich bei derImplementierung beider Lösungen enorme Synergieeffekte und eine Kos-tenreduktion erzielen, da die gesamte technische Infrastruktur und Inter-faces nur einmal entwickelt werden müssen. Auch im anschließenden Pro-duktionsbetrieb hat dieser Ansatz Vorteile, da sich wegen der geringerenAnzahl von Applikationen und Interfaces der Wartungsaufwand reduziert.

SAP als renom-mierter Partner

SAP ist bekannt als stabiler Partner für strategisch wichtige Projekte beiBanken, was bei den herausfordernden Rahmenbedingungen von IAS vongrößter Bedeutung ist. Mit der IAS-Lösung erwerben die Kunden dahermehr als nur eine reine Software. SAP ist ein verlässlicher Partner, der überlange Jahre neben dem rein technischen Know-how über komplexe ska-lierende Anwendungen auch ein umfassendes fachspezifisches Bankwis-sen aufgebaut hat. Aufgrund jahrelanger Projekterfahrung und der engenZusammenarbeit mit Top-Beratungsgesellschaften ist SAP ein idealer Part-ner, um strategische und kritische Projekte durchzuführen. Durch die di-rekte Zusammenarbeit mit SAP können die Kunden bei der Implementie-rung auf eine intensive Betreuung, Schulung und Support vertrauen.

2.4.2 Basel II-Lösung

Die neue Baseler Eigenkapitalvereinbarung – auch Basel II genannt – isteine der höchsten Prioritäten in der Finanzbranche. Basel II bildet dieGrundlage der Mindestkapitalanforderungen für Finanzdienstleister undwurde als Reaktion auf das rapide Wachstum, das in den letzten Jahren anden internationalen Finanzmärkten stattgefunden hat, ins Leben gerufen.Das neue Regelwerk soll sicherstellen, dass Finanzdienstleister ihr Eigen-kapital in angemessener Weise einsetzen und insbesondere ihre Verfahrenzur Risikosteuerung verbessern. Obwohl die neue Eigenkapitalvereinba-rung erst Mitte des Jahres 2004 offiziell verabschiedet wird, sind die wich-tigsten Auswirkungen von Basel II bereits seit längerem bekannt.



Der professionelle Umgang mit Kredit-, Markt- und operationellen sowiesonstigen Risiken ist eine der wichtigsten Aufgaben von Finanzintermedi-ären. Solche Risiken dürfen nicht zu Instabilitäten im Finanzsektor führen.Die Steuerung des Risikos, das der Zahlungsausfall einer Bank für die Exis-tenz anderer Banken mit sich bringt, hat sich zu einer wichtigen Aufgabeder Bankenaufsicht entwickelt. Basel II schreibt vor, dass die Banken übereine ihrer Risikosituation entsprechende Kapitalausstattung verfügen, dar-über hinaus eine angemessene Risikosteuerung durchführen und die ein-gegangenen Risiken rechtfertigen müssen. Daten, die bisher nur dem Ri-sikomanager der Bank zugänglich waren, werden in Zukunft offengelegtwerden. Das bedeutet, dass die Bank die strengen Anforderungen der Auf-sichtsbehörden, der verschiedenen Interessengruppen und des Markteserfüllen muss. Dies hat weitreichende Folgen für die Datenqualität undSystemintegration und folglich auch für die Systemlandschaften der Ban-ken. In vielen Systemen und Bereichen einer Bank werden aufgrund vonBasel II Investitionen in die IT-Infrastruktur erforderlich. Die Banken solltendaher frühzeitig ihre Implementierungsstrategie definieren und bereitsjetzt die ersten Schritte einleiten.

Die drei Säulen von Basel II

Das deutlich umfangreichere Regelwerk des neuen Baseler Eigenkapital-akkords besteht aus drei sich gegenseitig ergänzenden Säulen, die dazubeitragen, das Bankensystem sicherer, stabiler und effizienter zu gestalten.

Abbildung 2.35 Die drei Säulen von Basel II

Die erste Säule: Mindestkapital-anforderungen

Ausgangspunkt des neuen Baseler Eigenkapitalakkords sind die quantita-tiven Regeln für die Mindestkapitalanforderungen. Während die Regelnfür Marktrisiken gleich geblieben sind, wurden die Messverfahren für Kre-ditrisiken stark überarbeitet. Dabei wurden alle Faktoren, die Einfluss aufdie Risikoposition einer Bank haben, mit einbezogen. Dadurch erhöht sich

Supervisory Review Process

Basel IIBasel II

Market RiskCredit Risk

Operational Risk

Minimum Capital Requirements

TransparencyResponsibility

Disclosure of:Risk Segments

Capital Structure

Market Discipline


das Volumen der erforderlichen Informationen und die Komplexität dervon den Banken verwendeten Modelle erheblich. Über eine Vielzahl vonWahlrechten werden Banken zu folgenden Handlungen motiviert:

� Ein bankinternes Ratingsystem zu entwickeln, um die Ausfallwahr-scheinlichkeit eines Kreditnehmers zu kalkulieren

� Sicherheiten differenziert zu betrachten

� Die Übertragung des Kreditrisikos durch Kreditderivate und verbriefteForderungen (Asset-Backed Securities, ABS) zu berücksichtigen

Darüber hinaus verlangt der neue Baseler Eigenkapitalakkord erstmalsauch die explizite Unterlegung von operationellen Risiken mit Kapital.

Dei zweite Säule:Bankaufsicht-

licher Überprü-fungsprozess

Die in der ersten Säule enthaltenen quantitativen Mindestkapitalanforde-rungen und allgemeinen Regelungen werden durch ein aufsichtsrechtli-ches Überprüfungsverfahren ergänzt, das eine angemessene Einschätzungder individuellen Risikosituation der jeweiligen Bank sicherstellen soll. ImAnschluss an die Überprüfung der bankinternen Verfahren zur Kapitalal-lokation kann die Bankenaufsicht gegebenenfalls eine höhere Eigenkapi-talunterlegung festsetzen.

Die dritte Säule:Marktdisziplin

Das Ziel der dritten Säule ist die Stärkung der Marktdisziplin durch eineverbesserte Offenlegung der Banken. Durch die Offenlegung von detail-lierten Informationen über alle Risikoarten wird es den anderen Marktteil-nehmern ermöglicht, die Risikoposition und die Angemessenheit der Ei-genkapitalausstattung einer Bank zu beurteilen. Die zusätzlichenOffenlegungen sollen – soweit möglich – mit den Rechnungslegungsvor-schriften der International Accounting Standards (IAS) abgestimmt wer-den.

Die Basel II-Lösung von SAP

Die in Basel II festgelegten neuen Eigenkapitalanforderungen haben weit-reichende Folgen für die Banken. Die neuen Regelungen wirken sich aufdie allgemeine Struktur und die Prozessorganisation innerhalb der Bankenaus. Das bedeutet, dass ihre IT-Systeme angepasst werden müssen. DieBanken stehen vor der Aufgabe, die expliziten und impliziten Anforderun-gen des neuen Regelwerks in einer Vielzahl von unterschiedlichen IT-Sys-temen abzubilden. Als Lösungsanbieter sowohl für operative Systeme alsauch für Systeme zur Gesamtbanksteuerung unterstützt die SAP ihre Kun-den bei der Erfüllung dieser Anforderungen. Zu diesem Zweck erweitertSAP den Funktionsumfang von mySAP Banking durch die Entwicklung ei-ner speziellen Komponente für das neue Basel II-Regelwerk in Zusammen-arbeit mit mehreren Kunden.


Abbildung 2.36 Die Architektur der BASEL II-Lösung im Überblick

Thema Kredit-risiko

Die SAP-Lösung für Basel II legt ihren Fokus auf den Aufbau einer geeig-neten Infrastruktur für das Management von Kreditrisiken. Die SAP-Lö-sung unterstützt alle im Rahmen von Basel II vorgesehenen Verfahren zurBerechnung von Kreditrisiken – vom Standardansatz bis hin zu einem fort-geschrittenen, auf bankinternen Ratings basierenden Ansatz (Internal Ra-tings Based Approach, IRB-Ansatz). Bestehende Lösungen im Rahmen vonSEM Banking komplettieren das Lösungsangebot. So verfügt die SAP mitihrem bewährten Limitsystem für Ausfallrisiken bereits über eine ausge-zeichnete Grundlage für das Risikomanagement. Die existierenden Kom-ponenten für Asset Liability Management und Marktrisiken sind ein inte-graler Bestandteil der Basel II-Lösung und werden die neuenAnforderungen für das Zinsrisikomanagement im Bankbuch abdecken. Diegrößte Herausforderung im Bereich des operationellen Risikos besteht inder Einrichtung einer IT-Infrastruktur zur Unterstützung von Prozessen fürdas operationelle Risikomanagement. Mit der verfügbaren Data-Ware-house- und Reporting-Infrastruktur innerhalb von mySAP Business Intel-ligence bietet SAP eine gute Basis, um wichtigen Herausforderungen aufdiesem Gebiet zu begegnen.

Enge Kooperation zwischen SAP und den Banken

Es wird zwar noch einige Jahre dauern, bis die Regelungen von Basel II innationale Gesetze aufgenommen werden und in Kraft treten. Angesichtsder Komplexität der Herausforderung sollten aber die Banken die verfüg-bare Zeit nutzen und schon jetzt erste Schritte einleiten. Damit den Bankenausreichend Zeit für ihre interne Implementierung bleibt, entwickelt SAPin enger Zusammenarbeit mit Pilotkunden bereits die notwendigen Funk-

Rating EngineRating Engine CollateralManagement

CollateralManagement

Financial DatabaseFinancial Database Historical DatabaseHistorical Database

Exposure CalculationExposure Calculation

Reg.Reporting Processing for Basel IIReg.Reporting Processing for Basel II

Regulatory ReportingRegulatory ReportingDisclosureDisclosureInternal ReportingInternal Reporting

StandardApproach

Foundation IRBApproach

Advanced IRBApproach

3rd party3rd party

Business Partner

Business Partner

SAPSAP

SAP Basel II Solution

Estimation of Loss Given Default

Estimation of Loss Given DefaultSAP or 3rd partySAP or 3rd party

......

Estimation of Default Probability


tionen. Als Erstes wurden die Bausteine entwickelt, die höchste Prioritäthaben, wie zum Beispiel die Definition der Datenanforderungen für dieoperativen Systeme, die Struktur der Historiendatenbank und die Grund-lagen für die Exposurekalkulation. Diese Funktionen wurden bis Ende desJahres 2003 zur Verfügung stehen. Die Banken haben die Möglichkeit, biszum Inkrafttreten der neuen Regeln eng mit der SAP zusammenzuarbeiten.Diese enge Kooperation verschafft den Banken die größtmögliche Sicher-heit, dass die erforderlichen Funktionen rechtzeitig implementiert wer-den.

Integration vonBasel II in die

bestehendeLösung

Die SAP-Komponente für Basel II wird ein wichtiger Bestandteil der be-stehenden SAP-Lösung zur Gesamtbanksteuerung werden. Als Elementvon mySAP Banking wird die neue Komponente den hohen Anforderun-gen, die der neue Baseler Eigenkapitalakkord an die Systemlandschaftstellt, gerecht werden. Die SAP-Komponente für Basel II wird mit den be-stehenden Funktionen von mySAP Banking verzahnt. Dies gilt sowohl fürdie Gesamtbanksteuerung (z.B. Strategische Planung, Risikomanagement,Limitmanagement und Portfoliomanagement) als auch für das operativeBankgeschäft (z.B. Geschäftspartnerverwaltung, Rating- und Vertragsver-waltung). Mit der Komponente Collateral Management zur Sicherheiten-verwaltung bietet die SAP darüber hinaus eine voll integrierte Lösung füreinen weiteren Bereich, in dem die Banken in Vorbereitung auf die neuenBaseler Eigenkapitalregeln eine zügige Anpassung ihrer Systeme vorneh-men müssen. Die SAP wird eng mit nationalen Lösungsanbietern zusam-menarbeiten, um die Meldungserstellung an die nationalen Behörden zuunterstützen.

Über die Erforder-nisse von Basel II

hinaus

Basel II erfordert Investitionen in eine erweiterte Plattform für das Kredit-risikomanagement. Die SAP-Lösung reicht über die Erfordernisse von BaselII hinaus und bietet eine integrierende Grundlage für drei Bereiche:

� Basel II

� Kreditportfoliomanagement

� Limitmanagement

Dieser Rahmen beinhaltet sowohl die externen aufsichtsrechtlichen An-forderungen als auch die eigenen internen Risikoeinschätzungen der Bankund stellt daher in allen Aspekten eine solide Basis für ein effizientes Kre-ditrisikomanagement dar.

Heute in dieErfordernissevon morgeninvestieren

SAP wird weiterhin auf dieser Infrastruktur aufbauen, um auch in Zukunftden Erfordernissen der Bankbranche einen Schritt voraus zu sein. Durchdie enge Kooperation mit führenden europäischen Banken, die in der Zu-


sammenarbeit mit verschiedenen Partnern erworbene Fachkompetenz so-wie das Wissen und die Erfahrung aus mehr als 800 Implementierungenvon mySAP Banking in über 55 Ländern verfügt die SAP über entschei-dende Vorteile bei der Entwicklung einer Lösung für Basel II. SAP ist gutdarauf vorbereitet, schnell auf Veränderungen zu reagieren und neue An-forderungen effizient zu erfüllen. Die SAP-Lösung für Basel II ist eine Stan-dardsoftware, mit der »Best Practices« umgesetzt und den Banken riskanteund langwierige Eigenentwicklungen erspart werden.

Abbildung 2.37 Die Basel II-Lösung und angrenzende Komponenten im Überblick

Die zentrale Vision der neuen Baseler Eigenkapitalvereinbarung bestehtdarin, die regulatorischen Kapitalbemessungen enger mit den internen Ri-sikomanagementverfahren der Banken zu verzahnen. SAP verwirklichtdiese Vision durch eine Kombination von Kapitalmanagement und Risiko-management in einer einzigen integrierten Plattform auf der Basis einereinheitlichen Technologieinfrastruktur. Zudem unterstützt die Basel II-Lö-sung von SAP weitere Prozesse der Gesamtbanksteuerung, wie z.B. dasRentabilitätsmanagement und die Erfüllung von Offenlegungspflichten imRahmen von IAS. Mit der Basel II-Lösung bietet SAP eine Standardsoft-ware, die bereits heute die Anforderungen von morgen auf globaler Ebeneerfüllt.

Rating Engine CollaterialManagement

Other

FinancialDatabase

Exposurecalculation

Reporting for Basel II

Credit Portfolio

Model

Limit Manage-ment

Result Database

Reporting Tool

Results from other Analyzers Results to other Analyzers


2.5 Ausblick auf der Grundlage des SAP Bank Analyzer

Aufbauend auf der Gesamtbankinfrastruktur des SAP Bank Analyzer plantSAP eine Reihe von Anwendungen, die eine Gesamtbanksteuerung auf derBasis von Kennzahlen ermöglichen.

Die vom SAP Bank Analyzer zur Verfügung gestellte Gesamtbankinfra-struktur lässt sich durch Customizing flexibel auf die Erfüllung vielfältigerbetriebswirtschaftlicher Anforderungen hin anpassen. SAP plant aus die-sem Grund, zusammen mit seinen Kunden und Beratungspartnern meh-rere Anwendungen zu erstellen, beispielsweise zu den Themen Profitabi-lity Management, Asset Liability Management, Limit Management,Integrated Accounting oder Hedge Management. Wir wollen uns im Fol-genden auf das Hedge Management konzentrieren.

2.5.1 Hedge Management

Die meisten Banken sichern (also hedgen) einen Teil ihrer Geschäfte schonheute routinemäßig gegen Marktrisiken ab – sei es gegen das Zinsrisikodurch Zinsswaps oder gegen das Währungsrisiko durch Devisenterminge-schäfte. Zur Bilanzierung nach IAS 39 wird nun genau vorgeschrieben, inwelcher Weise solche Sicherungsbeziehungen (Hedgebeziehungen) in dieBilanz einfließen dürfen. Dadurch entsteht eine Notwendigkeit, Systemeund Prozesse einzuführen, die es erlauben, Hedgebeziehungen den IAS-Richtlinien gemäß zu designieren und ihre Effektivität zu beobachten. DasSAP Hedge Management stellt solch eine zentrale Lösung dar, die hedge-spezifische Informationen aus allen Vorsystemen analysieren kann und zu-gleich die Schnittstelle zum Balance Analyzer und der Financial Databaseim Bank Analyzer bildet.

Grundlagen Das SAP Hedge Management bietet einen zentralen Einstieg zur Verwal-tung und Verarbeitung von Hedgebeziehungen im SAP Bank Analyzer. Esrealisiert eine Überwachung aller Hedges in der IAS-Buchhaltung und ge-währleistet einen konsistenten Abgleich mit der Financial Database. Somiterhalten Sie einen Überblick über ihre nach IAS abgesicherten Risiken so-wie über die ganz oder teilweise abgesicherten Geschäfte und können aufÄnderungen am Markt direkt reagieren.

149Ausblick auf der Grundlage des SAP Bank Analyzer

Durch das SAP Hedge Management verfügen Sie über einfache, aber den-noch umfangreiche Möglichkeiten, Hedgebeziehungen zu verwalten:

� Sie haben die Möglichkeit, Hedgebeziehungen gemäß IAS 39 zu knüp-fen und zu designieren.

� Es wird ein prospektiver Effektivitätstest angeboten, der die zukünftigeEffektivität nach der Methode des Markdaten-Shifts simuliert.

� Das Hedge Management reagiert automatisch auf Vorfälle in der Finanz-bestandsführung und leitet gegebenenfalls die Auflösung eines Hedgesein.

� Die Verwaltung von Hedgebeziehungen des IAS-Hedgetyps »Fair ValueHedge« ermöglicht die Knüpfung von n:m-Relationen als Voll- oderTeilsicherungen (Micro-Hedges).

� Die Verwaltung von Macro Cashflow Hedges nach IGC 121-2 (Batch 6)wird unterstützt.

� Die Unterstützung des Portfolio Fair Value Hedges (momentan im Sta-tus eines Exposure Draft zum IAS39 ) ist geplant.

Unterstützt werden Sie dabei von einer ansprechenden, intuitiven und mitABAP-Technologie programmierten Oberfläche, die Ihnen alle wichtigenInformationen auf einen Blick liefert.

Einbettung der Hedge-Manage-ment-Lösung in die IAS-Lösung

Das Hedge Management ist als Add-On zur IAS-Lösung konzipiert. Den-noch wird es sehr stark in die Gesamtprozesse der IAS-Buchhaltung inte-griert. Es nutzt die Bestände aus der Finanzbestandsführung der IAS-Lö-sung unter zusätzlichem Lesen von hedgerelevanten Information aus derFDB (z.B. Finanzgeschäfts- und Finanzinstrumentsdaten). Bevor neuange-legte Hedgebeziehungen in die IAS-Lösung veröffentlicht werden, kannein prospektiver Effektivitätstest angesteuert werden. Durch die Veröf-fentlichung werden die FDB-Hedgebeziehungen aktualisiert, und es wirddie IAS-Buchhaltung zu Umbuchungen veranlasst. Neben dem Eingehender Hedgebeziehungen wird zudem auch das Auflösen gesteuert.

Eine Reihe an einstellbaren Funktionalitäten hilft dem Anwender bei allennotwendigen operativen Tätigkeiten, z.B. bei der Suche von passendenGeschäften zur Knüpfung von Hedgebeziehungen durch eine Kandidaten-findung. Die operativen und publizierenden Prozessschritte werden do-kumentiert und können als Report verfügbar gemacht werden.


Abbildung 2.38 Einbettung der Hedge-Management-Lösung in die IAS-Lösung

Vergleichbar mit einem der Analyzer, ist das Hedge Management einge-bettet in die Komponentenwelt des BA. Die Kommunikation kann durcheine Reihe von Programmierschnittstellen (APIs) und Business Add-Ins(BADIs) in beide Richtungen stattfinden. Hier sind Datenflüsse darge-stellt, die bei hedgetypischen Geschäftsprozessen (z.B. der Designation ei-ner Hedgebeziehung) auftreten können.

Ergänzend zum Hedge Accounting, das alle buchhalterischen Operatio-nen einer IAS-Hedgebeziehung abdeckt, stellt das Hedge Managementalle für den Aufbau und für das Auflösen von Hedgebeziehungen notwen-digen Operationen zur Verfügung. Es übernimmt die Verwaltung und Do-kumentation bestehender, aufgelöster bzw. ausgelaufener und im Aufbaubefindlicher, schwebender Hedges.

Das SAP Hedge Management ermöglicht eine konsistente Abbildung vonHedgebeziehungen in der SAP Bank Analyzer-Welt. Konsistent heißt indiesem Zusammenhang, dass die abhängigen Objekte – das FDB-Primär-objekt »Hedgebeziehung« und die Finanzbestandsobjekte der IAS-Buch-haltung – nach abschließender Fortschreibung in einem widerspruchs-freien Zustand gehalten werden. Dabei läuft die Aktualisierung derBestandsobjekte durch interne Geschäftsvorfälle der Bestandsführung ab.Diese internen, hedgespezifischen Geschäftsvorfälle werden durch dieFunktion Veröffentlichen des Hedge Managements erzeugt und direkt inder IAS-Buchhaltung gebucht.

Der Arbeitsplatz »Hedge Management« ist in das generische Konzept desBank Analyzer (IAS-Lösung) eingegliedert. Dementsprechend sind Ein-

Service Functions

Fair Value CalculationAmortized CostCalculation

EffectivenessManagement

Ext. Business Transactions

Valuation ResultsFinancial

Instrumentsand Transactions

HedgingRelationships Market Data

Document Storage

Document Preparation

Accounting Totals

B A,E GJ

Key Date ValuationFinancial Position ManagementPosting of Business Transactions

Hedge Management

Administration HedgingRelationships

IAS-Accounting

151Ausblick auf der Grundlage des SAP Bank Analyzer

stellungen bei Benutzung des Hedge Managements auch in anderen Kom-ponenten des Bank Analyzer zu berücksichtigen. Hier sollen nun zwei Bei-spiele aufgeführt werden, um solche Wechselwirkungen zu illustrieren.

Der Benutzer kann sich Bestände im Sinne von Finanzbestandsobjektenaus der IAS-Buchhaltung in weitem Umfang auf die eigenen Bedürfnissezuschneiden. Dazu entscheidet er selbst über Felder und Granularitäten.Diese müssen natürlich zu den angestrebten Funktionalitäten des HedgeManagements passen. Ist es notwendig, Bestandsinformationen durch Ge-schäftsinformationen zu ergänzen, so muss der IAS-Bestand eine eindeu-tige Referenz auf das Geschäft mitführen.

In der FDB werden zentral die Felder, die die Komponenten des SAP BankAnalyzer verwenden, angelegt. Auch die kundeneigenen Felder des HedgeManagements müssen dort angelegt werden.

Archiktektur der Hedge-Manage-ment-Lösung

Das Hedge Management ist in sechs funktionell getrennte Komponentengegliedert:

� Datenbereitstellung (HMDA – Hedge Management Data Appropriation)

� Verwaltungsdienste (AHR – Administration of Hedging Relationships)

� Datenfortschreibung (HMID – Hedge Management Information Dispat-cher)

� Reporting (HMR – Hedge Management Reporting)

� Kundeneinstellungen (CHM – Customizing Hedge Management)

� Datenhaltung (HMDB – Hedge Management Database)

Abbildung 2.39 Die Funktionsbereiche innerhalb des SAP Hedge Managements im Überblick

Datenbereitstellung (HMDA) Verwaltung (AHR) Datenfortschreibung (HMID)Operationen an Hedge-Beziehungen

Anlegen Hedge-Beziehung

Zuordnung Bestände

Kandidatenfindung

Informationsanreicherung

Validierung

Start Prospektiver Effektivitätstest

Zwischenstände speichern

Reaktion auf externe Ereignisse

Kundeneinstellungen (CHM)

Datenhaltung (HMDB)

Reporting (HMR)

Ermittlung von Geschäften

Vorhalten IAS-Bestände

Selektionen

Arbeitsvorräte füllen

Aktualisierungen

Fortschreibung Bestandsführung (IAS-Lösung)

Fortschreibung Primärobjekt Hedge-Beziehung

Datenex- und -importPersistierter Hedge-LebenslaufArchivierung

Übersicht der Hedge-Beziehungen

DetailprotokolleHistorie

Hedge Management


Bei dem Geschäftsprozess Designation einer Hedgebeziehung werden dieBereiche in Pfeilrichtung durchlaufen (siehe Abbildung 2.39). Ausgehendvon ungesicherten Beständen, bzw. nicht sichernden Derivatpositionender IAS-Finanzpositionsführung, werden Umbuchungen auf gesicherteund sichernde Bestandspositionen durchgeführt. Die Pfeile deuten denArbeitsablauf an, der beim Eingehen einer Hedgebeziehung durchlaufenwird.

Die HMDA sorgt für die Datenaufbereitung. Was die Datenversorgungangeht, so bildet die HMDA die Schnittstelle des Hedge Managementsnach außen und ist flexibel einstellbar (CHM).

Nahezu alle operativen Funktionalitäten sind in der AHR konzentriert.Basierend auf der Datenversorgung durch die HMDA und unterstütztdurch die Hedge-Arbeitsplatzoberfläche kann der Anwender seine opera-tiven Tätigkeiten ausführen. Der Arbeitsfortschritt wird über die Status-verwaltung dokumentiert und in der HMDB festgehalten. Nach Abschlussder operativen Tätigkeiten kann das HMID in Aktion treten.

Außerdem reagiert Komponente AHR des Hedge Managements automa-tisch auf äußere Ereignisse, wie z.B. auf das Auflösen einer Hedgebezie-hung, angestoßen aus dem Hedge Accounting durch Bestandsabgängeoder Ineffektivitätsvorfälle.

Das HMID ist der prinzipielle Datenausgang des Hedge Managements undveröffentlicht die neu verknüpften bzw. aufgelösten Hedgebeziehungen.Dazu nutzt es die Einstellungen des Anwenders zu den zu belieferndenSchnittstellen (CHM) und die durch das AHR in der HMDB abgelegtenInformationen.

Zusätzlich zu den bereits dargestellten Funktionalitäten der HMDB alsDatenhaltung des Hedge Managements können hier auch Daten direkt ex-und importiert werden.

Das HMR stellt Sichten zwecks Reporting auf die HMDB zur Verfügung.

Es sei an dieser Stelle an einem Beispiel des Eingehens einer Hedgebezie-hung veranschaulicht, wie die einzelnen Komponenten des HedgeManagements ineinander greifen können:

� HMDAIn Selektionsbedingungen ist schon festgelegt worden, welche Eigen-schaften die Kandidaten für den Hedge mitbringen müssen. So kannz.B. in der Produktart für die Grundgeschäftskandidaten festgelegt wor-den sein, daß es sich um Darlehen handeln muss. Die Datenbereitstel-

153Markt und Positionierung

lung baut die ausgewählten Arbeitsvorräte aus den IAS-Beständen anGrund- und Sicherungsgeschäften unter Nutzung der Selektionsbedin-gungen auf.

� AHRSind die Arbeitsvorräte gefüllt, so werden sie gezielt für einen Grund-und für einen Sicherungsgeschäftspool eingelesen. Dies geschieht mit-tels der AHR. Ein Pool umfasst die (eventuell reduzierte) Auswahl anBeständen eines Arbeitsvorrats. Manuell wird in der AHR eine neueHedgebeziehung angelegt und das erste Sicherungsgeschäft zugewie-sen (drag/drop hedgerelevanter Merkmale und Kennzahlen). Mittelsder Suchfunktionalität (Hedge-Kandidatenfindung) werden Grundge-schäfte vorselektiert, die für diese Hedgebeziehung in Frage kommen.Der erste passende Bestand wird ausgewählt und mit entsprechendemVolumenanteil eingesetzt. Nach weiterem Ausfüllen der Felder sowiePlausibilitätenprüfung und Validierung wird diese schwebende Hedge-beziehung als für das Hedge Management abgeschlossene Hedgebezie-hung abgelegt. Anschließend kann die Veröffentlichnug einer schwe-benden Hedgebeziehung in die IAS-Lösung simuliert werden. Insbe-sondere findet hier eine erneute Bestandsprüfung in der IAS-Buchhaltung statt. Die schwebenden Hedgebeziehung muß nun außer-halb des Hedge Managements veröffentlicht werden.

� HMIDDazu aktualisiert die Datenfortschreibung das FDB-Primärobjekt»Hedgebeziehung«, wobei ein Mapping der Informationen über dieschwebende Hedgebeziehung in die Strukturen erfolgt, die das Primär-objekt versteht. Ein ähnlicher Mappingvorgang ist für den internenGeschäftsvorfall nötig, der die Bestände der IAS-Buchhaltung aktuali-siert. Sind beide Vorgänge abgeschlossen, so wird protokolliert, dass dieHedgebeziehung erfolgreich systemweit angelegt worden ist.

2.6 Markt und Positionierung

von Dr. Peter Stork, Partner, IBM Business Consulting Services, IBMDeutschland GmbH

Wandel in der Finanzwirtschaft

Kaum eine Branche hat sich in den vergangenen Jahren so stark gewandeltwie die Kreditwirtschaft. Internationalisierung und (De-)Regulierung derFinanzmärkte, rascher Fortschritt in der Informations- und Kommunikati-onstechnologie sowie verändertes Kundenverhalten haben einen tiefgrei-fenden Wandel des Bankgeschäfts bewirkt. Banken sind heute konfrontiertmit einer Konsolidierung unter den Finanzdienstleistern, mit wachsendem


Wettbewerb auf den Geld- und Kapitalmärkten sowie neuen Vertriebska-nälen und -konzepten. Dies wird begleitet durch sich wandelnde regula-torische Rahmenbedingungen und eine wachsende Bedeutung der Cor-porate Governance.

HoheIntegrations-

anforderungen

Die Buchhaltungs- und Managementsysteme in vielen Finanzinstitutenstoßen unter diesen ständig neuen Anforderungen an ihre Grenzen. In ei-ner Vielzahl von Projekten hat sich gezeigt, dass die Mehrheit der BankenSchwierigkeiten hat, die für eine integrierte Banksteuerung notwendigenInformationen vollständig und zeitnah zusammenzuführen. Dies liegt vorallem darin begründet, dass die vorhandenen Informationssysteme undProzesse in den Banken oft nicht ausreichend integriert sind. Ein Beispielist die funktionale (und damit systemtechnische) Trennung der zentralenBankbereiche des externen und internen Rechnungswesens, des Risiko-controllings, des Meldewesens sowie des Treasury.

Der Gedanke, dass die verschiedenen Steuerungsmechanismen einer Bankals unterschiedliche Facetten einer konsistenten Gesamtsicht verstandenund angewendet werden müssen, ist nicht neu. Durch die Einführung derIAS bzw. IFRS (International Financial Reporting Standards) und der neuenBasel II-Regularien wird diese bislang abstrakte Vision nun aber zur fachlichund technisch umzusetzenden Notwendigkeit. Immer deutlicher unddringender wird die Erkenntnis, dass man die ständig wachsende fachlicheKomplexität der Gesamtbanksteuerung technisch überhaupt nur nochdurch eine grundlegende Überarbeitung der Lösungsansätze zu einer in-tegrierten Architektur adäquat wird abbilden und unterstützen können.

Marktverän-derung durch den

SAP Bank Analyzer

Mit dem SAP Bank Analyzer verändert SAP den Markt für Banksteuerungs-systeme. Der Bank Analyzer ist das erste Produkt, das vom Softwareher-steller von vornherein dazu ausgelegt wurde, als integrierende Plattformfür alle Anforderungen der Banksteuerung – von der Buchhaltung über dieRisikosteuerung bis zum Meldewesen – in Banken zu dienen. Anders alsProdukte, die ausgehend von einer einzelnen Anwendung historisch in dieBreite gewachsen sind, ist der SAP Bank Analyzer dementsprechend auf diedrei Grundanforderungen

� Fachliche Breite (horizontale Integration)

� Architektonische Tiefe (vertikale Integration)

� Technische Tragfähigkeit

gleichzeitig umfassend ausgerichtet und entwickelt worden.


Dies beginnt mit der Financial Database, deren Positionierung und Bedeu-tung in Abschnitt 2.6.1 besprochen wird. Dem schließen sich Abschnittezur Einordnung der IAS-Solution und der Basel II-Solution an. Abschnitt2.6.4 schließlich gibt einen Ausblick auf weitere Entwicklungen des SAPBank Analyzers und damit den Rahmen für eine Gesamtbetrachtung.

2.6.1 Financial Database

Funktionale Rolle als Operational Data Store

In der SAP Financial Data Base (FDB) werden sämtliche für die Banksteu-erung relevanten Vertrags-, Bewegungs- und Stammdaten abgelegt. Dieserfolgt als inhaltliche Kopie der originalen Daten, jedoch in einem an dieFDB angepassten und vom Kunden vorzugebenden und konfigurierbarenDatenmodell. Jedes Geschäfts wird nur einmal abgelegt. Hinzu kommenKopien der Bankstruktur- sowie Marktdaten. Die zentrale und überschnei-dungsfreie Zusammenführung der Ausgangsdaten für die Banksteuerungs-verfahren an einer Stelle ist das architektonische Schlüsselelement zur Si-cherung der Daten- und Ergebniskonsistenz. Die FDB erfüllt damit in derfunktionalen Lösungsarchitektur des SAP Bank Analyzer die Rolle des (kon-solidierten) Operational Data Store, der die zentrale Originaldatenbasis ei-nes Banksteuerungssystems bildet (vergleiche Abschnitt 2.6.4).

Flexible Daten-modellierung

Bei der Entwicklung hat SAP die FDB bewusst als offenes und flexiblesWerkzeug ausgelegt, um eine maximale Breite von Kundenanforderungenerfüllen zu können. In Form der so genannten Primärobjekte stellt SAP eineGrundmenge von Informationen nach logisch getrennten Entitäten (z.B.Marktdaten, Sicherheiten, Transaktions- und Bestandsinformationen) zurVerfügung. Die individuelle Ausprägung des Datenmodells erfolgt durchden Kunden bei der Implementierung. Um die Einführung zu beschleuni-gen, wird SAP in Zusammenarbeit mit den Partnern Mustervorgaben fürdie FDB anbieten, und Partner können – wie im Fall von IBM Business Con-sulting Services – ganze Bankdatenmodelle für die FDB anbieten bzw. auf-bereiten.

Darüber hinaus sind in der Financial Database diejenigen Verarbeitungs-und Berechnungsverfahren angesiedelt, die Allgemeingültigkeit über ei-nen einzelnen Analyzer hinaus haben.

Infrastruktur für Datenmanage-ment und Administration

Neben ihrer Funktion als Operational Data Store beinhaltet die FDB je-doch noch eine ganze Reihe von Datenmanagement- und Administrati-onsfunktionen, die für den eigentlichen operativen Aufbau und Betrieb ei-nes Data Warehouses in einer Bank zwingend notwendig sind. DieDatenmanagementfunktionen umfassen:


� Werkzeuge zur Datenübernahme von Vorsystemen

� Schnittstellen zu Analyzern und Drittprodukten

� Werkzeuge zur Modellierung der FDB

� Physikalische Datenhaltung

� Versionierung und Historisierung

� Archivierungsfunktion

Die Administrationsfunktionen umfassen:

� Ablauf- und Prozessüberwachung

� Generierung von Audittrails zur Nachvollziehbarkeit und Prüfbarkeit

� Korrekturserver zur detaillierten Dokumentation von Veränderungenan Daten

� Metadatenmanagement

� Zugangssicherung und Berechtigungskonzept

Reporting mitSAP BW

Die FDB als Operational Data Store ist fokussiert auf die Datenhaltung. DieBerichterstellung im SAP Bank Analyzer – sei es aus FDB-Daten oder ausErgebnissen der SAP Analyzer – wird durch das SAP BW übernommen, dasauf die effiziente Präsentation multidimensionaler Berichtsdaten ausgelegtist.

Lösungspaket fürein Operational

Data Store

Die FDB stellt somit eine umfassende Softwarearchitektur zum Aufbau undoperativen Betrieb eines Operational Data Store für die Banksteuerung dar.Verbunden mit der von der SAP-Basis grundsätzlich gegebenen techni-schen Infrastruktur für Hardware und Datenbank bildet sie ein komplettesLösungspaket für ein Operational Data Store. Der Anwender kann sich aufden differenzierenden Bestandteil, die individuelle Datenmodellierung,konzentrieren. Die FDB ist jedoch kein Enterprise-wide Data Warehouse;eine Speicherung von Kundenkontaktdaten (Client Relationship Manage-ment, CRM) ist z.B. derzeit nicht vorgesehen.

Sonderstellung amMarkt

Die FDB unterscheidet sich damit in ihrem Leistungsumfang deutlich vonanderen Lösungsansätzen für das Data Warehousing in Banken, die sich indie folgenden Gruppen einteilen lassen:

� Reine Bankdatenmodelle Bankdatenmodelle zielen auf die Reduktion der Modellierungsauf-wände und die Stabilität des Datenmodells bei fachlichen Erweiterun-gen. Reine Bankdatenmodelle müssen jedoch physikalisch implemen-tiert werden, und die gesamte Infrastruktur zum Betrieb des Operatio-nal Data Store muss zusätzlich bereitgestellt werden.


� Relationale Datenbanken Sie stellen lediglich die datenbanktechnische Plattform einer Imple-mentierung eines Operational Data Store dar. Zur Implementierungeines Operational Data Store muss ein Bankdatenmodell entwickelt undtechnisch implementiert werden, zudem muss sämtliche Infrastrukturzum Betrieb bereitgestellt werden.

� Operationale Data Stores/Geschäftsdatenspeicher in Banksteue-rungssystemen Diese in vorhandenen Paketen enthaltenen Datenbanken entsprechenam ehesten vom Aufbau und Zweck her der FDB. Sie unterscheiden sichin folgenden Punkten:

� Fachliche Breite

� Vorgabe eines mehr oder weniger festen Datenmodells

� Geringere Flexibilität bei der Abbildung von Kundendatenstrukturen

� Geringerer Umfang der Infrastrukturleistungen

� Geringere Unabhängigkeit von Hardware und Datenbanksoftware

Mit der FDB positioniert SAP ein Produkt an einer zentralen Stelle der Lö-sungsarchitektur einer Bank. Bei einer Einführung der FDB werden damitgleichzeitig SAP-Softwarestandards an zentraler Stelle der Softwareinfra-struktur implementiert.

2.6.2 IAS-Lösung

Die Einführung der IAS ist ein strategi-sches Projekt

IAS (die neue Bezeichnung lautet IFRS) wird der internationale Konzern-rechnungslegungsstandard mit maßgeblichem Einfluss auf die Außen-darstellung aller Bankprodukte und Dienstleistungen. Die daraus resultie-rende Änderung der Steuerungsphilosophie und damit derSteuerungssysteme hat abteilungsübergreifenden Einfluss auf die Organi-sation, die Prozesse und Systeme. Damit ist die Einführung der IAS ein stra-tegisches Projekt. Ziel ist es, ein modernes externes Berichtswesen aufzu-bauen, welches als Dienstleister entscheidungsrelevante Informationenfür das Management und die Geschäftsfelder der Bank bereitstellt.

Erhöhte struktu-relle Anforde-rungen

Obwohl die folgenden Anforderungen grundsätzlich an jedes Rechnungs-wesensystem zu stellen sind, sind sie bei den IAS erheblich dringender um-zusetzen bzw. werden direkt durch den Standard erzwungen:


� Multidimensionalität im Berichtswesen und in der vorgelagerten Auf-bereitung, Multi-GAAP-Fähigkeit, Multi-Legal-EntitiesIAS muss in vielen Ländern bis auf Weiteres neben dem lokalen Rech-nungswesenstandard betrieben werden.

� Einheitlichkeit und Konsistenz von Geschäftsdaten und BewertungDie IAS-Bewertungsverfahren sind im Allgemeinen komplexer als diebisherigen Verfahren; sie hängen zudem in vielen Fällen von Marktda-ten ab. Nach IAS muss sichergestellt werden, diese Bewertung auf derBasis einheitlicher Verfahren und Daten innerhalb der gesamten Bankidentisch vorzunehmen.

� Schnelle Verfügbarkeit von qualitativ hochwertigen InformationenNach den IAS ist ein mindestens quartalsweises Berichtswesen anzu-streben, d.h. eine Vervierfachung der Berichtspflichten. Ferner verlan-gen die internen und externen Berichtsempfänger die immer frühereund zeitnähere Vorlage der Bilanz (Fast Close).

� Flexibilität, Anpassungsfähigkeit, Robustheit und SkalierbarkeitDie IAS sind ein evolvierender Standard. Das Rechnungswesensystemmuss sich diesen Veränderungen effizient anpassen lassen können.

Erhöhte funkti-onale Anforde-

rungen durch IAS

Im Zentrum der Diskussion einer Standardisierung der Rechnungslegungfür Banken steht die Bilanzierung von Finanzinstrumenten nach IAS 39.Kernpunkte sind hier:

� Bewertung großer Teile der Finanzinstrumente nach Fair Value

� Aufnahme sämtlicher Derivate in die Bilanz

� Bilanzierung von Hedgebeziehungen nach komplexen Regeln

IAS 39 stellt damit Anforderungen, die mit den Strukturen der gewachse-nen Rechnungswesensysteme nicht abgedeckt werden können.

FunktionaleBausteine

Diese Anforderungen müssen mit den Grundelementen der Bewertung,der Buchung, des Berichtswesens zusammengeführt werden und führendazu, dass jede technische IAS-Systemlösung mindestens die in Abbildung2.40 dargestellten funktionalen Blöcke enthalten muss.


Abbildung 2.40 Funktionale Blöcke der IAS-Lösung (© IBM Corporation 2003)

� A: Geschäftsvorfälle werden an die Bestandsführung übertragen.

� B: Vorfälle rufen direkt (B) oder über Bestands- und Werteführung (B')Buchungssystematik auf.

� C: Zu Kalkulationszeitpunkten erfolgt eine endogene und exogeneBewertung aus Informationen der Bestandsführungen; Weiterleitungder Informationen an Werteführung (C').

� D:Die Werteführung ruft nach Bewertungsläufen das Hedge-Accoun-ting (D') inklusive Effektivitätstest sowie die Buchungssystematik auf.

� E: Buchungen generieren Salden auf Bestands- und Erfolgskonten, ausdenen Berichte (GuV, Bilanz) erstellt werden.

� F: Aus der Werteführung werden direkt Berichte erzeugt (z.B. Notes).

Diese funktionale Architektur bezieht sich bewusst auf den IAS-Einzelab-schluss, da dieser oder ein dem Einzelabschluss äquivalentes Zahlenwerkdie notwendige Grundlage des IAS-Konzernabschlusses ist (auch wenn derIAS-Einzelabschluss in den IAS selbst nicht gefordert wird). Die tatsächli-che Komplexität einer IAS-Implementierung liegt im Einzelabschluss. DieKonzernkonsolidierung erfolgt dann in einem üblichen Konsolidierungs-werkzeug.

Werteführung

Berichtswesen

Buchungssystematik

Geschäftsbestandsführung

Geschäftserfassung/-vorfälle

Bewertung

Hedge-Accounting

A

B B‘

B‘

B‘

C

C‘

D‘

D

E F


Marktein-schätzung vonIAS-Lösungen

Die beschriebene generische Architektur kann mit einem integrierten Soft-warepaket oder mit einzelnen Komponenten umgesetzt werden. Für dieUmsetzung mittels einer auf Einzelkomponenten basierenden Lösung bie-ten sich neben EAI-Tools (Enterprise Application Integration) für Extraktionund technische Standardisierung auch so genannte Regel-Maschinen fürValidierung, fachlichen Standardisierung und Buchungslogik an. Von Re-levanz sind ferner kommerzielle Bankdatenmodelle und Data-Warehouse-Lösungen für Datenpools (siehe Abschnitt 2.5.1). Abgerundet wird die Pa-lette der Einzelkomponenten durch Tools zur Unterstützung der finanz-mathematischen Methoden, General-Ledger-Systeme für das Hauptbuch,Berichtsgeneratoren sowie Konsolidierungstools.

Eine Reihe von Banken hat ihr IAS-Rechnungswesen auf der Basis solcherEinzelkomponenten entwickelt. Allerdings bedarf es dann besonderer, imAllgemeinen umfangreicher manueller Anstrengungen, die oben genann-ten strukturellen Anforderungen der IAS zu erfüllen.

Es existieren eine Reihe von Softwarepaketen, welche die Funktionen DataWarehousing/Operational Data Store und Bewertung für IAS anbieten.Hierbei handelt es sich im Allgemeinen um Pakete, die aus Risikomanage-mentsystemen o.ä. abgeleitet werden, und die demzufolge keine Buch-haltungsfunktionen enthalten. Es handelt sich also nicht um IAS-Rech-nungswesensysteme, sondern nur um IAS-Bewertungssysteme.

Vollständiges IAS-Rechnungswesen

Die SAP-IAS-Solution ist nach unserem Kenntnisstand die einzige inte-grierte Lösung, die sämtliche funktionalen Bausteine für ein IAS-Rech-nungswesen – insbesondere Bewertung und Buchhaltung – in sich vereint.Zudem ist die Abstimmung mit der Bilanz nach lokalem GAAP ein funda-mentaler Bestandteil der Lösung (Saldenzusammenführung), eine Funkti-onalität, die in dieser Form kein Konkurrenzprodukt aufzuweisen hat.

Weiterent-wicklung zurumfassendenMulti-GAAP-

Lösung

Die aktuelle IAS-Solution setzt in der üblichen Konstellation das Vorhan-densein einer vollständigen Bilanz im lokalen GAAP voraus. Sie behandeltzudem ausschließlich den Wertebereich der Bank. Die IAS-Buchhaltungdes Betriebsbereiches – soweit sie sich von der lokalen Bilanzierung un-terscheidet – muss daher zunächst noch separat (z.B. in SAP FI) erfolgenund dann mit der IAS-Bilanz des Wertebereichs integriert werden, wozuinsbesondere die in der Lösung enthaltene Saldenzusammenführung ge-nutzt werden kann.

Der SAP Balance Analyzer, dessen Bestandteil die IAS-Solution ist, wurdevon seiner Architektur her als ein Multi-GAAP-System angelegt. Dement-sprechend kann er in einem nächsten Ausbauschritt zu einer vollständigen


Bilanzierungslösung für alle gängigen Rechnungslegungsvorschriften(HGB, US-GAAP usw.) erweitert werden. Dabei sind lediglich die für an-dere GAAP benötigten Methoden zu ergänzen. Eine weitere Option be-steht in der Verzahnung von externem und internem Rechnungswesen(siehe Abschnitt 2.6.4).

2.6.3 Basel II-Lösung

Die Umsetzung der neuen Baseler Eigenkapitalrichtlinie (Basel II) ist aktuelleine der weitestreichenden Entscheidungen für Banken. Die Diskussionüber die technische Umsetzung und deren Kosten hat dabei in den Kre-ditinstituten streckenweise die Tatsache in den Hintergrund treten lassen,dass es sich für sie um eine strategische Weichenstellung mit Wettbewerb-sauswirkungen handelt. Die Wahl des Standardansatzes ist keine tragfä-hige Alternative für größere Häuser mit entsprechender Marktstellung, dasich die Verwendung eines ausgefeilten Ansatzes als essentiell für den Sta-tus und das Ansehen am Markt erweisen werden. Neben dem Regulatorselbst werden insbesondere Analysten und Ratingagenturen das Vorgehendes Unternehmens bewerten – mit entsprechenden Auswirkungen auf In-vestoren und den Kapitalmarkt für das Unternehmen. Die Anstrengungenzur Erfüllung der gesetzgeberischen Vorgaben von Basel II müssen gleich-zeitig auch für die Unterstützung der Geschäftsprozesse genutzt werden,wenn auch ein positiver geschäftlicher Effekt erreicht werden soll. Das er-fordert einen konsequenten Neuentwurf des regulatorischen Prozessesund die Nutzung der neuen Strukturen für die Kreditprozesse. Auf tech-nischer Ebene besteht zudem eine deutliche Überschneidung mit der Im-plementierung der IAS, vor allem bei der Schaffung eines Operational DataStore, was einen Ansatz zur Hebung von Synergien aufzeigt.

Erhöhte struktu-relle und funkti-onale Anforde-rungen

Die Einführung der neuen Eigenkapitalvereinbarung führt also in den Ban-ken zu einem weiteren Berichtswesen, das zudem, da es auf Einzelge-schäftsinformationen beruht, eine sehr hohe Granularität bezüglich derDatenhaltung und -verarbeitung bedeutet. Überdies sind im Bereich Kre-ditrisiken gleich zwei neue und strukturell verschiedene Anforderungen zuerfüllen:

� Integration, Speicherung und Verarbeitung komplexer Geschäftssach-verhalte für die regelmäßige Berechnung der Risk Weighted Assets zurErmittlung der Eigenkapitalunterlegung:

� Dazu muss der aktuelle Bestand an Aktivgeschäften bereit gestelltund Geschäft für Geschäft verarbeitet werden.


� Dies wiederum erfordert die Zusammenführung und Verarbeitungder Geschäftsdaten, zusammen mit den Kundenstammdaten, denBesicherungsbeziehungen sowie gegebenenfalls Nettingvereinba-rungen, d.h. eine Integration komplexer, bis dahin separater odernicht elektronisch geführter Informationsbestände.

� Die Speicherung historischer Zeitreihen von Geschäftsstammdaten und-attributen zusammen mit Einstufungen und Ausfalldaten, sowie diestatistische Verarbeitung dieser Zeitreihen für die Kalibrierung der inter-nen Modelle:

� Hier liegt die Anforderung in der Langzeitablage von möglicherweisesehr großen Zeitreihen und dem flexiblen und schnellen Zugriff aufdiese Zeitreihen und Ausschnitte daraus.

Ähnlich wie bei den IAS (siehe Abschnitt 2.6.2) sind diese Anforderungenzusammen mit weiteren generellen Anforderungen umzusetzen, die nichtneu sind, die jetzt aber durch die Vorschriften der Basler Übereinkunft di-rekt oder indirekt gefordert werden und entsprechend auszuprägen sind:

� Datenqualität und ProzesssicherheitDie neuen Basler Vorschriften stellen die Risikoermittlung hinsichtlichDatenqualität, Richtigkeit, Vollständigkeit und Nachvollziehbarkeitpraktisch den Daten und Prozessen des externen Rechnungswesensgleich. Das heißt, Datenvollständigkeit, Qualität und Konsistenz erlan-gen eine absolut kritische Bedeutung. Die technische und prozessualeStabilität muss damit zwingend hohe Priorität bei der Umsetzung vonBasel II haben.

� Flexibilität, Anpassungsfähigkeit, Robustheit und SkalierbarkeitAnders als sein Vorgänger wird der Basel II-Standard weitaus schnellererweitert und angepasst werden; entweder durch das Baseler Gremiumselbst oder durch die nationalen Gesetzgeber. Das Risikomesssystemder Banken muss sich diesen Veränderungen effizient anpassen lassenkönnen.

Erhöhte funkti-onale Anforde-

rungen durchBasel II

Basel II führt in den hier betrachteten IRB-Ansätzen als neues zentrales Ele-ment die einzelgeschäftsbezogene Ermittlung des notwendigen Eigenka-pitals ein. Hierbei werden ungleich komplexere Berechnungen als bishergefordert. Gleichzeitig bedeutet die Entwicklung und laufende Pflege in-terner Modelle einen Quantensprung in der mathematischen Komplexität,der bewältigt werden muss. Es besteht dann auch die Notwendigkeit,sämtliche Risikoinformationen zusammenzuführen und sowohl dem Re-gulator als auch dem Markt (überblicksweise) zur Verfügung zu stellen.


Funktionale Bausteine

Diese Anforderungen führen dazu, dass jede technische Basel II-System-lösung für das Kreditrisiko mindestens die in Abbildung 2.41 dargestelltenfunktionalen Blöcke enthalten muss.

Abbildung 2.41 Funktionale Blöcke der Kreditrisikomessung (©IBM Corporation 2003)

� A: Ablage aller relevanten Daten in der Datengrundlage der Kalkulation

� B: Der Kalkulationskern berechnet die Risikogewichtete Aktiva (RWA)in Abhängigkeit vom Ansatz.

� C: Speicherung relevanter Kalkulationsergebnisse und weiterer Infor-mationen in der Historiendatenbank, z.B. Ratings

� D:Versorgung interner Modelle mit historischen Zeitreihen für dieSchätzung von Parametern, z.B. PD

� E: Übergabe der erforderlichen Daten an ein Reportingtool

� F: Erzeugung der aufsichtlichen Meldungen, der Berichte für dieexterne Offenlegung sowie weiterer interner Berichte

� Nicht abgebildet: Limit Management, Portfolio Management, Manage-ment von Marktpreisrisiken etc.

Neben der unverändert notwendigen Kontrolle der Marktrisiken ist zu-sätzlich für die Messung des operationalen Risikos eine neue, im Vergleich

Basel II Datengrundlage Berichte

Geschäftspartnerdaten

Geschäftsdaten

Sicherheitendaten

Ratingdaten

Basel IIKalkulation

RWAsStandard/

IRB Ansätze

Histo-rischeDatenZeit-

reihen

Interne ModelleRating

PDLGDCCF

AufsichtlicheMeldungen

Offenlegung / internes Reporting

Datengrundlage

A

B C

C D

E

FF


zur Messung der Kredit- und Marktrisiken strukturell anders gearteteFunktionalität zu schaffen.

Marktein-schätzung von

Basel II-Lösungen

Einen Überblick über die logische Lösungsarchitektur einer umfassendenBasel II-Implementierung gibt die Abbildung 2.42.

Abbildung 2.42 Architekturelemente für eine Basel II-Lösung (© IBM Corporation 2003)

Derzeit arbeiten diverse Softwareanbieter an Basel II-Lösungen. Die jewei-ligen Lösungen befassen sich dabei mit den unterschiedlichsten Aspektenaus dem Basel II-Spektrum. Es gibt beispielsweise Lösungen für Kreditri-sikokalkulationen, für die Bestimmung der operationalen Risiken und fürinterne Modelle, d.h. statistische Methoden für die Schätzung der IRB-Pa-rameter PD, LGD und CCF.

Einschränkung aufKreditrisiko

Die Diskussion technischer Lösungsansätze sowie verschiedener Lösungs-pakete wird hier auf das Kreditrisiko beschränkt, da dieses den wichtigstenBereich darstellt. Das Management der Marktrisiken ist in den Banken zurZeit gelöst, und die Behandlung operationaler Risiken unterscheidet sichinhaltlich und technisch vollständig von der von Kreditrisiken. Insbeson-dere existieren in den Banken keine Systeme oder Front-Office-Anwen-dungen, die an ein System zu Verwaltung operationaler Risiken angebun-den werden müssten.

Abgrenzung unter-stützender

Systeme

Die Diskussion der Lösungsangebote für die Basel II-Kreditrisikomessungmuss sich daher über sechs Themenfelder erstrecken:

OperationalData store(konsolidiert)

Extraktion

Transformation& Kalkulation

Datenquellen

Data Marts HistorischerDatenbestand / Zeitreihen

Anwendungen / Berichtswesen

Operative und unterstützende Systeme

Kernbanken-systeme

KrediteSicherheiten

(CMS)

Extraktion, Konversion, Normierung, Prüfung, Transport, Import

BII Operational

Risk Verfahren

Rating

Verf.

BII Credit

Risk Verfahren

Melde-

wesen

Basel II Berichtswesen

Kundenstamm …

Interest Rate

Risk Verfahren

Kreditrisiko

Zinsrisiken

Operationale Risiken

Internal Credit

Risk Verfahren

Interne

Berichte

Ereignis-Datenbestand

Ergebnis-daten

Ergebnis-daten

Ergebnis-daten

Ergebnis-daten

PD

Verf.

LGD

Verf.

CCF

Verf.

Geschäftsdatenbestand


� Unterstützende Systeme für Basel II, wie Sicherheitenverwaltungs- undKundenstammsysteme

� Extraktions- und Transferwerkzeuge, die den Datenaustausch zwischenden einzelnen Komponenten der Basel II-Lösung leisten

� Operational Data Stores zur Bereitstellung der Geschäftsdaten für dieExposurekalkulation sowie die Speicherung der historischen Zeitreihen

� Basel II-Kreditrisikokalkulationskern einschließlich Sicherheitenzuord-nung zur Ermittlung der Eigenkapitalunterlegung

� Statistikwerkzeuge zur Entwicklung und Kalibrierung der internenModelle

� Berichtswerkzeuge

Von Bedeutung ist im Weiteren die Anforderung, die Kreditrisikomessungzu integrieren:

� In den gesamten Kredit- und Kreditportfolio-Management-Prozess derBank

� In ein technisch und prozessual möglichst einheitliches Managementsämtlicher Risiken der Bank

Die Systeme zur Sicherheitenverwaltung, Verwaltung von Nettingverein-barungen sowie die Kundenstammsysteme müssen zwar den Anforderun-gen von Basel II entsprechen, sie müssen jedoch unabhängig davon undaus eigener Notwendigkeit entwickelt und betrieben werden. Sie werdendaher hier nicht weiter betrachtet. Ebenso wird hier von einer Diskussionvon ETL-Werkzeugen sowie von Berichtswerkzeugen abgesehen, da es sichnicht um fachspezifische Produkte handelt.

Integration in zwei Richtungen

Die beschriebene Architektur kann mit einem integrierten Softwarepaketoder mit einzelnen Komponenten umgesetzt werden. Die am Markt be-obachteten Ansätze können anhand von zwei Integrationsdimensionenklassifiziert werden:

� Vertikale Integration Ist der typischerweise benötigte Operational Financial Data Storezusammen mit dem Kreditrisikokalkulationskern (und dem Berichtswe-sen) in einem Paket integriert?

� Horizontale Integration Ist die Kreditrisikokalkulation ein allein stehendes Produkt oderBestandteil eines fachlich breiteren Paketes?


Für den separaten Aufbau eines Financial Data Stores existieren Bankda-tenmodelle (z.B. IBM Banking Data Warehouse), die als Ausgangspunkt füreine Individualentwicklung dienen. Die vertikale Integration zu den Kal-kulationsverfahren, zugekaufte Spezialsoftware oder Eigenentwicklung,und eine etwaige horizontale Integration liegen dann vollkommen auf Sei-ten der Bank. Als Standardsoftware werden solche Financial Data Storesüblicherweise nur als Bestandteil einer integrierten Paketlösung für das Ba-sel II-Kreditrisiko oder andere Gesamtbanksteuerungsthemen angeboten.

Integrierte Pakete zur Basel II-Kreditriskomessung wiederum werden zur-zeit von einer Reihe von Herstellern angekündigt bzw. entwickelt. Prak-tisch ausnahmslos setzen die Hersteller dabei auf einer vorhandenen Soft-wareinfrastruktur auf und erweitern ein vorhandenes Softwarepaket. Beider Ausgangssoftware handelt es sich typischerweise um Pakete zumMarktpreis- und Kreditrisikomanagement oder Software mit Schwerpunktim Financial Accounting und in der Profitabilitätsmessung.

Als weitere Gruppe sind Analysesoftware, Statistikpakete und Reporting-anwendungen zu finden, bei denen das unterliegende Data Warehouseund die Auswertungsroutinen für das Bankrisikomanagement erweitertwurden. Die letzteren Pakete haben ihren Schwerpunkt eindeutig in derEntwicklung und Kalibrierung der internen Modelle sowie in der Zeitrei-henspeicherung.

Da eine abschließende Festschreibung der Anforderungen von Basel IInicht vor Ende des Jahres 2003 erfolgen wird, befinden sich alle angekün-digten Systeme noch im Entwicklungsstadium. Allerdings bestehen ganzerhebliche Unterschiede darin, wieweit die Produktkonzeption bereits de-tailliert wurde, welcher Stand der Programmierung tatsächlich erreicht istund vor allem, ob und wie viele Pilotbanken das entstehende Produkt ein-führen.

Bewertung derSAP-Basel II-

Lösung

Die SAP-Basel II-Lösung deckt aus dem für Basel II erforderlichen Spek-trum den Bereich Eigenkapitalunterlegung für das Kreditrisiko vollständigab. Sämtliche dafür erforderlichen Verarbeitungsschritte sind Bestandteilder SAP-Lösung. Daneben bietet sie mit ihrer Historiendatenbank einezentrale Plattform für den Aufbau der geforderten Zeitreihen und die Da-tenversorgung interner Modelle. Die Lösung wird durch die Financial Da-tabase (FDB) und die Berichtsweseninfrastruktur des SAP Bank Analyzersabgerundet, auf dessen Basis und als dessen Bestandteil sie entwickeltwird. Sie ist sowohl vertikal als auch horizontal in das gesamte SAP Bank


Analyzer-Konzept integriert und stellt eine umfassende Lösungsplattformfür das Basel II-Kreditrisikomanagement dar.

Die Lösung wird von SAP mit mehreren Pilotbanken entwickelt. Denmehrjährigen Entwicklungsfahrplan einhaltend, sind große Teile der Soft-ware bereits planmäßig erstellt und werden von den Pilotbanken getestetund eingeführt. Die Konzeption weiterer Funktionen erfolgt parallel zumEntwicklungsprozess von Basel II.

AusblickSo sind für das SAP Basel II-Release 4 (geplant für Ende 2004) beispiels-weise die Themen »Angekaufte Forderungen«, »Beteiligungen«, »Verbrie-fungen«, »Spezialfinanzierungen« und »Stresstests« vorgesehen. In derDiskussion befinden sich zudem die Erweiterung der Konsolidierungsfunk-tion über die für Release 4 vorgesehene Konsolidierungsunterstützung hi-naus sowie die tatsächliche Ausgestaltung der Schnittstelle von der FDBzum kompletten Meldewesen.

Erweiterung zur Kreditrisikolösung

Ein zentraler Punkt für die weitere Entwicklung sind der Aufbau und die In-tegration der SAP-Basel II-Lösung in eine allgemeine Kreditrisikolösung,gemeinsam mit Bausteinen wie dem SAP-Financial-Services-Geschäfts-partner oder SAP-Collateral-Management-System, und die Einbettungdieser Plattform in den gesamten Kreditprozess der Bank.

2.6.4 Der SAP Bank Analyzer als Integrationsplattform

Wie bereits in der Einleitung zum Abschnitt 2.5 dargestellt, wird die Er-kenntnis deutlicher, dass man die ständig wachsende fachliche Komplexi-tät der Banksteuerung technisch überhaupt nur noch durch eine grundle-gende Überarbeitung der Lösungsansätze zu einer integrierten Architekturadäquat wird abbilden und unterstützen können. Wesentliche Elementeder von IBM Business Consulting Services dafür empfohlenen und ver-wendeten Lösungsarchitektur sind im Schichtenmodell der Abbildung2.43 dargestellt. Es zeigt die grundsätzlichen Datenbestände und Funkti-onsblöcke eines Gesamtbanksteuerungssystems und ihre logische Grup-pierung in Schichten. Der logische Datenfluss von Geschäfts- und Trans-aktionsdaten zur Steuerungsinformation verläuft dabei durch dieSchichten von oben nach unten.


Abbildung 2.43 Schichtenmodell für Banksteuerungssysteme

Infrastruktur fürvertikale und

horizontaleIntegration

Mit dem SAP Bank Analyzer schafft SAP ein Produkt, dass von Beginn andarauf ausgelegt ist, ein Gesamtbanksteuerungssystem entsprechend die-ser Lösungsarchitektur – von den Schichten »Operational Data Store« bis»Berichtswesen« – umzusetzen:

� Eine einheitliche Datenbasis für alle BanksteuerungsaufgabenDie FDB übernimmt die Rolle des konsolidierten Operational DataStore; sie ist darauf ausgerichtet, sämtliche für die Banksteuerungsauf-gaben relevanten Bankgeschäftsdaten und weitere Informationen auf-zunehmen.

� Zusammenfassung aller bankfachlichen Methoden zur Bewertung,Kalkulation, Auswertung u.ä. in der Schicht »Transformation und Kal-kulation« und deren horizontale IntegrationDer SAP Bank Analyzer setzt bankfachliche Verfahren technisch nur ein-mal um. Dies und die Möglichkeit, Ergebnisse zwischen den Analyzernauszutauschen, stellt eine konsistente Implementierung und einheitli-che Verwendung der Verfahren sicher, auch wenn die Verfahren inunterschiedlichen fachlichen Kontexten und Zielrichtungen eingesetztwerden.

� Gemeinsame fachliche und technische InfrastrukturDer SAP Bank Analyzer schafft durch die einheitliche Datenmodellie-rung in der FDB, durch die einheitliche Nutzung der finanzmathemati-schen Verfahren sowie durch einheitliche Berichtswerkzeuge und gra-fische Oberflächen eine Integrationsplattform für die Gesamtbanksteu-erung. Auf der technischen Ebene zeigt sich der SAP Bank Analyzer als

Operative BanksystemeDatenquellen

Integriertes Berichtswesen, Decision Support Systeme, MIS

Buchungs-

daten

Bilanz

GuV

Extraktion, Konversion, Normierung, Prüfung, Transport, ImportExtraktion

Operational

Data Store

(konsolidiert)

Transformation &

Kalkulation

Data Marts

Anwendungen/

Berichtswesen

Allgemeine Transformations- und Kalkulationsverfahren

Geschäftsstamm,

Konditionen,

Bewegungsdaten

Szenarien ...

GAAP

methoden

Controlling-

methoden

Risikobewertungs-methoden

RegulatorischeMethoden

....

Kundenstammdaten

Bankstrukturdaten

Marktdaten

ALMmethoden

Controlling

Ergebnisse

Risikobewertungs-

Ergebnisse

ALM

DatenRegulatorische

Ergebnisse ....


Applikation auf dem durchgängigen technischen Standard der SAP-Basis-Plattform.

Wesentliches Teilziel erreicht

Mit den heute verfügbaren bzw. teilausgelieferten und in der Weiterent-wicklung befindlichen Lösungen ist ein wesentliches Teilziel in der von SAPverfolgten Strategie erreicht, den SAP Bank Analyzer als eine integrierteGesamtbanksteuerungsplattform aufzubauen. Mit der FDB als integrieren-der Datenplattform und den darauf aufsetzenden Lösungen für IAS undBasel II kann SAP die Tragfähigkeit des Konzepts beweisen.

Ausbau zur Gesamtbanksteu-erungslösung steht bevor

SAP wird den SAP Bank Analyzer um weitere Bestandteile der Banksteu-erung erweitern, wobei SAP auf das im SAP SEM Banking gesammelte An-wendungswissen aufbauen kann. Hier sind insbesondere das interne Rech-nungswesen und dessen Verbindung mit dem Balance Analyzer zu einemintegrierten Rechnungswesen sowie die Kreditrisikosteuerung zu nennen.

Documents

2 SAP Bank Analyzer im Überblick · 2014-02-17 · SAP Bank Analyzer im Überblick 73 ziehbar sein, d.h., die Eingangswerte, der finanzmathematische Ablauf ei-ner Methode, der Zeitpu