Vermögensverwaltungsfirmen, auch Finanzintermediäre genannt, betreuen das Wertschriftenportfolio von Firmen und Privatanlegern und erwirtschaften Gewinne durch den Handel mit Titeln an den
Finanzmärkten. Bislang geschieht dies vor allem in den kleinen und mittleren Institutionen noch vorwiegend durch manuelle Tätigkeiten, was Ineffizienzen, Fehl- und Doppelerfassungen sowie hohe Personalkosten zur Folge hat. Aus diesem Grund wurde im Rahmen eines Systemanalyse-Projekts untersucht, inwieweit der
Wertpapierhandel auf elektronischem Weg erfolgen kann, und welche betrieblichen und softwaretechnischen Voraussetzungen hierfür geschaffen werden müssen. Dies im Angesicht der Erkenntnis der durchgeführten Produktevaluation, die gezeigt hat, dass auf dem Schweizerischen Markt bislang keine nutzbringende und gleichzeitig bezahlbare IT-Lösung für kleinere Vermögensverwalter angeboten wird.
Inhaltsverzeichnis
1 Einleitung
1.1 Einführung in den Themenbereich Wertpapierverwaltung
1.1.1 Vermögensverwaltung und -handel als Kerngeschäft
1.1.2 Geringer Automatisierungsgrad bei Kleinunternehmen
1.1.3 Suboptimale Prozesse mit fehlender Softwareunterstützung
1.1.4 Folgerungen
1.2 Motivation und Auftrag
1.3 Fragestellung
1.4 Ziele der Arbeit
1.4.1 Sachziele
1.4.2 Persönliche Lernziele
1.5 Ansatz- und Schwerpunkte
1.5.1 Inhaltliche Themenschwerpunkte
1.5.2 Ansatz
1.5.3 Abgrenzung
1.5.3.1 Thematische Abgrenzung
1.5.3.2 Organisatorische Abgrenzung
1.5.3.3 Fachliche Abgrenzung
1.5.3.4 Markttechnische Abgrenzung
1.5.3.5 Methodische Abgrenzung
1.6 Überblick über die vorliegende Arbeit
2 Grundlagen
2.1 Begriffe
2.1.1 Fachterminologie
2.1.2 APMS – Asset Portfolio Management System
2.2 Standards
2.2.1 Der GIPS-Standard
2.2.2 Anforderungen und Relevanz
3 Methodik
3.1 Ausrichtung und empirische Überlegungen
3.2 Vorgehensmodell zur Projektdurchführung
3.2.1 Beschreibung und Diskussion
3.2.2 Projektcharakter, Scope und Phasen
3.2.2.1 Initialisierung
3.2.2.2 Voranalyse
3.2.2.3 Konzept
3.2.2.4 Realisierung
3.2.2.5 Einführung
3.2.2.6 Abschluss
3.2.2.7 Phasen-Entscheidungspunkte
3.3 Alternativmethoden zur Projektdurchführung
3.4 Vorgehensmodelle zur Systemrealisierung
3.4.1 Objektorientierte Analyse / objektorientiertes Design
3.4.2 Quasar
3.5 Systementwicklung als Kombination mehrerer Methodiken
3.6 Empirische Überlegungen
4 Voranalyse
4.1 Zielvereinbarung
4.1.1 Situationsanalyse
4.1.1.1 Beschreibung des Ist-Systems
4.1.1.1.1 Prozesse
4.1.1.1.2 Akteure
4.1.1.1.3 Mengen und Häufigkeiten
4.1.1.1.4 IT-Landschaft
4.1.1.2 Schwachstellenanalyse
4.1.1.3 Sicherheit
4.1.1.4 Zukünftige Entwicklungen und Trends
4.1.2 Systemziele
4.2 Lösungsauswahl
4.2.1 Systemanforderungen
4.2.1.1 Funktionale Anforderungen
4.2.1.1.1 Anwender / Rollen
4.2.1.1.2 Anwendungsfälle
4.2.1.2 Nicht-funktionale / attributive Anforderungen
4.2.1.3 Schnittstellen
4.2.1.4 Ausnahme- und Fehlerbehandlung
4.2.2 Lösungsvorschläge
4.2.2.1 Auswahl und Begründung
4.2.2.2 Lösungsbeschreibung
4.2.2.2.1 Lösungsansatz
4.2.2.2.2 Struktur des Systems und Lösungsbestandteile
4.2.2.2.3 Schnittstellen
4.2.2.2.4 Anforderungszuordnung
4.2.2.2.5 Realisierbarkeit
4.2.2.2.6 Sicherheit
4.2.3 Fazit
5 Konzept
5.1 Evaluation von Fertigprodukten
5.2 Detailstudie
5.2.1 Konzeptionelles Datenmodell
5.2.2 System-Architektur
5.2.2.1 Rolle der Architektur in der Systementwicklung
5.2.2.2 Architektur und Komponenten
5.2.2.3 Softwarekategorien
5.2.2.3.1 Konzentration von fachlichem Wissen mittels Kategorien
5.2.2.3.2 Von Kategorien zu Komponenten
5.2.2.3.3 Kommunikation zwischen Komponenten unterschiedlicher Kategorien
5.2.2.3.4 Kombination und Transformation unterschiedlicher Kategorien
5.2.2.3.5 Standardkategorien
5.2.2.3.6 APMS-Softwarekategorien
5.2.2.4 Nutzungsbeziehungen, Koppelung und Schnittstellen
5.2.2.5 Konfiguration und Dependency Injection
5.2.2.6 Architekturmetapher
5.2.2.6.1 Das Schichtenmodell
5.2.2.6.2 Kritik
5.2.2.6.3 Schlussfolgerung: Metapher als Ordnungskriterium
5.2.2.7 Architekturstil
5.2.2.8 Unterteilung und Abgrenzung
5.2.2.9 Anwendungskern und Anwendungskomponenten
5.2.2.9.1 Theoretische Betrachtung
5.2.2.9.2 APMS Anwendungsarchitektur
5.2.2.9.3 Realisierungsscope
5.2.2.10 Bezug zum Datenmodell
5.2.2.11 Bezug zum Schichtenmodell
5.2.2.11.1 Allgemeine Überlegungen zu Komponentenstruktur und Schichtung
5.2.2.11.2 Zusammenhang von Quasar und Dreischichtenarchitektur
6 Realisierung
6.1 Struktur
6.1.1 Konventionen
6.1.1.1 Darstellung
6.1.1.2 Namensgebung
6.1.1.3 Struktur
6.1.2 Komponente Assethandel
6.1.3 Komponente Datenprüfung
6.1.4 Komponente Verbuchung
6.2 Verhalten
7 Diskussion und Ausblick
7.1 Beantwortung der Fragestellung
7.2 Zielerreichung
7.2.1 Sachziele
7.2.2 Persönliche Lernziele
7.3 Erkenntnisse
7.3.1 Projekt-Methodik
7.3.1.1 Praxistaugliche, skalierbare Instrumente sind anwendbar
7.3.1.2 Planung ist zentral
7.3.1.3 Unklare Gliederung und Begriffswahl führen zu Inkonsistenz
7.3.1.4 Lineare Zielorientierung und Agilität sind kein Gegensatz
7.3.1.5 Qualitätsansprüche kosten Zeit
7.3.1.6 Generalismus fördert das Denken im Grossen, belastet jedoch die Effizienz
7.3.2 Architektur und Systemdesign
7.3.2.1 Es gibt keine kleinen Software-Projekte
7.3.2.2 Es gibt keine implizite Architektur
7.3.2.3 Es gibt keine Kreativität beim Entwurf von Architektur und Software-Design
7.3.2.4 Ordnung muss sein – in vernünftigem Mass
7.3.2.5 Standards in Ehren – aber bitte mit gesundem Menschenverstand
Zielsetzung & Themen
Die Arbeit untersucht, wie der Prozess des Wertpapierhandels bei kleinen bis mittelgroßen Vermögensverwaltern, der heute durch manuelle Tätigkeiten und Ineffizienzen geprägt ist, durch eine technisch fundierte, elektronische Lösung optimiert werden kann, um eine vollautomatisierte Abwicklung zu ermöglichen.
- Prozessanalyse und Optimierung des "Handel"-Kernprozesses
- Entwicklung einer skalierbaren, technikneutralen Software-Architektur basierend auf dem Quasar-Ansatz
- Erarbeitung von Systemanforderungen und Datenmodellen für ein Asset Portfolio Management System (APMS)
- Kritische Reflexion von Projektmanagement-Methoden (Hermes) und Architektur-Stilen in der Praxis
Auszug aus dem Buch
6.1.2 Komponente Assethandel
Die Komponente Assethandel ist das Kernstück und gleichzeitig das komplexeste Teilsystem der Anwendung, da sie die eigentliche Handelsfunktionalität implementiert und somit auf praktisch allen Finanz-Anwendungskomponenten aufbaut. Hier erfolgt die Abwicklung von einfachen und mehrfachen Handelsaktionen (d.h. Handel über mehrere Depots). Gemäss oben definierter Konvention wird die Struktur massgeblich mittels Schnittstellen spezifiziert und durch realisierende Klassen implementiert.
Der Eintrittspunkt der Komponente ist das aus einem oder mehreren Assets bestehende Handelsgeschäft, modelliert durch das Interface IAssetHandel. Die Schnittstelle ist die einzige Nicht-Entität der Komponente und stellt die grundlegende Funktionalität für den Wertschriftenhandel bereit. Jede Handels-Instanz aggregiert über die Methode GetAssets 1 bis N gehandelte Wertpapiere, also Assets, vom Typ IAsset. Die wertmässige Summe der einzelnen Handelsobjekte wird von der Methode GetHandelsvolumen berechnet. Jedem Handelsgeschäft ist ein verantwortlicher Asset-Manager vom Typ IAssetManager zugeteilt, der über die Methode GetManager abgefragt wird.
Zur Handelsfunktionalität gehören des Weiteren die beiden statischen Methoden GetDepots und CreateAsset (im verwendeten UML-Tool leider nicht als statisch markierbar). GetDepots bietet die Möglichkeit zur Suche derjenigen Depots, die einen bestimmten Titel (Typ ITitel) enthalten und eine oder mehrere Eigenschaften eines bestimmten Werts aufweisen (IAssetEigenschaft). Zum anderen übernimmt die IAssetHandel-Schnittstelle auch die Instanziierung der einzelnen Asset-Objekte über die Fabrikmethode CreateAsset, d.h. entsprechende Instanzen lassen sich von aussen nicht direkt über die Asset-Klasse erzeugen, was zur komponenteninternen Entkopplung beträgt.
Interessanterweise greift die implementierende Klasse AssetHandel nicht auf die IPool-Schnittstelle des Persistenzmanager zu, was sich durch das zugrundeliegende Datenmodell erklären lässt: Da sich aus fachlicher bzw. bankenrechtlicher Sicht sämtliche Handelsgeschäfte immer auf genau ein Depot und einen Titel beziehen und ein „Handel über mehrere Depots“ nur in elektronischer Form existiert, werden die entsprechenden Datensätze ebenfalls einzeln abgespeichert (siehe 5.2.1).
Zusammenfassung der Kapitel
1 Einleitung: Beschreibt die Ausgangslage, die Ineffizienzen im manuellen Wertpapierhandel und die Zielsetzung für eine elektronische Branchenlösung.
2 Grundlagen: Definiert die zentrale Fachterminologie sowie den GIPS-Standard, der für die Vermögensverwaltung eine wichtige Rolle spielt.
3 Methodik: Erläutert die Wahl des Hermes-Vorgehensmodells für das Projekt und den Einsatz von objektorientierten sowie komponentenorientierten Ansätzen (Quasar) für den Entwurf.
4 Voranalyse: Analysiert den Ist-Prozess und die Schwachstellen, um Anforderungen und Lösungsansätze für ein neues System abzuleiten.
5 Konzept: Erarbeitet ein konzeptionelles Datenmodell und eine robuste Systemarchitektur basierend auf dem Quasar-Konzept und dem Schichtenmodell.
6 Realisierung: Spezifiziert die Systemarchitektur im Detail durch UML-Klassendiagramme für die Kernkomponenten Assethandel, Datenprüfung und Verbuchung.
7 Diskussion und Ausblick: Reflektiert die methodischen Erfahrungen, validiert die Zielerreichung und diskutiert Erkenntnisse zu Architektur und Design.
Schlüsselwörter
Vermögensverwaltung, Wertpapierhandel, IT-System, Systemarchitektur, Quasar, Hermes, Prozessoptimierung, Automatisierung, Software-Design, Datenmodellierung, UML, Finanzdienstleister, Komponentenorientierung, Wartbarkeit, Schnittstellen
Häufig gestellte Fragen
Worum geht es in dieser Masterarbeit?
Die Arbeit befasst sich mit der technischen Konzeption eines elektronischen Wertschriftenportfoliomanagementsystems (APMS), um manuelle, ineffiziente Prozesse bei kleinen bis mittleren Vermögensverwaltern zu automatisieren.
Welche zentralen Themenfelder behandelt die Arbeit?
Die Arbeit umfasst die Prozessanalyse des Wertpapierhandels, die Modellierung von Datenstrukturen, den Entwurf einer skalierbaren Softwarearchitektur und die praktische Anwendung von Software-Engineering-Methoden.
Was ist das primäre Ziel der Arbeit?
Das Ziel ist die Erstellung eines exemplarischen Systemdesigns, das als Grundlage für die spätere technische Realisierung einer IT-Branchenlösung dienen soll, um Effizienzsteigerungen durch Automatisierung zu erreichen.
Welche wissenschaftlichen Methoden werden verwendet?
Das Projekt folgt dem phasenorientierten Hermes-Vorgehensmodell des Bundes. Für die Systemkonzipierung kommen objektorientierte und komponentenbasierte Ansätze wie OOA/OOD und die Quasar-Methodik zur Anwendung.
Was wird im Hauptteil behandelt?
Der Hauptteil gliedert sich in eine detaillierte Voranalyse der Geschäftsprozesse, die Konzeption eines Datenmodells sowie die Entwicklung einer Softwarearchitektur, die abschließend in konkrete Systemdesign-Diagramme (UML) für zentrale Komponenten überführt wird.
Welche Keywords charakterisieren die Arbeit?
Zentrale Begriffe sind Wertpapierverwaltung, Prozessoptimierung, Softwarearchitektur, Quasar, Hermes, Automatisierung, Finanzdienstleister und Modellierung.
Warum reicht ein einfaches System nicht aus?
Viele kleine Finanzdienstleister nutzen zwar einzelne Access-Datenbanken, doch diese sind nicht vernetzt, verursachen Medienbrüche und können den modernen Anforderungen an Automatisierung, Standardisierung und Revisionssicherheit nicht gerecht werden.
Wie löst das System das Problem der Medienbrüche?
Durch eine durchgängige elektronische Abwicklung (Web-Applikation), die Schnittstellen zu den Banken zur automatisierten Einlesung von Bankbelegen nutzt und somit manuelle Erfassungsschritte eliminiert.
Warum spielt der "Realisierungsscope" eine so große Rolle?
Der Scope konzentriert sich auf die ergebnisträchtigsten Elemente (Assethandel, Datenprüfung, Verbuchung), um sicherzustellen, dass die Architektur auch bei einer schrittweisen Umsetzung stabil und wartbar bleibt.
Inwiefern beeinflusst der GIPS-Standard das Design?
Obwohl sich die Arbeit primär auf die interne Effizienz konzentriert, dient GIPS als wichtiger Qualitätsstandard, dessen Einhaltung dem System eine hohe Marktrelevanz und Firmen-Transparenz verleiht.
- Quote paper
- Anonym (Author), 2009, Elektronisches Wertschriftenportfoliomanagementsystem, Munich, GRIN Verlag, https://www.grin.com/document/153909
