Management Summery

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.

Die Projektdurchführung wurde nach dem phasenorientierten Hermes-Vorgehensmodell des Bundes geplant und strukturiert. Innerhalb der Konzept- und der Realisierungsphase kamen ergänzend objekt-und komponentenorientierte Ansätze nach den Methodiken OOA / OOD und Quasar zum Einsatz. Ziel war dabei nicht die Erstellung einer lauffähigen Software, sondern lediglich dessen Konzeption bis auf Stufe System-Design.

Im Rahmen der Voranalyse wurde anhand eines Fallbeispiels aus der langjährigen Branchenerfahrung des Auftraggebers eine Situationsanalyse durchgeführt, welche gravierende Schwachstellen insbesondere hinsichtlich der im heutigen System unvermeidlichen Medienbrüche, manuellen Datenprüfungen und hohen Betriebskosten zu Tage führte. Daraus ableitend wurden Anforderungen an ein zu entwickelndes Neusystem erarbeitet, wobei der Fokus auf den fachlichen bzw. funktionalen Erfordernissen lag, welche gemäss den gewonnenen Erkenntnissen oft entscheidender sind als die rein technisch zu lösenden Anforderungen.

Als Hauptziel einer entsprechenden Branchenlösung wurde die möglichst vollständig elektronische Abwicklung eines noch zu optimierenden Handelsprozesses inklusive automatisierter Datenprüfung erkannt. Dessen Erreichung soll die Marktposition der betroffenen Institutionen verbessern durch entscheidende Wettbewerbsvorteile hinsichtlich der aktuellen Trends in der Finanzbranche: Kostendruck, Standardisierungszwang, Revisionspflicht und zunehmende internationale Konkurrenz. Es konnte dargestellt werden, dass eine Neuentwicklung realisierbar und wirtschaftlich ist, wobei bestimmte technische Einzelheiten weiterführender Abklärungen bedürfen. Dies betrifft insbesondere den Import der elektronischen Bankdaten aus den jeweiligen Fremdsystemen, welche für eine vollständige Automatisierung des Handelsablaufs zwingend erforderlich sind. Der daraus abgeleitete Lösungsvorschlag basiert auf einer Optimierung des Handelsprozesses einerseits und dessen Elektronifizierung im Rahmen einer web-basierten Client-Server-Anwendung anderseits. Die Detailstudie brachte ein vollständiges konzeptionelles Datenmodell sowie die darauf aufbauende Anwendungsarchitektur hervor. Zu deren Modellierung wurde das ergebnisorientierte Konzept der Softwarekategorien angewendet, das eine Unterteilung des Gesamtsystems in disjunkte Wissenskategorien anstrebt, dadurch massgeblich die Komponentenbildung erleichtert und zu einer besseren Kontrolle der systeminternen Abhängigkeiten führt, was letztlich Voraussetzung für eine hohe Wartbarkeit, Weiterentwickelbarkeit und Wiederverwendbarkeit der Systemkomponenten ist. In diesem Zusammenhang wurde auch auf die Wichtigkeit von Schnittstellen zur Entkopplung und zur konsequenten Trennung von Zuständigkeiten im Entwicklungsprozess hingewiesen.

Der Weiteren konnte aufgezeigt werden, wie sich die verbreitete Metapher der Mehrschichtenarchitektur vorteilbringend in den komponentenorientierten Architekturstil integrieren lässt, indem die Schichtung der Komponenten als zusätzliches Ordnungskriterium verwendet und gleichzeitig zur Validierung der entworfenen Komponentenstruktur herangezogen wird. In einer ersten Ausbaustufe des Systems wurde für die technische Systemspezifikation der Fokus auf die ermittelten Kernkomponenten gelegt. Zu diesen konnte jeweils eine schnittstellenorientierte Klassenstruktur entwickelt und beschrieben werden, welche sich an den Richtlinien der Qualitätssoftwarearchitektur (Quasar) orientiert. Die Modellierung des Verhaltens bzw. der dynamischen Interaktion zwischen den Anwendungskomponenten ergänzt das System-Design. Die Erkenntnisse aus der Arbeit wurden ausgewertet und kritisch hinterfragt. Daraus konnten Praxisempfehlungen für künftige Systementwicklungen hinsichtlich Projektmethodik, Architektur-Modellierung und System-Design abgeleitet werden. Als Fazit wurde festgestellt, dass selbst fundierte und praxiserprobte Ansätze immer in Hinblick auf die jeweiligen Anforderungen geprüft und zugeschnitten werden müssen, um zielführend und letztlich auch wirtschaftlich umgesetzt werden zu können, und dass in diesem Zusammenhang insbesondere der ingenieurmässigen, industrialisierten Softwareentwicklung ein grosser, auch heute noch leider oft unterschätzter Stellenwert zukommt.

APMS  Asset Portfolio Management System  

Inhaltsverzeichnis

Management  Summery  4

Inhaltsverzeichnis   6

Abbildungsverzeichnis   9

1  Einleitung  10

1.1  Einführung in den Themenbereich Wertpapierverwaltung.  10

1.1.1  Vermögensverwaltung und -handel als Kerngeschäft.  10

1.1.2  Geringer Automatisierungsgrad bei Kleinunternehmen  10

1.1.3  Suboptimale Prozesse mit fehlender Softwareunterstützung.  11

1.1.4  Folgerungen.  11

1.2  Motivation und Auftrag  11

1.3  Fragestellung  12

1.4  Ziele der Arbeit.  12

1.4.1  Sachziele  12

1.4.2  Persönliche Lernziele  13

1.5  Ansatz- und Schwerpunkte  13

1.5.1  Inhaltliche Themenschwerpunkte  13

1.5.2  Ansatz  13

1.5.3  Abgrenzung.  14

1.5.3.1  Thematische Abgrenzung  14

1.5.3.2  Organisatorische Abgrenzung  14

1.5.3.3  Fachliche Abgrenzung  14

1.5.3.4  Markttechnische Abgrenzung  14

1.5.3.5  Methodische Abgrenzung  14

1.6  Überblick über die vorliegende Arbeit  15

2  Grundlagen  16

2.1  Begriffe  16

2.1.1  Fachterminologie  16

2.1.2  APMS - Asset Portfolio Management System  17

2.2  Standards  18

2.2.1  Der GIPS-Standard.  18

2.2.2  Anforderungen und Relevanz  18

3  Methodik.  19

3.1  Ausrichtung und empirische Überlegungen  19

3.2  Vorgehensmodell zur Projektdurchführung.  19

3.2.1  Beschreibung und Diskussion  19

3.2.2  Projektcharakter, Scope und Phasen  20

3.2.2.1  Initialisierung  20

3.2.2.2  Voranalyse  20

3.2.2.3  Konzept  20

3.2.2.4  Realisierung  20

3.2.2.5  Einführung.  20

3.2.2.6  Abschluss.  20

3.2.2.7  Phasen-Entscheidungspunkte  21

3.3  Alternativmethoden zur Projektdurchführung.  21

3.4  Vorgehensmodelle zur Systemrealisierung  21

   6/81

APMS  Asset Portfolio Management System  

3.4.1  Objektorientierte Analyse / objektorientiertes Design.  21

3.4.2  Quasar  22

3.5  Systementwicklung als Kombination mehrerer Methodiken  22

3.6  Empirische Überlegungen.  22

4  Voranalyse  23

4.1  Zielvereinbarung  23

4.1.1  Situationsanalyse.  23

4.1.1.1  Beschreibung des Ist-Systems  23

4.1.1.1.1  Prozesse.  23

4.1.1.1.2  Akteure  25

4.1.1.1.3  Mengen und Häufigkeiten.  25

4.1.1.1.4  IT-Landschaft.  26

4.1.1.2  Schwachstellenanalyse.  27

4.1.1.3  Sicherheit  27

4.1.1.4  Zukünftige Entwicklungen und Trends.  27

4.1.2  Systemziele.  28

4.2  Lösungsauswahl  28

4.2.1  Systemanforderungen  28

4.2.1.1  Funktionale Anforderungen.  29

4.2.1.1.1  Anwender / Rollen  29

4.2.1.1.2  Anwendungsfälle  29

4.2.1.2  Nicht-funktionale / attributive Anforderungen.  30

4.2.1.3  Schnittstellen.  30

4.2.1.4  Ausnahme- und Fehlerbehandlung.  30

4.2.2  Lösungsvorschläge.  30

4.2.2.1  Auswahl und Begründung.  30

4.2.2.2  Lösungsbeschreibung  30

4.2.2.2.1  Lösungsansatz  31

4.2.2.2.2  Struktur des Systems und Lösungsbestandteile  31

4.2.2.2.3  Schnittstellen  34

4.2.2.2.4  Anforderungszuordnung  34

4.2.2.2.5  Realisierbarkeit.  35

4.2.2.2.6  Sicherheit.  36

4.2.3  Fazit  36

5  Konzept  37

5.1  Evaluation von Fertigprodukten  37

5.2  Detailstudie  37

5.2.1  Konzeptionelles Datenmodell  37

5.2.2  System-Architektur  42

5.2.2.1  Rolle der Architektur in der Systementwicklung  42

5.2.2.2  Architektur und Komponenten  42

5.2.2.3  Softwarekategorien  43

5.2.2.3.1  Konzentration von fachlichem Wissen mittels Kategorien  43

5.2.2.3.2  Von Kategorien zu Komponenten  43

5.2.2.3.3  Kommunikation zwischen Komponenten unterschiedlicher Kategorien  43

5.2.2.3.4  Kombination und Transformation unterschiedlicher Kategorien  44

5.2.2.3.5  Standardkategorien  44

5.2.2.3.6  APMS-Softwarekategorien  45

5.2.2.4  Nutzungsbeziehungen, Koppelung und Schnittstellen  46

5.2.2.5  Konfiguration und Dependency Injection  46

   7/81

APMS  Asset Portfolio Management System  

5.2.2.6  Architekturmetapher.  47

5.2.2.6.1  Das Schichtenmodell.  47

5.2.2.6.2  Kritik.  47

5.2.2.6.3  Schlussfolgerung: Metapher als Ordnungskriterium  47

5.2.2.7  Architekturstil.  48

5.2.2.8  Unterteilung und Abgrenzung  48

5.2.2.9  Anwendungskern und Anwendungskomponenten  50

5.2.2.9.1  Theoretische Betrachtung  50

5.2.2.9.2  APMS Anwendungsarchitektur.  50

5.2.2.9.3  Realisierungsscope  52

5.2.2.10  Bezug zum Datenmodell  52

5.2.2.11  Bezug zum Schichtenmodell.  54

5.2.2.11.1  Allgemeine Überlegungen zu Komponentenstruktur und Schichtung.  54

5.2.2.11.2  Zusammenhang von Quasar und Dreischichtenarchitektur  54

6  Realisierung.  57

6.1  Struktur.  57

6.1.1  Konventionen  57

6.1.1.1  Darstellung  57

6.1.1.2  Namensgebung.  58

6.1.1.3  Struktur.  58

6.1.2  Komponente Assethandel.  59

6.1.3  Komponente Datenprüfung.  62

6.1.4  Komponente Verbuchung  64

6.2  Verhalten  64

7  Diskussion und Ausblick  67

7.1  Beantwortung der Fragestellung.  67

7.2  Zielerreichung  68

7.2.1  Sachziele  68

7.2.2  Persönliche Lernziele  69

7.3  Erkenntnisse  69

7.3.1  Projekt-Methodik.  70

7.3.1.1  Praxistaugliche, skalierbare Instrumente sind anwendbar  70

7.3.1.2  Planung ist zentral.  70

7.3.1.3  Unklare Gliederung und Begriffswahl führen zu Inkonsistenz  70

7.3.1.4  Lineare Zielorientierung und Agilität sind kein Gegensatz.  71

7.3.1.5  Qualitätsansprüche kosten Zeit  72

7.3.1.6  Generalismus fördert das Denken im Grossen, belastet jedoch die Effizienz.  72

7.3.2  Architektur und Systemdesign  73

7.3.2.1  Es gibt keine kleinen Software-Projekte  73

7.3.2.2  Es gibt keine implizite Architektur  74

7.3.2.3  Es gibt keine Kreativität beim Entwurf von Architektur und Software-Design  75

7.3.2.4  Ordnung muss sein - in vernünftigem Mass  75

7.3.2.5  Standards in Ehren - aber bitte mit gesundem Menschenverstand.  76

Literaturverzeichnis   77

B  ücher und Zeitschriftenartikel.  77

Online  -Quellen  78

Anhang   79

A.  Projektplan.  79

B.  Nicht-funktionale / attributive Anforderungen  80

   8/81

APMS  Asset Portfolio Management System  

Abbildungsverzeichnis   

Abbildung  3-1: Hermes Projekt-Phasen  

Abbildung  4-1: Gesamtprozess Handel.  

Abbildung  4-2: Detail-IST-Prozess Handel.  

Abbildung  4-3: Struktur der Anforderungen.  

Abbildung  4-4: Prozessoptimierung mit Elektronifizierung.  

Abbildung  4-5: APMS Systemübersicht  

Abbildung  5-1: APMS Entitäten-Relationen-Diagramm  

Abbildung  5-2: Standardkategorien im Kategoriengraph  

Abbildung  5-3: APMS Software-Kategorien  

Abbildung  5-4: Drei-Schichten-Architektur  

Abbildung  5-5: Unterteilung der System-Architektur  

Abbildung  5-6: APMS Anwendungsarchitektur als Komponentenstrukturdiagramm (UML 1.4)  

Abbildung  5-7: Segmentierung des Datenmodells anhand der Anwendungskomponenten.  

Abbildung  6-1: Struktur der Komponente Assethandel als Klassendiagramm (UML 1.4)  

Abbildung  6-2: Struktur der Komponente Datenprüfung als Klassendiagramm (UML 1.4)  

Abbildung  6-3: Struktur der Komponente Verbuchung als Klassendiagramm (UML 1.4)  

Abbildung  6-4: Gesamter Handelsprozess als Aktivitätsdiagramm (UML 1.4)  

1 Einleitung

1.1 Einführung in den Themenbereich Wertpapierverwaltung

1.1.1 Vermögensverwaltung und -handel als Kerngeschäft

Die Finanzbranche ist neben ihren Hauptdarstellern, den Banken, konstituiert durch zahlreiche Finanzdienstleister oder im Fachjargon Finanzintermediäre unterschiedlichster Couleur, etwa Berater für Firmen und Privatpersonen, und allen voran: Vermögensverwaltungsfirmen. Finanzintermediäre im Bereich der Verwaltung von Geldern, genauer gesagt Wertpapieren oder Wertschriften, von Klein- bis Grossanlegern sichern den Vermögungserhalt und -zuwachs ihrer Kunden und somit ihren eigenen Gewinn durch den Handel mit Titeln an den Finanzmärkten. Sie arbeiten in der Regel mit einem oder mehreren Händlern, den sogenannten Brokern, zusammen, welche ihrerseits im Auftrag des jeweiligen Vermögensverwalters die diversen Geldtransfergeschäfte, den eigentlichen Handel, durchführen. Die Gesamtheit der einzelnen Wertschriften eines Kunden, dessen Portfolio, führt der Vermögensverwalter in Form eines Depots.

1.1.2 Geringer Automatisierungsgrad bei Kleinunternehmen

Die Zusammenarbeit zwischen Finanzintermediären, Händlern und Kunden sowie die eigentlichen Wertpapiergeschäfte sind in der Schweiz heute weitgehend durch De-jure- und De-facto-Standards reguliert. Das bedeutet, dass der Spielraum der Geschäftstätigkeiten von Vermögensverwaltungsinstitutionen durch rechtliche Rahmenbedingungen sowie in der Branche allgemein anerkannte Richtlinien weitgehend vordefiniert - man könnte auch sagen: industrialisiert - ist. Im Gegensatz dazu zeigt sich bei der praktischen Durchführung der einzelnen Verwaltungs- und Handelsaktionen eine grosse Spannweite: Während bei grösseren Finanzunternehmen heute vorwiegend umfangreiche und entsprechend kostspielige IT-Systeme zum Einsatz kommen und fast den gesamten Handelsprozess automatisiert abwickeln, arbeiten vor allem die kleinen Vermögensverwalter noch weitgehend manuell. So werden vielerorts handgeschriebene Fichen mit relevanten Kunden- und Wertpapierdaten zwischen den am Handel beteiligten Parteien weitergereicht, die übrigen Handelstätigkeiten werden mittels Telefonaten erledigt. Lediglich bei der Verwaltung der Kundenangaben lässt sich auch bei kleineren Finanzintermediären eine gewisse Tendenz zur Elektronifizierung erkennen, welche meist durch einfache, monolithische Datenbankapplikationen (etwa in MS Access) ohne Vernetzung erreicht wird. Solche Systeme erleichtern zwar das Wiederfinden und die Aggregation von Finanz- und Kundendaten, stellen aber aufgrund der unvermeidlichen Medienbrüche zwischen manuell verarbeiteten Fichen und elektronischen Marktinformationen keine durchgängige Softwareunterstützung bereit, wie dies nur bei teuren prozessintegrierenden Grosssystemen teilweise der Fall ist. Das Resultat und die Kernproblematik dieser mangelnden Automatisierung bei kleineren Vermögensverwaltern sind grosse Effizienzverluste und hohe Personalkosten.

Eine Anbindung an die professionellen IT-Systeme der grossen Finanzintermediäre ist in den meisten Fällen aus Kostengründen nicht möglich. Und für Kleinfirmen erschwingliche Branchensoftware ist zumindest im Schweizer Finanzmarkt praktisch inexistent. Es herrscht sozusagen ein akuter Mangel an skalier- und vor allem bezahlbarer Wertschriftenportfoliomanagement-Software für kleine bis mittlere Vermögensverwaltungsinstitutionen.

1.1.3 Suboptimale Prozesse mit fehlender Softwareunterstützung

Bei der Business-Analyse kleiner Finanzintermediäre zeigt sich, dass nicht nur durchgängige IT-Systeme fehlen, sondern dass diese überhaupt erst eingesetzt werden könnten, wenn die Kernprozesse der betreffenden Unternehmen entsprechend umgestaltet würden. Denn wie bereits angetönt herrscht bei Kleinbetrieben heute vielfach noch mangelnde Industrialisierung bzw. Standardisierung bei der Abwicklung des Handels- und Verwaltungsprozesses vor, sodass eine Elektronifizierung mittels adäquater Softwareunterstützung die vorgängige Straffung und Optimierung der bestehenden Prozessstrukturen voraussetzt.

1.1.4 Folgerungen

Zusammenfassend kann die aktuelle Situation von kleinen und mittleren Vermögensverwaltungsinstitutionen durch zwei zentrale Feststellungen betriebswirtschaftlich und software-bezogen beschrieben werden:

1. Der Handelsprozess ist kaum automatisiert und stark von manuellen Tätigkeiten mit entsprechend hohen Fehlerraten, Mehrfacherfassungen und Personalkosten geprägt. 2. Der Schweizerische Markt bietet praktisch keine nutzbringende und gleichzeitig bezahlbare IT-Lösung zur integralen Prozessunterstützung für Klein- und Mittelunternehmen, die obigem Problem zumindest von technischer Seite her entgegenwirken könnte.

Dieser Befund stellt den Ansatzpunkt der vorliegenden Arbeit dar, welcher im Folgenden mittels konkreter Fragestellungen und Zielsetzungen genauer umrissen wird.

1.2 Motivation und Auftrag

Der Auftraggeber der vorliegenden Arbeit, die Finalsolution GmbH, ist eine in der Zentralschweiz positionierte Unternehmensberatung mit Sitz in Zug. Die Kleinfirma entwickelt individuelle Lösungen mit und ohne Software-Unterstützung. Zu ihrer Kundschaft gehören nebst Unternehmen aus unterschiedlichen Branchen auch Finanzintermediäre - derer es im Kanton Zug nicht gerade mangelt. Für einen langjährigen Kunden im Bereich Vermögensverwaltung hatte die Finalsolution vor mehreren Jahren drei verknüpfte MS Access Applikationen zur Verarbeitung und Verwaltung von Wertpapierdepots entwickelt, die gemäss damaligem Kundenwunsch als Stand-alone-Lösungen konzipiert wurden. Die über die Jahre historisch gewachsenen Einzelsysteme bieten auch heute weder Mehrplatzfähigkeit noch Schnittstellen zu Banksystemen oder Inter-/Extranet-Portalen, welche die Zusammenarbeit mit den verschiedenen Brokern (Händlern) bzw. mit den Kunden massiv erleichtern würden.

Aus diesem Grunde erfolgen viele Arbeitsabläufe manuell ausserhalb des elektronischen Systems. So erfassen die einzelnen Broker die (meist mehrteiligen) Fichen noch von Hand auf Papier, diese müssen anschliessend durch eine zweite Person ins bestehende System eingetippt werden. Des Weiteren haben sich auch die fachlichen Anforderungen der beim Kunden vorhandenen Business-Prozesse im Verlauf der Zeit verändert und intensiviert, was die drei Teilsysteme an die Grenze ihrer Möglichkeiten gebracht hat, sodass ein weiterer Ausbau nur mit grossem Aufwand und hohen Kosten möglich wäre. Dieses Szenario stellt gemäss den Branchenerfahrungen der Finalsolution - und wie bereits oben erläutert - bei weiterem kein Einzelfall dar.

Da die Finalsolution das Vermögensverwaltungsgeschäft und die typischen Abläufe / Prozesse des Wertschriftenhandels durch die langjährige Zusammenarbeit mit ihren Kunden gut kennt, wurde sie beauftragt, mit einem ganzheitlichen Ansatz Vorschläge aufzuzeigen, wie und wo man effiziente Rationalisierungsmassnahmen umsetzen könnte. Daraus entstanden ist die Anforderung nach einem wieder verwendbaren, vollständig elektronisch gestützten Gesamtsystem für die Verwaltung von

sowohl Kunden- als auch Wertschriftendaten, inklusive Abbildung der entsprechenden Handelsprozesse. Die Wirtschaftlichkeitsrechnung basiert auf der Grundidee einer Investition in eine bedarfsgerechte Systementwicklung zugunsten des Wegfalls wiederkehrender hoher Personalkosten. Mit der technischen Konzeption dieses Systems wurde der Autor beauftragt.

1.3 Fragestellung

Vor dem geschilderten Hintergrund des heute betriebswirtschaftlich suboptimalen Prozesses des Wertpapierhandels bei kleinen bis mittelgrossen Vermögensverwaltern lautet die Kernfrage der vorliegenden Arbeit:

Ist es möglich, den gesamten Prozess des Wertportfoliohandels so zu gestalten, dass er vollständig elektronisch abgewickelt werden kann, und welches sind die betrieblichen und softwaretechnischen Voraussetzungen hierfür? Im Einzelnen sind demnach die folgenden Detailfragen zu klären:

1. Wie sieht der betriebliche Prozess exemplarisch aus, der einen vollständig elektronischen Handel ermöglicht, und welche Organisationseinheiten sind in der Praxis davon betroffen?

2. Welche normativen Rahmenbedingungen und Standards sind dabei zu beachten?

3. Welche Systemanforderungen sind an eine Branchensoftware zu stellen, um als integrale Prozessunterstützung den elektronischen Handel ermöglichen zu können?

4. Welche Aspekte und Bestandteile einer Software sind für die Erfüllung der Kernfrage von besonderer Relevanz, und wie können diese in der Praxis wirtschaftlich umgesetzt werden?

5. Wie kann bzw. sollte eine entsprechende Software-Architektur gestaltet werden, und auf welche Architekturaspekte ist beim Entwurf besonders zu achten?

6. Welches sind die zentralen Software-Komponenten und wie sollten diese gestaltet werden?

1.4 Ziele der Arbeit

1.4.1 Sachziele

Ableitend von den zuvor formulierten Fragen werden in der vorliegenden Arbeit zwei Hauptziele verfolgt, die einerseits auf die betriebswirtschaftliche und anderseits auf die software-technische Komponente der vorliegenden Problemstellung fokussieren:

1. Gestaltung eines exemplarischen betrieblichen Prozesses, der unter den gegebenen Vorraussetzungen eine vollständig elektronische Abwicklung der Verwaltung und des Handels von Wertpapieren bzw. Wertpapierportfolios ermöglicht.

2. Gestaltung einer exemplarischen Software-Architektur und eines entsprechenden System-Designs, welche die Grundlage zur technischen Realisierung eines auf dem definierten Prozess basierenden Softwaresystems darstellen.

Durch die Erreichung dieser beiden Zielsetzungen - so lautet die Annahme - wird für die avisierte Zielgruppe der Kernnutzen erlangt: Die möglichst vollständig elektronifizierte und automatisierte Abwicklung des Wertpapierhandels und dadurch Effizienzsteigerungen und Einsparungen um Grössenordnungen.

Als weiterer Nutzen sollen die Ergebnisse dieser Arbeit als Grundlage eines nachfolgenden technischen Realisierungskonzepts seitens des Auftraggebers dienen. Im Verlauf der Arbeit werden

deshalb spezifischere Projekt- und Systemziele definiert, die sich obigen Globalzielen unterordnen bzw. diese weiter verfeinern.

1.4.2 Persönliche Lernziele

Neben den beschriebenen Sachzielen verfolgt der Autor mit dieser Arbeit auch individuelle Lernziele zu Themen, die im Rahmen des absolvierten Masterstudiums nicht oder nur oberflächlich behandelt wurden. Diesen Zielen soll ebenfalls ein beachtlicher Stellenwert zukommen:

1. Aneignen von Grundkenntnissen und ersten Anwendungserfahrungen mit der Hermes-Projektführungsmethodik, sowie Beurteilung derer Vor- und Nachteile.

2. Anwendung, Zusammenfassung und Vertiefung der bisherigen Erkenntnisse des Autors im Bereich Softwarearchitektur, einer in der praktischen Entwicklung von Systemen einer gewissen Grösse unverzichtbaren Disziplin eines Softwareentwicklers.

3. Vertiefung und praktische Anwendung der Kenntnisse in OOAD- und UML-Modellierung.

1.5 Ansatz- und Schwerpunkte

1.5.1 Inhaltliche Themenschwerpunkte

Aufgrund der grossen Tragweite der beschriebenen Thematik ist eine Konzentration und damit Beschränkung auf bestimmte Teilaspekte des Problemfelds im Rahmen der vorliegenden Arbeit unausweichlich. Im Nachstehenden sollen daher folgende Schwerpunkte vertieft behandelt werden:

- Fokus auf die Optimierung des Kernprozesses „Handel“ („Asset Trading“): Ist Soll-Zustand.

- Erarbeitung der zentralen Projekt- und System-Anforderungen für die geplante Softwarelösung. Der Fokus liegt dabei auf den fachlichen bzw. funktionalen Anforderungen.

- Entwicklung einer exemplarischen, technikneutralen Software-Architektur als zentrales Mittel zur skalierbaren elektronischen Umsetzung des Handelsprozesses.

- Erörterung ausgewählter Aspekte des System- bzw. Software-Designs, welchen - als Verfeinerung der Architektur - für die technische Umsetzung im Themenbereich zentrale Bedeutung zukommt.

1.5.2 Ansatz

Grundsätzlich verfolgt der Autor den Ansatz, ein marktorientiertes Problemfeld wie das oben beschriebene einerseits mittels Optimierung der betrieblichen Prozesse und anderseits durch die Bereitstellung einer adäquaten IT- bzw. Softwareunterstützung zu behandeln. Im allgemeinen Fall schliesst dies die Evaluation bestehender IT-Lösungen mit ein (Marktanalyse). Dies ist auch im vorliegenden Fall geschehen, soll allerdings nicht den Schwerpunkt der Arbeit bilden; da sich beim Evaluationsverfahren gezeigt hat, dass praktisch keine nutzbringenden Produkte auf dem Schweizer Markt angeboten werden, wird im Folgenden auf die Entwicklung einer neuen Software fokussiert. Entsprechend dieser Ausrichtung wird ein projektorientierter Ansatz in mehreren Phasen gewählt. Die methodischen Details werden in Kapitel 3 erläutert.

Bei der Abbildung der technischen Voraussetzung und Konzepte wird ein objekt- und komponentenorientierter Ansatz gewählt. Betriebliche Prozesse werden in Form von funktionsübergreifenden Flussdiagrammen dargestellt. Zur Veranschaulichung von technischen Strukturen und Abläufen innerhalb von System-Architektur und -Design kommt UML (Unified Modelling Language) zum Einsatz. Datenmodelle werden als ERD (Entity Relationship Diagram) dargestellt. Alle Illustrationen werden durch textliche Beschreibungen ergänzt.

1.5.3 Abgrenzung

Sämtliche angestellten Überlegungen bis ins Detail zu beschreiben, würde den Rahmen dieser Arbeit sprengen. Dieses Dokument soll stattdessen ergebnisorientiert sein. Das heisst, dass der Schwerpunkt der nachfolgenden Darlegungen auf den Resultaten der einzelnen Projektphasen liegt, welche ihrerseits jeweils Basis für die folgenden, darauf aufbauenden Phasen dienen. Konzeptionelle Alternativen und Hintergrundgedanken werden aus diesem Grunde nur aufgeführt, insofern sie für den Gesamtzusammenhang der Erläuterungen in dieser Arbeit erforderlich sind.

1.5.3.1 Thematische Abgrenzung

Im Rahmen dieser Arbeit erfolgt eine Konzentration auf den Kernprozess „Handel“ (den Wertpapierhandel im engeren Sinne), welcher das zentrale und damit entscheidende Element des untersuchten Geschäftsbereichs darstellt. Umliegende Prozesse und Themenbereiche werden nur erläutert, soweit für die Zweckerfüllung und das Verständnis des Gesamtsystems erforderlich. Bezüglich der Konzipierung und Realisierung des Systems interessieren vorwiegend die anwendungsbezogenen, aber technikneutralen Aspekte. Auf spezifische Technologien, Implementierungen, Protokolle oder Frameworks wird daher höchstens peripher eingegangen. Allerdings besteht der Anspruch, das nachfolgend geschilderte Vorgehen dergestalt zu konzipieren, dass es ohne Weiteres auf die restlichen Bereiche des Gesamtsystems übertragbar ist. Insofern erfolgt in der abschliessenden Diskussion auch eine Überprüfung der Tauglichkeit der verwendeten Methoden und Ansätze.

1.5.3.2 Organisatorische Abgrenzung

Die Grundlagen dieser Arbeit werden durch den Autor im Rahmen der zeitlich begrenzten Masterarbeit als Einzelleistung erbracht. Drittleistungen fliessen in Form von Basisliteratur sowie administrativen Hilfsarbeiten (wie etwa Korrekturlesen) ein.

1.5.3.3 Fachliche Abgrenzung

Da der Autor selber über keine einschlägige Branchenerfahrung im behandelten Themenfeld verfügt, wird ihm das Wissen aus der praktischen Geschäftstätigkeit des Auftraggebers zur Verfügung gestellt, ergänzend wird Branchenliteratur beigezogen.

Entsprechend erhebt diese Arbeit keinen Anspruch auf hundertprozentige fachliche Korrektheit und Vollständigkeit, legt ihren Schwergewicht stattdessen auf die praxisorientierte Methodik, welche themen- und branchenneutral sein soll.

1.5.3.4 Markttechnische Abgrenzung

Im Vorfeld der hier aufgeführten konzeptionellen Überlegungen wurde vom Auftraggeber ein Vorprojekt durchgeführt, dessen Thema einerseits eine Prozessanalyse eines konkreten Branchenvertreters im Sinne einer Fallstudie und anderseits eine Kurzevaluation der bestehenden Systeme auf dem Markt war. Die entsprechenden Ergebnisse liegen dieser Arbeit zugrunde und werden, soweit für das Verständnis erforderlich, an der jeweiligen Stelle zusammengefasst dargestellt.

1.5.3.5 Methodische Abgrenzung

Als genereller methodischer Rahmen gilt Projektmanagement nach Hermes, dazu kommen bekannte Analyse- und Designmethoden. Detaillierte methodische Ausführungen hierzu folgen in Kapitel 3.

1.6 Überblick über die vorliegende Arbeit

Im Verlauf der vorliegenden Arbeit wird auf die zuvor definierten Ziele und Fragen eingegangen, wobei der Fokus auf einer exemplarischen Erläuterung der jeweils als besonders relevant erachteten Aspekte liegt.

Die Kapitel 2 und 3 erläutern die verwendeten Grundlagen, Branchenstandards und Methoden, bevor in Kapitel 4 die zentralen Anforderungen an ein entsprechendes IT-System erarbeitet werden, während sich die Kapitel 5 und 6 der architektonischen und designtechnischen Ausprägungen einer Software, welche diesen Anforderungen gerecht werden soll, widmen. Da im Rahmen des Masterstudiums der Bereich Softwarearchitektur nur gestreift wurde, soll die theoretische Betrachtung dieser wichtigen Disziplin sowie deren praktische Anwendung in Kapitel 5 etwas ausführlicher gestaltet werden. Zuvor wird die durchgeführte Fertigproduktevaluation kurz dargestellt. Abschliessend werden in Kapitel 7 die gewonnenen Erkenntnisse in Bezug auf die Fragestellung validiert und diskutiert, um Rückschlüsse und konzeptuelle Verbesserungen hinsichtlich der nachfolgenden technischen Realisierung sowie zukünftiger Arbeiten zu ermöglichen.

2 Grundlagen

Dieses Kapitel erläutert die zentralen Fachbegriffe und Standards, welche für das Verständnis und die weiterführende Auseinandersetzung mit der behandelten Problemstellung von Bedeutung sind. Da zum Erstellungszeitpunkt dieser Arbeit keine Modelle oder Forschungsarbeiten zum Untersuchungsfeld vorliegen, werden hier auch keine entsprechenden Unterkapitel eingeführt.

2.1 Begriffe

2.1.1 Fachterminologie

Die Finanzbranche hat eine kaum mehr überschaubare Anzahl an Fachbegriffen hervorgebracht, von denen in dieser Arbeit der Verständlichkeit halber nur ein kleiner Bruchteil verwendet wird - im Wissen, dass dadurch gewisse fachliche Unschärfen in Kauf genommen werden müssen. Untenstehend eine Aufführung der zentralen Fachwörter dieser Arbeit. Die Definitionen lehnen sich an das sehr umfassende, aber dennoch nicht vollständige Online-Bankfachwörterbuch der UBS an (siehe UBS 2008, online). Technische Begriffe werden jeweils bei ihrer einführenden Verwendung definiert und sind daher hier nicht aufgeführt.

Bank Finanzinstitut, das im rechtlichen Sinne Bankgeschäfte betreibt und im Rahmen des Wertpapierhandels als durchführende Instanz fungiert. Bankberater Natürliche Person, die als Angestellter einer bestimmten Bank für die bankseitige Betreuung eines Kundendepots zuständig ist. Bankkonto Von der Bank für ihre Kunden geführte Rechnung über alle ein- und ausgehenden Zahlungen (Transaktionen bzw. Buchungen). Börsenmakler

Broker Synonym von Börsenmakler. Buchung Die einzelne Transaktion, die zu einer Veränderung des Saldos eines bestimmten Kontos führt (Saldo-Betrag).